How to approach first days on a new job as a senior engineer?

Context: I was an early strategic technical hire by a director/manager/CTO 3 times to help execute process changes and lead new initiatives healthcare SaaS companies between 2014-2020 and then started working in strategic cloud consulting since then where I am brought in to get developer, operations and the “business” to be better aligned and/or to lead new initiatives.

I’m currently a “staff software architect” at a 3rd party cloud consulting company.

What not to do:

1. Disrespect current processes. What you call “legacy code” was done for a reason, is generating revenue, solving real world problems, and the reason you have a job

2. Make any suggestions about improving processes before you have been their at least 90 days and understand why the current system is like it is.

3. Suggest rewriting something or introducing new to the company technology until you have worked there 90 days. Especially don’t start doing resume driven development.

What to do:

1. Set up a meeting with sales and ask them to “sale you the value proposition of the product as if you are the customer”. Ask questions as if you were a potential customs and raise objections to the product as if you were customer. Sales is usually very good at answering those questions.

2. Talk to your manager and ask what are their 90 day and 1 year plans for your team and make sure your work is aligned with the goals.

3. Get to know the pecking order. The org chart will not show you who has the most influence in your department.

4. Setup “getting to know you” 1-1’s. What are people working on? What do they want to be working on? What are their biggest pain points? What would they improve if they had a magic wand?

5. Pick up small stories, bugs to get familiar with the development process.

6. Learn about pre-wiring a meeting when you are trying to suggest changes. Do a POC, talk to the person who might have the biggest objection or has the most influence and work collaboratively to address their objectives. Keep doing that for more people on your team. It helps get more people on your side.

ADKAR change management model

https://www.prosci.com/methodology/adkar

Keep lab notes! I keep detailed daily notes of what I've learned, code I've run, what my todo list is, etc. in markdown. Getting in the daily habit helps you not go "eh I don't need notes for this" and is a GODSEND come review time when you need to write a self eval.

When I onboarded at a larger (10k people) company, I asked my manager for people who did a similar role to me across the company and asked for a fifteen minute time slot on their calendar to ask about how they work, what they thought was vital for me to learn or would be an accelerant to my onboarding, any tips or tricks for working with the company or our tools, and other people they thought would have good answers for those questions, and then rinse and repeat for that new list of people. I ended up doing ten interviews in my first two weeks, published a little internal blog post about common themes and what I learned, and that helped shape a lot about how I worked. Not to mention that type of proactivity in and of itself impressed a lot of people; doing things for clout is dumb but making things you learn public and synthesizing them into a form that's accessible to others is an important hallmark of a senior in my opinion.

Ask SO many questions. Got opaque docs that are important? Ask for a quick meeting with the person who wrote them to make sure your understanding is crystal clear. Abandoning ego and being a knowledge sponge makes such a huge difference.

This is a pretty low-level mechanical thing, but your first day/week is the best time to do it...

Almost every time I join a company/project, they don't have even remotely accurate docs about how to set up a development environment (configure workstation with prerequisites, check out the code, run the code).

If they already have a wiki page you can start editing, great. If they have a wiki without such a page, great. If they're open to having this info in the README.md of the repo, great.

Document everything you have to do, which the next hire probably will have to. (Example: Don't have some credential or authorization to access the repo? Ask around for how to get it, someone tells you that you go ask person X? Document who someone should ask if they don't have that thing.)

If you're not sure whether you'll be stepping on toes, make the notes in a file in your home dir, as you're going through it, and later ask someone about whether it'd be helpful to new hires to put it in the wiki/repo/etc.

I'd say pay very close attention to who does what, literally write it down, what people say they do, what you observe them doing. Try to make no impact, as close to zero as possible. Two weeks later try again to assess who does what. Does it agree. Who changed? Why do you think something is different, why did some things stay the same? Repeat. You will naturally come into contact with most important people trying to get access to everything, where does it go fast, where does it go slow? Who didn't you come in contact with? Who gives bad information? Who gives useless information? Who gives good information, where is their source? Now based on that information you can try to suss out the overall dynamic and form a theory of impact. What are you trying to impact? Do you want to do the things you apparently need to do to make that impact? What is your exit plan if you find yourself in bad positions? What kind of bad positions can you imagine being put in, how do you today wish to see yourself handle it?

My point is that I rarely don't regret (for my careers sake) jumping in and delivering (obvious to me heh heh) value right away because I see the code I see where it ought to be and the new boss is really eager to see somethin, but I'm steamrolling toes and throwing elbows in eyes that I was entirely unaware of. I guarantee the people you will work with do not see you as a senior for some time, any misstep is a case against your status, its better to move slowly and thoughtfully with regard to politics than try to lightning strike some progress in the hopes it gets noticed 3 levels above you (they don't give one shit you already shot your wad can you do it again? and again? and again?)

It is surprising that this still happens, but I’ve had senior engineers (L6-L7 from FAANG) join my teams (multiple examples, different companies) and in the first couple days make extremely superficial but strong arguments on how the architecture of a system should be completely revisited, and how libraries that have been in production for years should just be rewritten from scratch asap.

In virtually all cases the suggestion was extremely naive and coming from a lack of understanding of all the requirements. This did not come from a curious angle “wondering if we could do X?”, it was always based on some ground truth they knew better.

Very calmly, you start explaining to them all the key requirements that they just missed in their grand vision. Upon hearing those, some will decide to double down and come up, on the spot, with increasingly complex and arcane evolutions of their initial proposal (this is always very comical, and painful to witness), while others will quickly get the message and basically say “oh sorry, seems like I lack a lot of context, please ignore”.

And let’s not even talk about their first code reviews.

I truly don’t know what goes in someone’s head when they decide, shortly after joining, to dismiss years of work of a competent team who has objectively solved problems for the business.

My experience is limited to technical teams in technology companies (primarily CA Bay Area based), as such what I've experienced and learned may not be as applicable to what you're getting into. That said, there are some common things I've noticed, and one is that 'new senior guy' is a disadvantageous position to start in. Generally due to the competitive nature of such places there are others in the team who probably feel they would have been a better choice to fill your new role.

Listen a lot, keep a notebook, don't go in with the idea that you are going to make the product better, go in with the idea that you're trying to find ways to make the team better at making product.

Sometimes that takes mentoring, sometimes that takes technical leadership, sometimes that takes being the person who can help others see each other's perspective.

Be really clear with your manager about what you learn your evaluation of the current situation and look for and listen to feedback to gauge your discernment accuracy.

Always ask people you meet what could you help them with, what would make it easier for them to accomplish what they are trying to accomplish.

Finally, take time to do things that a 'junior engineer' would do as part of the program of helping. People will want to know you can work at all levels and that you aren't just some 'high level thinker' who doesn't understand how things really work.

I have always advised new senior engineer hires, even though you're senior you are going to have to go through your entire career in speed run mode it seems at the new place so that people understand how you got to be senior.

Something that has always been really appreciated, and can be an easy "first commit": update/complete the docs. There's always a missing step, something unclear, an outdated link, and undocumented "whys", something to automate, ...

When you've just joined from outside, you're in a unique position in that you haven't internalised yet all the little idiosyncrasies. Best to take note of them, understand the context, and maybe help change them.

Figure out the core technologies they use and become an expert at them. Read the documentation of those technologies like a book. Is kafka at the heart of the stack? Learn everything related to kafka and setup a small dummy instance to play around with. This can take some time but after a couple of months you'll be more knowledgeable about the technology than many people on the team who have been there longer.

Assuming not management track:

- Make a token commit day 1 or 2 to show you can and will deliver, even if just docs. Ensure you can go end-to-end on a real code PR week 1, even if a trivial one. Identify which area of code is most important for you to learn, vs not learn, and focus there.

- Get agreement on week 1 / month 1 / q1 goal for you+team+co with your direct peers, manager, skip level. Assuming a startup, also with CEO. Meet associated peers, like if an eng mang, other eng manga, and if a startup, head of X, Y, Z.

- Learn the business & product, eg, use it + shadow sales/marketing meetings.

- Observe culture and start acting: your first 30-90d is when you can make some changes by power and set tone, but doing any in weeks 1-2 are generally presumptuous as means you don't care about existing people & their earned & lived experienced. Change depends on seniority, eg, less senior can mean just adding better linting.

I’ve always treated my first days on any job as “my job is to make the (inevitably outdated) onboarding docs as good as possible.” That way you can contribute from day one, and you hopefully lower the rope ladder some for the next new hire.

Dig in to learn the details of how your systems and software work, do this by getting local dev resources set up, reading docs/diagrams, etc.

Start to get to know people, and focus on learning about them and what they do.

Don't start immediately dispensing wisdom / advice / opinions unless asked, take time to really understand what has come before you.

At the same time, be helpful to build rapport, if you see someone more junior post a trivial problem on Slack (ie: "getting this error in Docker..") then jump in to help.

Take notes, and make onboarding better for the next person. Are the onboarding docs unclear? is setting up a dev-env the first time somewhat convoluted? Make meaningful and appreciated improvements.

Learn about the product, the customer experience, and be a user of the product to the best of your ability. Make contact with customer support folks as well to learn more about their jobs, pain points they see, etc.

Go in, set up your laptop. Take notes, update the welcome docs, and provide it to the team to consider merging in. Don't go in trying to change everything on day 1. Listen. Provide useful advice. Start providing value. Meet everyone, and understand how they like to work and be managed. Do you need to manage up? Down?

I'm starting as a Staff SDE at a new company next week, and this is roughly my onboarding plan:

1. Meet a lot of people through 1:1s, both from tech, leadership and customer side.

2. Get the codebase working on my machine, document anything that's missing from the docs they already have.

3. Ask questions in the open - in a team Slack rather than DM'ing people. Everyone can learn from my questions, and in a team Slack it'll be searchable.

4. Understand from my lead (director) on what the short and long-term goals of the org are. And then talk to others to see how they fit with that story :)

5. Ask about what the role expectations are, how they do performance evaluations, etc etc. I'll ask this to my manager and peers to get a better view.

---

There's probably more that I'll do once I actually start, but this is the quick list of what came to mind.

Run the code base through Gource. It will give you a visual on the history of the project and where all the time is being spent. This video is cool to show management.

Make sure you understand the business problem.

Document your pain points for the next person. Document, don’t just learn, and share it with your team.

Actually a good book: https://www.amazon.ca/First-Days-Updated-Expanded-Strategies...

Just joined a new team as a senior dev last fall and went through this. I simply worked my ass off the first couple of months and asked a lot of questions and banged out some very high quality initial commits to make a strong first impression. Have a zen mind/open mind, things will be different and you may not care for some of the approaches taken. Play the long game and gradually make suggestions and changes as you get to know the landscape. My initial feedback from management was very positive, so this approach worked for me.

There was a discussion about 8 months ago about a "wtf" journal and all of the things that need to be considered about current processes and team dynamics before you start making big (and effective) waves. A lot of the points are already made in the replies here, but it was a good discussion and article you may be interested in:

https://news.ycombinator.com/item?id=40078106

Try and talk to the other seniors? Last time I joined (fully remote) I asked all the other seniors for a 1 to 1 - not all replied but I learnt a huge amount about past projects, what people would have done differently and where the pain points were. Meant I could get a jump on the issues rather than find out slowly. You also get a sense of the weather and who you can vibe with. Oh yeah, taking notes about everything!

In a senior role, you'll spend more time working with people who aren't developers. PMs, designers, managers, etc. In your first few weeks, book a little bit of time to meet them. They'll appreciate the forwardness, you'll quickly expand your network in the company, and it can be the start of a good working relationship that pays off 3-6 months later.

Building a reputation is important. Can you make a contribution immediately? I was pulled into a firefight where the biz folks were micromanaging the tech folks with twice-daily meetings, with little progress being made. Two or three obvious and immediate fixes later I was able to cut the meetings back to daily and after a few more to weekly.

The optimal strategy was pretty well-documented[0] back in 2016 (nsfw warning: language, humor, mistreatment of eggs)

[0] https://medium.com/feature-creep/the-software-engineer-s-gui...

Set up your dev environment and get the project running locally. This can take anywhere from 2-3 hours to a week. But if it does take towards the longer end of that period, you will have learned tons about the application's architecture, past design decisions, and will probably have made at least 1 git commit to a README somewhere.

To add to what others have said, I would ask every person in my team what's the most important think I need to know.

#1 Listen #2 Listen More and be patient. #3 Resist the urge to fix things that aren't broken. It may not be the way you would do it but recognize this as an opportunity for you to learn. #4 If you do items 1, 2, and 3 you will see where you have an opportunity to contribute constructively.

You're going to enter a complex political environment that has developed over years.

Start humble, ask questions, don't alienate anyone, set up 1:1s with lots of people where you ask them for their perspective and advice. Listen listen listen.

Figure out who might be threatened by you and earn their trust.

I observe what the company is doing, and from there deduce what needs to be done. Then I execute.

Like any new job in which you are unaware of the context or politics; with your mouth shut.

Listen more than you speak.

Don't be afraid to ask. They know, you know, everyone knows what a release is supposed to be in theory but only _they_ know how _they_ do it.

spectacular anti-patterns -- grandiose "accomplishments" ; bullying peers and coddling weak subordinates ; splashy, attention-getting cubicle changes ; attention-seeking past war stories ; incessant industry name-dropping ..

apparently from the San Francisco dot-com rush culture?