Different types of Software Engineers: a football (soccer) analogy
“You see, in this world, there’s two kinds of people, my friend: those with loaded guns, and those who dig. You dig.” [C. Eastwood]
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8ebfb025-584d-494b-9498-e2caef6e6c85_4368x2912.jpeg)
There isn't a single type of software engineer out there. Each one of them has different peculiarities, strengths and weaknesses. There is a model I've been using when thinking about different typologies of software engineers, and how to better leverage their strengths when assembling a team.
Like always with archetypes and labelling, a word of caution is required. These categories are just approximations and mental models that help you reason about a certain problem. I don't think there is a single person that fits 100% in any of the following definitions as humans are complex and unique beings that can't be reduced to fixed categories.
With that in mind, let's explore the model base on a football analogy.
You can typically break down the members of a football team in 3 main categories:
Strikers: The ones whose main job is to score goals. These tend do be the most popular and well paid players, the ones most often celebrated in case of victories.
Defenders: The ones whose main job is to prevent the opposing team to score goals. Their job is less glamorous but nevertheless very important to the success of the entire team.
Midfielders: Those who can support either strikers or defenders depending on what is going on at a specific point in the game. They also serve as a connection between defence and offence.
We can look at Software Engineers in a similar way, and what follows is the description of what I've been observing as key traits in the different categories.
Strikers
These are what I also often call ‘Hackathon Developers’. They excel in turning ideas into code quickly, they can leverage the most modern frameworks and tools, and tend to be very opinionated on the product side. They work extremely well as solo developers or in small teams, and get really excited whenever they're putting new code and products in front of users, and observe their adoption.
They are not afraid of taking risks in order to get traction and adoption, and typically find processes and documentation more of a burden rather then something helpful. They value their ability to take decisions quickly and often live by the motto “move fast and break things” that used to be very popular in the early days of Facebook. They tent to dislike anything that can “slow them down", whatever that might be.
They like to work with other strikers as they share the same language and value system.
More specifically, these are some of the bright sides / dark sides of the Striker archetype that I've been observing.
Strikers - The Bright Side
They ship quickly and often. Their main goal is to ship product improvements, and as such they tend to have ver high delivery speed - at least in the short term. They really value productivity in terms of the amount of features shipped by unit of time, and take a lot of pride in being considered 10x engineers by a certain part of the organisation.
They are not afraid of taking risks, even big ones, for the sake of getting the product out in front of the users. It's more natural and preferable for them to ship a fix than to spend too much time trying to think about all the corner cases up front.
They can easily take product decisions. They often have opinions about how the product should look like, and with the right level of balance they can really help PMs nailing features and capabilities by autonomously taking many decisions by themselves.
They are usually comfortable with many different technology stacks. As they're naturally curious and they aren't necessarily interested in advanced optimisations, they're often very keen and enthusiastic about picking up new languages and frameworks. Whatever promises to increase their ability to ship quickly the next feature is a good candidate for being added to the team's technological stack.
As a consequence of many of the previous points, they tend to have good full-stack proficiency and are able to ship end-to-end features by themselves without the need for a lot of external support. They like to be able to spin up cloud services, set up database schemas, and start building features on top as quickly as possible.
They're great for prototyping and helping the company iterate towards product-market fit. During the early stages of a startup, engineers that align with this archetype are crucial in their ability to iterate quickly, navigate ambiguity, scrap their work and start from scratch when needed, and even take some product decisions in full autonomy. Engineers that align with the Striker archetype often tend to be very successful at Hackathons and early stage startups, where their ability to ship quickly for the end user is often a great differentiator.
Strikers - The Dark Side
Their code is usually not optimised for scalability or maintainability. Often what they build stays at the prototyping stage for quite a long period, as they typically favour building more capabilities rather than refactoring, optimising and making their code easier to understand, evolve and maintain for the rest of the team.
They tend to jump into implementation before thinking of and designing the underlying architecture. They usually consider most planning as a waste of time that takes them away from their main purpose of building stuff.
They often lack security awareness and competence. Security is boring, and it is rarely something explicitly requested by end users. The Striker archetype often dismisses security concerns by stating that without their work and focus on shipping there might not even be a business to protect soon. Their views are not completely unfunded, but you want to make sure you have some counter views in your team if you want to achieve a more balanced outcome.
Little documentation is produced before and after the development. Code should be self explanatory! Similarly to architectural design, Strikers tend to consider the job of writing documentation largely as a distraction. Better to spend that time coding instead, especially as anything we're building right now might not stick around for too long.
As they tend to optimise for short term speed of delivery, they're often not able to evaluate mid/long term implications of adding new technologies. Are they introducing potential security or scalability issues? Is the project mature enough and the community big enough to ensure a certain level of continuity? How does the new technology impact overall complexity and cognitive load for the team? More often than not Strikers don't really address those questions before pulling the trigger on something that will make them faster in shipping what's on their desk at the moment.
Might get bored easily and leave stuff unfinished. Striker often display a certain need for novelty and love to work on building solutions that address 80% of the problem, and then jump onto something else. This can potentially compound over time into a product that feels rough on the edges, unfinished, forever in beta, unless you have a team that can pick up the task of finishing what a Striker has implemented so far.
They can lead to an accumulation of technical debt. Due to all of the above, if kept unchecked a team of mostly Strikers can easily lead to an accumulation of technical debt over time. The illusion of short term speed gradually gives room to inefficiencies, frustrations and a general inability to ship anything meaningful in a reasonable amount of time.
Defenders
These are software engineers that excel in building scalable systems and architectures. They focus in shipping code that can be easily maintained by others, and love to build tooling and automation a way to achieve speed of iteration. They usually like optimising existing systems over reinventing the wheel or shipping new features.
They tend to see processes and documentation as a way to ensure that the code being built and shipped will last for months and years without significant degradation in quality. They take security seriously and tend to favour “good” over “fast”.
They are usually more comfortable working with other defenders. Isolated defenders in a team that is mostly composed by strikers tend to build up frustration and can end up feeling they're being ignored.
These are some of the bright sides / dark sides of the Defender archetype that I've been observing.
Defenders - The Bright Side
They like to build code that is scalable, robust and maintainable. They generally think about what they build as something that needs to stick around for a while, and as such it has to be easy to maintain, improve resiliency of the system and reduce the amount of toil it generates. That usually means it'll take a longer time for them to come up with an initial working solution, and that is something they see as a useful investment rather than a distraction.
They put a lot of emphasis in documenting processes and code. As they typically want other people to be able to maintain and evolve the code they've built, they want to implement scalable systems to ensure that. They prefer to make other people do the right thing autonomously rather than having to constantly police them instead.
They tend to be mindful of tradeoffs and decisions at the system and architectural level. They rarely take an architectural decision without thoroughly considering its implications, and evaluating a bunch of alternative approaches. They like to make tradeoffs explicit by documenting architectural decisions or by over communicating about them in various forums.
They are typically very security minded. Most of the engineers that identify with the Defender archetype are conscious of security risks and how to avoid many common pitfalls. They tend to ask questions about security and seek the advice of security teams or other experts in the field to make sure the solution they're going to build will not introduce unwanted vulnerabilities.
They are comfortable with writing thorough design documents, evaluating architecture tradeoffs and propose a solution that will have positive long term repercussions. They see the up-front design and discussions as a valuable investment to ensure we end up building a system that won't require to be thrown away and reimplemented too soon due to major pitfalls.
They are careful with introducing new technologies, framework or languages in the stack as they're concerned about the increase in complexity that this will cause. They're more interested in removing languages or frameworks whenever possible so as to simplify the system and make everyone more productive in the long term. They're often reluctant to adopt the latest shiny new piece of technology as they're worried about the anti-pattern of solutions in search of a problem.
They are able to significantly optimise existing systems to squeeze out more performance, reduce cost or increase developer experience. The Defender archetype is often more interested in making other engineers more productive rather than on shipping features themselves. They take great pleasure in seeing the impact they can have on other and are comfortable with the patience required in order to see the results of their work.
Defender - The Dark Side
They can be perceived as slow, especially in the short term. Given their tendency to think and plan before jumping into execution, these profiles can be too slow in reacting to situation that present a serious or even existential threat to the company.
They can fall into premature optimisation before knowing whether or not the system being built will have a future. This can be particularly true in early stage startups where the survival horizon is evaluated in months, quarters at most. In situations when there is a need to find product market fit by trying out many different approaches, spending too much time building scalable systems can definitely have serious negative consequences for the company.
They are generally risk averse. They don't like to randomly update to the lates version of a library, framework or system before having tested and double-checked for potential side effects or issues. When there's too much uncertainty they have a tendency to investigate and research rather than trying things out.
Paralysis by analysis. As a consequence of the previous points, they could fall victim of the paralysis by analysis anti-pattern. Instead of accepting some risks or shipping a suboptimal solution, they'd rather spend some additional time researching, analysing all the options and delaying the decision that they perceive as too risky.
They can end up considering technology as an end in an of itself, rather than a means to an end. Their obsession for perfection could easily lead them to loose sight of the actual problems we're trying to solve for our end users, and get stuck in pure technical considerations, constantly in search for a technological Holy Grail.
They can become perfectionists, unable to accept any tradeoff. The system is either perfect or it's not worth building. This dogmatic approach can lead them to cause intense friction and undermine trust within their team as they can be perceived as very judgemental and finger-pointy by their peers.
They can struggle with too much ambiguity. Lack of clarity on the desired outcome or destination makes it difficult for them to objectively and rationally evaluate different options to select the most adequate solution. As such they might often complain that “they don't know what they want” when referring to Product or Business stakeholders, rather than proactively find ways to help the organisation quickly validate some hypothesis through rapid experimentation.
Midfielders
The third category is largely made up by software engineers that are able to display the strengths of both Strikers and Defenders, depending on the context and the needs of the current business needs. They are great at supporting and working in teams with either one of the two other types, and can serve as a good counterbalance for the most radical and extreme Strikers or Defenders.
Are they just an “average” of the two other profiles?
I don't think so, or at least not exactly. First of all these archetypes - like any model - are broad generalisations. Every software engineer sits somewhere in the continuum that goes from one extreme - the Striker - to the opposite extreme - the Defender.
These archetypes are based on personal observations, not rigorous research. As such I can't pretend to know exactly how people are distributed along this imaginary line. They way I think about the distribution is with a bell curve, with the two tails representing each extreme of the spectrum.
The vast majority of engineers fall within the middle part of the bell, the area that represents the Midfielder archetype. As you can see from the drawing, you can further split this category into “Defensive Midfielders” and “Attacking Midfielders”.
In the former category, Defensive Midfielders, you'll find engineers that can display the traits of both Defenders and Attackers, with a slight to significant dominance of Defender traits. Conversely, in the Attacking Midfielder category you'll find engineers that can display the traits of both Attackers and Defenders, with a slight to significant dominance of Attacker traits.
Another way to look at it is to think about Defensive Midfielders as a more balanced version of Defenders, displaying less of the most extreme Strengths and Weaknesses of this archetype. Attacking Midfielders would be the equivalent for Strikers.
Conclusions and next steps
In this post I've introduced the Striker, Midfielder and Defender archetypes for Software Engineers. It's very important to take these labels for what they are: a model to help managers empathise with and better understand people in their team. You will never find a single person that perfectly matches any of these categories, as humans are complex unique creatures that don't really fit in boxes or tight categories.
At the same time I have found this classification to be useful in various instances in my career.
I like to think about such models as a pair of lenses I can leverage to see the world of Software Engineering from a very specific dimension. The reality of software engineering is a multidimensional space, and dimensions such as seniority or domain knowledge are very much orthogonal to the football analogy dimension.
Please let me know if you find this classification useful, and please share your suggestions on how this could be made even more useful for your or other cases.
In the next post I'll be sharing some thoughts on how to work with the different archetypes. How to recognise them? How to manage their expectations? How to help them grow? How to combine different archetypes to build a team?
See you in a few weeks for the second part!