[Reading time: 1 minute 22 seconds]
I’d like to write about organisation today.
It’s all the rage these days to complain about silos. Silos are bad, people say, they’re the old way of doing things.
But what’s a silo, in DevOps parlance, and why is it bad?
I mean, I agree “silo sounds kind of bad – soulless maybe, or not very sophisticated.
I suppose few people would like to work in a “test silo”, for instance, or a “database silo”.
But if you told someone their workplace was the “database team”, or the “test department”, that wouldn’t sound so bad, would it? I’d wager you have such teams or departments.
So why should that be bad?
I’ll tell you a secret: it isn’t. Not in itself, anyway. It often makes sense to group people with similar tasks together. If you call them “community of practice”, it even sounds cool and modern and agile.
The problem arises when those silos (by whatever name) start to take on a life of their own, retract into themselves, start to optimise for their own goals, not the organisation’s goals.
And this is why agilists argue for cross-functional teams: to try to avoid a focus on activities, and set a focus on product creation (a business outcome).
How does it work in your organisation? Do your organisational units, whatever their name and structure, optimise for overall success? Or do they focus on their own, local concerns? And what effects do you see on the organisation as a whole?