What Makes an Awesome Team?

In our previous post, we established that the primary job of an Engineering Manager is to build awesome teams. But what exactly makes a team “awesome”? In this post, we’ll dive deep into the characteristics of high-performing engineering teams and explore why self-organization is a key factor in team success.

Google’s Recipe for Awesome Teams

When it comes to understanding team dynamics, few studies have been as influential as Google’s Project Aristotle. After years of research, Google identified five key factors that set successful teams apart. Let’s break these down:

  1. Psychological Safety: Can team members take risks without feeling insecure or embarrassed?This is the foundation of all great teams. When team members feel safe to voice their opinions, admit mistakes, and take risks, innovation flourishes.
  2. Dependability: Can team members count on each other to do high-quality work on time?Reliability builds trust, and trust is essential for smooth collaboration and high performance.
  3. Structure & Clarity: Are goals, roles, and execution plans clear within the team?When everyone understands their role and the team’s objectives, it’s easier to align efforts and make progress.
  4. Meaning of Work: Is the work personally important to team members?Teams perform better when individuals find their work meaningful and aligned with their personal values.
  5. Impact of Work: Do team members believe that their work matters?Understanding how their work contributes to the larger goals of the organization can significantly boost motivation and performance.

These factors provide a solid framework for what makes a team “awesome”. But there’s another crucial element that ties into several of these factors: self-organization.

The Power of Self-Organizing Teams

The concept of self-organizing teams is a cornerstone of many modern software development methodologies, including Agile and Scrum. As the Agile Manifesto states:

“The best architectures, requirements, and designs emerge from self-organizing teams.”

But what does self-organization really mean in practice?

According to the Scrum Guide:

“Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team… Development Teams are structured and empowered by the organization to organize and manage their own work.”

Self-organizing teams have the autonomy to decide how to approach their work, distribute tasks, and solve problems. This autonomy directly contributes to several of Google’s success factors:

  • It enhances psychological safety by empowering team members to make decisions.
  • It increases dependability by allowing the team to commit to what they believe they can achieve.
  • It provides structure and clarity by enabling the team to define their own processes and roles.
  • It boosts the meaning and impact of work by giving team members more control over their contributions.

Why Self-Organization Matters

  1. Encourages Ownership: When teams have the power to make decisions, they’re more likely to take ownership of both the process and the outcome.
  2. Increases Engagement: Autonomy is a key factor in job satisfaction. Self-organizing teams tend to be more engaged with their work.
  3. Promotes Responsibility: When team members are involved in decision-making, they’re more likely to take responsibility for the results.
  4. Fosters Innovation: Self-organizing teams can quickly adapt their processes and try new approaches, leading to innovative solutions.
  5. Builds Leadership Skills: In a self-organizing team, leadership is often distributed, giving team members opportunities to develop leadership skills.

The Role of the Engineering Manager in Self-Organizing Teams

You might wonder, “If teams are self-organizing, what’s left for the Engineering Manager to do?” The answer is: plenty!

The shift towards self-organization doesn’t diminish the importance of the Engineering Manager. Instead, it changes the nature of their role. Rather than directing the team’s day-to-day activities, the Engineering Manager becomes a facilitator, coach, and guardian and helps the team maintain autonomy.

In our next post, we’ll explore how to initiate and nurture self-organizing teams, and discuss the delicate balance of providing guidance without undermining the team’s autonomy.

Wrapping Up

Building an awesome team isn’t just about assembling a group of skilled individuals. It’s about creating an environment where psychological safety, dependability, clarity, meaning, and impact are prioritized. By embracing self-organization, teams can take ownership of their work, leading to higher engagement, more innovation, and ultimately, better results.

What’s your experience with self-organizing teams? Have you seen these principles in action? Share your thoughts in the comments below!

3 thoughts on “What Makes an Awesome Team?

  1. Great post! It’s fascinating to see the key factors that contribute to high-performing engineering teams and how self-organization plays a crucial role in team success.

    A question I have for you is: How do you suggest overcoming potential challenges that may arise when transitioning to a self-organizing team structure, especially in traditionally hierarchical organizations?

    Liked by 1 person

    • Great question.

      first, get alignment, like “we are trying something different in this pocket, we have these rules around it, in our bubble for the experiment.” We will report upwards on X cadence, leave us out of other reporting cycles and everyone should agree on this.

      We are going to measure with X, which should relate to business impact as close to the bottom line as possible.

      protect the team from the business in this contract negotiation. Create a bubble where you can prove it works.

      As wwell as business impact I would use developer engagement surveys using the experiment team as a B variant and compare them to other teams in the org as the A.

      collect data, if it proves its not better iterate, if it prove it is better this justify the change. If the business accepts this data as a reason to change you are on and can start scaling. If they don’t accept data as evidence, they you are in the wrong organisation and you should leave.

      Liked by 1 person

Leave a reply to Dicko2.0 Cancel reply