Engineering Management

A Simple Framework for Software Engineering Management

Andrei Gridnev
Jul 19, 2020 · 6 min read
Photo by bantersnaps on Unsplash

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

  • 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

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

  • 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

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.

The Startup

Get smarter at building your thing. Join The Startup’s +799K followers.

Andrei Gridnev

Written by

Software engineer, manager since 2002. Engineering management, leadership, software architecture, high-performing teams, professional growth.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +799K followers.

Andrei Gridnev

Written by

Software engineer, manager since 2002. Engineering management, leadership, software architecture, high-performing teams, professional growth.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +799K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store