The Buck Stops Over There

When software development projects fail, somebody needs to be held accountable. When corporate HQ is calling to find out what the heck happened, somebody needs to be ready with an explanation. And, yet, what often happens at companies both big and small is a very sophisticated game of buck-passing. In short, there is a total lack of accountability. You know the drill: the backend engineering team blames the frontend engineering team, which blames the sales team, which blames the marketing team, which blames the legal team, which blames the new guy who just started at the company a few days ago (“It’s his fault we’re late with the project!”). Unfortunately, this finger pointing is a very counter-productive process. Instead of trying to figure out why a project failed, and what steps can be taken to prevent similar failures in the future, the misguided focus is on trying to figure out who is to blame. However, you can bet that the sales and marketing team is never going to admit that they were being a bit too aggressive in over-promising what a product could actually do. And you can also bet that super-talented programmers and engineers, all of them pulling down six-figure salaries, are never going to admit that they were responsible for a project failing. And if you think that the CEO of the company is going to fall on his (or her) sword over a software project, you’ve been drinking way too much of the Kool-Aid. Let’s be honest here, there’s no such title in the corporate world called “Fall Guy.” If somebody does not have to accept blame for a project, why should they? It’s only human nature to point the finger at someone else. After all, there are three simple words that every person learns from the time they are little children: “It wasn’t me.” That’s why many software development teams specifically designate one individual to be the “project owner.” This person is accountable if something goes wrong. (But never if something ends up going right, but more of that later…) It’s this person who steps up to the plate, admits blame, and accepts responsibility. When you designate a project owner, you immediately end the game of buck-passing. Everyone knows who is responsible, and everyone knows who is to blame. So you immediately eliminate this very unproductive and morale-sapping part of the workplace. Instead, you can focus on making changes and corrections and fixing what’s wrong. In fact, this is really one of the key principles of software development today — the whole idea of continuous process improvement. Everything is an iterative process, and everything is in continuous beta. You might even say that this new way of thinking about product development has taken some of the sting out of failure. Suddenly, it’s not so risky to be the anointed Fall Guy because nobody expects things to turn out perfectly in the end anymore. So if you’re looking for a way to improve the success rates of your software development projects, think about ways that you can introduce accountability into the workflow. When SHTF, somebody needs to be ready with a good answer. Hey! I’m , an entrepreneur and maker. You might know me from Mevee, and , among other products I’ve launched! This article is a part in a larger series I’m writing mostly based on my experiences and is largely made of my and my team’s opinions. Tomer Crane Shots I hope this helps you to avoid making the same mistakes I did, and remember to keep shipping! reasons why Software Development projects fail : This article is part of a series 10 System Requirements Can Bring Any Software Project To a Screeching Halt Hey, Who Moved the Goalposts? What We’ve Got Here Is Failure to Communicate Poorly Defined Outcome “Your app will be finished on Tuesday.” — which Tuesday?!