Silos: Part II — How not to handle increased workload.

Continuing the Roman/ Gallic theme from Part I, it is sometimes speculated that in hand-to-hand combat a roman soldier without his armour would be no match for a Gallic warrior. They were taller, stronger, bellicose. Their very appearance of muscular bodies, long greased hair, and willingness to fight naked was often enough to instill fear in the average Roman. It was only the legions’ cohesion, discipline, superior group tactics and strategy that enabled them to, in most cases, steam-roll the relatively disorganised Gallic armies. Often, the Gauls’ first charge would be fast, savage and incredibly powerful. Yet they frequently relied on the tactic of surprise in order to ambush the Romans while marching out of their infamous battle formations. But Caesar knew that this quick, lightning attack of menacing individuals could not be sustained. If his men could weather the initial storm, the Gauls would tire, and the legions would begin their butchering. It was a battle between the fast and the steady, the individual and the group.

Go fast or go far. You can’t have your cake and eat it too.

Sometimes though, the ability to travel far (together) is forgone in favour of a need, perceived or not, to travel fast (alone).

Although the ‘fast’ approach can work in some circumstances it is also fraught with risk. For a modern tech team the pressure of increased work, deadlines, meeting expectations, changing requirements, fixing unforeseen bugs etc. can result in a desire to be faster, to react faster, to develop faster, to finish faster. Sometimes this pressure develops from mistakes in planning, prioritisation or misunderstanding of expectations. No matter where the pressure comes from or how it develops, as the proverb implies, you cannot go as fast together as you can if you go alone. Therefore somewhat logically, this pressure to move faster can manifest in the idea for leaders or self-organizing teams to subdivide teams, sometimes into groups of one or two, with the logic that more work can be done in a shorter period of time by multiple smaller groups working in parallel. Occasionally this can even happen unconsciously where gradually specific individuals in the team gravitate towards working on specific tasks. However in cases where it was a conscious move, one might be forgiven for thinking it a good decision given the circumstances, right?

Not necessarily. Especially when these smaller, divided groups remain parts of the same whole, yet focus on different projects for sustained lengths of time, then you’ve just jeopardised the common goal and sown the seed for silos. You may as well be the guy who suggests “We should split up.” when you and your friends are locked in an abandoned warehouse with a serial killer.

Consequences of valuing travelling fast over travelling far.

Here are five consequences of dividing a tech team.

1. Withered Mutual Accountability

The first casualty tends to be mutual accountability, a cornerstone of any team.

“Mutual accountability is a process by which two (or multiple) partners agree to be held responsible for the commitments that they have voluntarily made to each other.” — OECD

When you are in a team working towards a common goal, your team member’s setback is your setback too. But when you find yourself just one of several sub-teams with differing objectives, the concerns of the ‘other’ projects in your team become peripheral. When divided, team members will naturally gravitate towards their own projects.

2. Crippled Critical Thinking

Once mutual accountability has started to weaken, so too will the benefits of critical thinking within a team. Even if you continue trying to act as one team, reviewing one another’s pull requests and performing stand-ups, groomings, planning and retros together etc. collaboration, participation and interest in general with each other’s work will probably be half-hearted at most.

As such, poor design decisions, over-engineering, or other bad coding practices can easily start to be overlooked. It might even be that different parts of your team start working on solving the same or similar problem and not realise.

3. The Bus-Factor

Especially if your sub-teams are very small, knowledge sharing can become a significant problem. The number of people who know about specific projects or domains will be so low that in the (hopefully unlikely) event they get hit by a bus, few, if any, others will be able to maintain or continue developing them. With a loss of mutual accountability, even code reviews will likely not be enough to adequately foster shared-understanding.

4. Risk of Meeting Peter (The Principle)

The chance of code smells starting to appear increases rapidly once critical thinking has left the building. Poor decisions and innocent mistakes overlooked at a time when they could have been nipped in the bud, are now more likely to fester just under the surface, like the rotting roots of a tree. The risk of having an over-complicated, over-engineered and buggy project is now quite high.

At this point maybe you recognize the woe in your ways, and try to regroup the team, sort out your priorities and get them working again on the same project. But now you risk losing time with onboarding the ‘new’ members and disagreements regarding previously implemented solutions are more likely to occur (because now everyone is invested). Kids, say hi to Uncle Peter*:

“The software Peter Principle is … a dying project which has little by little become too complex to be understood even by its own developers.” — Wikipedia

5. Time lost

Scrum teams are not (usually) formed around short-term projects. A team often needs time to form, storm, norm and perform, and as a result are usually long-lasting to minimize this ‘down time’. In other words, scrum teams are normally in it for the long haul.

When they are divided, whatever momentum they had before will most likely be lost, and it will be some time before they build it back up again, and may never be quite what it was. Dividing the team can also spread skill sets thin and actually result in tasks and projects taking much longer to complete. Not to mention the mistakes that are more likely to be made and the problems that they will cause later on and the time it will take to fix them. Not to mention the higher risk of making mistakes and the increased time it may take later on to fix the problems they cause.


Somewhat ironically, the resulting formation of silos is almost never intentional, and yet they can consequently threaten to jeopardize the very reason the decision to divide the team was taken in the first place; to gain speed.

So, next time your team is faced with pressure to move faster, how will you choose to face it? Hopefully you won’t divide and conquer yourselves.

*The Software Peter Principle is derived from the original ‘Peter Principle’ relating to incompetence within hierarchy.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Austin Mackesy-Buckley

An Agile Coach and dad who writes from time to time about his thoughts and experiences of work and life.