All the world knows that Mozart was prodigious in his talent, and prolific to boot. His first known piece of music was a Minuet and Trio, published when he was about 5. When I was 5 I was probably still in nappies.
When he reached the tender should-be-out-playing-football-and-not-embarrassing-us-all age of 14, he wrote his first string quartet. Over the next three years, he wrote 12 more. Another 10 more quartets would be composed during the remainder of his lifetime.
23 quartets. Just let that sink in. Let the waves of inadequacy flow through you.
Another interesting characteristic is that quartets are well suited to their environments. Typically these days you might see them at a wedding, providing the ubiquitous 'background music' which accompanies life nowadays; and satisfies the constraints of our 5-minute attention spans. That was never really their intention - chamber music was originally and primarily played at musicians' homes as a focal point, in order to entertain. My own ranting ramblings aside, we can say that regardless of the setting, and because of its size: the quartet is clearly adaptable, flexible.
Hierarchically, the string quartet is as flat as they come. To begin with there's the obvious - yet notable - absence of a conductor. We might say that by design, they are self-organising. Perhaps even more interesting is their body language and non-verbal communication. As they move through the music, they are in constant contact with one another: maintaining rhythm; tuning to one another; altering dynamics; changing tempo. Anyone who has played music with others will know that, given enough time and and practice, there can be a very tangible sense of 'one-ness', or flow, through playing together. Chamber music is no exception - it's well recognised that the more an ensemble play together, the better they get. By recognising the nuances of one another's sound, each member is able to adjust, to respond, and to complement.
The lovely thing about the composition of the quartet is that - despite its diminutive size - it is well balanced, harmonically. A cello, viola and two violins come together to provide more-or-less equal representation across a broad register of pitches.
In short, the quartet is a balanced team where each member has some definite and significant part to play.
At this point you might be asking "What the dickens has this got to do with software development?". Well, in my experience, it's common for people to think that cross-functional teams can increase their output by having more people added to the team. Often there are constraints which require that software be built in a certain amount of time. I believe that altering teams based on time constraints is a mistake, and I believe this because software teams that perform well are structured and behave similarly to string quartets.
String quartets have a goal of playing beautiful music to be enjoyed by people.
Software teams have a goal of delivering a product to be enjoyed by people.
In this frame of mind, it makes no sense at all to ask the question "How much time will this take?".
It just so happens that it takes about 7 hours to play all of Mozart's string quartets back-to-back. Sure, you could add another viola or cello into the mix - but the running time of Mozart's 23 pieces is still about 7 hours. In fact, by adding more people to the quartet (quintet, sextet), I think you would incur more cost than benefit. Firstly, you're upsetting the balance of the team, and therefore the relative harmonies in the music. Secondly, the communication cost increases dramatically when more people are added to the mix.
This cost, represented by the number of arrows between people, increases quadratically as more people are added to a team. You can see below (and here) how quickly this rises: For a group of 4 people, there are 6 communication paths. Doubling that team size to 8 yields 28 communication paths.
This has a real effect on our daily work. If we have to spend more time engaging with extra lines of communication - as much as that may be enjoyable - we aren't spending time with our customers, we aren't understanding their problems and we're not collaborating to build a strong product.
For me, even though I'm aware of the theory, I'm still surprised to see this cost quantified - it's just not something I often think about. Whilst we know that clear, transparent communication and fast feedback is vital for teams to succeed in their endeavours, we don't often consider how best to configure ourselves to reduce this cost.
This becomes particularly pertinent for growing organisations. As their scope increases and new teams are formed to support increased delivery, it's important to take the time to ensure that teams can reduce this communication cost, and therefore maintain a sense of balance.
At Birdie, we've tried to organise our delivery teams into empowered squads, in ways that facilitate good collaboration and reduce unnecessary cognitive load. Each squad is responsible for a part of the product: they speak regularly with our customers about their problems and use their feedback to find a solution that improves the product as well as their customers' experience. The actual size of the squads varies from 3-7 and whilst there is no hard upper limit and ultimately the squads themselves decide on their organisation, it's understood that at a certain size a team may be responsible for too much and their ability to deliver their product and communicate effectively might benefit from a re-structure.
Beyond communication, there are of course other elements that make teams successful: diversity of thought; psychological safety and an environment that nurtures learning and growth are a few that come to mind. These are all wonderful attributes and are always to be encouraged, but without strong communication we'll struggle to get those right.
Undoubtedly, there are other characteristics I haven't mentioned which are not shared by quartets and software teams, but I find it very interesting that some of the qualities that make a string quartet successful are the same qualities that make a software team successful.
Thanks to Fred Platt, Daniël Hogers, Einar Norðfjörð and Robbie Heygate for your helpful feedback.