The Science Behind Team Design

Our vision was to have everyone working in a squad within the next three months, which meant finding the best way to run a squadification process—the term we came up with to describe the process whereby people select who is going to be part of which squad.

We started looking into the science behind the design of teams, which some research suggests is the most important factor in overall team performance. Studies conducted by J. Richard Hackman,^[4] for example, found 60% of the variation in team effectiveness is attributable to the design of the team, 30% to the way the team is launched, and 10% to leader coaching once the team is under way.

This is certainly consistent with our own observations: we’ve seen more than one star-studded team grossly underperform because the mix of personalities just wasn’t right. We’ve seen teams fail because the star players weren’t able to see past their personal differences and were more focused on their own performance or objectives than the team’s achievements.

We firmly believe that designing a team doesn’t necessarily mean picking the best people but rather deciding on the best combination of people based on their interdependent skills, preferences, and personalities.

We knew we’d have to be considerate in our approach at Trade Me. Imagine if your manager or coach came to you and said, “Let’s talk about your team and the way you work and potentially change everything from the ground up.” That’s a very important conversation to have in the right way. We knew that if we got it wrong we were going to annoy and worry a lot of people.

We looked at two potential methods for designing teams:

Managerial selection:

Managers decide on which team a person should work.

Self-selection:

People decide for themselves on which team they want to work.

Managerial Selection Breaks When Organizations Grow

Managerial selection is the traditional way of allocating people to teams. Good managers design teams based on their knowledge of employees’ skills and personalities and who they think would get along with whom.

In a small company this often works well—a good manager is aware of relationships between people and knows the skills, personalities, and preferences of each of them. Often they come up with team compositions that are mostly right, and it’s a quick way to get team selection done.

This model breaks down when a company grows or goes through a period of significant change, such as during an agile adoption. Managers might still know their direct reports’ skills and personalities, but it becomes increasingly difficult to understand the intricacies of relationships among people as the number of relationships increases almost exponentially. In our experience the breaking point is around ten people.

As David remembers:

I would come out of meeting after meeting of managers where we would select staff for teams or projects based on our best guess. I remember so many conversations that started, “So, what squad is Peter going to be in?” “Peter is going to go into this squad.”

And then I’d have a conversation with Peter’s manager or someone else who knew him and they’d say, “Oh, I think he really wants to work on this other part of the code,” or “I’ve heard he doesn’t like working with one of the people there,” so we’d go back to the drawing board.

We spent hour after hour as managers trying to unravel these scenarios (surprisingly, in hindsight, never actually talking directly to the person in question), and more often than not we’d get it wrong. We had a feeling something wasn’t quite right with the way we were doing things, but at the same time it seemed so conventionally sound. It’s what managers do, right? They tell their staff what to work on. But something felt fundamentally wrong about the way we were going about it.

When you think about it, managerial selection made good sense in its historical context of industrial factories where workers’ tasks were relatively simple and repetitive, and workers were pretty much interchangeable. It simply didn’t matter who worked with whom, and high-performing teams couldn’t achieve anything a collection of people couldn’t get done. In the complex and collaborative workflows of organizations today, however, managerial selection makes much less sense, but our methods haven’t kept pace with the amount of change the working environment has gone through.

The same is true of the carrot-and-stick approach to motivating staff, which suggests that people charged with repetitive and boring tasks were best incentivized by monetary rewards. Author Daniel Pink turned the tables on that idea in his 2009 book, Drive: The Surprising Truth About What Motivates Us, [Pin09] pointing out that today’s work mainly comprises creative, complex, “right brain” activities. Pink cites research that shows the best motivators in such an environment are autonomy, mastery, and purpose:

• Autonomy provides employees with freedom over some or all of the four main aspects of work: when they do it, how they do it, who they do it with, and what they do.

• Mastery encourages employees to become better at a subject or task that matters to them and allows for continuous learning.

• Purpose gives people an opportunity to fulfil their natural desire to contribute to a cause greater and more enduring than themselves.

Pink is not the only one to support claims that these motivators are what lead to people performing better. In her research, Margareth J. Wheatley^[5] establishes a clear causality between participation and autonomy on one hand and productivity on the other. Her research shows that productivity gains in truly self-managed work environments start at a minimum of 35% higher than in traditionally managed organizations.

With Daniel Pink’s book and Margaret J. Wheatley’s research in mind, knowing that highly motivated people perform best, and considering our own observations of managerial selection breaking down as a company grows, we started to look more closely at self-selection as a tool to design our teams.

What better place to start offering autonomy than by letting staff members decide for themselves which team they would prefer to work in?

Self-Selection Has a Good (and Interesting) Track Record

Self-selection is neither a new nor an unproven idea. Leo McKinstry described one of the earliest and most successful large-scale self-selections in his 2009 book Lancaster—The Second World War’s Greatest Bomber [McK95] about the Royal Air Force’s Lancaster bomber crews in the early 1940s.

Lancaster crews were tightly knit, and survival and success on a Lancaster depended entirely on the intimate understanding among the crew members. That critically close relationship among airmen underpinned the self-selection process used to form bomber crews.

Recruits were trusted to form their own crews without any guidance from senior commanders. There were no rules and no restrictions, other than the number of airmen and skills needed to man an aircraft. McKinstry explains that the trainees had to rely on gut instinct when selecting a group to join.

Fast-forward to 2004 when Atlassian, an Australian Internet company, created the ShipIt Day concept: a twenty-four-hour hackathon that lets employees choose their own projects and teams to build something unconnected to their regular jobs in a single day.

Originally named “FedEx Day” after FedEx’s 1980’s slogan, “When it absolutely, positively has to be there overnight,” ShipIt Day went on to become highly successful and gained worldwide popularity after it was cited by Daniel Pink in his book Drive.

Numerous companies around the world including Spotify, Atlassian, Nintendo, and many others organize ShipIt Days on a regular basis to kick-start innovation, focus on the importance of speedy delivery, and simply have fun and learn new things.

In this spirit we had many ShipIt Days at Trade Me, and it was always a joy to see an entire organization self-select into small teams, self-organize, and work on projects of their own choosing. During one memorable day we had roughly eighty people in fifteen teams working on fifteen projects that they had designed to benefit the company in one way or another.

We saw ShipIt Day as a study in what happens when you give a group of people complete freedom to work on what they think is important, with whomever they like, and using whichever approach (agile certainly wasn’t prescribed) they think will work best to get the job done.

When employees self-selected into teams for ShipIt Day we observed the following:

• People naturally form small, cross-functional teams. Teams are between three and six people and team composition is based on skill rather than role. There is no one person per skill, and those T-shaped people who are good at collaborating are in high demand.

• No one chooses to work on more than one team or project. Time and again organizations fall into the trap of optimizing resources rather than focusing on outcomes. People often believe that multitasking, having people work across several projects, and focusing on resource utilization are the keys to success, when in reality they’re not. It’s interesting to note that when employees are determined to ship, no one thinks it’s best to do more than one thing at a time and nobody worries about utilization during a ShipIt Day! And nobody believes they are more valuable as specialists across teams than as generalizing specialists within one team.

• People communicate face to face. There are barely any discussions about process or how to communicate. Team members just talk and coordinate and collaborate as needed. Things are much faster that way. This is also most likely why, even though our company spans three cities, all of the teams decided for themselves to be 100% co-located. This meant that even when the "ideal" person wasn’t on site, they felt it would be better to go with someone who was in the room and who would work outside their usual boundaries.

• A shared, clear goal makes everything so much easier. When people buy into the goal and know clearly the problem they’re solving and understand why it’s a problem, things become a lot easier for everyone. It’s easy to make decisions and reach consensus when everyone understands and supports the objectives and constraints around a project or product. Selecting what they wanted to work on offered great benefits for ensuring that the team had a shared and compelling goal.

• Team members are highly motivated, enjoy the experience, and get lots of work done. Some of the projects people built, such as an “Is Someone in the Shower?” application for reducing wait times for people in the office who exercised (no, it didn’t involve a camera; it was a light switch sensor), a virtual receptionist, or the room-booking app “Get a Room,” were simply incredible additions to the office and are still in use today.

Seeing everyone so happy and motivated before, during, and after ShipIt Day, we couldn’t help but wonder whether we could find a way to allow employees to choose who to work with and what to work on in their normal working lives too.

Sandy remembers:

For us, that ShipIt Day was a real lightbulb moment. We realized that we could take the way in which people organize themselves when they want to achieve something and apply it to the entire organization. That’s what we wanted to do: apply those principles to achieve our goal of total squadification.