#behavior #bestpractices #productivity #work

Choose your engineering archetype - by Drew Hoskins

It’s the fiftieth anniversary of Dungeons & Dragons, and I’m celebrating the only way I know how—with a post on software engineering.

See also Work smarter, work slower, Stop Ignoring Your High Performers

D&D parties have several types of characters that any party needs to face down monstrous threats. A Tank is the barbarian, fighter, or paladin who can form the front line and soak up damage from enemies. A Blaster, perhaps a rogue or a warlock, dishes out brutal ranged attacks from afar. A Healer is a cleric or druid who can treat the party’s wounds and revive fallen comrades. And finally, a Face is a talker who can earn the party allies or schmooze their way out of combat.

Unbalanced parties may not last long. Sending a group of Blasters into a dungeon crawling with orcs will not end well when the orcs move into close combat and start batting aside bows-and-arrows. Faces are no help if the monsters simply want to eat everyone.

Software engineering teams need the same balance and versatility, and I’ve worked at two great software companies as they figured this out, feeling the pain before and joy afterward.

I joined Facebook in 2009 during the era of “Move Fast and Break Things.” Back then, the company had an engineering monoculture that lauded young guns churning out vast amounts of decent-but-not-great, untested code. An internal page called the “Hall of Heroes” tracked and ranked engineers by their amount of output, and it was never quite clear how ironic it was—after all, the engineer who created it was consistently in the top 5. On many teams, the amount of code you’d checked in factored heavily into your performance review. At some point, it became shown in the tool used during calibrations to determine engineers’ ratings, and rumors swirled about how seriously different managers took the data.

I was not a “Coding Machine.” On my performance review for late 2010, my manager wrote: “Facebook is a ship first, fix second culture, and that should not change. Therefore, the challenge is to create the best possible code within that constraint, not to rail against it.”

You can sense that I was frustrated. I’m not here to justify my decisions as a junior engineer—I’m sure I ratholed more than my fair share—but I was on a developer platform team, where breaking things is generally a bad idea if you want developers to trust you enough to rely on you for their businesses. I felt that platforms should be well-tested, and platform teams should have at least some engineers drawn to that level of rigor.

I wanted to feel like my manager was coaching me, yes, but also finding ways to use my skills rather than treating me like an interchangeable cog.

Stripe was (and is) a “measure twice, cut once” company—almost the opposite of early Facebook. This culture fits Stripe’s goals of building robust, polished developer platforms that move money around.

However, when I joined Stripe in 2018, it also had an engineering monoculture. The quintessential Stripe engineer was thoughtful, highly positive, and social—they call this “exothermic”—and great at reading long documents and politely giving feedback. Such “Tech Leads” could juggle participating in design reviews of half a dozen projects, mentor others, and triage inbound requests for teams of 30, while still somehow finding time to code. It was tough to find principal-level folks who didn’t fit this mold, and engineers who struggled with the required interpersonal skills were either not hired or not promoted.

But again, the monoculture sometimes hurt Stripe. Interpersonal feedback was hard to come by because people feared ruffling feathers. One org I worked in hired a bunch of Staff Engineers in this Tech Lead mold, only to wake up after a year and realize none of their Staff Engineers were coding, and thus, the group wasn’t actually building things.

Personally, I tried to embrace this culture, becoming a “Pillar Tech Lead” of 40+ engineers in part because it seemed like that was what a Stripe should do. I enjoyed it at first but quickly burned out in this hyper-social, scattered role. I longed for deeper, more focused work.

To both companies’ credit, they saw the problem—Facebook had created an engineering organization full of Blasters, and Stripe an org full of Faces.

They both instituted an informal system of “Archetypes” to describe what types of Staff Engineers could be effective there. Archetypes are like character classes in D&D, or more precisely, class specializations. An adventurer might start as a Druid and, after gaining a few levels, specialize as a Moon Druid. A computer science graduate becomes a software engineer and later might specialize as a Tech Lead.

Here they are, to the best of my memory.

Notice how these Archetypes differed across companies—we should not assume that all companies can fit all engineers! Yet, they were dramatically more inclusive than the straitjacket monocultures of the early years.

Here are a few quick hits about Archetypes at these companies:

Look closely at Facebook’s newer engineering tagline from 2014, “Move Fast with Stable Infra,” and you almost spot the different Archetypes making it happen—Coding Machines and Generalists who move fast, Product Hybrids who give them a direction, and Fixers and Specialists who build and maintain solid infrastructure foundations for them. It may be less catchy, but inclusion rarely is—witness LGBTQIA+.

At both companies, the rollout of Archetypes made a deep and lasting impact on me. They made me feel like I could belong and be valued while doing my best work. They fostered a distinct sense of identity that made me feel like more than a cog in some machinery.

At Facebook, after languishing as a would-be Coding Machine, I latched onto the role of Product Hybrid and rode that to some successful products.

After burning out as a Tech Lead at Stripe, I switched to the Architect archetype, forming a team to create a workflow engine (built on Temporal) to form a new foundation for most of Stripe’s async computing.

Combine those two experiences, and you get my current position as a Staff Product Manager at Temporal! I am a product person helping engineers to architect foundational developer products at a company whose goal is to be as reliable as gravity. It’s the kind of targeted career switch that’s only advisable after a lot of introspection and past managers helping me find my calling.

I wanted to tell my story since I existed before and after Archetypes at two important companies and am uniquely positioned to feel their power. I’m grateful to the thoughtful folks at Facebook and Stripe who figured this stuff out. I wonder if they were D&D players.

Update! - I learned from Inside Meta’s Engineering Culture — Archetypes that Kent Beck helped with archetypes at Facebook (clarification: he helped inspire them but did not draft them). I asked Kent if he played D&D: “I was at San Antonio Hobby Shop the day they unboxed the first D&D rules.”

If you have links you think I should add here, please reach out!

Class Specializations in D&D by The Escapist

Staff archetypes by StaffEng. A deeper look at a few Archetypes, including the “Right Hand”—I have friends at both Stripe and Oracle who describe their jobs this way.

Staff+ engineering archetypes at Spotify by Joel Kemp (Medium). This is a different list. While the concept of Archetypes should become an industry standard, each company might have a different list.