In 2008, I published version one of the management and technical career growth tracks, a framework for giving technologists career progression without forcing them into people management. Since then, I have implemented variations of this framework at two organizations and collected feedback from colleagues across the industry. This second version reflects what I learned.
The core principle remains the same: a strong technology organization needs parallel tracks so that a brilliant engineer is not forced to become a mediocre manager in order to earn a raise. But the details matter, and several things needed to change.
What Changed and Why
A product management track is now included. In version one, product management was not represented because most organizations I worked with at the time treated it as a business function, not a technology function. That has changed. Product managers increasingly sit within technology organizations, collaborate daily with engineers, and need a career path that lives alongside engineering, not in a separate department. Future updates may include other tracks like design, editorial, and marketing.
The contributor level on the people-management track is removed. Version one had entry-level positions on all three tracks, including management. In practice, most organizations do not have a role where someone’s primary job is to manage other people but they sit below the manager level. If you are managing people, you are a manager. The contributor and senior contributor levels now exist only on the technical and project management tracks.
The two contributor sub-levels are merged into one. Version one had both a contributor and a senior contributor level, making for 6 levels total. In practice, the distinction between “contributor” and “senior contributor” is better handled through title modifiers (e.g., “Senior Engineer”) than through separate levels in the framework. This keeps the system simpler.
A C-level band is added above VP. Version one topped out at VP. This version adds C-level (CTO, CEO, Chief Scientist, Chief Product Officer) as a distinct band. This matters because the jump from VP to C-level is qualitatively different from VP to Senior VP. A CTO is not simply a more senior VP of Engineering. The role requires a different set of skills, a different relationship with the board and CEO, and a different scope of accountability.
The director-level technical role is now called Principal Architect. “Architect & Director” from version one was confusing because “Director” implies people management. “Principal Architect” or simply “Principal” makes it clear that this is a senior technical contributor at the director level of influence and compensation, without people management responsibilities.
Minimum direct report guidelines are added for managers. A manager should directly supervise at least 3 contributors, and a director should supervise at least 3 managers. These are guidelines, not hard rules — exceptions can be justified. But without a minimum, organizations end up with too many managers and too few makers. Titles inflate, layers multiply, and the ratio of people doing the work to people managing the work tilts the wrong way.
The Framework
| Level | People Management | Engineering | Product Management | Project Management |
|---|---|---|---|---|
| C-Level | CTO, CEO | Chief Scientist | Chief Product Officer | - |
| VP | Vice President | Fellow & VP | VP Product | VP (Program) |
| Director | Director | Principal Architect & Director | Director of Product | Program Director |
| Manager | Manager (3+ direct reports) | Senior Architect | Senior Product Manager | Program Manager |
| Contributor | Senior (Contributor) | Senior Engineer | Product Manager | Senior Project Manager |
| (Contributor) | Engineer | Associate Product Manager | Project Manager |
The interactive version of this diagram is also available on Prezi and embedded below.
How to Implement This
If you are adopting this framework in your organization, a few practical suggestions:
- Start by mapping your current employees into the levels. If the mapping feels forced, the framework needs adjusting, not the people.
- Communicate the framework to your team before applying it. People need to understand that the technical track carries the same compensation and influence as the management track.
- Be prepared for questions about where specific roles fit. A tech lead who manages two people but also writes code may not map cleanly to either track. That is OK. The framework provides structure, not rigidity.
- Review and adjust annually. The right number of levels and tracks depends on your organization’s size and stage. A 30-person startup does not need 6 levels.
(Thanks to Brian Murphy and Brad Kagawa for their contributions to this system.)
Updated: This framework has been further expanded in version 3, which includes salary ranges and covers engineering, product, and project management across 4 levels with sub-levels. See also: discretionary job titles for flexible title naming within this framework, and CAREER-CLEAR for how to evaluate employees at each level.