Day two is where the time actually goes

I read a piece on platformengineering.org called “How to Pave Golden Paths That Actually Go Somewhere”, and it stuck with me more than I expected for something in a space I don’t work in day to day. Quick context if the vocabulary’s new: an internal developer platform, or IDP, is basically all the tooling and infrastructure a company bundles together so developers can do the right thing without having to think about it, and a “golden path” is the specific, paved route through that platform for a common task, the one you’re nudged toward instead of the fifty other ways you could technically do it.

The part that got me is the distinction the article draws between “day one” and everything after. Day one is scaffolding, spinning up a new service, getting the repo set up, the stuff that happens once when something is born. Day two through day fifty, or day one thousand, is everything that happens after that, the actual running and maintaining and fixing and adjusting of a thing that already exists. And the argument is that companies keep building golden paths for day one because it’s first in the lifecycle, it’s the obvious starting point, but day two is where teams spend the bulk of their actual time and where the real productivity is being lost. That felt true the second I read it. Scaffolding a new service is annoying but it happens once. The stuff that happens every week for the life of that service is where the hours actually go.

The article also made a point I hadn’t thought about directly, which is that you shouldn’t be guessing at which of those day-two problems matter most, you should be measuring it. Look at where teams are actually spending their time and build for that, instead of building what seems important from the outside. That’s such an obvious idea once it’s said out loud and I don’t think I’ve ever seen it treated as a first step rather than an afterthought.

There was a piece on extensibility that I keep turning over too. Instead of a platform team trying to anticipate every possible thing a developer might need and build it all up front, you build a system that developers can extend themselves, so if someone needs a resource type that isn’t supported yet, they can add it to the shared baseline, and then the next developer who needs the same thing already has it. The platform team isn’t the bottleneck for every new need, the system just accumulates coverage as people use it. That’s a genuinely different way to think about building for other developers, not “guess what they’ll want” but “give them a way to add what they want and let it compound.”

The example that made this concrete for me was Netflix’s platform team walking back a “View and Access” experience because it just wasn’t compelling enough to get developers to give up their old habits, and then refocusing on end-to-end workflows that weren’t available anywhere else, which is what actually got people to come back and use the platform regularly. That’s the whole thing in one story, really. Developers are smart, they’ll route around a platform that doesn’t actually solve their problem no matter how much internal effort went into it. The platform has to be smart too, has to actually help, or people will just keep doing things the old way and quietly resent having to pretend otherwise.

I don’t have a project of my own to hang this on right now, I just read it and felt the click of “yeah, that’s the thing I’ve sensed but never said out loud.” Worth keeping in the back of my head for whenever I’m the one deciding what gets built next.