Team

On-call has a bad reputation in software engineering, and often deservedly so. Being paged at 3am for an alert that didn’t need to wake anyone is demoralising. Being on-call for systems you didn’t build, don’t understand, and can’t fix is terrifying. Being paged multiple times a night for weeks is a health risk. But on-call done well is a powerful practice. It creates direct feedback between the reliability of what you build and the experience of carrying it. When engineers are responsible for their own systems, they ship more reliable systems. Here’s the version that worked at the European fintech firm. ...

Over two years running engineering hiring at the firm, we made about twenty senior engineering hires. Some were transformative — engineers who raised the quality of everything they touched. Some were neutral — competent contributors who did what was asked and not much more. A few were net negatives. Looking back, the correlation between interview performance and outcome was weaker than I’d expected. The things that predicted good hires were visible in the interview, but we weren’t consistently measuring them. ...

The fintech startup started using RFCs (Request for Comments documents) when we hit seven engineers and decisions stopped being made naturally in conversation. Before RFCs, we’d build something, present it, discover disagreement, and partially rewrite. The disagreement was always there — we just discovered it late. RFCs in theory: write down what you’re proposing before building it, get feedback, align, then build. RFCs in practice, initially: long documents that people didn’t read, discussions that went in circles, and decisions that weren’t really made. The format that fixed it took six months to evolve. ...

The standard startup narrative is that small teams move fast because they cut process. No PRD approval chains, no design committee sign-off, no six-week delivery timelines. Just engineers and a product idea, shipping. That narrative is true as far as it goes, and incomplete in important ways. The startup I joined from 2019 to 2021 was fast for reasons that went beyond “we skipped the bureaucracy.” Understanding those reasons changed how I think about engineering productivity in any context. ...

I was promoted to tech lead at the startup in early 2020. The team was five engineers, including me. My previous experience managing people: none, unless you count mentoring a couple of interns. The first month was humbling. The second month was better. By the third month I had a clearer mental model of what the role actually required and how it differed from what I’d been doing before. ...