How I run a small engineering team
Concrete, honest, occasionally uncomfortable — the operating rules I use to keep a small team fast, aligned, and sane.
DRAFT — replace with Matthias’s own words.
I’ve managed teams inside a large company and I’ve built one from scratch. Small is harder in ways nobody warns you about. There’s nowhere to hide a bad process, no slack in the system to absorb a bad week. Every structural mistake shows up in the next sprint with your name on it.
Here’s roughly how I run things now. None of it is novel. All of it is hard-won.
Context over control
The single highest-leverage thing a small-team lead does is transfer context, not tasks. If I find myself assigning tickets, I’ve already failed — it means the person doesn’t have enough of the picture to see the work themselves.
So I over-explain the why. Why this customer, why now, why this tradeoff and not the cleaner-looking one. It feels like too much. It is never too much.
A small team doesn’t need a manager who assigns work. It needs one who makes the work assignable to itself.
Protect the maker’s day
Engineers produce their best work in long, uninterrupted blocks, and a small team can’t afford to fracture them. My rules are boring and non-negotiable:
- Meetings cluster; they don’t scatter. One bad 2pm meeting can cost a whole afternoon on both sides of it.
- Async by default. If it can be a written update, it is one — and the writing itself sharpens the thinking.
- The lead takes the interrupts. Someone has to absorb the pings, the “quick questions,” the context-switching. On a small team that’s my job, precisely so it isn’t theirs.
Disagree in the open, decide once
Small teams die from unspoken disagreement more than from loud argument. I’d rather have an uncomfortable ten-minute debate than a comfortable decision nobody actually believes in.
The rule I borrow and keep: disagree and commit, but do the disagreeing out loud first. Once we decide, we decide together, and we stop relitigating it in side channels. If new evidence shows up, we reopen it deliberately — not by quiet foot-dragging.
Hire for slope, not intercept
For the roles I hire, I care far more about the rate someone improves than where they are today. A brilliant engineer who stopped learning three years ago is a worse bet, on a small team, than a hungry one who’s visibly better every month.
Concretely, in interviews I ask people to teach me something they learned recently and got wrong at first. What I’m listening for is whether they enjoy being wrong on the way to being right. That trait, more than any credential, predicts who thrives when the ground keeps shifting — which, on an early team, it always does.
The uncomfortable part
Running a small team well means being legible about your own mistakes, out loud, first. If I want honesty about what’s broken, I have to model it — including when what’s broken is a call I made. That’s the part no framework prepares you for, and it’s most of the job.