Belgian Draft Horses are very large animals that measure an average height of 16-17 hands (5.3 - 5.5 feet at the withers - the ridge between the horse’s shoulder blades.) and typically weigh between 2,100 and 2,300 lbs. Given their size we would expect them to be very strong and indeed they are. Once fully grown they are capable of pulling 8,000 pounds. An interesting fact is that when two horses pull a load together, they don’t just pull 16,000 pounds but the team of two can pull 22,000 pounds. If that isn’t impressive enough, when they train together, they can pull up to 32,000 pounds. For any of us who have worked in teams, this should not be surprising.
One of my favorite sayings about teamwork is an African proverb, “If you want to go fast, go alone. If you want to go far, go together.” This for me summarizes my experience with teams. Almost always I can do the work much faster by myself but eventually I get to a point where I run out of skill or determination or ideas. With a team, I find myself going slower initially, getting people heading in the same direction takes time, but eventually we get much further than I could have by myself. I experienced this most recently working on a scholarship. A group of us got together to work on outlining the purpose, how it would be awarded to students, in what amounts, etc. Of course I had ideas and answers to all of these but so did everyone else. While I could have easily laid all of this out in a document in a few hours, it would have been just so-so. What resulted after many hour-long conversations, email threads, and even individual phone calls between team members, was a much, much superior product than what I would have come up with on my own. The team had thought about edge cases, fundraising strategies, and even a unique naming option, none of which I would have come up with on my own.
The way we build modern software products is in teams. While I’m sure there are people that have all the requisite skills such as product vision, management, user experience, analytics, and software development to build something all by themselves, it’s almost guaranteed that a better product could be built by leveraging people with stronger skills in those areas. Each of these skills take years to develop and decades to master. In this way, teams leverage the strengths of individual members and make up for each others’ weaknesses. The ASTNA, which is the industry association for flight nurses who work as part of patient care teams, states in their publication, “Within highly effective teams, individual strengths offset other teammates’ weaknesses, allowing for the team to be stronger and higher performing then the individuals that make it up.”
We have all probably heard the comparison that teams are like chains, only as strong as their weakest links, but I don’t think this is true. In fact, I think teams can be stronger than even the strongest team member alone depending on how we measure that strength. When it comes to solving complex problems, groups perform better than even the highest-performing individuals, according to Patrick Laughlin, et al from the University of Illinois at Urbana-Champaign. Reporting in their paper in the Journal of Personality and Social Psychology that, “Groups of size three, four, and five performed better than the best of an equivalent number of individuals.” They attribute this superior performance to the ability of people to work together to generate and adopt correct responses, reject erroneous responses, and effectively process information. This superior performance of teams can also be found in terms of innovation. A 2015 report from the consulting firm McKinsey & Company found that teams made up of members from diverse backgrounds (gender, age, ethnicity, etc.) are more innovative and perform better by up to 35 percent, compared to more homogeneous teams. Instead of looking at an issue from a single vantage point, a broader view can lead to an exponential increase in ideas which produce better results.
The benefits of teams also go far beyond performance on complex tasks and innovation, they also include strong benefits for the individuals on the teams including reduced burnout and increased happiness. However, this is not achieved as easily as putting a group of folks together on a team. As Susan McDaniel and Eduard Salas state in their special issue on The Science of Teamwork for APA PsycNet:
Even in our individually oriented culture, teams are now ubiquitous in most areas of science, work, and art—teams predominate in aviation, the military, business, space exploration, academia, and health care. In fact, considerable investment has been made in recent years to gain a better understanding of teamwork and what works. We have made significant progress in understanding how to compose, develop, assess, and manage teams…Teamwork is a complex phenomenon requiring multiple lenses and approaches.
We need to be focused and thoughtful about how to organize, how to provide autonomy, how to divide tasks, what tools to provide, etc. for our teams.
In a previous role, we found that moving an entire team from one initiative to another resulted in the team taking on average six weeks to reach the same level of productivity, as measured by experiment velocity, as before the move. The really interesting insight was that when we broke apart a team, e.g. removed or added team members, the loss in productivity was double, on average twelve weeks! We’ve probably all heard of Tuckman’s stages of group development (forming, storming, norming, and performing). Our observation and data suggest some strong validity to these stages and to the length of time that they take to work through, at least within our particular culture.
Teams are critical to accomplishing anything really large and meaningful but they don’t just instantly form and work. They require planning in terms of skill sets, e.g. what is the right makeup of skills for a frontend vs backend team? They require capacity planning, e.g. how many engineers are needed for a particular initiative? And, of course, strong leadership to get everyone excitedly on the same path. All of this is a lot of work and definitely slows down progress in the beginning, but if you are willing to put in the time and effort the results make up for it in the long run. If things go well you and your teammates can maybe one day pull 32,000 pounds together (at least metaphorically).
I love the draft horse example. Here's a similar, more personal example that I've observed. I use the leg press machine at the gym, doing a mix of single leg press repetitions and repetitions with both legs. My maximum repeatable weight with both legs is more than 2x my maximum repeatable weight with either single leg. That makes me think how a team is like a body that a) depends on each specialized type of muscle doing what it is best for, and b) shifting burden from more fatigued to less fatigued muscles to achieve maximum sustainable effort.
I've certainly seen teams where an individual reaches the "fatigue" limit of what they can achieve on their own, and passes the baton to someone else who can carry solution-building further. What's interesting is that over time such teams tend to rely less on hitting the limit as a signal to hand off, and instead a) collaborate more from the outset, and b) hand off sooner than reaching that personal fatigue limit.
As a leader, monitoring team health and needed adjustments is much like an athlete deepening their understanding of their own body, reading the signals they're receiving, and adjusting accordingly.
Great write-up! The "going faster alone" was so true for me early in my career and really held me back as a leader. Once I accepted that a team would go slower, I finally gave up on personal fastness, and we got so much more done!
Agile development seems to increase output through teamwork, although it's not stated explicitly. I dislike it when I hear from an exec "if I only had one amazing developer to get things done...". It's almost never the right approach, and it doesn't scale.