I’ll admit I’ve used the term “spec-driven development” myself when describing how I work with AI agents to analyse problems and generate initial solution representations. But I’m increasingly concerned about the implications of this terminology, especially as someone cheekily abbreviates it to “SDD”.

In traditional software engineering, a “specification” meant a comprehensive, detailed document that captured all requirements upfront - a contract written in stone before any code was written. It was the cornerstone of Waterfall, where business analysts would throw specs “over the wall” to developers who were expected to implement exactly what was written, no questions asked. And Waterfall is a dysfunction; not a model for software.

Sobering after-dinner thought: today I had a chat with a friend who’s just joined a large — and quite dysfunctional — organisation. She’s frustrated and a bit defeated after talking to her boss. She’d taken the initiative to highlight several problems and asked for help in fixing them. The answer she got was lukewarm.

One of those classic middle-management responses designed to stay neutral and avoid any real risk.

That conversation reminded me of how organisations evolve. At the start, culture dominates. A small group of people, clear purpose, everyone wears multiple hats. You handle the technical side, someone else manages commercial. There’s trust, alignment, energy. As the business grows, success brings structure. We hire more people. Roles appear. Processes emerge. But with every layer added, structure starts to shape behaviour more than culture does.

It’s quite common to find QA teams still sitting at the end of the delivery line, validating work before it reaches production. Not because they want to be blockers. Many of them genuinely wish things worked differently. They talk about shared ownership, testing earlier, continuous delivery. But then they sigh and say something like, “in an ideal world, yes, but for now developers just aren’t ready to work without us.”

We’ve all been in that start-of-Q4 meeting. Leadership unveils an ambitious strategic initiative and asks: “Can we ship this by Christmas?” The room goes quiet. Engineers shift uncomfortably. Someone mumbles “we’ll do our best” and everyone knows that’s code for “probably not, but I don’t want to be the one who says it.”

There’s a better way to have this conversation. One that respects both the business’s needs and our team’s reality. One that replaces optimism and pressure with data and confidence levels (remember what Robert Martin said: “one of the purposes of Agile is to replace hope with data”).

I’m an engineer at core, but I’ve come to a point in my career where I’m much more than that. I’ve seen lots of pain, fear, damage, and my ‘professional angle’ is much wider than it was when I started my career.

I’ve been working for a long time on how to bridge the gap between managers and engineers.

The problem I often see is that managers think engineers have no business sense, and based on the dynamics I observe in engineering teams, I cannot entirely blame them.

There’s a sad phenomenon I’ve observed in so many organisations: they proudly declare themselves agile, yet somehow end up running waterfall in disguise. The gap between management expectations and engineering reality keeps widening, and I’ve been trying to understand why.

It often starts innocently enough. Leadership embraces agile terminology but struggles to let go of traditional command structures. They want the benefits of agility (speed, innovation, adaptability) whilst maintaining the comfort of detailed roadmaps and fixed deadlines. Meanwhile, engineering teams start with genuine enthusiasm for agile practices, only to find themselves executing predetermined plans with little room for iteration or learning.