Software engineering management is a challenging role, with many different skills required to do it well. It can be challenging to know where to start when considering moving into the role. This post lays out a framework that can be used by the managers of prospective engineers as well as the engineers who may be looking for a successful path into a management role.
When discussing a move into engineering management with interested engineers, I like to frame it through 4 pillars of engineering management:
- Product – Understanding the business and how your product satisfies customer needs. Knowing how to manage stakeholder expectations.
- Process – Understanding how the system of humans in a company turns problems into solutions. Often this entails agile development methodologies, but it can also include creating systems to manage internal issues like compensation reviews.
- People – Understanding what matters to people, how to communicate well, how to manage both conflict and feedback effectively.
- Technology – Understanding how your system is built, areas of risk, scaling problems, and architectural patterns.
I want a new manager to demonstrate basic competency in each of these areas. In addition, they need to show high promise in at least one, ideally more, of these. To provide a bit more detail: imagine ranking everyone on the engineering team on a 1-10 point scale for each aspect (with 5 as the median). I consider basic competency for a new manager as 6+ on this 10 point scale. I also want to see them at an 8+ for one of these areas. This quantification is somewhat subjective, but it suggests they are better than 80% of your engineering team. Two examples of this are: 1) I would consider an 8 for technology as nearing the high end for a senior engineer and 2) I would consider someone an 8 for process if they were able to successfully play the role of scrum coach on their development team, while also performing engineering duties.
Most engineers moving into management will be strongest in technology, as it is currently their primary focus. This still leaves the remaining Product, Process, and People to demonstrate. Because this person is coming from a different role into a management role, they likely won’t have a track record of performance in all 4 areas. Instead, I am looking for enough evidence to feel confident in their potential to rapidly develop above-average skills in each of these areas.
For a new engineer who has expressed interest in managing, I would do the following:
- Do a quick score assessment of where I think they fall in each category. Document what evidence I have to either support or detract from their number.
- Discuss and provide evidence for my scoring process (I don’t always share the specific numbers, but would give directional feedback). During this process, I’ll encourage them to add any additional evidence I have missed.
- Brainstorm opportunities to demonstrate any skills I found lacking, then prioritize and execute on skill-building exercises (See the appendix for ideas of what these could look like).
Depending on where they are starting from, steps #2 and #3 can take months or years to work though, but at any point in time the engineer should have one or two areas they are working on to build skills. This could be taking the lead on a new project (process/product), mentoring an intern (people), organizing a group to tackle an area of tech debt (people/process). It should be possible to find items which benefit the business, give them a challenge, and demonstrate leadership skills.
As you choose the right tasks for prospective managers to work on, consider how much risk is appropriate based on their current skills as well as the task. In giving them managerial work , you are putting them in a position to improve or detract from the work and careers of those around them. Some risk is okay, but don’t be delinquent in considering the impact to others on the team. I like to consider the ‘blast radius’ — meaning, if this went really wrong, how big would the likely effect be, and how quickly could I identify and mitigate it?
As a final note, as you work together through these projects, make sure they are documenting their learnings and successes. This can both help them stay motivated and help you build a solid promotion-case for anyone you may have to convince (even if it’s just yourself).
Appendix:
Here are some ideas for skill development in each area outside of technology, which likely is covered by their day-to-day activities. Note that there is overlap among them:
Product
- Work with the product manager to write tickets for a project
- Help the team understand how their current projects tie to company goals and finances
- Work with other engineers to develop a long-term technical roadmap that supports business needs
- Find opportunities to improve the product and work with others to refine the idea and get it shipped to production.
- Build metrics and dashboards for products the team is building and monitor them after launch for learnings
Process
- Run team scrum process and meetings
- Participate in long-term team planning process, including helping develop artifacts, such as the product roadmap
- Build out and manage a Gantt chart for a complicate project with dependencies
- Project-manage a complex, multi-team project (tech debt projects are great opportunities for this)
People
- Onboard a new engineer
- Lead team meetings
- Identify conflict on the team and help encourage healthy dialogs
- Perform 1:1s with the team while the manager is on vacation
- Mentor engineers on other teams or participate in a company mentorship program
- Consider opportunities for leadership within technical initiatives, hackathons, organizing a team events (be mindful to not just have this person do all of the planning grunt-work on the team, but some is useful)