Joining a new engineering team
Jun 24, 2019 · 6 min readThis post aims to cover off a simple checklist 📝 to work through when joining a new engineering team 👩🏾💻👨💻. Whilst this is aimed at senior or technical lead positions, these tips can help everyone.
I’ve recently switched teams at work, and something dawned on me. Over the last 8 or so years I’ve generally built teams, and not really joined an existing team. So joining an existing team, with their own established ways of working, and existing decisions is something rather 👽 to me. This is also the first time, in the same period, where I am the only remote engineer on the team 😬.
So, here are some tips, in no specific order.
Get to know the people
Whether you know the people from a distance, or have no knowledge whatsoever, I recommend you engage with the team early. Get to know their personal traits, strengths, weaknesses, likes, and dislikes.
Also try to understand if certain tasks are owned by certain people. I personally like to work on all aspects of the team, it doesn’t really matter to me what it is: development, testing, documentation, process etc. So if I actively engage in testing for example, is this going to upset someone. You have to try to understand this relatively quickly. If it is going to upset someone, what’s the plan? I suspect honesty from you, and respect of others, is the place to start.
Read the documentation
Hopefully the team you are joining are ✒️ documenters 🖋. If they are, read all the things. My tip is to scan for important stuff, then gradually over the course of a couple of weeks, double back and re-read the docs in greater detail each time.
...read all the things.
If the team are not documenters, add this to your list of items to discuss at the next team meeting or retrospective. Leading by example here is going to be a good idea. If you start to document as you onboard into the team, hopefully the team start to see this and follow suit.
Which leads me to..
Keep a list of actions
It’s time to see this from the other side. What is it like for existing team members when a newbie joins. How is your personality going to impact the team. I’m energetic, active, chatty 📣, and like to get things done. I am remote, meaning that my main communication channel is Slack, or some form of online communication. I like to question all the things so I understand not only what is happening, but how we got there. History of a team is important (to some extent).
Now imagine someone like me joining a quiet(ish) team. If I bombard the team with question after question, it’s going to be overwhelming for them, and I’m likely to cripple velocity whilst I onboard. Whilst this is likely to happen, we don’t want to make it excessively worse.
It's time to see this from the other side.
So I keep a list, and try to ask the big key questions first, and drip feed questions over the course of the first couple of weeks. Try and understand early what the key communication channels are for Q&A like this: Email, team meetings, Slack, start of day calls, retrospectives, adhoc etc.
When I get the answers, I update the team documentation, so hopefully the next person can benefit too.
Over time, this secret checklist you have locally, needs to make its way to the team backlog and become team based work. For example if some code review or build processes need to change, this is not just on you, but the team. There also needs to be rationale for the change.
Code review process
Code reviews, I love them. I love the participation and discussion that happens (hopefully it’s happening in your new team 🤞). It is also the front door into your new codebase, make sure it’s secure 🔒. You don’t want a front door, back door, and cat flap where work gets through.
Understanding and quickly engaging in the code review process is either going to make you warm and fuzzy, or is going to generate tasks on your task list (see above).
Are standards clearly documented? Are automated tools helping? Are you all using the same tools? Are obvious trigger issues already resolved (tabs vs spaces, how many spaces, all that stuff).
Communication channels
What are the team communication channels? What’s the dynamic. If you are the only remote engineer joining a co-located team, the communication channels are going to be geared towards face to face. How are you going to deal with that? You don’t want to stamp your brand on the existing team (they were here first), but you also need to be embraced for this to be a fruitful relationship.
I don’t want to turn this into a “remote engineering” post, but advocate for “remote first”, and all that entails if you are a remote engineer. A remote first approach also helps co-located teams: asynchronous communication and decision making, self documenting due to the nature of the tools being used, better for all members who need to work from home from time to time. It doesn’t matter where you are, as the process works. It’s also very good for business continuity planning.
Testing processes
Another first for me. This is the first time I have been in a team since Plusnet, where I have a specific test engineer in my team. But you know what? It shouldn’t matter, you still need to understand the processes/tooling and get it all running. I am a massive advocate of all engineers picking up all work. There should be no single points of failure in an engineering team. This means you should pick the next item on the backlog, irrelevant of the flavour of work.
There should be no single points of failure in an engineering team.
Build and release processes
This is a personal favourite of mine. I’m a massive build/CI/CD/automation nut, so when I learnt my new team was using CodeBuild and CodePipeline there was lots to learn. I’ve been a Jenkins kinda dev for years and years, even when it was Hudson. I can understand why folks want to use CodeBuild/Pipeline, but wow, Jenkins is so much more powerful and feature rich.
Anyway (massively side tracked there), understand all the details of the build process. This is how you ship your apps/services, so understanding it is crucial.
It’s good to reflect
I have this weird thing I do, which I was reminded of at work last week. The documentation I keep when leading teams is versioned based on my team number. Each time a new person joins or leaves a team I am leading on, I bump the version number. You can see the engineer in me here right. This is a natural time to reflect as an existing team member on processes, ways of working, and previous decisions. Do not be precious over your past, be open to change (this is something I have faltered on over the years).
Do not be precious over your past
That’s a full lid
As CJ Cregg would say, that’s a full lid. I’m going to update this post as and when new tips/tricks and ideas crop up.
Enjoy your new team folks.
💃🏿🕺🏿