The perception of control

Over the last few years I've begun using the phrase "the perception of control" to describe a phenomenon in company decision making I've seen unpleasantly often. I view it somewhat as a successor to my previous pet phrase "un/informed decision making" and coupled to the phrase "the illusion of efficiency" which I’ve also enjoyed using.

Un/informed decision making

I'm pleased to say I've spent most of my career working for small startup companies, where necessity requires that decision making is done by the same people that actually do the work. This usually leads to relatively well informed decision making. However, at least once I have worked for a large company that was structured with vertical silos such that decisions were made by managers that usually knew very little about the subject on which they needed to take the decision. Generally they also didn't have the time or inclination to educate themselves, or at least talk to the 'people on the ground' who actually knew something. Take a look at a recent posting on this subject by an IT professional forced to follow IT decisions taken by his IT-illiterate boss: When servers crash and burn

This vertical silo structure has a secondary effect when large companies try to increase efficiency by creating narrow, specialized roles, which leads me to my second phrase:

The illusion of efficiency

Back in the same large company, I had the rather illuminating experience of being part of a 5 man international team that took 6 months to install a printer. Yes, you heard me right, six months and 4 teleconferences simply to install a printer. This amazing level of extreme inefficiency was the direct result of IT projects designed to increase company operational efficiency through specialization. The point was that if each individual only did one specific task, they would do it faster, perhaps as much as 20% or even 30% faster than someone switching context between several tasks. The end result: IT support was located in Asia, core networking in Germany, Windows domain management in Norway, hardware requisition in Belgium and Project management in Scotland. With business management in California, things could have been even more complicated, but luckily they were only required in one of the meetings. Had we had an onsite IT individual handling all the various IT-related tasks, the project would have taken a couple of hours at most.

More recently I've been in discussions with my current management on the subject of software development efficiency. They can see that 20% to 30% efficiency gains might be possible through the reuse of software code components across the company product lines. I have argued that any fractional operational cost gains will be offset by dramatically increased time-to-market losses. We're not talking 6 months for a 2 hour project, like my previous example, but we're certainly talking about taking 6 month software projects and scaling them up to years. This problem is nothing new. Software companies have battled with these issues for decades, and many books have been written on the subject. One of the earlier ones is ‘The mythical man-month’ covering related issues, but more recently the flood of Agile development books, like ‘Lean software development’, ‘Extreme programming’ and of course the entire ‘pragmatic programmer’ series.

Drawing from experience I can say that for years I too believed in trying to increase software development costs through increased code re-use, or the sibling concept:- coupling existing software projects together to prevent re-inventing the wheel. However, retrospective analyses of such projects lead me to a few ‘startling’ conclusions:

• Projects easily became much more complex than initially expected if any one of a few conditions existed:
• more than one pre-existing code-base or product
• more than one team of software developers
• specification and core development are geographically separated
• Projects intended as ‘prototypes’ or ‘research only’, and as a result were run with small teams with close access to a ‘trial customer’ magically hit much, much tighter deadlines and often with a feature set and level of quality akin to what would have been planned with a ‘real product’ development, but minus much of the heavy project planning.

These observations have made me a natural believer in much of the new Agile development methodology that is such a hot topic these days. Clearly there is a growing body of software developers that no longer believe in ‘silo’d’ projects with ‘uninformed decision making’ and ‘the illusion of efficiency’ driving project decisions. I’m certainly one of them, but unfortunately many managers are not in agreement. This leads me to the main point of this article:

The perception of control

In a small startup company, where there are few people interacting, people generally have a high level of ‘control’ over their environment, colleagues or projects. This is a natural consequence of the fact that any decision maker needs to talk to very few people, if any, to take an “informed decision”. Quite often the decision maker is actually the person that knows the most, and the person that needs to follow through with actions. However, as companies grow, the number of employees increases and jobs become more specialized, decision makers start ending up in the position where they no longer know enough to make an informed decision. Things can go in two ways:

• Delegate. The decision makers entrust aspects of the decision to others who are closer to the data, the customers, or the people on the ground. This requires the ability to trust others, to stick with decisions and to not change the rules of interaction or balance of authority depending on the current political climate. It is a challenging task surprisingly often excelled at by people who are not entrepreneurs, and need to delegate and trust by necessity. Coupled to this is the ability to take blame when necessary, and not look for scapegoats. See this very interesting article on the subject: My Bad!
• Dictate. The decision maker takes the decisions themselves, and maintains total control. This is where the ‘perception of control’ comes into play. No matter how brilliant any leader is, they can only scale so far. Sooner or later a growing company exceeds their ability to maintain genuine control over everything that happens. This is a very common situation for entrepreneurs to end up in. The same strong leadership characteristics that helped that person excel at starting a company and build a new business, often lead to this situation where they cannot successfully delegate. All decisions end up being made based on the dictators ‘perception of control’. They can never have real control because the company has grown beyond that, however their need to feel in control means that they will take decisions based on that feeling, not on real knowledge of the situation.

Paradoxically enough, those that are most dictatorial are exposed soonest and often thrown out by the first controlling VC around the corner, while those that try hardest to do it right and delegate are those that end up maintaining the dictatorial approach for longest. But it cannot last. Dictators are always overthrown.

So, how do you tell the difference between true delegation and dictators operating with the ‘perception of control’? Well it’s not as hard as you might expect. There are a few rather simple things to look for:

• Middle managers admit that success within the company requires having the ear of the ‘decision makers’ (ie. decisions are made through ‘lobbying’, not informed decision making). I observed this situation once when an external management consultant asked key questions as part of management training, and was somewhat distressed by the answers, even though several of the managers involved did not see the problem (since they did indeed have the ‘ear of the decision maker’).
• Strategy decisions are taken in closed meetings, or without the considered input of a reasonable representation of management. This one can be harder to judge, but can show itself through a simply polling of people in the company with the question: do you feel that your opinions are considered in company decision making? Another side to this situation is that the people placed in specific decision making positions end up not having real decision making power, and become mere puppets, which is usually a very unsatisfying role, leading to lack of motivation and often early departure from the company.
• The use of FUD.
• The decision makers are never willing to admit they are wrong: See My Bad!
• Individuals that express contrary opinions to the decision makers are removed from positions of influence. When such people are few, this might not be a real sign of a problem, but when this involves a large number of people, you know immediately that it is a major effort to maintain ‘the perception of control’.

This last point reminds me of a situation I experienced a few years ago, where the large majority of the people involved in a key project were removed from the project and from positions of influence, in order to kill the project. This drastic level of ‘surgery’ was required because the particular project had substantial internal company support, and a very strong business case. The fallout from that executive decision resulted in the loss of a major customer, the loss of several highly talented employees, and several years of subsequent squabbling within the company as it attempted to deal with the business case, which had simply failed to go away. And all this was done in the name of ‘the perception of control’.

Clearly the executives taking the decisions did not feel like they had control over that specific project. And that was in fact quite true. But to achieve the nirvana of stable management for the benefit of the company, true delegation is a necessity, complete control an impossibility, and the ‘perception of control’ a destructive middle ground.