A couple of days ago, I got another question about Staff Engineer,
which felt worth digging into a bit:
I started reading your new book Staff Engineer and wondering if you can write about your thoughts on the difference between what we know as Technical Architect vs Staff Engineer. It looks like the big companies ditched the “Architect” title and invented the “Staff Engineer.” The more I read your book, the more I feel like Staff Engineers are plain old tech architects. Having set up an architect group that reports to the CTO office based on this: http://files.catwell.info/misc/mirror/2003-martin-fowler-who-needs-an-architect.pdf , I am now confused if I should rename the team :)
I hadn’t read the linked Who Needs an Architect
by Martin Fowler, so I started by working through that. The core arguments I read were:
- The term “software architect” means different things to different people
- Despite that term confusion, there’s still software architecture to be done
- Some “architects” prioritize mentorship, others decision-making
- Despite the numerous definitions of “Architect,” the term is generally understood to refer to the decision-making oriented variety
I agree with all those points, and eighteen years later (the article was written in 2003!),
the tactics are clearer: use the Staff-plus engineer titles rather than the architect title.
When I worked at Yahoo!, the career ladder went from Senior Engineer to Architect, and from there,
the architect titles got increasingly fancy. Software Architect? Sure.
Senior Software Architect? A good step.
Distinguished Architect? Yeah, most definitely.
These titles do a good job of conveying seniority, but they also suffer from
artificial specificity. There are many folks out there doing work at the level of
a Senior Software Architect who are not doing typical architecture.
The Staff-plus sequence of titles decouples seniority from archetype and is more durable for it.
You can assess someone’s seniority from their title:
Staff engineer, Principal engineer, Distinguished engineer, perhaps with some
varieties like Senior Staff engineer thrown in for very large organizations.
You can separately understand someone’s mode of operation by documenting someone’s
archetype: solver, architect,
tech lead, or right hand.
If you were feeling argumentative, you could have a title for every archetype,
but I don’t think that would work well in practice. There are two reasons why this is hard.
First, archetypes create clarity by creating distinctions, but reality tends to be blurry.
Very few folks mix “tech lead” and “right hand”, but many “tech leads” spend some time on
doing “architect” work. This makes evaluating folks a nuanced activity.
Second. creating four useful career ladders is surprisingly challenging.
It’s very possible to add specializing paragraphs to a couple of blocks explaining how
a “solver” might create impact differently than an “architect.” However, I don’t know
of any company that operates different ladders for each archetype successfully.
Performance ratings seem simple but are nuanced and frustrating at scale across thousands of people.
Winding back to the specific question, I would ask the current tech architect team
what they want. Long term, I think you’d be better off with the Staff-plus titles,
but that sort of change needs to happen at the organization level and might take a while.
Short term, it’s probably not worthwhile to change titles again if the change happened recently
unless the team is already excited for the change. If you don’t make the change now,
slot it into the organizational backlog and figure out when it might make sense later.