Every engineering team has a roadmap. Most engineering roadmaps are wrong. Not in a surprising way — in a predictable way that reflects structural problems in how they’re created. After doing roadmap planning at two companies at different scales, here’s what I think actually works and why most roadmaps fail. ...
Go’s lack of inheritance is deliberate. The Go designers observed that inheritance hierarchies tend to create tight coupling and fragile base classes — problems that composition avoids. Embedding is Go’s tool for composition: you can embed one type in another and promote its methods, without inheritance’s downsides. It’s more powerful and more subtle than it appears. ...
A service that calls a database, calls another service, or writes to a message queue will eventually encounter a failure. The question is not whether — it’s whether your service handles failures gracefully or cascades them into a larger outage. These patterns are well-documented in the resilience literature. What this post focuses on is the specific Go implementation and the traps that make naive implementations incorrect. ...
The term “technical debt” was coined by Ward Cunningham specifically as a financial metaphor. Debt isn’t inherently bad — it’s a tradeoff: you get something now in exchange for a future obligation. When the metaphor is understood, the management of technical debt becomes clearer. When the moral framing replaces the financial one, it becomes a guilt-driven cycle that helps nobody. ...
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. ...
Go 1.18 was still months away when the design was finalised, but the proposal was public and we were already prototyping. After building several services at the European fintech firm with the experimental toolchain, the pattern of when generics help versus when they don’t was becoming clear. The answer is not “always use generics” or “avoid them.” It’s more specific than that. ...
The startup had been good. We’d grown from twelve people to forty, shipped something real, and the technical foundations were solid. But the Series B had brought in a new leadership layer, the founding team’s velocity calculus had changed, and I found myself doing more coordination than building. I’d been at this inflection point before — at the institution, actually — and I recognised what came next. The new role was at a well-established European financial technology firm. Structured, profitable, engineering-first culture, around 400 people. Not a startup. Deliberately not a startup. ...
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. ...
We moved our internal service communication from REST+JSON to gRPC when the data pipeline scaled past a point where JSON parsing overhead was measurable in profiles. Two years later, the performance win was real and smaller than expected; the developer experience wins were larger; and the operational complexity was a genuine tax that we underpriced initially. ...