Engineer Archetypes: Which One Are You?

While junior engineers are like dedicated worker bees who fix bugs, churn out code, and follow instructions, senior developers assume decision-making responsibilities that draw on their expertise in a certain programming language, technology stack, or business problem.

At the senior level, developers typically assume an “archetype”—an unofficial, self-determined persona or role within the development team. These archetypes are unrelated to official job titles; they represent a cross between your strengths, weaknesses, and domain knowledge.

In his book, Staff Engineer, veteran software engineer Will Larson posits that these archetypes manifest when developers hit the ‘staff engineer’ level. In some organizations, staff engineer is a senior position, virtually synonymous with ‘principal engineer.’ In larger companies, most engineers on the team might have the ‘staff engineer’ title.

While staff engineer implies managerial responsibilities, it usually falls within the technical leadership track rather than people management. GitLab, a DevOps platform, defines staff engineer as a senior position on the individual contributor track. This position is typically awarded after six or more years of software engineering experience, with the responsibility to provide technical leadership to a team of 3-6 developers. At Google, staff software engineers must have 9+ years of experience and strong interpersonal skills.

Common staff engineer responsibilities include:

• Providing technical direction for the team—programming languages, technology stack, product insights.
• Serving as the go-between for higher management and junior engineers who write the code.
• Shipping high-quality work with best practices like proper testing.
• Spotting the biggest pain points in the system/product/team and proposing solutions with deliverables and milestones.

We looked at a range of frameworks and schools of thought categorizing different staff engineer archetypes and created a list of the most common ones.

1. Architect

Architects typically preside over a specific technical domain within the IT department, such as cloud infrastructure, API design, or database management. They dictate technical standards for their domain, including software coding tools, platforms, and programming languages.

While the architect makes important design decisions that impact entire teams, they aren’t people managers. Rather, they’re called upon for their knowledge of how to reconcile technical constraints, user needs, and business requirements. They use these insights to identify and advocate for effective approaches within their area of focus.

Here are some common responsibilities of the architect:

• Reporting to stakeholders about software requirements
• Designing documents and product specifications
• Providing junior engineers with architectural blueprints for them to follow
• Testing the final product to ensure it meets business and user requirements

2. Tech lead

Tech leads head up a team of developers and take charge of all software development projects, making high-impact decisions about project timelines, technology stacks, and architectural constraints. This is the most common engineering archetype, seeing as most digitally mature organizations need roughly one tech lead for every eight engineers.

While the role is not on the people management track, a tech lead’s role is to:

• Establish a shared vision for the product
• Manage the technical quality of team deliverables
• Ensure the team uses appropriate engineering practices and invests in continual improvement to tooling

While a tech lead’s people management responsibilities are limited to delegating and mentoring junior engineers, they still represent the “face” of the tech team—meaning they must publicize the team’s triumphs and take the heat when things go wrong.

Tech leads have typically had experience implementing the team’s most complex technical projects, so they are in the best position to delegate tasks in the most effective way for the team to grow. Time spent on actual coding is minimal but in the event of a major setback—say a senior developer quits in the middle of a sprint—the tech lead might need to step in and write code.

3. Solver

Solvers are proficient at putting out fires and overcoming gridlock. According to Larson, they “dig deep into arbitrarily complex problems and find an appropriate path forward.” These problems usually constitute the organization’s biggest, most abstract pain points—problems that lack a clear approach or carry a high degree of risk. Examples include managing ‘scope creep’ (when a project’s scope becomes distorted due to changing requirements) or evaluating market changes.

Sometimes, these assignments are designated by senior leadership as mission-critical; other times, the solver takes the initiative. Some focus on a given area for long periods while others bounce from one area to another as dictated by leadership. However, solvers don’t work in isolation. They help guide ICs on the team when they’re struggling to find a solution.

While the solver archetype suggests someone with authority who has been with the company for enough years to understand its biggest pain points, the fixer/optimizer may be a self-starting IC who is proficient not only at finding and fixing bugs but solving problems across product lines.

4. Right hand

The right hand operates as “an unofficial senior organizational leader without direct managerial responsibilities.” Working as a sidekick to an executive (such as a principal engineer, CTO or engineering manager) means they must be deeply aligned with that leader’s approach, belief, and values.

Here, Larson makes an apt comparison to the Hand of the King in Game of Thrones. Engineers in this role attend the leader’s staff meetings and work to remove problems from the leader’s plate. However, these problems are never purely technical—they involve the intersection of the business, technology, people, culture, and process.

When something is amiss, right hands jump in, modify the approach, delegate tasks to the most appropriate teams, and find the next fire to put out elsewhere in the organization. In this respect, they aren’t so different from a solver, except that they serve a leader’s best interests instead of their own.

5. Product engineer

Product engineers are user-focused engineers who work closely with product managers. They spend significant time on market and consumer research, consulting with end-users to refine the product roadmap. This archetype is especially important for niche products designed for deeply technical end-users, such as software engineers who use low-code platforms to build e-commerce sites. Product engineers “focus more on the why, what, and what next rather than the how,” according to Pat Kua, a technology leader with 20-plus years of experience.

This type of engineer coordinates with the product development team to finalize product ideas, tests the product for design flaws and safety hazards and comes up with unique solutions to product defects. They may also use CAD software to prototype products. This archetype is especially prevalent in teams that don’t have a product manager.

6. Code machine

Maybe you aren’t interested in people management, technical leadership, or being a leader’s right hand, but you’re really good at programming and you love wading into a complex codebase. Code machines are good at producing large volumes of code. They keep up with ongoing technologies and are always searching for the best way to write code and optimize it to deliver the best results.

Engineers can be highly effective even if they choose to remain an IC. In fact, as software applications grow more complex, demand is mounting for technical experts with 10+ years of experience as coders. Longstanding ICs may be regarded as subject matter experts in their respective domains, and may still be called upon to weigh in on executive decisions

Finding your archetype

Finding your archetype isn’t mandatory to succeed as an engineer, but identifying your strengths and understanding what aspects of the job you like or dislike helps you perform better in the long run. For example, if you prefer to be client-facing, a role that enables you to exercise the privileges of a product engineer will be more rewarding than remaining in the role of code machine.

Before you determine your archetype, consider the track you want to be on: people management, technical leadership, or individual contributor? Next, determine your work style. Do you enjoy staying on one team and working on one product long-term (architect), or do you thrive on constant change (solver)? Here are some other questions to consider:

• What type of work energizes me?
• Does my company emphasize individual ownership or team ownership?
• Do I like untangling abstract problems, or do I prefer to work on tangible products?

Finally, know that not all archetypes are possible at every company. Archetypes like architect and right hand only show up once companies have hired a thousand or more engineers, where scaling issues make these roles possible. While it’s important to aim for an archetype that fits you well, don’t feel pressured to pigeonhole yourself. You might find that you identify with one or more archetypes, or your proclivities may change as you evolve in your career.