How to Screw up Your Organisation Part 1

Once upon a time, people worked in teams focussed on a common piece of work and had most of the skills needed to do that work within the team. This went pretty well as people sat near each other, usually in the same office and all worked for the same company. Then, as I mentioned in the introduction to this blog, Where IT all went Wrong, managers were persuaded to take people with the same or similar skills from multiple teams and create new capability-focussed teams. So for example all the developers were moved into a development team. This seemed like a great idea because:

• The teams can optimise the use of expensive technical experts by balancing workload peaks and troughs between internal ‘customers’.
• Teams can build capability and enable junior team members to learn from more experienced ones.
• Each team can establish best practice and standards for their area of expertise.
• It facilitates outsourcing and offshoring by providing scale.

Actually, this is a really terrible idea. Let’s look at each of these in turn; next week I’ll look at further downsides of consolidation.

Optimising Resources

It’s a compelling argument that by taking people with similar skills from several teams you will need fewer people overall because you avoid the slack each team has to allow for workload peaks. So often though managers do point optimisations like this without looking at the whole picture. Within the new capability team, everything initially looks fine. OK, they had to add a team leader to manage the team but that was still covered by the optimisation saving. Then they needed a process to prioritise competing demands, so they built a portal and a ticketing process. Then to try to manage the arguments they created a Service Level Agreement. Then to manage all that they hired a relationship manager and a help desk sitting across the capability teams. By this time, no-one wants to go back and look at the business case because it’s already blown, and that’s before you look at the mayhem created everywhere else. But on the plus side, the team has built a queue of work to make sure team members are fully utilised, so the optimisation appears to be going well.

Back out in the projects, things are not looking so good. You had anyway optimised your resources by broadening the remit of the team members, so that a developer say could also turn her hand to analysis or database management. Now, when you want something done you can’t just ask Bill or Jane at the next desk, you have to raise a ticket or fill in a request form. This goes through a help desk that doesn’t understand what you want and relays a scrambled request to someone in a silo team which could be anywhere in the world, likely you don’t even know where. Because the remote team has optimised its workload, you have to wait in the queue to get your request looked at, which likely takes several days. If you complain you get referred to the Service Level Agreement, and I always get the feeling that the stated response time is a minimum as well as a maximum wait time. Once your request gets looked at, the fun really starts. An extended email debate begins, drawing in more people with each response. The two teams are remote so trust breaks down. Your team thinks the remote team is inefficient and / or lazy because they take so long to respond. They think your team is incompetent because you don’t understand the nuances of their particular technical niche. Enter the relationship managers (ladder shakers!) to add to the party. I’ve seen twenty or more people involved at this stage even for a simple request.

So, looking at the whole picture, costs have gone up and projects take longer. Sounds familiar?

Building Capability

You will be able to build a much deeper level of technical expertise which you can deploy across different projects as required. On the downside though, this expertise will be divorced from the practical realities of project life and may develop an ivory tower attitude.

Standards and Best Practice

You can do this better with a lightweight community of practice convened by one of the team as a part-time role. They will have a more rounded view by being part of a less specialist team and having closure exposure to project issues and requirements.

Facilitating Outsourcing and Offshoring

You already know from Outsourcing is Stupid what I think about that, and I will be discussing offshoring in the next few weeks.

Next week I’ll look in more detail at how silo organisations destroy productivity by increasing the communication span between individuals.

Please use the comments below to share your experiences.