Over the past several weeks, I've introduced five engineering archetypes that I've encountered throughout my career:
- The Gardener
- The Mason
- The Blacksmith
- The Bear Killer
- The Chef
If you've read the series from the beginning, you may have noticed something. I never intended these articles to become a personality framework. They're certainly not a hiring rubric, and they aren't meant to suggest that every engineer fits neatly into one category.
Their purpose is much simpler.
I wanted to give engineers and engineering leaders a common vernacular for describing something many of us have observed but sometimes struggle to articulate.
Different engineers naturally excel in different areas. They approach problems differently, notice different things, and bring different strengths to an engineering organization.
Sometimes we recognize those differences immediately. We know that engineer who can walk into a legacy system everyone else is afraid to touch and somehow make it better. We know the person who thrives when handed a blank page and told to experiment. We know the engineer everyone calls when something has gone horribly wrong.
We recognize them.
What we don't always have are words to describe them.
That's what these archetypes are intended to provide.
Different Questions
One thing that became increasingly apparent to me while writing this series is that each archetype tends to approach a situation by asking a different kind of question.
A Gardener wonders:
"What could this become?"
A Mason naturally asks:
"What will everything else be built on?"
A Blacksmith asks:
"Can this be improved before we replace it?"
A Bear Killer wants to know:
"What's actually broken?"
And a Chef is usually thinking:
"What has to be true before this can happen?"
These aren't necessarily literal questions you'll hear someone ask in a meeting. They're abstractions of the way these engineers tend to think about problems.
None of those questions are wrong. In fact, they're all incredibly valuable.
The challenge is recognizing that different situations require different kinds of thinking.
Archetypes Aren't Identities
One of the things I want to make particularly clear is that these archetypes aren't permanent identities.
Someone isn't necessarily a Gardener in every situation simply because they have Gardener tendencies.
Throughout a career, engineers may move between several of these archetypes. Sometimes they'll even move between them during the lifecycle of a single product.
An engineer might help establish the larger direction of a project, spend months building its foundations, shift into experimentation as the product grows, become the person troubleshooting its most difficult problems as release approaches, and eventually spend years modernizing the system as it ages.
The archetypes describe strengths and ways of approaching problems.
They aren't boxes.
That distinction matters because the goal isn't to walk around an engineering organization assigning everyone a label.
It's to recognize the kinds of engineering strengths already present on the team.
The Right Engineer for the Problem
One mistake I've seen organizations make is assuming an engineer's effectiveness is universal.
It isn't.
The same engineer who thrives in one environment may struggle in another.
A Gardener placed indefinitely on maintenance work may become frustrated because there is little room to explore.
A Blacksmith asked to constantly abandon existing systems and prototype something new may never get the opportunity to do the work where they excel.
A Mason may struggle in an environment where foundational decisions are continually postponed in favor of immediate delivery.
A Bear Killer can solve some of the organization's hardest problems, but an organization that requires Bear Killers every day probably has a different problem entirely.
A Chef may be able to see how an entire initiative fits together, but that ability provides little value if nobody gives them visibility beyond their individual ticket.
None of those engineers suddenly became less capable.
The environment simply isn't asking for the kind of thinking where they create the most value.
Recognizing that difference can change how we think about staffing projects, assembling teams, mentoring engineers, and even evaluating performance.
Engineering Organizations Have Seasons
Engineering organizations also change.
Sometimes we're exploring. Sometimes building. Sometimes we're just stabilizing or modernizing.
Sometimes something has gone sideways and we simply need someone who can figure out what happened.
The engineering strengths an organization needs most will change with those seasons.
A startup building its first product probably needs a very different mix of engineers than a company maintaining a twenty-year-old platform. Even within the same company, a greenfield initiative and a legacy modernization project may require completely different strengths.
That doesn't mean one archetype is more valuable than another.
It means context matters.
The Goal Isn't Balance
When people hear the word "ecology," they often imagine balance.
I'm not convinced healthy engineering teams require an equal number of every archetype.
Some organizations genuinely need more Gardeners.
Others desperately need Blacksmiths.
A rapidly growing platform may benefit enormously from strong Masons, while an organization dealing with years of accumulated technical debt may need something entirely different.
The goal isn't equal representation.
The goal is understanding what you have, understanding what you need, and recognizing the difference.
That starts with having language to describe it.
A Common Vernacular
One of my favorite things to happen since I started publishing this series was hearing from someone who told me that he and a coworker had been talking about these archetypes.
That meant more to me than I expected.
Not because I think I've discovered some fundamental truth about software engineering. I haven't.
But two engineers were using these ideas to talk about the people they work with and the different ways those people contribute.
That's exactly what I hoped these articles might accomplish.
I wanted us to have words that make it possible to say:
"This project could really use a Mason."
Or:
"I think we need a Blacksmith involved here."
Or even:
"Who's playing Chef on this initiative?"
Those statements communicate something different from a job title or seniority level. They describe the kind of thinking we believe a problem needs.
And once a team has that language, it becomes easier to talk about strengths that might otherwise be difficult to describe.
This Isn't the End of the Conversation
There's another question that has started coming up as people have read the series:
How do these archetypes interact with one another?
I think that's a fascinating question.
I also think it's a much larger conversation than I can do justice to here.
There are natural handoffs between some of these archetypes. There are combinations that can make a team remarkably effective. There are also places where their instincts can create tension, even when everyone involved is making perfectly reasonable engineering decisions.
I've been thinking a lot about those interactions, and I suspect I'll come back to them.
For now, though, I want to leave this series where it began.
With vocabulary.
These articles aren't intended to tell you what kind of engineer you are.
They're not intended to tell engineering leaders which archetype they should hire.
And they're definitely not intended to divide engineering teams into five neat little buckets.
They're simply names for patterns many of us have seen throughout our careers.
The engineer who cultivates possibilities.
The engineer who builds foundations.
The engineer who strengthens what already exists.
The engineer who walks toward the problem everyone else is struggling to solve.
And the engineer who sees how all the moving pieces fit together.
If these articles accomplish anything, I hope it isn't that people remember my definitions perfectly.
I hope someone leaves a meeting and says:
"You know who we need for this? We need a Blacksmith."
And everyone else at the table knows exactly what they mean.
Because at that point, the archetypes have done their job.
They've given us a common language for talking about the engineers we've been working alongside all along.
