by Pravin Paratey

Engineering Archetypes

Today, I’d like to talk about engineering archetypes. Engineering archetypes or engineering personas are a skill-agnostic way of classifying engineers. I find it’s a handy tool for managers to answer these questions,

  1. How do I think of different engineers on my team? What career paths within software engineering make sense for them at their current stage of development?
  2. How do I best structure my team? What personalities are missing on my team? What have I overindexed on? Do I have a healthy tension on my team?
  3. How do I compare engineers working on different tech stacks (ex. front-end, back-end) and normalise their impact to the business?

For software engineers, in large organisations, it’s a handy tool to answer questions like,

  1. What kind of work do I prefer to do? Do I want to grow in that area?
  2. What kinds of projects or teams best suit my archetype?

Before I begin, I’d like to say that every individual engineer is unique and this isn’t presented to take away that individuality, but to act as an aid to help build a diverse and complete team. Also, an individual isn’t stuck with an archetype - it can change as their preferences change over time or it can change situationally, based on their team’s needs.

The archetypes

Code machines


As the name suggests, code machines are really good at writing good code and well versed with their choice of programming language and technologies. They are able to produce massive amounts of code v/s their peers. And are usually experts in their area.

However, they tend to dislike what they perceive to be time wasters – like meetings and interacting with people.

Fixers / Optimisers


They love diving deep into the problem and get tremendous satisfaction from making the least amount of change while maximising impact. You will find them disappearing for an amount of time and coming back with a (usually) successful outcome.

However, they dislike day to day iterative development and tend to get bored if they find themselves doing repetitive tasks.

Product engineers


They are constantly chasing business value, and love delivering products. They aren’t afraid taking shortcuts or making short-term engineering decisions if it leads to product in the market. They are usually very comfortable presenting ideas to non-technical stakeholders.

However, they dislike focusing on platforms or over-engineering.



They love architecting systems and drawing block diagrams. They enjoy working on complex products with many systems and moving parts.

However, all this may come at the cost of actually writing code.

Theoretical engineers


As the name suggests, they love working on abstract concepts. They may spend a lot of time reading research papers and using a pen and paper. They may find algorithms and mathematical concepts more appealing.

However, they aren’t the best at writing production quality code.

Systems/Infra engineers


They really know their physical machines. They have an innate understanding of how the kernel works, how memory allocation happens, the pros and cons of different file systems and storage media, cpu architectures. They prefer to work on low level system code or build services that other developers would use like databases. Some of them may enjoy devops.

However, they don’t enjoy building user facing products, and dislike the frequent (and in their opinion irrelevant changes) to UI and user workflows.

Mentor engineers


Potential future managers, mentor engineers love working with people on their and other teams with an aim to improve them. They are usually seen doing pair programming or mentoring junior engineers. They’d be the first to give feedback on issues that affect the team and come up with improvements to their teams ways of working.

However, they dislike being on projects where they have limited interaction with people or where they are the only developer.


There are no right or wrong archetypes. People are on a spectrum across these archetypes. Nobody is a 100% one or the other.

There is no right composition that makes up a team. Different organisations will need a different numbers of each archetype and this will change over time.

What do you think about these archetypes? How would you use this concept? Are there any archetypes that I have missed? Do let me know in the comments!