As part of an interview process I was asked to put together the rough shape of what I planned to do in my first 90 days in the Engineering Manager role. It felt like a great time to put my thoughts publicly - firstly because it would make it easier for me to find in the future, and secondly because I’d love to do a follow up post with how my plans went when/if I actually get to put them into action.

I will say that I haven’t changed jobs in almost 8 years(!), so what I’ve got here is framed deeply within my experience in one company. Though the company changed massively over those years, and I’d like to think that there are plenty of transferable lessons for me to put into place elsewhere.

What I’m generally looking out for

• Psychological safety. Who isn’t comfortable sharing their opinion? What might be stopping them from doing so?
• Motivation. Who is struggling to feel motivated? What’s missing for them to feel motivated?
• Developer time. Are there any specific bugs or process sticking points that are taking up more developer time than they should? What can we change to give them more time to focus on features?
• Burnout. Is anyone at risk of burnout? What can we adjust to make their workload more manageable?
• Engagement. Is anyone disengaged from the team? What’s stopping them from engaging with others? Are people avoiding responsibility, and putting more pressure on other members of the team?
• Delivery. Are teams getting stuck as they try to deliver? Is there something I can do to smooth out the bumps and have them more consistent?
• Fun. Are people having fun? Is there anything I can do that can make people excited to come to work, and to build relationships within the business?
• Tension. Are their people who are struggling to get on with each other? What’s the history behind it, and are we able to move forward together?
• Dependence. Are we depending on a handful of people for some specific tasks? Are there ways we can share that workload? Are there any knowledge silos?
• Gatekeeping. Is there anyone overly protective of their “turf”? What can we do to ensure that everyone has a chance to take some ownership every now and then?

Month 1: Understand people and build relationships

I’ve seen a lot of leaders come into businesses and attempt to change things quite quickly. When wide reaching change is needed, this can be great, but it can also make it harder for that change to be successful. I believe there are two reasons for this. One is that they likely don’t understand the context of the organisation yet. Similar to tech debt, things can look strange until you understand why they’ve come to look the way they do. The other is that for change to be successful, you need to have buy-in, to have buy-in you need to clearly explain the “why”, and to clearly explain the “why”, you need to have a solid understanding of why the existing processes aren’t working.

Now that we’ve covered the “why”, I’ll talk a bit about the “how”.

Meet the people I’ll be working with one-on-one - people I’m leading, people in the same role as me, stakeholders, support roles for the team. Through these I’ll be trying to:

• Learn the ways that they like to work
• Set up regular one-on-ones with those I’m managing directly
• Understand their goals and how are they tracking
• Understand what they believe are the most important things for me to be focusing on
• Learn what’s been working for them and what they’d like to see change
• Anything they’ve been working on that they’d like a bit of extra support on

Build an understanding of the product. You generally get a decent understanding of the product you’ll be working with during the interview process, but now is when the rubber meets the road. I’ll be trying to get a tour of the overarching product with someone from the team, and also to dive in more specifically to understand the area I’ll be working in the most. As someone with a technical background, I still want to be at least a little bit involved in technical things - I’m someone to bounce ideas with, support with a bit of pair programming, and very occasionally write a little bit of code if needed. I feel like this is important because it helps you to build your own understanding of the product’s processes and pain points.

Attend squad ceremonies. Depending on how deeply I need to be integrated within the squad(s) I’m working with, I plan to attend either all or a decent amount of squad ceremonies. It’s another way of building context for the ways that the team likes to work, and to support them in their day to day lives. I’ve got plenty of experience running and participating in these types of meetings, and I’m looking forward to seeing how another organisation does it.

Build an understanding of how personal performance is measured. The people I’m leading deserve to have a leader that cares about them and their growth. Each company measures this a little differently, and values slightly different skill sets. By understanding the way that the company measures people it will make sure that when I’m making suggestions for people’s goals, that I’m able to focus on the goals that will help them the most in this particular business.

Build an understanding of how team performance is measured. Identifying the automated and manual ways that a teams performance is measured. At Flick we use Multitudes which has been a great way to automate some of the measurement of teams. We use these tools to help teams understand their own performance, rather than reporting up, but I’m sure different organisations will want different levels of oversight.

Socialise! I’ve made many close friends over the years at workplaces. I love to meet new people and learn what makes them tick. What hobbies do they have? What travel do they have planned? What’s their background? Assuming there are company parties / mixers of some kind, I’d be making sure to go to those so that I can meet the people outside of my immediate bubble. Having existing relationships with people all over the business can make everything a bit smoother when you end up collaborating with them, or if there is some degree of conflict to manage in the future.

Month 2: Support, tweak, and share

At this point I believe I will have a decent understanding of the environment I’m working within, and some small changes that I think would be useful. Though I’m not looking to overextend myself too much. There is no point trying to push my own ideas when the people I’m working with likely have a bunch of great ones already.

Run a health check with the team. Health checks have proven to be a useful tool to celebrate the things that are going well, and to highlight the areas that the team believes need to change. The reason I’ve left this for later is that I believe that for these to be successful, the team needs to trust you. I feel confident that I will have enough trust by now, but if not I’ll likely delay it until next month. Our usual routine with health checks is to run a retrospective based on the low points afterwards so that we can get something more actionable to try differently. This is another chance for me to take away actions for myself to see if I can support the team better by adjusting the way I work.

Support the day-to-day. Every company needs slightly different things for a role. At this point I should have a pretty good idea of the gaps within the day-to-day team activities that need a little support. Whether that be helping to understand and plan initiatives, deal with bugs, running meetings, coordinate work between teams, prioritise work, or the many other possibilities that aren’t coming to mind right now.

Support initiatives already in motion. At this point I feel like I’ll have ideas of my own that I’d like to pursue, but what’s more important is to be supporting initiatives that others have already been working on. This reduces the amount of change that’s happening all at once, and also gives me a chance to build a deeper understanding of what it’s like to make change within the organisation, without being the one who’s “owning” it.

Share some knowledge. I’ve run a bunch of talks at Flick over the years, and I’d be seeing if any of those would be useful to transfer over into this new company. Coaching, mental health, feedback, managing stress, a grab bag of things I’ve learnt, sustainable teams, and less work-y stuff like photography. I’ve got a lot of experience as both a tech lead and a people lead, so I’d be looking to see if there is something in there too. Personally I prefer running sessions like this in environments where people can add their own experience and ideas as we go, and that works a lot better when you’ve got a bit of an existing relationship with the people you are sharing with which is why I’m leaving this for later.

Month 3: Reflect

At this stage I will likely have my hands full. Realistically, I’ll still be working on a bunch of the things above as I continue to establish myself in the team. I will have spent enough time with people that they would have valuable feedback about the ways that I work that they would like to see more and less of.

Get 360 feedback for team members. This is my way of making sure that the way I work is working for the team. I try to foster a culture of psychological safety so I hope that any big stuff would come up sooner rather than at this point, but I find that feedback in this form can help to tease out some of the longer term things that could be holding me back.

Check-ins for each of the people I lead. I like to do check-ins with the people I lead outside of the review cycle. This is a time where the feedback is lower stakes (because it’s less directly tied to pay), and it gives people a chance to make a few changes and set themselves up for a good end of year review. These are an informal format with what’s going well, what could change, and what they could try in the next few months.

Organise some fun things. I like to bring a bit of joy into the office, but I’m not sure what specifically I’d try to do at this stage. Bringing in the Switch for some Mario Kart, setting up a puzzle, organising some board games. It all depends on the feel of the office.

Reflect on the glue work I’m doing, and see if some of it can be delegated. I’ve always been lucky to work in motivated teams, with plenty of people ready to grow their skills. As an Engineering Manager you have a perfect opportunity to give people that space to grow if it’s what they are looking for. If there is a task that could be delegated, then I generally try to give people a chance to take the reins for a while to see how they do. At Flick this has come in many forms, e.g. allowing other developers in the team to plan out an epic with my help, taking turns to run meetings, getting information from stakeholders, encouraging people to give talks, and connecting people for pair programming. This can sometimes require more support than it would have been to do yourself, but you are setting the team up in a much more sustainable position.

Conclusion

This is not something I’ve been able to put into practice at a new company yet, but I’m confident that it’s flexible enough to pivot into whatever else is needed of me. I believe that all of these are useful things to do at some point, but the rate at which I end up doing them will depend on what’s important to the company when I join.

If I’m lucky I’ll be able to put this all into action at some point and write a follow up post! Even if I completely fall on my face, I’m sure I’ll come out of it with a bunch of lessons that will be worth growing through.

My email is on my About page. I’d love feedback on anything you’ve seen here.