Startup-Eng

Somewhere around year eight or nine, the question stops being hypothetical. Both paths are available. The organisation is large enough that both exist as genuine roles, not just titles. You have to actually decide. I’ve been close to this decision twice. The first time, at the startup, it was resolved by circumstance — there was no EM role to take, so staff-track it was. The second time, in a larger organisation, it was a real choice. Here’s the framework I used and what I’d change about it. ...

At the large US technology company, no single team controls the entire system. A feature that touches payments, identity, and platform teams requires coordination across three codebases, three on-call rotations, and three sets of priorities. Getting technical alignment across teams without creating bureaucratic overhead is an active engineering problem. ...

At the large US technology company, RFCs circulate widely. A proposal touching platform infrastructure might be read by engineering leadership, a dozen affected teams, security review, and a product counterpart — none of whom share the same technical context. Writing for a narrow expert audience is one skill. Writing for a wide, mixed audience is a different one. ...

I’d worked at organisations ranging from twelve people to four hundred. The new role is at a company with tens of thousands of engineers. The systems are bigger, the coordination surface is larger, and some things I assumed were universal engineering truths turned out to be scale-specific. ...

I started writing code professionally in 2012. This year marks eleven years. The milestone prompts a kind of stock-taking that I find useful to do in writing. This is not a career advice post. It’s a personal retrospective on what happened, what I learned, and what I’d change — useful mostly as a data point rather than a prescription. ...

In the years at the European financial technology firm, the engineering organisation went through three significant restructuring events: a change in engineering leadership, a shift from functional to product-aligned teams, and a consolidation of two separate engineering groups. Each one produced the same kind of disruption and the same kind of opportunities. Org change is uncomfortable. It’s also underanalysed. Most engineers treat it as something happening to them, not something to navigate actively. ...

The first feature flag I implemented was a boolean in a config file. Toggle it to true, deploy, feature is on. Toggle to false, deploy, feature is off. Simple. The fifteenth feature flag was a percentage rollout with user cohort targeting, metric-based automatic rollback, and a kill-switch that worked without a deployment. The gap between those two implementations is what this post is about. ...

We had an incident that took down pricing for 23 minutes during the London open. High severity, real monetary impact, humbling root cause: a configuration value that worked in staging silently didn’t apply in production due to an environment variable naming collision. The postmortem process that followed was one of the better-run ones I’ve participated in. Here’s what made it useful. ...

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. ...

The team I joined was called “platform engineering.” The mandate was loosely: make other engineering teams faster. The first three months were spent understanding what “faster” meant, which was more contentious than expected. ...