Anyone who has worked in a large IT department will be familiar with an org structure that splits people into functional silo teams – all the telecoms specialists together in one team, all the server folks in another team, and so on. They may be on different floors of the same building. They may be in different buildings altogether. They may be in separate continents.
At the other extreme, the small IT team is full of Jack-of-all-trades technicians. They end up doing everything – installing hardware, loading software, setting up the storage and the network connectivity. It may be a small team, but everyone can do everything. And all 4 of them sit right next to the developers, which makes communication and team-work simple.
So why do large IT divisions end up in silos? And is that good, or bad?
Scale Brings Complexity and Increased Specialisation
If you’ve got 100 people in IT, you’ve got them because your business is larger, more complicated, and more dependent upon technology. Increasingly so if you have a thousand in IT. Or maybe you’re a big corporate with an IT “team” of over ten thousand.
Such complexity means you inevitably get deeper into the technology and require people with deeper technical specialism. And you have enough people with that specialisation to put them all in one team under a team leader or manager (likely that this is someone who has been promoted from the technical ranks because he/she was the best technician – that’s a subject for another day!)
Then you group similar silos together under 2nd line managers. And so it goes on until you have several fiefdoms. And once you’ve got more than 150 people in any organisation you’re past the Tipping Point (read Malcolm Gladwell’s book) and communication barriers appear between teams.
Why Does That Pose A Problem?
Firstly because of the invisible fence. Some IT staff begin to think that they’re not really allowed to speak to anybody outside of their own little team, so communication gets routed up the line of managers until it reaches somebody who is happy to bridge the virtual divide.
Secondly, organising and scheduling project work becomes unwieldy because of the demarcation lines. A developer can no longer tap a colleague on the shoulder and get everything provisioned for the new system. It requires a discussion with the server team, storage, DBA’s, the mainframe team, messaging, networks, and …
There’s a workflow that needs coordinating and managing – but it’s grown organically over time and nobody has really built a workflow process that encapsulates everything. Worse still, someone has built a mini workflow for their own silo that totally ignores the interactions and interdependencies required with the other silos.
Then the developers start demanding a co-located project team so that they have all the necessary engineers sat beside them to get their project delivered. The technicians remain reporting into their specialist silo managers but they are now sitting at desks in a different office and fully allocated to Special Project XYZ, steered by a Project Manager. Fully allocated, irrespective of whether the project needs them full time or not.
The next logical step is to put them all together in the same organisational unit under a line manager (as opposed to a project manager). Bingo. You can now use the Dev-Ops buzzword.
So – Everybody’s Happy – Yes?
Absolutely. Each Dev-Ops team is very business-focused and delivering the Projects for their particular business area. They’re using Agile, which gives everyone the impression that things are quicker too.
Then there’s an infrastructure incident on some shared components. And nobody knows who’s responsible for looking after it because once it’s been implemented it’s no longer got anything to do with any of the Dev-Ops teams. It’s not been configured to the agreed technical standards but nobody can get to the bottom of who configured it incorrectly. And nobody knows who is responsible for making sure it’s got sufficient capacity. And it’s not been patched and maintained like it should have been. And there are now separate technical configuration standards for some of the Dev-Ops teams because they “need them to be customised for their business area’s applications”.
The next logical step is to pull together a central team who can look after that specific piece of technology and ensure standards are being adhered to …
Like all organisation structures, there’s never a panacea. Silos or Dev-Ops – both have their advantages, both have efficiencies, both have drawbacks and inefficiencies. Whichever one you opt for, go into it with your eyes open. Recognise and accept the disadvantages then put the right processes and management in place to address the inefficiencies.
Brian Lancaster is a Director of BLMS Consulting