How to Screw Up Your Organisation Part 2

OK, I’m a week late with this one, Steve’s story was so timely I posted that last week instead. Last week I talked about the commonly given benefits of consolidation and why they are not as attractive as they seem. This week, I’ll go further and look at the unintended consequences which everyone below the truth ceiling sees every day.

• Any project will typically have to work across multiple silos each working to their own priorities and constraints. These silos typically span multiple locations, companies, teams and time zones. We saw a small example in the story last week of how this dramatically slows down projects. I have seen many other examples (see Ever wondered why you can’t get anything done?) and heard so often from people experiencing the same problem.
• Decision rights are unclear and far too many people get involved, typically on conference calls. I have often joined 50 or more people on an incident call. Typically, about one in ten of these people has the expertise to make a useful contribution. For the rest, either they say nothing so are of no use, or worse they feel they have to contribute and ask pointless questions or throw up unnecessary obstacles – this is what I call shaking the ladder, and led to the name of this blog.
• Each silo is optimised in isolation leading to work queuing to keep staff 100% utilised and by driving down skill levels by minimising day rates. While in isolation this appears to save money, as we saw last week it causes mayhem for people using the silo services so overall there is a cost increase rather than decrease.
• Each silo team starts to develop processes to manage its workload. Typical symptoms are portals, request forms, tickets, service (or operating) level agreements and relationship managers. This is one of the main reasons why a simple job takes five weeks instead of five minutes. When I worked as a database administrator, if I needed something done to a filesystem, I’d walk about ten yards to the system admins, get through some occasional surliness and get the change done. If we disagreed on how to do the work, the boss was right there and could bang heads together. Now there are change request forms, change managers, authorisation from large numbers of people who have no idea what is being changed and are anyway unqualified to judge if it makes sense. Then you have to wait for a ‘change window’ and so on and on and on. Above the Truth Ceiling senior executives are still claiming cost savings.
• The members of the silo teams may be experts in their technical field, but if the silo is outsourced then the outsourcer will recruit at the lowest rate and therefore minimum skill level. Further they are separated from the context of a request or incident, and as a result may make stupid decisions. I have experienced a system admin who just saw systems by their number. As a result, he made no distinction between a low criticality file/print server and a critical database server and rebooted the latter, taking down a key system for several hours.
• Issues and requests get escalated to senior levels to reach a point where all the silos are represented causing delay and wasting time of expensive senior management who don’t understand the issue anyway.
• A couple of real examples I have seen:
  • A simple, low risk configuration file change took 3 months and involved at least 12 people.
  • An attempt to fix a minor system misconfiguration entailed an extended debate between multiple parties in multiple companies and locations as to exactly how to perform the fix and who was responsible. The debate went on for ten months.
  • A new joiner employed for six weeks before his company laptop was ready.

The following highly simplified diagram of two project teams shows how silos break up the interactions between people who work most closely together.

The strong interactions are between individuals within each project (horizontal); these people are typically working under intense pressure and their primary interactions are with members of their project team, because their main focus is (or at least should be) on delivery of project artefacts or a support service, not the business of the capability silo.

Interactions between peers along the capability lines (vertical) for standards, best practice and shared learning are important but much less intense.

So here’s the problem. Consolidating the vertical silos increases the communication span between people who need to work closely together. Where they could be sitting next to each other, now they are in different departments with different managers, even in different countries and / or working for different companies.

Next week in Rise of the Zombie Ladder Shakers I’ll look at how we got to the point where about half the organisation are doing non-jobs.