I have my own strong opinion in this matter. The opinion is – being an engineering manager stops working once you stop being hands on. You are still a manager, but with each passing week of not jumping to hands on issues, you get further away. It becomes harder and harder to understand engineers. Up to a point where you stop being an engineering manager. You just can’t do it anymore.
It might come as a controversial statement.
Indeed, the woes of Software Engineering are not due to lack of tools, or proper management, but largely due to lack of sufficient technical competence.
Niklaus Emil Wirth
We need to acknowledge that engineering leadership is a technical role. You are accountable for helping software engineers who do technical work, for supporting to structure the team’s technical vision, and for making strategic technical decisions. To stay credible and plausible as an engineering chef it is imperative that you continue to be technical. And remember that chefs also do the dishes.
To stay there, you need to remember to have:
- An adequate depth of understanding of the systems your team owns
- The capability to discuss technical standards fluently
- Sound technical judgement to be capable to cause about trade-offs, and make desirable choices
Next in line comes the question on how do I stay up to date as an engineering manager. From my experience, it is hard to not attend some of the meetings. Not because you feel pressured, but more because as a manager you also have the responsibility for team visibility, PR and more. You also need to be the one, that takes some of the meeting burden off your engineers.
My answer to this dilemma is yes, you should still be writing code. And more. This does not necessarily mean that you need to spend 80% of your time daily to write code. You will need to be smart about it.
I am using the following rules to help me out with staying technical:
- Block focus time in your diary, at least 2 afternoons each week. People will need to adjust with their meeting schedules to your diary. You will learn to ruthlessly prioritize your meetings
- Share the technical decision load with senior engineers on your team. Their role is not only writing code.
- Be absolutely pedantic to not join meetings without an agenda and always finish meetings with an agenda on time.
- Be absolutely pedantic about process and form of the information provided to you. No more – I’ll rewrite this to our format, or can you please add detail. Teach others to appreciate the time you would spend on this, is not your top priority.
These help to enable to have the time required. You might seem a hardliner prick from time to time. At the same time, you need to learn to respect yourself and remember that the organization will still expect you to understand many technical details. You are doing yourself a favour by setting expectations and following some of your own rules.
Once the time is enabled, comes the question – what you can actually do with it? You might forget that you’ll spend it for tasks that will require long-term uninterrupted focus that can last for days. Your goal is to stay on top of things, not to become a primarily individual contributor again.
Here are some of my suggestions:
- join production incidents – here you can track and understand technical problems your teams are facing every day. You will also learn where logs and metrics are kept. At some point you might start contributing to analysis. This is also an excellent tool to understand what systems work where.
- pick up bugfixes – bugfixes are the place, where you can reasonably commit to over the course of your 2 afternoons of focus time per week. You won’t be able to fix all the bugs, but you will be able to fix some. And again, you will learn a lot of appreciation to the systems and problems your engineers face.
- read code reviews – set time apart to read the code reviews your team is producing. This helps you maintain consciousness of the areas of the code that are changing, spot technical debt, and preserve an eye on high-quality by means of reviewing assessments and reviewer comments.
- participate in design discussions — recognize how your structures are changing, ask considerate questions to help spotlight trade-offs, and assist the team to make sound technical decisions.
- read post-mortems — learn from the challenges different groups have faced, and deliver this expertise again to your team.
- evaluate new technologies — the implementation languages and technologies that we use trade over time. For example, your team might be thinking about making an attempt out Docker for local builds, or planning to use Kafka in a future project. Take some time to comply with tutorials, and construct a working example that you can continue to hack on. This will assist you advance a primary perception of the standards and terminology of the new domain, and supply you a beginning point to explore from in the future.
- participate in recruitment — conducting interviews in which you ask technical questions, and examine the code of others, helps to keep your expertise of engineering fundamentals fresh, and practice thinking algorithmically.
The conclusion is simple: if a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming.
Frederick Brooks
It is important to stay an engineer, while being a manager. Include and extend, not reject and replace. In most cases engineering is what made you tick first, management came in second. Remember to keep on re-invigorating that spirit by yourself.
Just to add, I also spend considerable time off-work, to stay on top of technology. Whether it is this blog, or doing some coding katas found on the web, I continuously feed my curiosity as an engineer. Then enrich it as a manager.
I also appreciate not all of us can do that. Some of us might have other commitments and might prefer time off-screen when off-work.
Gustaw Fit 