3 Differences between Software Engineers and Engineering Managers
On the face of it, to someone outside the industry, the life of a Software Engineer and an Engineer Manager might be almost indistinguishable. An Engineering Manager is just the best Software Engineer who is the boss… right?
With a more experienced and nuanced eye, this is very rarely true. I am certainly not the best Software Engineer on my team, or any team I have managed. I am proud of that. An Engineering Managers job is not to be the most capable technically on a team, it’s an Engineering Managers job to ensure the team is happy, safe and delivers business value.
Decision making.
As a Software Engineer, you and the team will need to be the technical experts of your infrastructure and technical estate. As a result of those technical expertises you are trusted and expected to make constant technical decisions about feature implementation, uphold technical standards and advocate for the long term technical strategy of the product.
This is flipped on its head as an Engineering Manager. As an Engineering Manager you must not make the technical decisions for the team. If you do, it will effectively make your team button pushers. They are smart and creative, collectively much more so than any one Engineering Manager, let them exercise that. Ask them key questions at key points such as ‘What would this design look like under 3x scale?’ or ‘What latency can this deliver?’.
As an Engineering Manager your role is to guide and not decide.
Impact change.
As a Software Engineer, there are two things you need to get promoted to the next level; impact and visibility. There are many other things you need to do, these are the most important and non negotiable. Deliver impact and make that impact visible.
Typically you will do that via influencing the technological estate you are charged with protecting and advancing. You will envision projects and enhancements to the technology surrounding you. That vision will be realised, the impact measured and if you make that impact visible, a promotion case will be strong.
This completely changes as an Engineering Manager. You still need to deliver impact and make that impact visible. At the highest level, that impact is over people and the team. You must ensure you are delivering business impact with your team. The best way to do that is by looking after the people. A happy, driven team with focus and boundaries is the best way to deliver business value. Those people, when enabled and trusted will deliver the technical excellence. Looking after the people scales, a manager making the technical decisions does not.
As a Software Engineer, there are two things you need to get promoted to the next level; impact and visibility.
Measuring gratification
As a Software Engineer, gratification can realised fairly instantly; that code works or that failing test now passes for example.
As an Engineer Manager it might take a while for your gratification to arrive, for your success to be measured. The changes you make to a team, and everything that encompasses can take months to bear fruit either positively or negatively.
Measuring the success over technology is much more binary than measuring success over people.
As a Software Engineer and an Engineering Manager there are obvious examples of where you would experience the opposite of what I have mentioned above. In general, from my experience Software Engineers have more mechanisms for instant gratification and an Engineering Managers role is more fraught with delayed gratification.
Great read, Ryan. When engineers own the decisions and solutions they bring interest, which in turn brings growth and performance. I do have one question: do you have any tips or suggestions in the case that team lead/lead engineer and engineering manager lines get blurry? For instance, on a small team there may not be enough managers or the org has no interest in adding one. How might someone in this position handle both sides of the coin?
Loved the term delayed gratification