The purpose of a system is what it does
When you’re building, running, or ultimately accountable for any mature system anywhere, the first thing you should understand that is that the purpose of the system is what it does.
The nature of working in a startup is that most business functions are either non-existent or broken and your job (regardless of when you join, honestly) is to help get them working well. Even the founders of the best companies I know, as in the $10B+ ones, will admit that whole chunks of the company are works in progress held together with duct tape at best, and blu tack at worst.
The job as an early hire in any function is to make it work well, and the evaluation of whether you did that will be simply: did that happen? Your intentions don’t matter. Your excuses don’t matter. Not to be all James Heftfield, but nothing else matters. The purpose of a system is what it does.
I recently saw a ex-Sonos engineer quip something to the effect of “please hire me, I worked on the team who focussing on making our product demonstrably worse, year after year, and got my CEO fired”. He was joking, but he wasn’t joking. The CEO ultimately lost his job. Somewhere, at some meeting the Sonos leadership agreed that they should task R&D with relentlessly rolling out unwanted upgrades, with increasingly larger footprints until one day the product just got too shit for everyone. Of course it wasn’t said like that, I bet the slides were slick as shit, but if you looked at it objectively from the outside in and give no benefit of the doubt, that is exactly what you’d conclude.
It takes a while for this to sink in, and your first reaction is always to lead with the counter-argument. I know it seems like this app has just gotten buggier but that’s not what they’re trying to do. I know it seems like we’re producing features no one uses but that’s not what we’re trying to do. I know that it seems like we’re just adding headcount here with zero impact but that’s not what we’re trying to do. But the purpose of a system is what it does, not what it’s trying to do. And if you evaluate the world around you like that, you’ll come to clarity quicker.
Bad shit happens in companies, all the time. And at every point you need to be hard enough on yourself to ask “Am I sure I haven’t actually designed a system that just does this?” and slightly more abstract “maybe locally the system I designed is fine but is it actually deeply integrated with a larger system, and the result of which is broken”, and you realise that’s what it is, and for a few hot seconds you might feel some personal relief. But the system is still broken because of what it does.