A chair for the engineer
I keep wondering why the people who know the system best are so often outside the room where the plans get made.
Let’s say you’re at the weekly engineering leadership meeting.
There’s a dozen managers in the room, we’ve got this doc, we have a list of projects and there’s little colored dots alongside each one.
The migration’s going according to plan. Everyone nods, since they haven’t looked at the code for a month. “According to plan” sounds so nice - there’s no checking against anything.
And then let’s say one of your senior engineers sits in the room. With you.
All the same things: same dot, same “according to plan”.
One of them, from the far end of the table, gently mentions that the data backfill isn’t even begun yet. And that’s the longest part.
The air’s maybe a degree or two colder now. Embarrassing, I suppose, for the dot-painter. But useful.
So I’m leaning toward the idea that senior engineers should just be in the meeting as members. Like, full members, not “oh we’ve got this one topic we want to invite you to talk about, so please feel free to exit after we’re done.”
They’d be in all the discussions, unless there’s a specific reason not to, such as calibrating the performance of a peer. With the same faith in them as everyone else. And the same consequences if it’s broken.
I think a big reason for me leaning toward this is seeing companies treat their senior engineers like children a lot. Like, sure, we’re happy for you to make a decision that’ll affect the system for the next five years. But please leave the reasons for the hiring plan out of reach.
That’s a weird thing to do.
And maybe it’s not a case of there being a lot of bad technical decisions because of bad managers. But because of there not being sufficient information for anyone to disagree in the room.
Not more status reports is going to fix that. Because what’s going to happen is there’ll be more dots on the room.
I think that’s more urgent now than it was a few years ago.
Because in a lot of teams now it’s agents writing most of the code. And that hard work is moving to the space of judgment (“what do we build? what do we accept? what can the system handle?”).
Which is exactly the kind of things a leadership meeting makes decisions on. Except that the ones with best judgment about those things aren’t necessarily managers.
Yes. I don’t want to dismiss them.
Yes some issues are touchy. But the ‘that’s touchy let’s just not include anyone’ before is better served by some narrow special case. And a lot of the issues discussed at those meetings aren’t even confidential - just not shared.
Some engineers will want a veto. This seems to work itself out since the guy in the room is on the hook for whatever gets decided in the room. Engineers who want to be authority without being on the hook usually find the chair uncomfortable. So it will take longer. It takes longer for the things that probably should take longer. Ten minutes of awkward questions is better than having to do it over two months in.
And engineers will take context back to their team. I don’t see the downside in this one, and I’ve tried.
If you’re a small team there might not even be a formal meeting. Just the guy who’s in charge of engineering and a couple founders going over what to trim for coffee. Same idea, smaller table.
I like the bit that makes managers a little less managerly and engineers a little less engineering-y. The managers need to know technical specifics. There’s someone in the room going to ask about that. And the engineers get to learn why the deadline is the deadline and what hiring freeze looks like from the other side of the table. Everyone becomes a bit less abstract, a bit less surprised.
Sometimes I wonder what those colored dots would look like if the people closest to the work had been dotting them. Probably more orange.