Flounder Mode #3: Staff Archetypes - Jack of All Trades, or Master of One?
Hello! My name is Jesse and I’m a software engineer. I’ve worked previously at Gusto, and currently at Cocoon.
This is a newsletter about some of the learnings I’ve made about work and life over the years, that I would like to pass onto the public.
If you find this content interesting, feel free to subscribe!
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.