I haven’t been posting much the last month or so and there is a pretty good reason for that. When I started back at work in January, I started back on a different team. I had been on the Web Team at the Economist for four and a half years so I was very familiar with the work involved. If someone had a problem with the website, I was usually able to debug it and help resolve it or if not, find the right people who could. I had spent a lot of time digging deep into the codebase and I know a big chunk of it like the back of my hand. I absolutely love the people on my old team - they made coming to work every day a lot of fun and we grew a lot together in the time I was there.

Even so, it definitely felt like it was time for a change - a new technical challenge and a new opportunity to grow for me. So when I was offered a spot as Tech Lead on the eCommerce team to learn about payments and subscriptions, I jumped at the chance. I wanted to write a bit about my experiences and provide a few tips for people who are in a similar position, but these tips will also work for anyone starting a new job, because moving teams is not that dissimilar an experience, in my opinion. Let’s dive right in!

Tip 1: ask questions, even if it feels icky

Moving teams has essentially been like starting a new job for me, except there was an expectation that I’d already have a lot of context. This is not untrue, I did, but sometimes it felt a little bit like I was supposed to know everything already, which I most certainly did not! Or perhaps that was just the pressure I was putting on myself. I have been trying hard to overcome this feeling and ask questions anyway, even if they feel like they might be simple and potentially annoying to the team. There has been a pretty consistent train of thought in the back of my head of “you are a Staff Engineer - everyone is going to think you’re ridiculous for not knowing this”, but I am well aware that this is my inner critic trying its best to protect me. It doesn’t matter what your role is - if you are new to the team, there is simply going to be stuff that you don’t know, because the work of an engineering team is often highly domain-specific. Luckily, everyone on my new team has been super lovely and willing to help answer my questions and I even had some feedback that some of my questions helped clear up a bit of confusion. Essentially, there are no “stupid” questions and in a company with a solid engineering culture, asking a question that is perceived as basic or simple should not reflect poorly on you. In addition, someone else on the team may have been wondering about the exact same thing, so you may be clearing something up for them while you’re at it.

Tip 2: ask why, don’t make assumptions

This one still catches me out sometimes. We all make assumptions, because we’re human and it’s natural, but I would urge you to try not to if at all possible. Rather than assuming that something was done for a particular reason or a decision was made without much deliberation, ask why something was done a certain way. This will give you a lot more context and help you learn about your new team’s ways of working as well as making sure no one thinks you are being negative about their approach, which can get people’s backs up. There are always going to be things that can’t be done in the absolute “perfect” way that you’d like them to be done because there simply isn’t time or capacity or a third party needed an integration to be done in a certain way or countless other reasons that crop up in the day-to-day life of a team. The added bonus here is that it may make people think about the why and consider whether it is still applicable - it may be that it was a short term fix that needs to be ported over to something more permanent and you asking the question has re-opened that conversation, resurfacing that opportunity.

Tip 3: share useful things you’ve learned

This goes both ways! Share the things that your old team was good at with your new team and share new exciting things you’re learning back across. This way, everyone grows and this can only be good for your organisation. I am very lucky to be mentoring two great engineers from my old team so I’m able to feed my experiences back this way, but there is absolutely nothing stopping you from sending a Slack/Teams/whatever message to your old team just to ask how everyone is doing (I did this a few days ago!) or post in their channel about something you’ve just found out that they could do with implementing too. Fostering relationships across the business is extremely important in my opinion, especially as you get more senior. You never know when those connections will serve you or others in the future and besides, it’s just nice to stay in touch and see what your old team is up to. Just because you’ve moved to another part of the company, it doesn’t mean your old team no longer exists!

Tip 4: live with it before suggesting changes

It’s very easy to get excited and come straight in with a huge list of suggestions for changes that you’d like to make to the team’s ways of working because you think it’ll improve everyone’s lives. It’s understandable - I have definitely found myself doing a bit of this because I wanted badly to prove my value and have an impact and I’ve got a lot of previous experience to share. However, just because a team does something differently, it doesn’t mean it’s not valuable to them. If you notice something that could be improved, rather than waltzing straight in and offering suggestions, maybe make a note of it and come back to it when you’ve been on the team for a while, then check whether it’s still important to you. You might find that the way things are done make more sense once you’ve been on the team for a bit and if not, you can still suggest the improvements a bit later down the line. By then, you should also have more of a handle on how busy the team is, meaning that you can be more conscious about not overloading them while they’re already busy.

Tip 5: document, document, document

As a fresh pair of eyes on a codebase that the rest of the team may have been working on for years, you will inevitably spot things that are out of date or undocumented. So go ahead and submit changes to documentation when you find discrepancies and add new documentation for things you have learned while onboarding. You might as well, because it’ll come in handy for the next person who joins the team after you. In my case, someone else joined the team a few weeks after I did and because I’d updated the setup instructions in the README, they were able to get up and running even faster than I had. I know there is often a feeling among engineers that documentation is hard to keep up-to-date and not super worth it, but I would wholeheartedly disagree (I’ll have to write a post about it at some point because I feel quite passionate about this). Writing things down means that when someone new comes into the team, they have a wealth of information to consult and you can just point them at the relevant bits to get them up to speed. It gives the new joiner agency and makes them feel good about getting things set up quickly and without much trouble. Joining a new team is a great opportunity to keep all that documentation nice and fresh and make sure other folks learn from your previous experiences.

Lastly: have fun!

This is a bit of a bonus tip and it’s all about getting to know your team as people, not just colleagues. If your team does any social stuff, join in. Chat to folks at the start of standup or other meetings. Post a funny GIF or use a silly emoji reaction just because it’ll make people smile. Maybe this is just me, but I feel like work becomes significantly more rewarding if I invest in getting to know the people I’m working with. It helps me see things from their perspective and have empathy and compassion, which is something I strive for as an engineering leader.

Alright, those were my tips! Do you think I missed anything important? Anything you agree or disagree with? Let me know in the comments!