Things I wish I knew when I became an Engineering Manager — Part 1
Software engineering is a demanding profession that requires an ever-learning mindset and high quality craftsmanship. Growth paths for software engineers vary, for example: an individual contributor path towards becoming an Architect or a Principal Engineer; a Developer Advocate path; an Engineering Manager’s path, and so on. Each path has its own tradeoffs.
I’d like to focus on the Engineering Manager’s path, as most developers face the management switch dilemma at some point in their careers.
Making the shift from an Individual Contributor (IC) to a manager is not trivial. It is a semi-profession change that requires a whole new skill set, while adjusting some skills you might already own. Keep in mind that it’s also common for software professionals to switch from a manager role back to an IC role. If you’re unsure about your path, don’t be afraid to give it a try.
This post is for any of you who either aspire to become engineering managers or are in the midst of their first managerial role, as well as for managers who’re constantly looking for new ways to improve. I’ll share tips and notions from my experience on making a smooth transition from maker to manager, what to expect in the process, and how to complete it successfully.
Part 1 of the series will mostly focus on scaling your skills up and out, to handle your team members’ growth and the team’s delivery.
It’s not a promotion, it’s a semi-profession change
Engineering management is partly about managing software and mostly about managing the people creating this software. It’s about making sure your team delivers maximum value with minimum resources, while remaining happy and motivated.
This role is not for everyone, and the strongest developer won’t necessarily make the best fit. For that reason, it’s crucial to understand the tradeoffs when choosing a managerial career path in software.
Scaling up and out
Tasks you used to do as part of your personal scope, should now be on a team level. Scaling up things like task readiness, delivery quality and being held accountable to timelines is crucial for a team to function properly. Scaling them out is no less important, as you will no longer directly execute most of the tasks, but rather delegate them and provide support whenever it is needed.
Less coding
It is no secret that managers code less. You will slowly move away from the code, and rarely get your hands dirty. It’s a result of both wanting your team to grow technically by building the product, and having less time due to new responsibilities, like planning sprints, interviewing candidates and attending meetings with your team, peers and executives.
More architectural overview
While you move away from the code, you’ll focus more on the wider scope of your system. Foreseeing architectural changes, setting the technical roadmap for the team and constantly raising the deliveries’ quality bar. Making sure velocity expectations are set and matched, and if not — investigating the root cause and planning towards their achievement.
Changing your state of mind - from maker to manager
The Delivery
As a manager, promoting high quality, on-time delivery is a key part of your team’s and your own success.
Quality
As an IC you are responsible for coding standards, proper testing and clear documentation. As a manager, all of these remain under your responsibility, except now you are not executing yourself. Your team’s engagement with this mission is crucial, since you can’t (nor shouldn’t) go through each line of code before it’s pushed to production.
Pay attention to sensitive areas of the system, always be thinking on ways to reduce risk and improve service quality. Develop an “every day is quality day” team mindset, and don’t fear stopping from time to time for a “quality hackathon”, or anything of that nature.
Hold teams accountable to timelines
On time delivery, especially for external commitments, is not easy when done across multiple projects and team members. It’s your job to build a culture of accountability, where flags are raised as soon as delays are identified.
Set your team up for success
If you wish to set high quality standards and on-time delivery, strive to make your developers’ life easier. Are they given well defined tasks? Are the tasks detailed enough? Do these tasks provide enough context?
Try to ask yourself these questions before assigning tasks to your team. Remember how frustrated you felt as a developer when requirements were vague and unclear.
Plan for the future, remove anticipated roadblocks
Shifting your focus from the present to the future is a big part of being a manager. Watch out for bad habits within the delivery process, predict where the next production issue might arise and work with your team on early prevention.
The Team
“Leadership is not about forcing your will on others. It’s about mastering the art of letting go.”
- Phil Jackson, Eleven Rings.
Step off the court
The biggest mindset shift you will need to make as a manager is to “step off the court”. The ball still goes inside the basket, but not from your hands anymore. You are now the coach — your role is to guide your team towards success.
Ask the right questions, give advice and make suggestions. Delegate often, and allow your team to discover the right path on their own. Provide rods, not fish. It will not be easy, especially when your team chooses a different path than the one you thought of.
That said, make sure you are there for the team when needed. Either on-demand, when your team member asks for it, or when you anticipate your involvement is required.
As a coach you are now responsible for the continuous improvement and growth of your team.
Actively listen
Growing your team members into their full potential requires more than delegation and empowerment. It requires listening. What do they want? What do they need? How can you help them achieve it? Learn by holding meaningful 1:1s and by observing your team frequently.
At first, the 1:1s I held focused on status updates. This is the easiest way to go, ensuring shallow communication levels and slow paced growth. It was only when I forced myself and my team members to make it about the bigger picture that we started seeing a change.
What new thing did you learn this week? What do you wish to overcome in the upcoming sprint? Asking the right questions invokes thinking. Learning curves became sharp, goals started to be met and progress was suddenly being made.
Set tailormade goals
Set short, mid and long term goals, based on each team member’s aspirations. Set these goals together, and follow up on a timely basis to make sure they are progressing in the right direction at the right pace.
Provide continuous feedback
Make it constructive and digestible, and allow them to learn from their rights and wrongs. Base your feedback on team values and on the goals you set together. A rule of thumb is to praise publicly and correct privately.
Constantly measure your team
Providing feedback requires you to understand how to measure performance. There are many ways to measure a team’s performance, for instance using the DORA metrics, but you should start with a few basic metrics that focus on progress.
Look for improvement over time, as these deltas are the instantiation of your developer’s potential. A team member should be measured compared to themself and their progress — don’t make it an intra-team competition, but rather a self improvement marathon.
Focus on outcome over output
When developers help each other there won’t necessarily be a direct output, like a pull request or a design document, but the outcome can increase team members’ velocity in future related tasks.
Promote delivery velocity multipliers and actions that improve the entire team over time. Encourage such ideas raised by your team, and consider forming an incubation process for visionary concepts. Remember — plan for the future
Distribute knowledge
As a manager you need to keep the “Bus Factor” in your mind. How many developers from your team need to get hit by a bus for the system to go down? It is a humorous term, which stands for a crucial concept in any team. Make sure knowledge is shared within the team, and avoid turning developers into single points of failure for your system.
Resolve conflicts
Your team won’t always get along. People have different perspectives and backgrounds. Strive for self-resolution of conflicts, while observing and stepping in when needed. Be everywhere, usually as an unfelt spectator, and take action based on context and your teams’ values and culture.
Wrapping up
Transitioning from an IC role to a manager role will require you to partly scale up skills you own and practiced before, and to partly develop a new set of never before used skills. Remember these are different roles with different requirements, success KPIs and sense of creation. As a manager, your team’s success IS your success. There will be times of great satisfaction, and others of grand frustration.
Even though it is a reversible decision, put in the time to consider what your passion is and pay attention to the tradeoffs between the roles.
For me it is an amazing journey and I truly enjoy it. It enables me to make a great impact on people and systems, and to develop a more strategic way of thinking in regards to planning and executing technological endeavors.
In the second part of this series I’ll further discuss the mindset shift required when transitioning to a manager’s role. I’ll focus on how to handle external entities within the organization, and will further discuss what to expect from yourself in the shifting process.
