I have always been amused at how far behind the software industry is to the manufacturing industry. There is no question, of course, that software has by and large replaced manufacturing in America. There is no question that Americans work more with creating new ideas than with tangible goods. Still, in manner of thinking and management of process, software lags behind.
Take, for example, the software project in trouble. In manufacturing, each person involved in the job is responsible for overall success. When the machines are being set up prior to starting to make something, the setup men are responsible for noting when something is wrong with the tooling and letting people know. Before the line starts up, the setup men and the line leader are responsible for running a test run and validating that they are building the right thing, that it meets specifications, and that there is nothing wrong with the end result before they waste the company’s money building thousands of wrong widgets. Once the line starts up, each worker is responsible for stopping the process if they discover something wrong. Toyota and other manufacturers have been famous since the 80s for the ubiquitous “quality line”, the magic line that any worker can pull and is responsible to pull if they see that the process has gone off the tracks. Manufacturing knows that the longer you wait to address a problem, the more it costs, and that you are better off to stop and fix things and miss your deadline than you are to deliver the wrong thing.
Not so in the software world. The industry is rife with discussion on the topic. New articles pop up online. Depending on who you read, the Project Manager is responsible, the development manager is responsible, the BA is responsible, the list goes on and on. Some (rightly) declare that, like in Manufacturing, everyone is responsible.
One could debate this all day long, but the reality is, we’re all asking the wrong question. People want to do good work (unless they’re just worthless employees). They want to do the right thing. They don’t like to waste their time. Everyone is willing to declare that projects are going down the wrong path if it is the right thing to do. Assuming you believe that about your employees (and if you don’t, you have the wrong staff), why do they not pull the line? Why is not pulling the line an epidemic in software development and project management?
The answer is because corporate leadership is teaching us all that pulling the line is wrong. Leadership shoots the messenger 99 times out of 100. The Death March must continue. No one wants to tell the customer we’ll be late. We’re teaching our workers through an almost Pavlovian punishment model that somehow the customer will be happier if we deliver a half-working thing that isn’t what they asked for instead. This is driven by a lot of things- fear of conflict with the customer (pretending there won’t be conflict when we deliver garbage), fear of telling the stockholders (pretending the stock isn’t affected by delivering garbage), fear of trying to stop the inertia or being called a finger pointer (pretending that if someone has screwed up and not taken responsibility for it, the finger should not be pointed).
Of all the problems in corporate culture today, this, more than any other, needs to change. In the last fifteen years I have changed companies a half-dozen times. A number of my friends have changed jobs as many as a dozen. In almost every case, the root cause has traced back to this. Company leadership refuses to face their problems and shoots messengers until either the company folds or so many projects fail that there is a significant purge of personnel within the company. You will never, ever deliver the right thing until you enable your employees to be able to stop delivering the wrong thing. If you are a corporate leader out there today, ask yourself some questions:
- Do I have a culture in my company where people can pull the line without fear?
- Do I even have a line? Is there a true, properly managed process for raising the red flag on projects with appropriate visibility?
- Do people know the process for raising red flags? Is making sure they know how part of project kickoff and project management?
- Is the process effective? Are there actual action items can be addressed as a result of the red flag process? Are they monitored and followed through on?
- Do I have a REWARD system for raising the flag? If raising the flag saves me from wasting money, why on earth not?
- If I am responsible for leading, is it not ultimately my fault if we fail due to flags not raised? Isn’t my own career ultimately on the line here?
There is a popular saying in the corporate IT world that has always amused me: ”No one was ever fired for buying IBM.” We live in a risk-adverse culture where the main risk we avoid is conflict. I challenge you to address this problem and pound the solution home until you overhear this in meetings in your company instead: ”No one was ever promoted for covering up problems”.
