I've worked with teammates across many different stages of their career. However, there's one inflection point I've found particularly challenging, often at the five- to eight-year mark, driven by the question "Should I shift into people management?" There are a number of factors that play into this, often by taking on more responsibility after a foundation of technical understanding and capability. Additionally, different employers may compensate managers differently than different roles, which (rightfully so!) may impact the thought process.
At HappyCo, one of the things that I'm particularly excited about is that we compensate technical roles with the same bands and have three pathways: engineering management, technical lead, and senior technical roles. Because of this, teammates are compensated based on their seniority, which aligns better with fulfillment and personal growth in the organization rather than feeling like they need to go into management to make more money.
Asking the Wrong Question
Answering "Should I shift into people management?" felt like the wrong way to determine a path forward. Instead, I wanted to hear, "What role(s) will provide an opportunity for growth that are fulfilling and engaging to me?"
Designing the Skills Matrix
Types of Work
Software development spans a number of different types of work, especially further into one's career. Writing software is only one portion of the potential responsibilities; ensuring individuals and teams are delivering and growing, participating in developing and sustaining a healthy engineering culture, and aligning technical solutions with customer needs are all necessary to the success of the organization.
For each of these, there are multiple axis that individuals can assess themselves, including "How skilled am I in this?" and "How engaging is this work?" These are the two I focused on.
By answering "How skilled am I in this?" and "How engaging is this work?", one can estimate their level of attention, e.g.
- Should I focus on this?
- Should I learn this?
- Should I continue doing this?
- Should I avoid this?
The Software Development Skills Matrix
Based on the types of work, self-assessment, and types of attention, I quickly put together a Google Sheet and asked three developers that I estimated fell into different roles (people management, technical lead, and staff developer) to complete the matrix. Each person's response cemented what I'd expected to see given their role, so I shifted from Google Sheets to writing a small browser-based application, available here.
The repository is open-source.
The recommendations around areas of focus, things to learn, and things to consider avoiding should all feel "right." If something doesn't, please flag this as an issue in GitHub.
While this isn't one-size-fits-all, the recommendations of responses across three potential tracks might look like:
- The results for People Manager Roles will often suggest a focus on hiring, teammate onboarding and retention, as well as team management.
- The results for Senior Technical Roles will often suggest a focus on many points within software development, teammate retention, and even hiring.
- The results for Technical Lead Roles will often suggest a focus on a number of different types of work across many or most of the different groupings.
It's worth calling out that if there also recommendations to avoid certain types of work that might fall into this role, it may not be something you can avoid. As an example, most people I've spoken with in people management roles don't enjoy putting teammates on a PIP (Performance Improvement Plan), but it still may be a manager's responsibility to do so.
One key aspect of effective leadership and people management is positioning people to succeed in their roles. By enabling software developers to better understand roles suited to their interests and skills, especially at such a critical career inflection point, we can help achieve role fulfillment in their work, leading to more effective teams.