So you want to be an Engineering Manager
Some thoughts on why moving from IC to Management it's not a promotion, and what one can expect from it and how to prepare for it.
A few years ago I was gifted with a though choice: I had a good and stable work in a company for a half decade already when I was invited to be the CTO of a startup. The team - friends of mine today - all young people, eager to conquer a huge opportunity in our home country. I decided to embrace the challenge and we did some awesome deliveries as a team, conquered big clients, and I was able to do a lot of code and architecture in a greenfield project during the bootstrapping months. After all, that’s what I had signed up for, at least in my mind.
When this project started to get serious, it’s when I realised that I was no longer a developer. I had to grew one app into a product with multiple apps, build and grow a team to evolve and maintain it while taking care of the architecture, setup presentations to investors, meetings after meetings with stakeholders, while also ensuring the product reliability to increase customer acquisition, retention and monthly recurring revenue. At this stage, I wore a lot of hats and developer was none of them. And I finally became one of the things I’ve always said I wouldn’t: a manager.
Still, this month’s issue is not about my trajectory, but about some lessons I learned along the manager path that I took and ended up enjoying. A path that once someone starts, will be more like a fork in the road than a continuation of the previous rides.
This painting is called Road In The Woods, by Constant Troyon.
A promotion? Not really …
One of the biggest mistakes I’ve seen people in my teams doing is having the will of “being promoted” to a lead/manager position. Rather than thinking on vertical move in the career ladder, I’d say that it’s in fact an horizontal one. It might be a new title with increased responsibility, but such transition involves so many structural differences between the previous and new role and responsibilities, that a whole new set of skills and capabilities is required.
What got you here, won’t get you there
If you try to solve the problems the same way you did as an IC, while also having to take care of team, delivery, stakeholder and strategy management you’ll fall into the seniority trap.
I saw this mistake happening more than once. Usually, a senior IC has developed both deep domain knowledge and technical expertise to solve problems by doing technical analysis, coding and troubleshooting. Trying to keep up with the same responsibilities or passion for coding will probably:
Turn you into your team’s bottleneck. Instead of being a blocker removal, you will be a blocker yourself. Your responsibilities have now increased a lot with people, project, delivery and process management so that you find yourself in a trap of constant context switching and having less and less time to focus on the coding part. Own tasks that might block your team delivery if they’re not done/delayed and boom: you have a recipe for disaster.
Block other people’s growth. If you come from a strong IC background and used to be the most senior in your team, you should already be used to help other less experienced members to grow. But regardless, a good thing to have in mind is that once you take over relevant work that needs to be done, you’ll always take the opportunity from people who would benefit a lot taking over and learning from it. That’s why it’s key to play the mentor role here instead of the contributor. And if you’re not a manager yet but already has a more senior position, start playing this role right away as your job is not to be your team’s superhero, but rather a role model and enabler.
Be a bad performer. Being a new manager is about having a whole new set of responsibilities that also require learning. Having to learn all of these things, while also being good at them for your team’s sake, and doing the same things you did a before … it’s just not possible. That’s why it’s important to have your priorities set clear and understand that what got you here, won’t take you there.
You might be thinking then: how can I be sure the work gets done if I’m not into it? Well, there’s a few ways.
Delegation and empowerment. Let it go should be the soundtrack for a new engineering manager with a strong IC background. Instead of taking a decision yourself, focus on providing enough context and creating a safe environment for the team so that they can take controlled risks and develop their decision making process.
Communication and collaboration. It’s not about anymore the small chunks deliver, but the outcomes your team as whole is delivering. Focus on creating collaborative teams, where egos are set aside and people can have a real culture of collaboration with each other to find answers for the challenges that arise.
Personal development and career planning. Most of the time, it’s about putting others ahead of you. It’s about thinking carefully on what skills can one develop by taking the lead of a given outcome or initiative and leveraging this to grow the skillset on each one of your team members.
Don’t make the same mistakes I did and underestimate the things described above: they’ll took the most part of your time. Also, your success as a manager is now measured over your team’s success, not only in deliverables, but also in other metrics such as retention, engagement and recognition.
It might seem crazy and bit counter-intuitive to think that the work that you used to do is no longer the success metric of your current position. In that sense, I really liked a phrase I heard in a presentation from Phil Calçado that said: “My job is to look at the whole ecosystem as a city. I'm really thinking about it like a city planner, not a bricklayer, not somebody who's building one building. I'm building a whole organization, and there's different ways to go about this”. You’re not the bricklayer, you have now way more than a single building to worry about.
Don’t rush it
As we’ve discussed above, once in a manager position, it is not only too difficult to keep hands-on but also less beneficial than it initially seems. At the same time, some of the best managers that I ever had and and still have as a role model are technical. And that makes a huge difference, since technical managers are able to:
Know how to remove complexity and find the shortest suitable path for new features implementations.
Know how to thrive in war times and act strategically in peace times.
Build relationships and decisions based also on your credibility, by demonstrating the necessary technical judgment to bridge business needs.
Leverage the reputation built above to have directly influence not only into a single team’s scope, but also into the organisation technical strategy.
That leads to the following question: when is the right time to make this move? While there’s no precise answer, I’ll completely follow Camille Fournier advice in the book The Manager’s Path:
”Stay technical until you feel that you have truly mastered what you want to learn for writing code and designing systems, and then decide if you want to switch careers into management. (…) It’s hard to make up lost time when you stop writing code, and if you do it too early in your career, you may never achieve sufficient technical savvy to get beyond the role of middle management.”
Take your time, have some big and complex technical accomplishments under your belt before ever moving to a line manager position. You’ll benefit much more from it thinking long term. And after getting there, if you’re thinking about how can one stay technical as an EM, there’s this great article from
which covers this topic in detail.You’re more than a role
I have read once DHH talking about diversifying your life when I was in a phase of tying to much of who I am to my career progression and I have come to a conclusion that my trajectory is way bigger that what I’m currently doing and that it is indeed a trajectory, with swirls and curves and different things along the way. Instead of thinking that I am an Engineering Manager, I rather think that I am currently an Engineering Manager. That single word makes a ton of difference.
And if you want to try something different tomorrow, or even go back to the individual contributor path, why not? Charity Majors has an excellent talk about it and she argues the following:
”You don't have to choose one or the other, fortunately. You can do either. You can do both. You shouldn't just pick a lane and stay there. However, you do have to choose one at a time. This is because there are certain characteristics of both roles that are opposing and not reconcilable. Lots of people are good at both of these things, but they're good at it serially. They're not good at it simultaneously. Nobody can do both of these things at once and do a good job of them because both people and code require the same thing, sustained, focused attention. Being a good engineer involves blocking out interruptions so you can focus and learn and solve problems. Being a good manager involves being interrupted all the time. You can't really reconcile these in a single role. You can only grow in one of these areas at a time.”
Remember the limited WIP mantra present in Lean? It fits precisely well here. If you’re now a manager, focus now on being really good at it. Being really good at letting people make mistakes and grow in environments as safest as possible. Being really good at switching contexts fast. Being really good at understanding systems and their components relationships. It is a completely different skillset that you’ll need to learn. But that compounds over time and can even compound to the previous IC background in an eventual return to the other path.
Wrapping up
If I could give one single advice for the ones looking for the next steps in the career ladder is: don’t think of being promoted to a manager. There’s no such thing. Rather think if you want to take the fork in the road and make a shift in your career. And also: you can always go back, but focus on one thing at time. Your sanity and your team(s) will thank you.
Appendix: My Engineering Management Library
There’s a lot more about Engineering Management and its internals than what I’ve spoken here. Really, a lot more. Below are some assets about Engineering Management or related topics from so many talented professionals that I look up to and definitely recommend to anyone thinking about following such path:
Books
The Managers' Path by Camille Fournier
An Elegant Puzzle by Will Larson
Becoming an Software Engineering Manager by James Stainer
The Making of a Manager by Julie Zhuo
Engineering Management for the rest of us by Sarah Dresner
No Rules Rules by Reed Hastings and Erin Meyer
Newsletters
Refactoring by
The Hagakure by
Software Design: Tidy First? by
BR: Technical Program Manager’s Field Manual by