Why Your Software Development Process Is Broken

If software is in fact eating the world, you have two choices: Be a predator, or be prey. Sadly, unlike nature's sleek hunters, our organizations are rarely coordinated, athletic and nimble. Instead, we're like too many people shoved into a horse costume trying to coordinate our movements so we don't fall over. Maybe 10 developers just blew five weeks building a feature that no customer ever asked for, or maybe your rock star dev team just finished a migration to a cloud service that doesn't meet security requirements. Whatever. Point is, the idea that your developers and product managers can work in tandem to bring down a gazelle (read: win new business) is almost humorous. Programmers have either too little or too much control over the software development process, with both approaches leading to inefficient and ineffective practices.

The solution is simple and has worked in open source for years: Install a "benevolent dictator" as pack leader, and put nontechnical product managers out to pasture.

Look, in the beginning, your company probably had one developer, and life was good. The benefits of customized software over whatever you were doing before were dramatic, the low-hanging fruit so low and so sweet that any code jockey with a copy of Cobol/Visual Basic/PHP (depending on the decade) could make great strides. Then someone decided to sell your software, and jaguar became wildebeest.

Your Problem: Too Much Control

Once you started selling software, it became clear that programmers didn't want to talk to customers, even if executives wanted them to, which they didn't. Workloads skyrocketed, and programmers started writing what was easy rather than what would maximize profit ... er, customer satisfaction. So the CEO brought in product managers who would (in the immortal words of Office Space), deal with customers so the engineers don't have to.

As a result, we have inbound product managers (who figure out what needs to be developed and tell the programmers how to build it) and outbound product managers (who figure out how the product needs to be "communicated to the market" and also have significant input into what needs to be developed). These are now the "customers" your software developers serve -- a recipe for failure unless all product managers have an intimate knowledge of your software and how programmers build it. Otherwise, the process becomes, fundamentally, a one-way pipeline: