This post is about a simple software engineering management framework that I’ve been using for about six months with the team that I’m currently leading. The framework focuses on three engineering management responsibilities: people management, delivery leadership, and technical system ownership. It helps to prioritise them against each other, and gives a structure to identify and manage tasks within each responsibility.
Engineering Manager’s Responsibilities
Let’s look into each of the three responsibilities.
- People management includes hiring, promoting and mentoring engineers, performance reviews, providing feedback, maintaining a healthy and productive team environment and so on. Although engineering managers are not solely responsible for some of those activities, for example hiring and promotions. However, their input is taken into account and they influence the process.
- Delivery leadership involves planning, setting goals, assigning tasks, liaising with other departments and/or clients, expectations management and other activities to keep projects on track and complete them successfully.
- Technical system ownership is about maintaining the technical systems behind the software products that the team is looking after: bug fixing, security, monitoring, alerting, adoption of new and removal of deprecated technologies, technology strategy and roadmaps, cost management, risk management etc.
Prioritising Engineering Management Responsibilities
To be successful, engineering managers need to pay attention to all three responsibilities. However, the amount of attention that each of them requires is not necessarily the same. It depends on the team, organisation, product, the current stage of its life cycle, and other factors. Different responsibilities are important at different times.
For example, a newly formed team has to learn to work together before efficiently delivering initiatives and maintaining the product. People management would be most important at this stage.
When the team has gone through forming, storming, and norming stages of its life-cycle it needs to start performing. For a team in an early-stage startup, delivery leadership clearly becomes more important. If the functionality is not delivered on time and the product doesn’t grow, it may be shut down and there would be no technical systems to own and no people to manage. If, however, the product is mature and requires mainly maintenance, then Technical System Ownership would become the most important responsibility.
Setting Priorities Within Each Responsibility
Within the scope of each engineering management responsibilities we can group all the things we have to deal with into three categories:
- issues: slow CI, inefficient collaborations with other departments, missing engineering capability, etc.
- things that are okay right now: the team workload may be just right, the infrastructure spent may be under control, delivery may be on track, etc.
- ideas and aspirations that the team would like to try or achieve: migrate the entire UI to React, create development plans for engineers, try a new way of collaborating with the design team, etc.
Issues have to be addressed or accepted depending on their impact on the team. If CI pipeline is too slow and fails too frequently because of flaky tests it has to be fixed. If there is a conflict in a team it has to be looked into immediately and resolved. If front-end developers are unsure how the new functionality that they are building should handle certain edge-cases, the UX designer needs to be engaged to unblock them. Teams with fewer issues are more efficient. Having lots of issues dragging on for a long time affects team morale and performance. Resolving issues promptly shows the team and the senior management that the manager cares about their team, delivery, and technical systems.
Things that are okay need only to be acknowledged and accepted. No need to fix things that are not broken. If the monthly spent on infrastructure is $1,000, there is no need to invest a month of developer’s time to take it down to $800. If every engineer who is working on an initiative knows what needs to be built and they are on track, there is no need to run daily meetings for status updates. If stand-ups are quick and on-point, there is no need to change their format.
Acknowledging and communicating that certain things are going as planned or are in good shape is important. Otherwise, team members and senior management would be taking them for granted and would be focusing on issues, including insignificant ones, too much. Spending time on things that are already fine, may be a sign that the manager doesn’t take into account the current business priorities and is wasting the team’s efforts.
Ideas need to be evaluated and, if they are good enough to be implemented, added to the roadmap. Aspirations need to be evaluated and converted into team goals if the team decides that they are worth pursuing.
The difference between ideas and aspirations is that ideas are specific suggestions to change something in the team: to start or stop something or do it differently. For example: change the stand-up format, migrate the front-end to React, involve engineers into planning delivery of the next initiative at an earlier stage.
Aspirations describe a goal but don’t necessarily specify how to achieve it exactly. For example, to have zero known bugs in the product, to become the best engineering team in the organisation, to get rid of all legacy technologies in the product.
Collecting and evaluating ideas and aspirations from the team members and acting on them shows the team and senior management that the manager cares about the future of the team, its members, and the entire organisation. Ambitious and meaningful goals as well as opportunities to experiment with new stuff motivate engineers to stay in the team longer and work with more passion. Not doing that is a signal to engineers that the manager doesn’t value their suggestions and doesn’t care about the future of the team. Best engineers will realise that their growth and careers may be at risk soon and start leaving the team.
Putting This Into Practice
To apply this framework, you can create a table like this and fill it in.
Here is an example:
You may fill in the table yourself or with your team. The latter requires more time, so it might be a good idea to do it asynchronously. The benefit of involving the team is getting more input and finding out what the team members care about and what they want to achieve.
Having this table and knowing which responsibility is most important right now you can start working through the relevant issues and ideas. That probably will take several weeks — all the changes should be done carefully to avoid disruption and to make sure everyone understands what is going on and why.
You may want to repeat this process once in several months. Maybe once a quarter.
To sum up, we can look at software engineering management as a combination of three areas of responsibilities: people management, delivery leadership, and technical system ownership. Paying attention to all three responsibilities is important. However the amount of attention each responsibility should get depends on the team, the organisation, the product, and other factors. It also changes over time. Within each responsibility area we can identify issues, things that are okay, as well as ideas and aspirations. Things that are already okay only need to be acknowledged. Issues need to be prioritised and promptly resolved. Ideas and aspirations should be evaluated and, if deemed relevant, executed or put on the roadmap.
I hope this framework will bring some structure, clarity, and efficiency into your day-to-day work of leading a team and help you succeed in your role.