Staff Archetypes - Jack of All Trades, or Master of One?
November 3, 2025 - đ Shared on Flounder Mode
Photo by Halfcut Pokemon
The first resource most managers send you once you flag your interest in being a Staff Engineer is the one that describes the four archetypes.
A common question that comes up is trying to figure out which archetype suits you and your strengths as a person. For some folks, it can be very obvious which archetype one gravitates towards; for others, itâs not obvious which one you should choose, and you sort of just go off of âvibesâ. Very much like choosing a starter Pokemon!
As I was trying to figure this out, I asked a ton of questions to my then skip-manager, who was the one that originally inspired me to even try and go for the promotion. I laser-focused on the archetype that I perceived to be closest to my strengths, which was The Tech Lead. I immediately discounted the one that I thought seemed boring and not aligned with my strengths, which was the Right Hand.
However, at some point, my skip-manager told me the following:
âYou canât just focus on one archetype. You have to be somewhat good at all four archetypes, eventually. So try not to index your whole career on just being good at the Tech Lead archetype.â
Using attitude as a mechanism for shifting archetypes
Looking back, this advice aligns tightly with last weekâs post on being a T-Shaped employee: itâs fine to play your strengths and work consistently within a single archetype, but going out of your comfort zone to practice the other Staff Archetypes every now and then helps keep the doors of opportunity open.
Iâve found this to be especially true during the latter half of my tenure at Cocoon. I donât know if itâs due to the necessity of wearing many hats at a startup, but even though I was most interested in being a Tech Lead, there were many instances where Iâve had to morph into the other archetypes, even if they arenât naturally what Iâm good at [1].
One technique that has helped me âmorph archetypes when neededâ is to just adopt an attitude of Getting Stuff Done As Soon As Possible (GSD-ASAP). If you have an attitude like that and youâre creative enough, you will find yourself naturally changing your personality and how you work to fit whatever situation is in front of you.
For example, you may not be the best negotiator in the world, but if the fastest way to finish a project is to find a vendor that does the exact thing youâre looking for and build an integration with them, suddenly youâre reading Never Split The Difference and getting on calls with their sales team, while reading their documentation on how to integrate their product quickly with what youâre building [2].
GSD-ASAP is a muscle that needs consistent flexing to strengthen over time, but itâs one of those things that click once youâve done it enough.
The archetypes are lighthouses
Just like how you shouldnât overspecialize in one area of software engineering, donât corner yourself into only being a single Staff Archetype.
While the archetypes are helpful as a reference, I prefer to use them as directional lighthouses of how I need to be acting within a certain context, to make whatever outcomes Iâm focusing on successful.
The best part about all of this is, you donât need to be a Staff Engineer to have a GSD-ASAP attitude! Itâs something you can adopt at any point in your engineering career.
As long as you have that attitude and these directions, youâll be able to navigate confidently through whatever chaos you find yourself in, and maybe have your roles and responsibilities evolve along the way.
Footnotes
[1] Iâve been in positions where I needed to influence our leadership to make certain decisions on our projects and the technology weâre using, which is very much a Right Hand thing. Iâve also been deployed to âurgent and importantâ situations, which is very much a Solver thing. And sometimes, Iâve had to zoom way-the-fuck out to think about a problem from first principles, which is very much an Architect thing.
[2] I had to do this when building out our historical leave import process at Cocoon. We partnered with a third-party to help us transform raw CSV data into domain objects that could be used by our product. Cocoon is not a CSV processing company, nor should we be, so this was one of those classic build-vs-buy moments where it was faster to buy a solution we could integrate in our processes.