Diversification is what you need.

I played basketball when I was younger. I remember wanting to become an expert at spinning a basketball on my finger. For some reason, this was the craft I chose to master.

I practiced for hours in my garage. When I started, I could keep the ball on my index finger for approximately one-tenth of a second. After five days of relentless practice, I could spin the ball as long as I wanted on all five fingers of my left hand.

This is impressive to anyone that witnesses it, even to this day. But it did little to make me a better basketball team member. I could spin the ball an entire game, but it would not help us win.

When we envision mastery, we often think about becoming an expert in our chosen specialty. Our mind focuses on being the best version of ourselves in our craft. But today’s product teams need less specialization, not more.

“Mastery is the desire to get better and better at something that matters.”

—Daniel Pink

Mastery is about diversification, not specialization. Deep knowledge in one area by one team member creates a bottleneck, reduces collaboration, and increases hand-offs. Specialization slows us down, and diversity speeds us up.

But in the organizations I coach, mastery remains focused on specialization. This results in significant weight the teams have to carry with them. Breaking this pattern is the key to building teams with high productivity.

Let’s start by discussing how specialization has become the goal of mastery today. Then, we will dive into ways we can master diversification.

---

Mastery in a silo

Our desire to hone a specialized skill originates in Taylorism and Scientific Management. In 1910, Frederick Winslow Taylor formulated this in The Principles of Scientific Management.

It may surprise you to hear, but Taylor’s book has many similarities to modern Agile and Lean thinking. It describes the impacts of waste in human effort and the difficulty in seeing this waste. His concepts elevate the need of the customer, wisdom of the workers, and support from leaders.

But the popular interpretation of Taylor’s principles is one of mechanistic thinking. We take The Scientific Thinking aspects to the extreme and apply to all human activities. The unfortunate result reduces humans to robots following their programs.

For example, the idea to split mental and physical labor isolates doers from thinkers. This separation has evolved further to a state of extreme specialization. Each job has its own required skill, a worker skilled in that job, and a specific series of steps to follow.

To illustrate, let’s take a deeper look into how Taylorism manifests in today’s product teams.

№1: The dysfunction of specialized mastery

In today’s organizations, we often have function and component teams. These teams focus on mastery of one specialized skill, such as:

• Product strategy and management
• Customer experience
• Architecture
• Business Analysis and Process
• Front-end development
• APIs
• Data
• Testing

This configuration is not optimized to deliver the “right” product for the customer.

Like an assembly line, each function does its piece and hands it off to the next worker. The flow of value halts as each group does its independent, serialized work. Assembly of the parts occurs at the end, assuming, in error, perfect planning and execution.

Through specialized mastery, we lose the “soul” of product development.

We bypass the human element. We lose touch with our customers. And we give up the collaborative power of the cross-functional team.

№2: The substandard standardized approach

Our human brain desires consistency and prediction. Evolution has wired our brains to predict and generalize. When we face scale, the tendency is to create and enforce standards to simplify.

As a result, we form centralized governance, centers of excellence, and review boards. We write lengthy procedure manuals. Every worker becomes trained and coached to follow the standard approach or framework.

Through a one-size-fits-all approach, we don’t tap into the brilliant minds of those closest to the work. As customer needs are critical to delivering the right product, the right approach requires team context.

Centralized, standardized, homogenous approaches, while tempting, do not support complex product work.

№3: Individual ownership over teamwork

Far too often, Scrum teams today resemble a collection of individuals versus a team. Let me explain.

I see alarming trends that signal a focus on individual contribution over teamwork. A few of the scariest trends are below:

• Tracking individual team member velocity
• Each team member owns a story on the Sprint Backlog
• All stories are in progress at once during the Sprint
• “When we have developed all stories, the testers test.”
• We assume one point per developer per day

In a misguided ambition for efficiency, we aim to get more done by starting everything at once. Each team member grabs their own story off of the Sprint Backlog and starts working. We hand-off work between functions rather than collaborate.

These behaviors avoid teamwork, lose the power of many minds, and slow the delivery of value. To those managing teams, note that keeping people busy results only in a bunch of busy people.

---

The type of mastery a product team needs

We have now established how mastery goes awry. At this point, you are likely deducing the type of mastery we desperately need.

We need mastery in diversity. This translates to a diversity of skills, diversity of viewpoints, and diversity of minds. Let’s dive in.

1Diversity of skills. A cross-functional product team has multi-skilled individuals. Mastery is in the pursuit of diverse skills by our product team members.

While each team member brings a deep specialty, today’s teams need T-shaped team members. Team members need not only a deep specialty but also broad, general capabilities. Diverse skillsets enable flow and reduce bottlenecks on specialized knowledge.

“The vertical stroke of the ‘T’ is a depth of skill that allows them to contribute to the creative process. The horizontal stroke of the ‘T’ is the disposition for collaboration across disciplines.”

—Tim Brown

I like to call a T-shaped team member the ultimate team player.

If you have specialized individuals on a team, you may often hear, “that’s not my job,” when faced with the unfamiliar. But if you have team members with diverse skillsets, you will instead hear, “how can I help?” Which type of team member sounds better to you?

2Diversity of viewpoints. Do you want agreement on direction amongst team members? Is this how you define alignment and harmony?

For 40 years, J. Richard Hackman was a leading expert on teams. He was the Professor of Social and Organizational Psychology at Harvard University. In his article, The Six Common Misperceptions About Teamwork¹, he explains how harmony is not what teams need. Contrary to popular belief, conflict and differences of opinion generate better, innovative solutions.

“For good ideas and true innovation, you need human interaction, conflict, argument, debate.”

—Margaret Heffernan

Agile Leadership requires that we encourage diversity of viewpoints on a team. Constructive debate and discussion is an investment in a better outcome; it is not a cost.

3Diversity of minds. Working as a team requires that we focus on one thing at a time and use our collective minds and effort to finish it. Starting everything at once does not harness the power of the team. It squanders the force-multiplier of many minds focused on solving one thing.

One-by-one production is an effective way I have found to embrace the diversity of many minds. This means a product team only starts one feature at a time and completes it before starting another.

There are different techniques teams use when practicing one-by-one production. For example, they might cycle between patterns of swarming, mobbing, and pairing:

• Swarming: Many minds, many keyboards
• Mobbing: Many minds, one keyboard
• Pairing: Two minds, one keyboard

Collaboration will accelerate with these techniques. You will experience increased throughput, innovation, feedback, skill transfer, and quality.

---

The takeaway

Master diversification, not specialization.

Mastery focused on specialization leads to ineffective teaming. It does not cater to the context-specific needs at the place of work. Specialization does not work for complex product development.

But mastery aimed to diversify results in flexible team members, more informed decisions, and a more effective flow of value.

Mastery is a journey and not a destination. When you master a path that enhances your product team, you are on the right track.

This thing we call Agile focuses on people working together and getting better at it. Practice mastery of collaboration, and all will be well.

Also published in Serious Scrum on Medium.

---

Related Posts

Read similar posts to this one below:

The Best Metric for Your Product Team

Three “Right” Ways to Develop Your Product

Excellent Product Teams Have These Five Daily Habits

Less Is More When You Scale Agile

---

References

1. The Six Common Misperceptions about Teamwork, Robert J. Hackman, June 7, 2011