What Makes a Senior Engineer Senior, and How Do You Build a Great Team?
A while back I was reading James C. Scott's Seeing Like a State, and toward the end of it he goes on a long tangent about agriculture. Specifically about the high modernist urge to rationalize farming completely, and squeeze the maximum possible yield out of every acre of land.
However, acres aren't the same. Not across a region, and not even across a single field. The soil composition shifts. There are rocks here, and not there. A creek runs through one corner, trees shade another. Even if someone handed you a perfectly rectangular plot, even proportions on all sides, you still couldn't farm all of it the same way, because the ground under it isn't the same.
So what do you do? You sample. You take soil readings across the plot, average them, and fertilize to the average.
Some of that field then performs exactly like you expected. Some of it does better. Some of it does worse. Because you you smoothed the differences away before you made the decision, you never really find out which parts are which. You never find the best that any one part could be.
This is a totally reasonable thing to do! At scale it might be the only tractable thing to do. However, you gave up knowledge of the actual field, in exchange for a number that describes no single part of it.
What Does This Have to Do With Software?
A long time ago I started keeping character sheets for the people on my team.
Not performance reviews. Nothing that went into a system anywhere. Just a running doc, a page per person, describing what each of them actually brings to a team. This one ships terrifyingly fast and won't stop to think about the shape of the thing. This one will spend two days drawing boxes before writing a line of code, but there code will unfailingly be correct. This one is who you want in the room when production is on fire, but is absolutely not who you want owning a greenfield project.
The point was never to grade people. It was to figure out who complemented whom. If I had someone fast and shallow, I wanted someone slow and deep sitting next to them. I wasn't trying to move anyone toward the middle. I was trying to arrange a set of complements.
I've never been able to hand that document to another manager in a way that was useful. I've tried.
For a long time I figured that was a failure of my writing.
Mētis
Scott has a word for the kind of knowledge that doesn't survive that handoff.
Mētis: practical, local, hard won knowledge. What people know who have actually done this work, in this specific place, for a long time. As opposed to technē, the systematic and theoretical knowledge that can be written down, taught in a classroom, and handed over in a manual.
The pilot who knows the entry to this harbor. The farmer who knows this field, not fields in general. Knowledge that is nearly impossible to codify without killing it in the process.
Once you have that word, the seniority ladder looks different.
What separates a senior engineer from a junior one isn't a bigger pile of technē. The junior might well have fresher technē, more recent and better organized, straight out of a program that taught the current version of things. What the senior has is mētis. Pattern matching earned by having been burned. The ability to read a stack trace and know what's actually wrong before the picture is completely clear, because they've seen this shape of wrongness before. The ability to feel an awkward architectural decision before it is a problem.
And look at what the character sheet actually was. It was my mētis. Local knowledge about specific people, in a specific configuration, at a specific moment. Of course it didn't transfer! And the second somebody turns it into a competency framework and rolls it out across the org, it fails, because the only thing that made it useful was that it described those people and not the average engineer.
Scott's argument, applied to running software engineering teams.
We Don't Average Because We're Dumb
This brings to the front a lesson that I didn't understand at first.
We don't fertilize to the average because we think the field is uniform. We fertilize to the average because averaging is the only way we can see the field from where we're standing.
States simplify because states need legibility from a distance. You can't administer what you can't perceive, so you build instruments that render the territory in a form you can act on, and then you start making your decisions against the rendering instead of against the territory. Cadastral maps. Standardized surnames. Scientific forestry.1 Simplification isn't ignorance, it's the price of being able to act at scale.
Engineering orgs do this constantly. Velocity. Story points. Leveling rubrics. Headcount plans that treat an open req as a unit of interchangeable capacity. Every one of those is an instrument for making a team visible in the abstract, and every one of them measures technē, because technē is the part that renders.
Mētis doesn't render. It has never once shown up on a dashboard.
So we manage as though the thing we can't see isn't there.
Sidebar: I can already hear someone saying this is just an elaborate excuse not to measure anything. It isn't. Measure! I'm a rubrics guy, I've written about that before. But know what your instrument sees and what it doesn't, and don't mistake the numbers for the whole story.
The Part Where I Contradict Myself
I want to say that software is uniquely bad at combining these two kinds of knowledge. We chase the new thing. We forget that most of our patterns got paid for by generations of people who hit the same wall we're about to hit.
But I think the opposite is also true, and we live in this interesting tension.
Our best practices are mētis. Compressed. Somebody learned "don't do X" through three outages at two in the morning. It got written down. It became a lint rule. And now you inherit it as technē, a rule with no scar tissue attached to it, and you follow it faithfully.
We pass down the fossil and lose the animal.
Peter Naur got at this back in 1985 in "Programming as Theory Building". His claim is that the real theory of a program lives in the heads of the people who built it, and can't be handed over in documentation. You can ship the code, ship the docs, and still fail to ship the thing that makes the system maintainable, because that thing was never a document in the first place. Forty years on and we're still mostly pretending otherwise.
Software should be unusually good at blending these two, because unlike most fields our theory was written by practitioners. The people who built the abstractions were the people using them. That's a real advantage, and we throw it away every time we flatten somebody's hard won mētis into a rule, and hand the rule to someone who has never seen why it exists.
Fertilizing to the average, on a field none of us has walked.
Where This Leaves Us
Go look at how you're staffing your next team. Not the headcount number, the actual arrangement. Can you say what each person on that team brings to the table? Can you say who still needs to be balanced? Can you say what skill and experience the team is missing? If not, you're fertilizing to the average and calling it a plan.
Then go find the person on your team whose value you've never been able to explain properly in the metrics part of a performance review. That's where your mētis is. Protect it, because the instruments can't see it, and we often optimize it away.
And if you're the one keeping the character sheets, quietly, in a doc nobody asked you for, thank you. That work matters more than it looks like it does. It creates teams that live up to the potential they have.
Footnotes
- Those tidy spaced single species rows were optimized for legibility, easy to count and easy to harvest, and the first generation produced beautifully. The second generation collapsed, and the Germans coined Waldsterben, forest death, for what they'd done to themselves. Meanwhile the Japanese approach to dense mixed planting, a bunch of native species packed tightly together, understory and overstory both, establishes far faster than we believed was possible for a long time. Rebanks is circling the same conlusion from the other side in The Shepherd's Life, and I have thoughts about what a mixed seniority team has in common with a mixed planting... but that isn't the topic at hand, which is why it's living down here in a footnote. Maybe it gets its own article someday. ↩
If you enjoyed this article please share it! I also have a newsletter that you might enjoy as well. Thanks! -Daniel