The trend, to the great benefit of the software industry, is to have separate career paths for management and non-management people (“individual contributors”). However, the existence of such a model doesn’t make it any easier for a developer (of any age) to decide what they want to be when they grow up - especially junior or mid career developers.

There certainly are options for those that want to move out of IC work: become a people manager, become a scrum master, product owner, project manager, or release manager. For the purposes of this blog entry we’ll consider those out-of-bounds, in the “management” track.

At the Individual Contributor level, leaning on Will Larson’s ideas around Staff Archetypes, but only to a point, I believe there are three different, and broad, areas of career focus, while at an individual level.

I will divide this all up into “areas” and “paths”. Each area has many paths.

These areas of focus are:

1. Leadership
2. Individual Contributor Focus
3. Architecture

The interesting part of a career in software development is that one might wander back and forth between these areas of focus, or even just the paths inside those areas, during your career.

Leadership

By leadership I mean a developer using their experience to lead, advise or coordinate teams or systems.

This may take the form of paths such as:

• Small team leadership “tech lead”
• The Right Hand Staff Archetype
• Project level tech lead
• Technical Project Management

Small Team Leadership “tech lead”

When given the choice I prefer separation of duties between the “people manager” and the “tech lead”. The former deals with people etc and is everyone’s boss “on paper”, and the latter focuses only on leading the team’s architecture between code or services.

The Right Hand Staff Archetype

Quoting directly from Staff Archetypes

The Right Hand extends an executive’s attention, borrowing their scope and authority to operate particularly complex organizations. They provide additional leadership bandwidth to leaders of large-scale organizations.

Project Level Tech Lead

Companies have different definitions of “projects”. A project could be “create functionality X” and the need for further coordination wound down upon completion. A project could also be long standing (either because the feature’s implementation life is measured in years, or the system is large enough or important enough that a tech lead like this can’t be disbanded).

If a system is composed of cliques of microservices sometimes projects are bigger than any one team and need coordination between multiple teams. Maybe this project also needs a single owner, someone ultimately technically responsible.

One could also build a solid reputation as the person who leads and completes various initiatives.

Technical Project Management

Note I don’t say “Technical Project Management”, which is its own thing, but ”Technical Project Management”. Think of this track as an enterprise architect merged with a normal project manager.

Business often don’t understand the technical ramifications of large business decisions: “Let’s move to the cloud” being a famous and modern one. A developer focused on the technical part of technical project management would be able to understand the components, systems, and teams involved (like an architect), and understand what that means for project management task ordering or dependency analysis. (You need a cloud account with a payment method first, before you can start building anything, for example…).

You may find yourself leading technical deprecation or adoption across teams, or even splitting desired technology outcomes into a two or three phased approach, in order to not introduce too much change into the system at any one time.

An individual on this track may find themselves involved in high level discussions in the software development layer cake: creating epics and understanding how at a large level pieces of the epic influence various teams.

Individual Contributor

Unlike the Leadership area, the Individual Contributor area may require less social and team working skills and more “gettin’ it done” skills.

This may take form of paths such as:

• “Do-er” Archetype
• Expert Generalist
• Expert Specialist
• Solver Staff Archetype
• Operations / SRE
• Software Engineer in Test

Do-Er

When I have my leadership hat on, I want someone who I can give independent work to, and have it cranked out for me. An engineering who is senior enough to do it well, not do off and spin wheels, while getting themselves out of any messes they find themselves in along the way.

This archetype is one I feel very lacking in the Staff Archetypes article.

I want this person able to focus on the technical things: not in leadership meetings, not pulled into 5 meetings a day: can they focus on the work in front of them (for the most part) and bang it out.

Expert Generalist

The Martin Fowler / Thoughtworks article on Expert Generalist defines the path well: where developers are good at a bunch of technologies. Similar to the “T shaped” moniker, but realizing that there’s not just one skill the developer will go deep on.

Beware: there is a trap in this path though: if the only commonality tech stack you have with the rest of the company is “writes code” you may spend a lot of time needing to learn new technologies very quickly. This may not play out well if the team expects a “hits the ground running” engineer.

Expert Generalists are important to orgs while being totally invisible to a normal org chart. Perhaps the API team and the mobile teams are finger-pointing because an API response crashes in certain cases: your expert generalist may be the only one to see the problem and understand the solution, because they’ve been on both sides of the debate.

Expert Specialist

Sometimes I really need someone who knows about DevOps and the Cloud, or Databases, or memory characteristics of Java 24, or even a really good Typescript type expert. The existence of Expert Generalists doesn’t replace this path, neither does “full stack devops developers”.

Operations / SRE

I lump Operations with SRE here: people that have seen the nonsense and developed Operational Expertise in whatever systems their program touches.They know how to keep Kafka, MySQL, DNS, or Kubernetes up, monitored well, and maybe in a performance optimized (ie: not solving problems by throwing money at it, ala engineers who sometimes don’t know what they’re doing).

These people are rare, and at a certain size they are essential.

Software Engineer In Test

The Software Engineer in Test role approaches software quality directly from a software engineering tools perspective, vs the (more usual) approach where Quality Assurance tools are applied to software projects.

Like SRE, a jump in focus like this means applying your craft in different areas, not simply what might feel like the “same old same old”

Architecture

The paths inside the Architecture area are easy to see because they often have “Architect” in the name. The annoying thing about different kinds of architect is that these may have different meanings per company.

As such I’m going to define them my way, knowing that those definitions may not be your way.

These may take the form of:

• Enterprise Architect
• Solution Architect
• Application Architect
• Security Architect
• Platform Engineering
• Project(s) level tech lead

Enterprise Architect

The Enterprise Architect has high level ideas about large scale initiatives at the company (or large department) and understands how those things operate. Is team A trying to pull in another vendor that does the same thing as what team B already has? What are the onboarding requirements for vendor relationships? How do all these systems we’re creating fit together?

Solution Architect

Typically I associate this kind of architect with Cloud Solutions architect. For example, for a message based application with some given constraints, does using a Cloud’s message/event system work for the use cases, or should they deploy a Kafka cluster? Or, in the case where multiple solutions exist natively on the cloud (I’m looking at you, AWS) which one will work for that application?

Application Architect

I associate this architect with creating styles and best practices across an organization, creating libraries for common concepts, establishing patterns for how teams talk to each other and the platform they’re on.

Security Architect

Advises teams on the safe / secure way to do a thing: be that to fit enterprise standards, work with enterprise systems, what encryption algorithm to use in a given case, or making sure your design doesn’t accidentally expose PII data.

Platform Engineering

Entries in here have had the name Architect in them, except this one. Anyone on a Platform team has an oversized productivity influence on the rest of the organization. Besides being one of the teams to help scale specialized expertise, they also are a specular lever for technical earned interest projects.

Working on problems to make developers faster, or your system work together better, is a spectacular way for an engineer to have an impact in lots of technology areas.

Project(s) level tech lead

This style of tech lead isn’t just leading one team of developers, as the Small Team Leadership “tech lead”, but instead providing technical leadership, overall, to multiple teams.

It’s not just one project, like the Project Level Tech Lead, it’s overseeing most of the projects.

Let’s say you’re a project(s) level tech lead for a shipping company. There’s a team taking care of integration with shippers, there’s a team taking care of the warehouse (getting orders packed in boxes), there’s a team working with inventory control to make sure we don’t run out of the thing. Each team has its own individual clique of microservices, and is really good at optimizing for their own comfort.

However, for all this to work you need someone concentrating on not just the teams, but the connections these teams have between each other. Are they giving each other correct data, tracing issues across systems, ensuring that the warehouse team doesn’t accidentally break the inventory control team.

What do you want to be when you grow up?

While most companies have career paths that go beyond, “Do your individual contributor job well enough and we’ll make you a manager”, that’s also not always the case, and sometimes it is easier to climb the company ladder in such a position.

However, there’s tons of career options for mid and senior engineers, and certainly a full career might have you trying many of these paths!