We celebrate velocity. We track story points. We measure commits, PRs, features shipped per sprint. Teams get rewarded for moving fast, for closing tickets, for hitting deadlines.
Very rarely does someone ask: did we build the right thing?
When you ship something nobody uses, everyone loses. Time gets wasted. Energy drains. Morale drops. Even when it's not your "fault", it still feels like you could have spent that time on something that mattered.
The Vicious Cycle #
Here's the pattern I've seen play out: Developers propose ideas during discovery. Product shoots them down or just doesn't ask in the first place. After enough times getting dismissed, developers lose the energy to contribute. They feel less relevant to the actual problem-solving. They become indifferent to what they're building. They start acting like order-takers.
And then the organization complains about developers who "just want to code" and don't think about the business.
The structure creates the very problem it complains about.
When It Clicked for Me #
I've been on teams where this wasn't the case. Building an API for internal cross-team use was one of those experiences. The users were right there. I could talk to them, understand their problems, see the impact of what we built.
The feature had meaning because I knew its purpose. I wasn't translating specs into code - I was solving a real problem for real people.
That changes everything. When you know the "why," you can push back on unnecessary complexity, suggest better approaches, measure if it actually helped. You're not just implementing - you're delivering value.
What Most Teams Actually Do #
Most of the time, dev teams get handed a "what" to build. Figure out the "how" part. And sure, most people enjoy the technical challenge. But after a few rounds of misalignment on the "why" - after building features that miss the mark or sit unused - it drains morale and energy.
In the end, you get disappointed users and exhausted developers.
What Delivery Actually Means #
Here's what we forget: users don't care that it's software. They come with a problem - they need to save money, work more efficiently, get past an obstacle in their work or life. Software just happens to be our tool for solving it. They'd take magic if that worked instead.
What matters isn't the elegance of your code or the cleverness of your architecture. It's whether you actually solved their problem.
When developers deliver value instead of just features, it looks like this:
- Understanding the "why" before diving into the "what"
- Questioning requirements that don't seem to serve the actual user problem
- Measuring whether what you built actually helped, not just whether you shipped it
- Saying no strategically when a feature won't solve the real problem
It's a complete shift from code producer to problem solver.
But here's the thing: in many orgs, developers are blocked from this engagement. Product owns discovery. Developers own implementation. The handoff seems clean on paper.
In reality, it's artificial. Developers have technical insights that matter for discovery - what's feasible, what the trade-offs are, what patterns we've seen work. Product has context that matters for implementation - why this matters now, what success looks like, how users actually behave.
Splitting this knowledge creates the waste everyone complains about.
What You Can Do #
If you're a developer (even in an imperfect org):
- Ask "why" persistently. Make them explain the problem, not just the feature.
- Build relationships with users when you can. Even informal chats reveal context that tickets don't capture.
- Propose alternatives when you see a better path. You might get shot down, but sometimes you won't.
- Measure your own impact where you can. Did the thing you built get used? Did it solve the problem?
If you lead teams or build organizations:
- Create space for developers in discovery. Their technical perspective matters for feasibility and trade-offs.
- When you dismiss their ideas reflexively, you create the indifferent order-takers you complain about.
- Align incentives around outcomes, not output. Celebrate solving user problems, not shipping features.
- Let developers talk to users. The translation layer is where meaning gets lost.
The Question #
What did you actually deliver this year?
Features? Or solutions to real problems?