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.
There is an African proverb I’ve heard often: “If you wish to go fast go alone. If you wish to go far go together.” You could argue that the Romans placed more value in travelling far than travelling fast, at the very least they truly understood how to utilise the power of the group and to exploit those who didn’t.
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.
Ultimately this can be viewed as the difference between valuing the short-term rather than the long-term. As pressure builds to deliver more, and perhaps unplanned work creeps into the team, rather than critiquing priorities or analysing and addressing the cause, a knee-jerk (but short-term) reaction can be to allocate specific projects to specific team members in the hope work can be done in parallel. However by doing so you risk dividing the team and splitting its purpose, outcomes that will likely wreak havoc, especially further down the line.
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.
Division and divergence of purpose can be seen as two key ingredients for the formation of silos, and although can sometimes happen in a more gradual fashion, are often intentional decisions that leaders make in response to pressure to move faster.
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.