"The Developer’s Bargain"

After that silent meeting — the one where no one could say what “world-class” looked like — I noticed something else:

Developers don’t just go quiet in meetings.

They make bargains.

One of the most common is this:

It sounds reasonable. Respectful, even. Let management decide the direction, and let the team get on with the work. No interference. No distractions.

But under the surface, this bargain isn’t about autonomy.
It’s about certainty.

I’ve seen it over and over.
Smart, thoughtful people asking for “clear requirements”, not because they’re lazy or resistant to ambiguity, but because they’re overwhelmed by it.

And in complex systems, ambiguity is everywhere.

Plans shift. Priorities collide. Customers change their minds. Engineers inherit incomplete context. Everyone’s under pressure to deliver, and in that kind of environment, clarity starts to feel like survival.

So the bargain is this:

But here’s the catch.

The roadmap isn’t solid ground. It’s a sketch on a moving train.

And when developers opt out of the ambiguity that shapes it, two things happen:

1. They become detached from the “why”, and lose the chance to influence what’s being built.
2. Leaders, sensing that detachment, respond by creating even more structure and control.

So the bargain becomes a trap, where everyone clings to stability, and nobody’s really learning.

The question this raises for me is:

What if the real work isn’t protecting people from uncertainty, but helping them feel safe enough to stay engaged in it?

Until next time,
Dermot
​The Messy Middle

​

✉️ Enjoying The Messy Middle?​
If this sparked something useful, consider forwarding it to a colleague or friend, it might help them too.

If someone sent this email your way and you’d like to get it direct, you can sign up here.