The best solutions tend to come from people or organizations that are close to the problem. This is true for any complex system: companies, government, and software.
Who can make the best decision about whether you should buy a small, medium, large, or XL t-shirt? Choose from the list below:
- The president of the united states
- The governor of your state
- The mayor of your city
- The CEO of your company
- Your boss
- Your mom
- You
People closer to the bottom of the list are closer to the problem. Your boss can probably make a better guess at your shirt size than can the mayor of your city. Your mom can probably make a better guess than that. But the person best equipped to answer the question is you.
Despite this, people have a natural urge to push decisions up the hierarchy. I suspect this is a desire to abdicate responsibility: they can say “this thing I’m doing is waste of time, but my boss wants it” as a way to avoid the time, energy, and risk associated with taking ownership for the problem.
For example: IT decisions made by upper management of a large company are almost always terrible. Expensive, heavyweight solutions like Oracle or SAP drain company resources for years as they are implemented, and the amount of value provided in the long run stacks up poorly on a cost-benefit analysis.
Compare to lightweight solutions snuck in the back door: Linux, Apache, MySQL, GMail. These are a better fit for the problems they solve; and their low time/money/energy setup and maintenance costs means they score high marks on cost-benefit. Yet such solutions are almost always resisted from above, and only gain traction because they solve problem immediately and extremely well - as judged by the people close to the problem. They sneak in the back door and then become vital pieces of the company’s infrastructure, while at the same time the top-down initiatives struggle to get running at all.
Are there any legitimate reasons to push things up the hierarchy? Certainly. Some types of information, like spotting broad trends, are hard to do in the trenches. There is also efficiency to be gained by standardization, which is unlikely to occur if all the individuals working in a paritucular role but in different places (say, car mechanics working at repair shops in different geographic locations) are not in contact with one another.
In historic times, the inability to diseminate information caused power to be pushed way up the hierarchy. Kings, popes, and more recently, presidents, prime ministers, and CEOs ended up making a lot of decisions even though they were quite far away from the problem. This probably made sense when information was so hard to share, and when economies of scale could be achieved by uniformity. Nations, companies, and yes, even software projects tended to grow in scope as they were successful, which removed the people at the head of those systems ever further from the problem.
Standardization was a similar issue. Without a top-down edict from the king, you were unlike to get a standard currency, a standard width of road (which matched that of the carriages), or standard weights and measures.
But we’re now at the cusp of an era of decentralization. Big companies are struggling to compete with small ones; sprawling software systems are giving way to lightweight, loosely-coupled tools assembled via package managers or service architectures. Information can be shared instantaneously, allowing members of a group to make better decisions than any one individual. Standards bodies spring up from among the self-organizing groups of people who are working in the same role.
So next time you’ve got a decision to make, whether it be in your company or on your software systems, ask yourself: how can this decision be pushed closer to the problem? Can you build an independent component, rather than adding it to my monolithic central codebase? If you’re in a mangement position, can you push the decision down to the people who are hands-on with the problem on a daily basis?