Careers ladders are all the rage in software firms. They create structure and shared expectations around different levels. Like any model, career ladders have pros and cons. Career ladders are a starting point for shared expectations across an organisation. However career ladders cannot be comprehensive, as people are unique, like snowflakes. People bring their different strengths and experiences to what they do. Everyone will do this differently. As a result, I like to explain that levels in a career ladder do not represent a checklist. Rather, levels reflect how people can have a different impact in an organisation in different ways.
In my most recent talk, “Talking with Tech Leads,” I explain how, some companies have a two-track career model. Two tracks are great, as they allow for more development and growth in different areas. Most of the research I did seemed to focus on two main tracks. In Silicon Valley they refer to these as Individual Contributor (IC) and Management tracks. I actually don’t think a two-track ladder is enough. This is why I present you the Trident Career Model below.
The Trident Career Model has three tracks. Each track represents where people spend most of their time or energy.
The Management Track
In this track, people spend a majority of their time (70-80%) on management activities. This still includes leading people, supporting people, managing structures & processes and organising. People in this track must still have some background in the topic they are managing.
Most importantly, their main value add is not necessarily through making decisions related to the specialist field (e.g. system architecture). Instead, they manage the surrounding system & structure to ensure people closest to the work have the best context and information to make better decisions. They provide enough support, time and/or budget to enable others to do what they do best.
Example roles in this track: Engineering Manager, VP Engineering, IT Manager
The Technical Leadership Track
In this track, people spend a majority of their time (70-80%) leading people on a technical topic. People in this track must have relevant hands-on technical skills and experience. They should have good but not necessarily the best skills in the team they are leading. People in this track draw heavily on refined leadership skills to be successful. Classic activities for this role (in the field of software) include:
- Establishing a Technical Vision
- Managing technical risks
- Clarifying/uncovering technical requirements
- Ensuring non-technical stakeholders understand technical constraints, trade-offs or important decisions
- Growing technical knowledge and cultivating knowledge sharing in and across teams
Example roles in this track: Lead Developer, Tech Lead, Principal Engineer, Software Architect
The True Individual Contributor (IC) Track
In this track, people spend a majority of they time (70-80%) focused on “Executing/Doing”. Software engineers early in their career reflect this very well. This track still requires people to have excellent communication and collaboration skills. People in this track have impact through the deep/detailed knowledge or skills they offer. Most small companies do not need a deep IC track, as there is no need for specialisation. As an organisation grows, they may need more of these roles. The number of these roles will always be smaller than the other two tracks in a well-functioning organisation.
Example roles in this track: DB Specialist, Performing Tuning Specialist, Domain Specialist.
Conclusion
This model is indeed a simplification. In real life, the Management and the Technical Leadership tracks are not always so clearly separate. I know some companies where Engineering Managers also take Technical Leadership responsibilities, or where Tech Leads or Lead Developers are also expected to take on Management responsibilities. This is not necessarily wrong.
I have personally found that, at scale, it is often hard to find people who have deep skills and experiences at both of these areas, and that it can be useful to have a discussion around where someone’s focus, passion or development progression lies.
As the famous quote goes:
All models are wrong, some are useful.
George EP Box
I have found this Trident Model a useful starting point to contrast differences in roles or expectations. Considering using this model:
- To develop skills in an area you may want to work
- When building out your own company’s Career Ladder
- To explain differences/focuses on existing roles and responsibilities
Looking for an example of this in the wild? This post, Engineering Levels at Carta, isn’t as visually deliberate, but points out “Senior software engineer II (L5) is the second of Carta’s two senior levels, our first terminal level.” This is made more explicit in this post about Staff Engineering at Carta, which says, “For those who wish to pursue it, our first level beyond “senior” and into focused technical leadership is staff engineer.”
I hope you found this post interesting. Please leave a comment about your thoughts of the Trident Model of Career Development.
Hi Patrick! I definitely agree with the three paths of career development as people gain experience.
I chewed over this sentence for a bit: “The number of these roles (true ICs) will always be smaller than the other two tracks in a well-functioning organisation.” This seems to only apply after the “split” in the paths. But at the same time, people earlier in their career are often referred to as ICs, at least where I have worked recently. Do you have a different term for people before the paths split? Or were you specifically only referring to people deeper in their software development career.
Hey davcamer!
Thanks for your comment. I haven’t found many people call people, as you say, “before” the split as ICs as they normally have more concrete roles (e.g. “Software Engineer”, “Agile Coach”, “SRE”, etc). That’s just my personal experience. I find this model much more useful to ask people about where they want to focus growth as these require different skills and time investment.
Hey Patrick, thanks for the article!
I’m a bit confused about the separation between technical leadership and just IC track. My assumption was that usually engineers develop and grow over time, leading to them taking more and more responsibility and effectively jumping on this “technical leadership” track. At the same time I understand that not everyone want to become a “leader” even in technical sense but I really don’t feel like this is accepted and expected by anybody. It’s like you become stale because of staying “just an engineer” for too long.
Would you please share your thoughts on that? Specifically because you made such a clear distinction between the 2 tracks, which is very interesting.
Thank you!
I like that you named the executive route “management”, rather than “leadership” or similar. Management isn’t nearly as glamorous as people think, so naming it as you have is helpful. Also, “technical leadership” is better than, say, technical management. Thanks for this model. I’m going to use this for someone’s career planning conversation this week.
Also, FYI, this model applies to my public sector work (e.g. policy development, contract management, etc).
Nice article. It would be interesting to see the Lead path in the middle of the trident, because it is kind of trying to keep one foot in each path (IC and Management).
Hi Evaldo. Thank you for the comment. The purpose of this is to show different career paths and how they diverge (or focus on different elements). There is definitely overlap in skills (e.g. people at higher levels on each track need strong communication skills). It’s up to the individual to choose which role works well for them and there are definitely many examples of people moving between each track