In November 2020 Dan and Tony (that’s us!) both became Engineering Managers, moving from a Senior Engineer role to Engineering Manager 🎉. In this post, we’ll go into the highs, the lows and the learnings we’ve gathered along the way.
You now feel like a Junior
Whatever we might have felt about our past achievements in our careers, we both now felt like Junior Engineering Managers! Being completely new to the role, we were constantly involved in new experiences, situations and conversations that we’ve never had to deal with before. We didn’t have a huge amount of manager experience to draw on, meaning we couldn’t use statements like “It’s cool, we’ve dealt with plenty of situations like this before”. We found at times this made us feel uncomfortable and less confident than during our time as Senior Software Engineers.
All of this is fine! – What we realised is that none of what we’ve just said should be seen as negative. Firstly, we had to accept how we felt and importantly, share these thoughts with our own managers. Nine times out of ten, they were able to help steer us in the right direction, it’s their job after all. We found it was really important that as early as possible, we set expectations for each other. This helped to clear up any concerns we had around our decision making or contribution. Also, as a junior, we’ve found feedback is more important than ever. There were many times we left meetings and didn’t think we contributed or made an impact. What really helped us here was reaching out to people after the meeting and asking for their feedback. At times this helped to reassure and other times when they had suggestions, it gave us an opportunity to improve.
Drawing from our experience of good managers we’ve had – We may not have been Managers before, but we’ve definitely had some great inspirational managers in our past. A great exercise we did was to think about managers that have really stood out for us. What made them great? What would we want to emulate? During this reflection, our minds inevitably went to the less enjoyable experiences we might have had with managers as well. What didn’t we enjoy? How would we improve on that experience?
Take more time to plan – We needed to acknowledge the fact that things won’t come immediately to us as they did when we were engineers with many years of experience under our belt. That meant prepping thoughts and questions well in advance of a meeting or workshop so we could contribute to the level that we wanted to. Or rehearsing a conversation that we’ve never had before with a colleague.
Use it as an opportunity – There’s nothing wrong with feeling like a junior. There are a lot of opportunities and heaps of learning we will get as a junior. In our first few months, we did receive more time as our manager let us settle into the role. This gave us an opportunity for us to learn and explore new things without the full workload of a more senior Engineering Manager.
Different dynamics within the team
Before being promoted to Engineering Managers, we were both Senior Engineers at Rightmove. This meant a sudden change in the relationships with our team members, we were friends and/or colleagues and now we’re in positions of more responsibility and accountability.
Have an honest conversation – These changes in relationships are common, people get promoted and they’re now no longer peers and the important thing is to talk about these changes. We decided the first step was to speak to our teams individually and find out how they felt about the change and what it means for the team and any concerns they may have. Finding these things out early meant we could address any issues sooner rather than later.
Contracting sessions – A contracting session is a meeting where we got everyone involved in the team (product owner, engineers, designers etc.) and discuss what expectations we have for each other in those roles. This is a good opportunity to understand what the team expected from us but also clear up any unknowns or question expectations that we believed weren’t part of our role.
Pretending we’re new to the team – One of the assumptions we made was thinking we knew the issues within the team and what the priority to fix these issues should be. Needless to say, the majority was wrong and after having that first conversation with our teams we realised that there were issues we were unaware of because they were discussed privately with their previous manager or didn’t affect us in our previous role as much as it did other people. This is why if we were to do it all over again we would act like we’re walking into a brand new team and are trying to learn how the team works, what could be improved etc. That way we could come up with a plan to resolve the team’s biggest issues as opposed to what we think are the team’s biggest issues.
Context switching
Over the past year or so, we’ve found that our to-do lists have gotten much longer, with a fair bit of juggling of tasks of all shapes and sizes. To make matters tougher, we now no longer had stories and sprint events to help us keep track of our progress like when we were engineers. Also, we often find these tasks were complete context switches! Being a technical manager means switching between technical discussions about things like system architecture and production issues, to less technical chats like personal issues impacting people in your team. Here are the changes we made that have helped us with this transition.
Prioritise with the help of a To-Do list – What has really helped us with our planning is having a multi-column, kanban like setup (listed below). Everyone is different and I’m sure this setup won’t work perfectly for everyone, but one question we made sure to ask ourselves each day is: “What do I need to do today?” and then as a follow-up, “But, do I really need to do that today?”. Asking those two questions have kept us somewhat sane.
- To-Do All the Time (e.g. Have a growth mindset, Stay positive!)
- To-Do
- To-Do Today
- Done
- Ideas/Personal Development
Practice makes perfect-ish – What we’ve realised is that part of the reason that context switching is harder for us now, is that there’s just so much to learn. In our previous roles, We managed to survive on a simple one-column To-Do list because a lot of our daily tasks had become second nature. We needed to accept that over time we would will get better at context switching, but this isn’t a process that happens overnight. At some point as engineers, we both improved our context switching so that we could write code, fix one of our broken CI builds, grab a coffee, monitor an application you just deployed to production, then do a code review. We shouldn’t forget how difficult that was (and still is!)
Learning through trial and error
Over the past year, we’ve read many books, blog posts and conference talks about building great teams and being a great manager. These have definitely helped us and given us some interesting insights from the perspective of veteran managers. Having said that, the most valuable source of learning we’ve found, is doing the job. Those new situations and experiences we encountered throughout our first year were gold dust for our learning, whether they were enjoyable experiences or not. By just learning on the job we gained a lot of insight into what kind of managers we wanted to be. To make this trial and error process smoother, there were a number of techniques and thought processes that really helped us.
Taking time to reflect – Just going through the motions wasn’t enough for us. We made sure to carve out some time each day to reflect on what had happened and what we would have done differently. It then became much easier to learn, improve and actively take steps to try different approaches.
Find some sounding boards – Reflecting by ourselves did work but worked even better for us speaking to others. We’ve found the other Engineering Managers we work with a great source of advice and great as ‘rubber ducks’ as well. Speaking with different managers gave us different options and perspectives. Sometimes these opinions conflicted with each other but just knowing these options and perspectives helped to make us better managers.
Mistakes – It’s fair to say that our first year as Engineering Managers has not been mistake free. But the important thing was that we didn’t beat ourselves up about them. When we made a mistake, the best and most healthy thing we could do was to acknowledge it, do what we needed to do to rectify the mistake and then move on, taking that learning with us.
Feedback is the biggest tool in our arsenal
As managers, our success hinged on our ability to not only gather feedback but create a culture of open feedback. Without feedback, we would find it hard to not only tell if we were doing a good job, if our team meetings were going well etc. but also if our team members are doing well and are ready for promotion, if there are areas we need to coach them in etc. A good example we have is when we ran a session to reflect on ticket cycle time and how we could improve it and afterwards we felt it could have gone better but we weren’t sure how. One of our senior engineers sent a message with suggestions for the next time we run similar sessions. We took this feedback on board for the next meeting and we got feedback that it went better than the last.
How did we do this? – There is no silver bullet here. People feel comfortable giving feedback in different ways. If we’re looking for feedback from a large group (e.g. about team meetings) a form can work but sometimes people don’t like forms and if they’re someone whose opinion would offer a different insight to others, we would have to follow up with them individually.
Some people might like small talk first to put them ease or they might want to just get straight in to talking about feedback. We found that we had to adapt our approach depending on the person and that it’s ok to ask what makes them most at ease to give constructive feedback.
One-to-ones – One-to-ones are obviously a great time to ask for feedback on how they’re doing, how the team is and also how we were doing as a manager. Again the individual would determine how we would do this. Some people preferred a direct approach, some people needed some more probing questions rather than just a general ‘Do you have any feedback on the team?’ or some people liked some time to think and reflect so we would ask for feedback and they would send feedback at a later date once they have had time to gather their thoughts.
Ask for feedback regularly – One of the things we’ve tried doing after we’ve run a session is to ask people to provide feedback while it’s fresh in their minds. This provides an opportunity for people to provide feedback without having to wait for a one-to-one or a quarterly email asking for feedback and allowed us to make changes quicker. It also helped to enforce that people should be gathering feedback constantly and not rely on sending an email every now and then because their manager asked them to gather feedback. This also allowed us to get more specific feedback than ‘Yeah all good, you’re really helpful’. We also asked them about specific situations like ‘How did it come across when I said X?’, ‘Did you enjoy the new icebreaker I tried?’. This helped us gather more specific feedback about what works, what doesn’t work and how we could improve.
One final takeaway…
If there’s one thing we would tell our past selves before we started the role it would be, be kind to yourself! We just started a new role so we’re going to make a lot of mistakes but that shouldn’t stop us from trying new things. In our experience, there were plenty of people who were happy to help when we were stuck or just feeling unsure about a decision. Remember that we all have uncertainties, whether we’ve been in the role one year or twenty years.
Thanks for reading and if you are interested in reading more about our journey, this is just part one in the series so stay tuned!
