Taking the leap from Engineer to Manager is not easy. The Manager role requires a different mindset and different level of thinking. I was reminded of this when I saw my team (who were tech leads) navigate the the path to pure manager roles.
My first 6 to 12 months as a Development manager was disastrous. I was young, leading a senior team with no managerial experience. I learnt some hard lessons over the first year that I wish to share. These are the things I wish I did when I first became a Manager of a Software Engineering team.
Align on Expectations
Firstly, set down expectations of your new found role with your Manager. Ask them what they expect from you in 6 months and 12 months time just like you would when you start at a new company with a new manager. Make sure they are achievable. Be clear that you are learning the ropes.
Also clearly identify areas you need to improve or strengthen. And get some guidance from your manager on training, experience or skills you need to improve the same.
The first couple of months can be messy as a manager but setting right expectations will help you focus on the right areas.
Enable Work don’t DO Work
Your job is no longer to DO work. Your job is to optimise and enable work. This is probably one of the hardest things for an Engineer to get used to. You may feel frustrated at first where you know you could solve a problem pretty quickly, but feel tied because you have to leave the problem to the team to solve. Start thinking about problems in Culture, Process and Technologies that will help the team deliver faster and efficiently.
Remove yourself from the Critical Path
This one I learnt the hard way. Second year on the job as a manager I decided to help out the team on a delayed initiative by cutting some code. I thought I was helping out. But I realised quickly it was a mistake:
- I no longer understood the platform any more. It had changed significantly since I last touched it.
- Due to the above I took shortcuts and caused a mess
- Because my capacity was not accounted Squad velocity was skewed
- Due to the aforementioned problem QA did not have capacity to test my code
- And the domino effect continued to Delivery and pushing back timelines
As a result I derailed the project more than helping.
I’m not saying don’t code. What I’m saying is choose the initiatives that you code on very carefully. I decided later that I would only delve into Engineering Enablement and POCs that were NOT on the critical path. Use your discretion wisely when you decide to help with delivery.
By the way, this behaviour should extend beyond code. Remove yourself from micro-decisions. Do not become the bottleneck of initiatives and projects because every decision has to be escalated to yourself. Find the middle ground of where you should get involved, and where you shouldn’t. For me this is, squad level backlog discussions remain in the squad. Consequential decisions that could impact the architecture, people, or budget is where I would get involved.
The Fruits of your Labour will take months
As opposed to Software Engineering, where you can see fruits of your labour in minutes, strategies and decisions you make as a leader will not make impact for months. This is something you will need to get used to and is often the bane and frustration of new managers. I spent the first 6 months being frustrated with the fact I could not see the impact of my decisions immediately if someone told me this up front I would have saved my team the ear ache of hearing ‘why things are taking so long?’. You will need to get used to the fact the decisions you make today will take anywhere from 3 to 12 months to make impact.
Get a Mentor
When I became a manager I was the most senior Tech lead in the company. I had no mentor or coach to guide me through the role of being a Technology leader. But I realise now this was no excuse to being a poor manager. If you do not have a mentor in your organisation go out and find one. You don’t have to find the most senior person in the room. Find someone who has done the first year to 2 years of management (and decided to stick around). I think I would have saved my frustration if only I had someone to mentor me. To the next thing you should consider …
Network with other Leaders
It’s pretty easy to find other Engineering leaders and managers that want to mentor. I left this to my second year. I should have done this much earlier. Simply go to one of your prominent Tech meet-ups in your area and I’m sure you will find many Tech Leaders happy to talk and assist. In the Sydney area I used to attend the Sydney Tech Leaders Meet up that helped me engage with people at that level, but also gave me insight into how leaders think and get multiple perspectives. And who knows , these same people may have opportunities for you in the future.
Read. And Read some more
I was very late to the game when it came to reading but when I started I saw my leadership capabilities shoot through the roof. A lot of people see reading as a long winded activity that requires hours on end. I did nothing more than 15 to 30 minutes every day of my ‘book of the moment’ or favourite Engineering Management blogs. One of my my go-to reads during my early days was Rands in Repose. Great content on pragmatic Engineering leadership.
Then I switched to meatier books. I have many recommendations, however, I recommend focus on building breadth of Leadership knowledge first by reading blogs, articles and online posts. Then delve deeper on particular leadership topics that intrigue you with a book. Will be posting some of my favourite reads later.
Seek Feedback , but also work on being Self Aware
Get feedback from your Direct Managers, primary stakeholders and most importantly your team. This doesn’t have to be a Survey or form. I think casual conversation around this topic is much more tangible. If you haven’t already, set up regular catch ups with your most prominent sponsors and occasionally ask them if you are meeting expectations. You want to ensure you are on the right track on the earliest stages of your journey.
In saying all the above, some of the best leaders I have seen are incredibly self aware. They know when they have dropped the ball without asking. And then they immediately try to fix it. This is next level leadership but it takes time. Expose yourself to good leadership (through reading, talks, mentors, managers) and you will start to understand where you sit when it comes to leadership maturity.
Your team will not understand your position
I used to be the Engineer who looked at Managers and think ‘What do you do all day? Do they even do anything other than attend meetings?’. And many of your team will probably think the same thing. No one can empathise with managers except for managers. As such you will need to get used to the fact Engineers in your team may not understand the problems you deal with. You will, however, have to get really good at articulating and setting the context for the problem to solve. This requires a great deal of empathy, context and compassion for those on your team. Unfortunately, it’s a one way street.
Finally, Don’t be afraid to call it
I had few people I managed take on Tech Lead and Engineering manager roles but struggled with the workload and context switching. I was deeply appreciative when they told me that the Manager role wasn’t for them. I gained so much respect for these people. Despite the fact the individual was not in a manager position anymore it was a great sign of Self awareness and Leadership to know when it’s just not for you. Don’t be afraid to tell your manager if it’s not working for you. Management isn’t for everyone (just like how Software Engineering isn’t for everyone!).
As you can see there was a lot that I got wrong in the first 12 months as a manager. I have gone through the pain of making many newbie mistakes that I hope you can learn from. Wishing you all the best in your journey to being a successful Engineering Leader. In the next couple of posts we will look at how to up your Engineering Leadership game after the first year of Management.
