trust scales

a VP of engineering posted on linkedin recently. he said:

“we need five senior engineers in the same room to debug most issues.”

and then:

“if someone tells you they can’t investigate without multiple people, they’re probably not senior. Real senior engineers own a domain independently.”

i called it:

completely delusional.

where the disagreement starts

here’s what i think:

where senior — staff, really — engineering fits in this model is uncomfortable for most orgs to hear. the engineer’s job isn’t to own the hardest problem. it’s to be the person who helps make the unit cohere.

in greek terms, they’re not the strategos giving orders from the rear. they’re the person in the front rank whose presence means the line holds. they’re in the boats with everyone else — and what they contribute isn’t a better technical decision, it’s the fact that a decision gets made at all and everyone commits to it. that’s the unsung hero yielding better outcomes. not having someone you can scream at because “ownership.”

this is the difference between teams and products that succeed and stay stable, and the ones that break themselves apart. the failure mode i see constantly is companies treating staff-plus as a reward tier for individual contributors who are really good at owning things. so you get a staff engineer who “owns” the data platform and a staff engineer who “owns” the API layer and they all interact through architecture review documents. nominal alliance, no care. no shared commitment. people leave. individual owners break and fall. and wont go for drinks, either.

that got more traction than i expected. 43 likes, predominantly from engineering leaders across FAANG, and a thread that turned into something worth writing about.

where i learned this

“Airplanes are beautiful dreams. Engineers turn dreams into reality” — Caproni, The Wind Rises

here’s the part i don’t talk about much.

everything i know about engineering consistency, about high performance, culture, lean teams, and about how people move together — i learned from a much darker place than i let on. for most of my journey i worked with an engineering leader who was, from a pure technical and organisational philosophy standpoint, a genius.

i don’t use that word lightly. this is someone who understood how consistency creates lean companies down to formal models, through social contracts as well as in code. he understood how to generate leverage in both those contracts and norms to get people moving in the same direction.

he could see the architecture of how teams of people work, at scale, and apply that vision to simplify the architecture of systems in ways most engineers have never seen, heard, or ever even thought about.

i’d say 90% of everything i know about building software, building teams, and building culture is derived from him, and that the ideas themselves are nothing short of brilliant.

the delivery was something else.

he would tell me i was fucking things up. he would say he couldn’t understand a word i was saying. that i was actually using english wrong. that i was inventing word usages. he went as far as telling me i was making everyone’s life harder and more miserable, that my communication was lacking empathy, that i was a net negative to the organisation.

i broke down in tears on multiple occasions. and i kept coming back. because i cared. truly, cared. about being the best engineer i could be, about defining for myself and unlocking what that actually meant.

i see so much beauty in what engineering accomplishes for humanity every single day, and i wasn’t going to let go of that. so i fought for it. i convinced myself i could extract the value nestled within the wounds under my skin. and like a boxer i took every hit, i felt ashamed to be myself, and i stayed.

ironically, when i eventually asked those people, the ones he said i was making miserable, they told me he was saying the same things about them.

that’s not feedback — telling each person individually they’re the problem, banking that nobody compares notes — that’s a weaponised isolationism. the moment we all talked to each other, the whole illusion evaporated.

to be clear, i never resolved him into one thing. that’s not how i see people. i see everyone in plain sight, never with a label, and try to take in the beauty and the harm.at his core, he genuinely knew his stuff. he genuinely taught me things that shaped my career. he is genuinely kind. and, i think he genuinely cared. how he cared about engineering and our shared ethos is how we cemented our friendship to this day and accomplished so very much together.

“I’m not being cruel, I’m being honest, and honesty is the real empathy!”

Such a twat!

if he’d just been a bumbling idiot who shouted, i’d have left and forgotten him. the fact that he was brilliant, and the fact we worked so hard together is exactly why the cruelty landed so hard and why i was still sorting through it years later.

because we fought wars together. real ones. we founded a company that is now on the NASDAQ, we were at the helm from the very beginning. and when things got bad — and they got bad — we worked for free. we chose that. and when the funding came through we paid ourselves off and kept building.

what we built was something i’ve never seen before or since. technology standards that enabled an entire engineering division to move in absolute lockstep. socially consistent, topologically consistent, so clean that 4000 commits a year pre-ai was trivial for any single engineer on the team — without accruing any tech debt whatsoever. that wasn’t an accident. that was the system he designed and we all bled to build. and every one of us knew it.

we were proud of it in a way that’s hard to describe to anyone who wasn’t there. we formed a culture around defending the marvel we had achieved and the work we had put into improving each other to get there. that kind of culture bonds you to someone whether or not it was always healthy.

for a long time after we all yearned for it — once more.

compounding debt and compounding interest

now that i’m an engineering manager, at a company that makes sense, i see the other side of the coin. rough waters make for rough turbulence. it makes you think “why is this person not more efficient.” “why are things moving so slowly.” and even “maybe we should let someone go.” i think sometimes when we are striving for greatness we are never quite satiated. sometimes we are constantly preparing for disaster because we feel we have to, even when the waters are fine.

so, i get it. i understand the pressure that made him the way he was.

understanding it doesn’t mean repeating it.

a reply came back in the thread:

“the head chef shouldn’t be chopping lettuce. what about the opportunity cost? if your senior dev is spending all their time chopping lettuce, leaving more complex architecting and mentoring unattended — isn’t something being lost?”

and i understood the question immediately. because i’d lived on both sides.

i know what compounding debt feels like. i’d been it. i was the engineer someone looked at and saw a net negative. the one who was told he was slowing everyone down, making people miserable, wasting the organisation’s time. that is what it feels like to be treated as debt.

and honestly? sometimes it’s real. sometimes you’re struggling with something foundational and it’s causing real problems. if the product is a salad, it’s not going to work well without good lettuce. goes without saying. and if leaving your junior to chop the lettuce of your salad company is causing debt, that’s foundational, it has to be fixed.

the question is how you fix it.

the lettuce story

you can do what was done to me. you can tell someone they’re the problem. you can isolate them, criticise them, use fear to try to squeeze performance out of them. and maybe, if they care enough, they’ll survive it. i did. but that’s compounding debt. it costs you the person even when you keep the output. it costs you trust. it costs you the team. and eventually the principal comes due. so what’s the alternative?

i responded, you invest:

there was once a junior developer chopping lettuce roughly while the senior dev was silo’d into mixing. the senior noticed. and instead of telling the junior they were the problem, the senior got beside them. coached their process. helped them get more efficient.

eventually the junior grew strong. chopping lettuce so well, they got into the ‘complex’ mixing project, and freed up the senior’s hands elsewhere.

that senior developer was me. i learned very quickly how mentorship and trust compounds into real gains. i applied that three times over and quadratically multiplied the number of projects i can work on. because i work through and with the team. thats the story of how i became a lead.

i knew what it felt like to be treated as debt. so i chose to lead with trust. because i’d been the person on the other end. and i resolved there had to be a better way.

not because it’s easier — it’s not. it’s annoying. it’s thankless, time consuming, and frustrating.

its a mistake to think the senior engineer’s time is more valuable than the junior’s prima-facie. the end goal is to trust your juniors to move and act like seniors.

but it’s not seniority that scales — that’s the red herring.

if you teach well and create trust, trust scales.

beyond good and evil

so this whole thread reminded me of how i got to where i am.

“completely delusional” is not a diplomatic opening. his willingness to call things delusional, to refuse to accept mediocrity, to say what everyone else is tiptoeing around. that’s definitely his energy running through my voice.

often, i’ve asked myself whether what we built was only possible because of how he was. it was built with extraordinary conviction but zero tolerance for deviation — and maybe that’s inseparable from the person. i spent every year since trying to prove it wasn’t.

i can now confidently answer. i have grown despite that approach, not because of it. the proof is in what i advocate for. standing beside others and using the same ruthless consistency and trust as the north star of building both systems and high performing teams.

i took his technical lessons and rejected his methods. that part is not his success story. that one is mine. and trust scales.