Back in the days of what we now call Waterfall, requirements were king.

Intelligent people got together to spell out features long before the first techy got involved.

The Requirements Gathering and Functional Analysis phases defined what we needed to create. Technical Design and Development was all about how to build it.

First, we came up with what to build and then decided how to do it. Perfectly logical. Writing down what we need requires a different skill set than figuring out how to build it. So it makes sense to divide this labor between two groups of specialists. Right?

The days of the Waterfall are long gone, but this separation between “thinkers” and “doers” is a vestigial organ in many organizations.

Company structures often reflect this dichotomy. There’s Business and IT. There’s a Product Manager and an Engineering Manager, each leading a silo.

The tell that gives it away is someone writing Jira tickets without the intent of coding themselves.

“Analysis should run at least a sprint ahead.“
“We need enough User Stories, so the devs don’t become idle.“

Of course, we know that technical insights are vital for design. Of course, we understand that Functional Analysis is the Devil. Yet somehow, this division seems attractive to us.

It creates impactless developers. Worker bees who can’t design features, influence roadmaps, or innovate. Since jotting down ideas is easier than implementing them, we guarantee our developers always play catch-up in an order taker role.

Successful companies come up with ways to break those silos. They involve developers in product design and ensure plenty of agency and innovation time.

Separating the thinkers from the doers is the reddest red flag in agile software development.

It relegates some of your team’s most creative problem solvers to pure execution. It guarantees that those with the least technical insights do all the solutioning.

That’s the road to mediocre software products.