There's a conversation happening in engineering right now. People call it a DevEx shift. I don't have clean words for it yet. The ground is moving too fast; whatever I said six months ago is already stale.

But I know what it's not. It's not about tooling.

Building the tool is the easy part. Deploying it is the easy part. None of that lands if nobody uses what you built.

Who gives a crap about things that are never used.

That question cuts clean through every conversation about DevEx. The beautiful internal portal. The golden path template nobody follows. The CI pipeline that shaves seconds off a build two teams know exists. All of it; irrelevant. Elegant architecture; irrelevant. If nobody uses it, it's not a platform. It's a monument. You built a thing and walked away. The organization routed around it before you finished the README.

Start at the destination: adoption. Work backward from there to what enables it. Start with the tool and work forward and you build monuments. I've seen it a hundred times. A team spends six months on an internal platform. They launch. They declare victory. Two quarters later somebody runs the analytics and the thing has three users. Two of them are the team that built it. That's not adoption. That's a memorial service for a product nobody asked for.

DevEx is shifting because engineering is shifting. Code production is being commoditized. Not replaced; commoditized. The work an engineer produces is worth less by the unit. What's worth more is what they decide: judgment, taste, knowing what not to build. That work doesn't fit in a ticket. Doesn't fit in a sprint. Doesn't fit in a metric.

Most organizations never cross the gap between deploying and adopting. They deploy; they declare victory; the engineers route around whatever was built and keep doing what worked before. Nobody checks whether anything took root. Nobody knows what root looks like in this context. Root looks like an engineer choosing your thing when they have a choice. That's adoption. Everything before that is just installation.

Adoption is the only measure that matters in compliance-heavy environments. I know that because it's what I'm building for. Call it Speckl if you need a name. It's scaffolding for agentic engineering where the problem isn't generating code fast enough. The problem is whether you can ship it. Whether it passes audit. Whether anyone trusts it. If a compliance team won't sign off, adoption is zero. If an engineer has to copy-paste out of the tool to do their actual work, adoption is also zero. Adoption is binary. You cannot half-adopt a tool. You use it or you route around it. Routing around is the default state of the world. Getting someone to stop routing around is the work.

The first user is the hardest one to get. Most teams invest in the launch; not in that first user. They prepare the staging environment but not the person. They write onboarding docs but don't sit through the friction. The first user doesn't need documentation. They need someone who cares whether the tool makes their actual Tuesday better. Not their hypothetical Tuesday. This Tuesday. The one with the compliance deadline and the review backlog and the ticket three days overdue.

Adoption is social. One engineer uses something; their life gets visibly better; others follow. But you have to get that one. You don't get that one by launching. You get that one by listening to what makes their Tuesday hard and building the thing that fixes exactly that. The Tuesday problem is always different from the deck problem. Always.

The tool that gets adopted is rarely the best tool. It's the tool that solves the problem people actually have. If your engineers are drowning in compliance documentation, a tool that makes documentation faster gets adopted. If leadership bought a tool to measure productivity, it won't. The difference is whose problem it solves.

This is where I see most platform teams go wrong. They build for a problem they diagnosed from two levels up. They build for what leadership said was the problem. They build for what they wish engineers cared about. They don't build for the Tuesday problem. The Tuesday problem is always different from the deck problem. Always.

DevEx is shifting from what you provide to what gets picked up. Supply-side to demand-side. Pushing tools to cultivating conditions. The words are still forming. But the direction is clear: adoption is the destination. Everything else is the ground you prepare to get there.

I don't have a neat framework for this. A framework implies the thing is settled. It's not. But the question stands. Who gives a crap about things that are never used. If you think about DevEx, start there. Not at the tool. Not at the stack. At the moment a human being looks at what you built and decides whether to try it. That moment is everything. Nothing else matters until that moment goes the right way.

The floor is open. What's your Tuesday look like.