Chapter 1. What Makes a Software Engineering Team Effective?

Some teams seem to operate like well-oiled machines, churning out successes. Communication flows seamlessly, they meet deadlines with a smile, and they tackle challenges head-on. Conversely, other teams struggle to reach every milestone. Communication is chaotic, and meeting deadlines is a challenge. What makes the successful teams effective? It’s usually a mix of things: clear plans, honest talk, a healthy dose of trust, and a shared belief in what they’re doing. Some teams already have the rhythm and the steps down pat, while others are still figuring things out. But the good news is that everyone can learn the steps. Even the most stumbling crew can find its rhythm with a little practice.

This rhythm manifests itself in software engineering teams as their ability to produce useful products or product features by writing code, testing it, and releasing it to the world. Teams that do this regularly are said to be effective. So, to build great software, we must first build effective engineering teams.

Throughout my 25+ years of experience leading engineering teams at Google and other tech companies, I’ve seen firsthand how team dynamics can make or break a project. Building effective teams is not just about assembling the right technical skills; it’s about fostering a culture of collaboration, trust, and shared purpose. In this chapter, I’ll share some of the key lessons I’ve learned about what makes engineering teams successful, drawing on both research and my own experience in the trenches.

What makes an engineering team effective hinges on the key thing that distinguishes teams from groups. On the one hand, a group is a collection of individuals who coordinate their efforts. On the other hand, a team is a group that is bound by shared responsibilities and goals. Their members work together and share mutual accountability to solve problems and achieve common goals. When teams plan their work, review progress, or make decisions, they consider the skills and availability of all the members and not just those of one individual. This shared goal is what drives an effective team.

I have had the opportunity to observe or be a part of such teams at Google. These teams are passionate about achieving their goals. They find brainstorming sessions fun rather than stressful. Team members may write and test code on their respective machines, but they are collectively tuned in to a unified vision of what the code should achieve. There have been times when they had to resolve some difficult issues, but a culture of collaboration, innovation, and mutual respect helped to see them through such times.

Leaders are an important part of this picture. As a software engineering leader who wishes to make your team effective, you serve as an anchor that connects individual team members to the shared responsibilities and goals of the team. You provide the vision, direction, guidance, and environmental framework necessary to form this connection.

Although it’s possible to have a team without a leader, the team will go much further with the support of a good leader—and that’s where you come in!

Building an effective software engineering team takes work. Many factors can influence the success of a software engineering team, such as team composition, communication, leadership, and work processes. This chapter will explore what traits make teams effective and how to build them into your team. These traits will be things you can look for when hiring, but they’re also traits you can nurture in your existing team.

Research on What Makes Teams Effective

First, let’s examine what makes teams effective. To do so, let us look at some of the extensive research that has already been done on this topic.

Project Aristotle

Google conducted one of the best-known studies on effective software engineering teams, known as Project Aristotle.¹ The project aimed to identify the factors that make some teams more successful than others. The study was based on the premise that the composition of a team was not the most critical factor in determining success but rather how team members interacted with each other.

Note

Before Project Aristotle, there was Project Oxygen, which looked into what traits make for a good manager. Some of the insights in this chapter were informed by the results of Project Oxygen, which I’ll talk about in detail in Chapter 4.

To determine what makes teams effective, the researchers first had to define what effectiveness means and how to measure it. They noticed that different roles had different perspectives on effectiveness. In general, whereas executives were interested in results such as sales numbers or product launches, team members thought that team culture was the key to team effectiveness. The team leaders indicated that ownership, vision, and goals were the most important measures.

Eventually, the researchers decided to study certain qualitative and quantitative factors that might impact team effectiveness, such as the following:

Team dynamics: Demographics, conflict resolution, goal setting, psychological safety
Personality traits: Extraversion, conscientiousness
Skill sets: Programming skills, client management

Researchers conducted interviews and reviewed existing survey data for 180 Google teams. They used this data to run 35 different statistical models and understand which of the many inputs collected impacted team effectiveness.

Project Aristotle identified five key dynamics that contribute to the success of software engineering teams (see Figure 1-1). These are listed next in the order of their importance:

Psychological safety

This was the most important factor identified by the researchers. It refers to the extent to which team members feel comfortable expressing their opinions and ideas without fear of retribution or criticism. Teams that have high levels of psychological safety tend to be more innovative and take more risks, which can lead to better outcomes. The researchers found that when teams feel safe, they:

Are less likely to leave the company
Are more likely to utilize the diverse ideas discussed by the team
Bring in more revenue and beat their sales targets
Tend to be rated highly on effectiveness by their leadership

Dependability: This refers to the extent to which team members can rely on each other to complete their work and meet deadlines. Teams in which individuals trust each other to be dependable are more likely to be efficient and effective in their work.
Structure and clarity: These are conditions under which team members clearly understand the project’s goals and their own individual roles and responsibilities. Team members who clearly understand what is expected of them tend to be more productive and focused.
Meaning: This refers to the extent to which team members feel that their work is meaningful and has a purpose. Teams with a strong sense of purpose tend to be more motivated and engaged.
Impact: This refers to how team members believe their work is making a difference and impacting the organization or society. Teams with a strong sense of impact are more committed to their work and the project’s success.

While Project Aristotle’s research was conducted within Google, the identified factors influencing team effectiveness could hold some relevance for teams in other contexts. By focusing on these five factors, software engineering teams can create an environment conducive to collaboration, innovation, and success. As I’ll discuss in Chapter 4, a good manager can foster these dynamics in their teams.

The researchers also discovered that variables such as team composition (size and colocation) or individual attributes (extroverted nature, seniority, tenure, etc.) did not contribute significantly to team effectiveness at Google. While these variables did not significantly impact team effectiveness measurements at Google, that doesn’t mean they’re unimportant, as indicated in the following section.

Other Research

While Project Aristotle is perhaps the best-known study on effective software engineering teams, many other studies have explored factors such as team composition, communication, leadership, and work processes. Here are a few key findings from some of these studies:

Smaller teams are better.: Although Project Aristotle did not recognize team size as relevant to team effectiveness, other studies have shown that smaller teams work better. As a team gets bigger, the number of links that need to be managed among members increases exponentially. Managing these multiple communication channels can be complicated. Many researchers have identified smaller teams containing less than 10 members as more likely to achieve success than larger teams.
Diversity can be beneficial.: It is sometimes suggested that team diversity may lead to communication and coordination problems. For example, a diverse team would usually consist of people from different family backgrounds. Those with young children are more likely to seek flexible work hours, leading to coordination challenges. However, others have found that diverse teams can be more innovative and effective. A study by Lu Hong and Scott Page of the University of Michigan found that groups of randomly selected (likely diverse) high-ability problem solvers can outperform groups comprising the best problem solvers. However, it’s important to note that diversity alone is not enough. Teams must also create an inclusive and respectful environment for all team members. For example, a team that is supportive of team members who need flexible work arrangements will be able to coordinate better than a team that is intolerant of members with such needs.
Clear communication is vital.: Effective communication is essential for effective teamwork. Studies have found that teams that communicate frequently and openly are more successful than those that do not. The idea of psychological safety is a shared belief among team members that they can freely express their thoughts, ideas, concerns, or even mistakes without fear of negative consequences or judgment. Its importance is backed up by the research from Project Aristotle. Clear communication also provides the glue to connect team members and establish structure and clarity within the team.
Leadership matters.: The leadership of a software engineering team can have a significant impact on its success. Google’s Project Oxygen showed that although teams could function without a leader, there is still a need for managers. It identified the essential traits that make for good managers and effective teams. I will talk about these traits in Chapter 4, but for now, it’s necessary to understand that there is a strong correlation between effective leadership and positive team outcomes.
Agility enables adaptability.: Agility is the ability to adapt quickly to changing circumstances. In software engineering, this means being able to pivot when requirements change or when unexpected issues arise. Agile teams are quick to adapt and can work swiftly and efficiently while maintaining high quality. A study by McKinsey & Company found that organizations that underwent successful agile transformations reported a significant improvement in efficiency, speed, customer satisfaction, innovation, and employee engagement, all of which are essential to effectiveness.
Colocation powers innovation.: The debate over whether colocation or remote work is better for software team effectiveness is ongoing, with both approaches having their own advantages and disadvantages. Multiple studies conducted at Harvard, Stanford, and others discuss the benefits of remote or hybrid work in terms of employee satisfaction and retention. However, other studies have shown that face-to-face interactions at the workplace, both planned and serendipitous, trigger the flow of knowledge, sharing of values, and exchange of ideas, which contribute to innovation.

While there may be trivial differences in the findings, we can build a theoretical picture of an ideal effective team based on the research findings discussed in this section. See Figure 1-2. By enabling psychological safety, clarity of structure and communication, dependability, meaningful work, and agility, software engineering teams can create an environment conducive to collaboration, innovation, and success.

You can now build on this understanding of dynamics and factors that influence the effectiveness of teams. The next things to consider are how the working environment can affect teams and how motivation can prime your team for success. As you go through the next sections, notice how the factors that affect teams pop up in various contexts.

Motivation Drives Performance

Before you can build an effective team or plan how to help make your existing team more effective, you need to understand and employ the power of motivation. By motivation, I’m not only talking about traditional rewards and incentives, such as compensation and tangible workplace perks. Such incentives can effectively motivate people to complete simple tasks. In contrast, intrinsic rewards, such as taking pride in your work and learning a new skill, are valued in modern workplaces where innovation and creativity are key—such as in software development. Intrinsic rewards motivate people to work on projects they’re already passionate about, which could include both current projects as well as new, innovative ones. This validation and support allows these people to thrive and do their best work.

According to Daniel H. Pink in his book Drive (Riverhead Books, 2011), there are three elements that genuinely motivate people and drive performance:

Autonomy: Autonomy is the desire to be self-directed and own one’s work. Software engineering teams with a high level of autonomy tend to be more engaged and motivated, as each team can work in a way that best suits its individual strengths and preferences.
Mastery: Mastery is the desire to improve one’s skills and craftsmanship continuously. This principle is essential for software engineering teams as technology constantly evolves and improves. Engineers committed to mastering their craft are more likely to produce high-quality work and contribute to their team’s success.
Purpose: Purpose is the desire to do something meaningful and vital. This principle is essential for software engineering teams, as engineers often work on projects that significantly impact their business or industry. Notice that this echoes one of Project Aristotle’s dynamics of effective teams: impact.

To build an effective team, you must consider these three catalysts that will help to motivate team members.

To understand this better, let me tell you a fictional story of a disillusioned engineer who was able to rediscover his passion and his empathetic manager who was able to motivate him. I shall call them David and Sarah.

David, once a bright-eyed software engineer at a tech company, was slowly losing his spark. He’d been there for five years, working on different projects, but the projects he worked on felt increasingly mundane. He missed the thrill of building something meaningful, something that wasn’t just another cog in the corporate machine.

His manager, Sarah, noticed the shift in his energy. David wasn’t the enthusiastic problem solver he used to be. During their regular one-on-one, Sarah gently inquired about his motivation. “It feels like you’ve lost your fire, David,” she said. “Is there anything we can do to help you rediscover your passion?”

David hesitated. He wasn’t sure how to express his growing dissatisfaction. But Sarah’s genuine concern prompted him to open up. He spoke about his longing for meaningful work, his desire to create something impactful beyond another profit-driven application.

Sarah listened intently, nodding her understanding. She knew David was a valuable asset, and she wanted to help him reignite his passion. She suggested exploring options within the company that aligned with his interests, perhaps volunteering his expertise for internal projects with social impact goals. With Sarah’s support, David began exploring different opportunities. He finally joined a team developing software for a renewable energy project, and his passion came flooding back.

He worked tirelessly, not for recognition or bonuses, but for the intrinsic reward of contributing to a cause he believed in. He was motivated by purpose and the firsthand impact of his work, knowing that his code was helping to create a cleaner future.

Sarah demonstrated good leadership skills in this case. She understood how motivation drives performance and used it to strengthen her team. She demonstrated empathy and collaborated with her employees and her fellow leaders to create a win-win situation for all.

As you can see, when someone is motivated, they are inherently driven to deliver high-quality results and are more likely to be effective. When building an effective team, identify how you can enable and activate the three elements that motivate and drive performance—autonomy, mastery, and purpose—into every step of the team-building process. For example:

Let team members lead the development of individual modules so that they can develop autonomy and a sense of ownership.
Help team members get access to the latest tools that will help them productively master the technology they are working on.
Articulate how their contributions directly impact organizational goals so that they have a meaningful purpose.

Building an Effective Team

As discussed, effective teams share certain qualities or dynamics that enable them to be effective. Their performance is also driven by motivation. Let’s now see how we can leverage this knowledge in practice to build these factors and motivations into an effective team. Regardless of whether you are working with an existing team, hiring new team members, or doing a mix of both, effective team building would usually require that you do the following:

Assemble the right people.
Enable a sense of team spirit.
Lead effectively.
Sustain effectiveness (a growth culture).

The steps outlined in this section are informed by the research findings on the key drivers of team effectiveness discussed earlier in the chapter.

Let’s explore each of these steps in detail.

Assemble the Right People

A modern software engineering team needs to be composed in a way that enables it to be effective. This means having the correct number of people with relevant skills, people with shared engineering mindsets, and people with diverse backgrounds and experiences, who can work together effectively to accomplish their shared goal. As the research on team size and diversity showed, the composition of a software team can have a big impact on its effectiveness.

If you’re working with an existing team on an ongoing project, assess your current team structure and collection of skills and backgrounds. You may want to adjust things after reading this section to improve team effectiveness. If you’re assembling a new team for a project, aim to build in size, mindset, and diversity from the start. You’ll also want to consider this when adding new team members to an existing project.

While ideal team size and composition will vary based on factors like industry, company size, and product complexity, research provides some general guidelines. One study found that the optimal team size for software projects is between three and five members. However, teams working on highly complex projects in large enterprise organizations may need to be larger, while startups or teams working on smaller-scale projects may be successful with even fewer members.

Hiring and interviewing for effectiveness

When building a new team or adding members to an existing one, it’s important to assess candidates not just for their technical skills but also for the key mindsets and qualities that contribute to team effectiveness. During interviews, ask questions that probe for evidence of the engineering mindsets discussed earlier, such as caring about users, being a good problem solver, and being open to learning and growth. Present candidates with scenarios that test their approach to challenges like prioritization and balancing trade-offs.

To build a diverse team, cast a wide net in your recruiting efforts and be aware of potential biases in your hiring process. Set diversity goals and regularly review your pipeline and hiring decisions to identify areas for improvement. Throughout the hiring process, communicate your team’s culture and values so candidates can self-select for fit. The hiring process is a two-way street, and you want team members who have bought into your team’s ways of working.

Size

The composition of a software development team may vary depending on the complexity of the project and the development methodology being followed. In addition to software engineers or developers, there could be project managers, product managers, quality engineers, technical architects, team leaders, UI/UX specialists, etc. Each member has a responsibility to fulfill, and modern software engineering teams can vary in size from small 2-person teams to large teams with over 10 people.

Determining the right size for your team for every project is essential. The same set of people who worked very well together on a large project may falter on a small project. Consider this fictional story about a startup—I shall call them Code Crusaders. They had delivered a strong initial version of their product with a can-do spirit. But their initial success soon dissolved as their team size ballooned beyond manageable levels.

With 30 developers working on four different versions of the same product, communication became a tangled web of meetings, emails, and conflicting priorities. Deadlines were missed, projects stagnated, and frustration grew. The once-cohesive team fractured into isolated pockets, each working on its own piece of the puzzle without a clear vision of the whole. Decision making became agonizingly slow, bogged down by endless debates and conflicting opinions. The joy of collaboration was replaced by a feeling of being lost in a bureaucratic maze.

Despite individual talent, the Code Crusaders team found their effectiveness crippled by their growing size. They were a victim of their own success, a testament to the fact that bigger isn’t always better.

The ideal size for your software engineering team depends on various factors, including the project, product, company culture, and team dynamics. Ask yourself the following questions:

Product: What resources do I need to build my product? Team size should reflect the resources required for a product. An app that needs to be updated regularly and has many users will require more resources than an internal tool that only one person uses.
Complexity: Is my product simple and easy to develop or intricate and tricky? A simple product, such as a chat client, will need fewer engineers compared to something more complex, like machine learning algorithms or AI systems.
Company culture: How much autonomy does each member have within their role or team? Some organizations prefer several small groups and encourage collaboration among them. Others prefer a small number of larger groups working independently.
Leadership style: Does the company encourage open communication between everyone involved so they know how their contributions fit into larger goals? Or does it focus more heavily on top-down decision making, where leaders make all major decisions without input from those below them who are closest geographically/organizationally?

Once you know the answers to these questions, you can check them against what you currently have or what you would want for your new team. You can then decide if:

You need any additional engineers or engineers with different skill sets.
The existing engineers on your team need to reskill.
Outsourcing is required for some modules, or if they can all be developed in-house.

Shared engineer’s mindset

To have an effective software engineering team, it would be ideal if each member had the right mindset. When I talk about mindset, I’m referring to the attitude of valuing the five dynamics identified by Project Aristotle (psychological safety, dependability, structure and clarity, meaning, and impact) and motivation for intrinsic rewards. This mindset is the glue that binds a group of software engineers together and makes them an effective team.

Software engineers have a clear high-level purpose: to build software that solves problems that customers would pay to have solved. Engineers must think about what matters most and the impact their software will have. Often, this involves delivering the best value to users and the business, and it also involves self-growth within the available time. As part of a team, engineers work in synergy to build software. Having a shared engineering mindset will ease the path toward synergy and effectiveness.

That said, in this section, I’ll talk about qualities you should look for in software engineers when building or enhancing an effective team. Keep in mind that not everyone will feel the same way to the same extent about everything or excel in all of these attributes, and that’s OK. The point is to have a healthy culture with characteristics of effective teams. However, by cultivating a diverse team, you may achieve a harmonious equilibrium, such that engineers can observe and learn from their colleagues within the team.

As such, when building a new team, hire engineers who already demonstrate most of the following characteristics. If you’re enhancing an existing team, encourage and help your team to further develop these characteristics.

Cares about the user.

When building a new team or building up your current team, you’ll want engineers who care about users. An effective software engineer must understand that the user’s needs are more important than using a specific technology or framework. A good software engineer will consider the following:

The problem domain: What does the user want to accomplish with the product?
The business context: What business purpose does the product support?
The business priorities: What product features are more important for the business over the relevant timeframe (quarter or year)?
The technology: What technologies are available, and which of these would work best for the product?

By asking these questions, a good software engineer will be able to contribute to a high-quality product that will fulfill the user’s needs. If they don’t think about how people will use the product or service, then it’s likely that what’s getting built won’t be helpful in people’s lives.

While this may sound obvious, I have seen developers who get caught up in the details of writing code without considering why they’re doing so in the first place. This can lead them astray from their actual goals. Focusing on small tasks instead of contributing to significant outcomes like solving real problems or creating meaningful user experiences can prevent engineers from doing their best work.

If you’re enhancing an existing team, develop this mindset in your team members by encouraging the following:

User interaction: While direct user interaction for each engineer may not be feasible, you can allow engineers to shadow support engineers or participate in usability testing drills to get acquainted with some day-to-day issues that users may encounter.
User research workshops: Encourage engineers to participate in workshops that focus on activities like user interviews or journey mapping. This can help them develop empathy toward user needs and perspectives.

Is a good problem solver.

In a 2017 commencement speech, Dr. Neil deGrasse Tyson said, “You realize when you know how to think, it empowers you far beyond those who know only what to think.” You can apply this principle to your engineering team because building software is not just about following established processes or knowing what to think; it’s about fostering a mindset that encourages thinking beyond the ordinary.

In the same speech, Dr. Tyson shared an interview scenario where two candidates are asked about the height of a building’s spire. The first candidate quickly provides the correct answer based on memorized information. The second candidate, however, admits not knowing the answer initially but demonstrates resourcefulness by measuring shadows to make an educated estimation. The second candidate in this case demonstrates the ability to think creatively and adapt to the situation to solve a problem.

Effective engineers have to be good at solving problems practically. Often, the best solutions are simple and elegant. But it may require thinking outside the box. Usually, a problem can be solved in multiple ways—some that are neat (but not overly complicated) and others that are unconventional but still effective.

The ability to solve problems also includes the ability to use prescribed tools and processes. An effective engineer should be able to solve problems within the constraints of the current technology while thinking out of the box if required. They should also consider all aspects of a problem at the same time.

Can keep things simple but cares about quality.

Some engineers write overly complex solutions for use cases that may not necessarily exist. Although they want to be thorough, the low likelihood of these scenarios occurring may not justify the effort spent. Effective engineers should understand the core problem and know how to solve it reasonably while keeping things simple. It’s also necessary for them to understand the trade-offs between simplicity and performance.

Although this trait may sound deceptively simple, it requires constant vigilance, as it may be necessary to balance trade-offs between different quality dimensions (e.g., accessibility versus performance). When competing priorities are in play, engineers should be able to make informed decisions based on their knowledge of the product domain and its users.

Encourage engineers to clearly define the core problem and specific use cases before diving into solution development. Doing this will help them avoid overengineering and deliver simple yet high-quality solutions.

Can build trust over time.

Effective engineers should understand the importance of being trustworthy, as in they can be depended upon to do their tasks as expected. Trust cannot be built overnight, so demonstrating trustworthiness for a period of time also shows dependability and consistency. This understanding of trust leads to engineers having autonomy and social capital:

Autonomy: Autonomy is built on trust. Someone is given autonomy if they can be trusted to do their tasks dependably and consistently. As mentioned earlier, teams with a high level of autonomy tend to be more engaged and motivated. Autonomous workers are happy workers—and happy workers tend to be more productive than their coworkers who aren’t given any choice in how they do their job. But autonomy doesn’t mean they can misuse their resources or power. Self-motivated engineers who can study a given situation to decide on the best way to address it are more effectively autonomous. Autonomy also does not translate to asking fewer questions. Committed individuals would promptly seek clarifications to unblock themselves and the task at hand in effective ways.
Social capital: You have social capital when you have a network of positive relationships with people. These relationships are built on cooperation and trust. Effective software engineers build networks of positive relationships with people. These engineers are adept at sharing their skills with others within and outside their team and enabling collaboration.

An effective software engineer understands that trust is built over time through mutual respect and open communication with other team members. They can make good with any autonomy granted to them while still collaborating effectively on projects requiring creativity and technical skill—and maybe even some good old-fashioned fun!

You can help your existing team members to develop these skills by encouraging them to participate in initiatives that span beyond their core roles and not only showcase their expertise but also foster relationships and trust with team members from diverse backgrounds. At Chrome, I frequently encourage my team members to write about the new features they are developing on the Chrome developers blog or engage with the developer community through tech talks. This collaborative experience not only builds their social capital but also grants them a sense of autonomy as they take ownership of their contributions.

Understand team strategy.

Effective engineers should understand and be able to communicate how the team will achieve its goals and how their actions can help or hinder its success. They should be able to answer these questions:

What are we trying to accomplish?
How do we plan on getting there?
What role do I play in achieving these goals?
How will my actions affect other teams or individuals in attaining their goals?

Whether you are interviewing someone new or conducting a one-on-one session with an existing team member, consider asking them questions such as “How do you see your skills contributing to our objectives?” or “What potential challenges do you foresee?”

Imagine you are managing a software development team tasked with reducing application load times to enhance user experience. As a manager, you could outline the strategy during a team meeting, emphasizing that faster load times are crucial for retaining and attracting users. You might also discuss the specific roles team members will play, such as optimizing code, improving server performance, or conducting user experience testing. This involvement helps team members connect their daily tasks to the broader goal of enhancing user experience. They are more likely to understand the team’s strategy and feel like they are a part of it, which in turn enhances their sense of purpose.

Can prioritize appropriately and execute independently.

Effective software engineers can prioritize appropriately and execute independently. Software engineers are often required to juggle multiple priorities, including technical debt, speed of delivery, and quality, while keeping the business goals and ultimately the customer in mind. When faced with issues, effective engineers don’t rush into quick fixes. Instead, they seek the root cause of problems and propose solutions that balance these priorities effectively.

A competent software engineer also knows when it’s appropriate to take ownership of tasks and projects without being told what needs to be done by their direct manager or leader. They will know when drawing from their peers for help bearing this load makes sense—and communicate effectively with other teams when necessary.

You can help team members prioritize their work by clearly sharing the organization’s and project’s strategic priorities and following up with them through regular check-ins and goal-setting sessions. Always ensure that engineers have the necessary resources and guidance to execute their responsibilities effectively.

Can think long term.

Thinking long term is an essential trait for an effective software engineer. They need to see the big picture and understand how each product component fits into the company’s overall goal or set of goals.

Software engineers who can think long term are better equipped to understand how new technologies will impact their products in the future. They also better understand what kind of team dynamics and culture will affect their development efforts. They design and build flexible solutions, anticipating the changes that may be required in the future.

When enhancing an existing team, you should positively acknowledge the actions of forward-thinking team members and encourage other members to follow suit. A simple example could be variable naming conventions in code. Using variable names such as x and y may be quicker but reduces the maintainability of the code for someone looking at it six months down the line. Encourage your team to write code that can be understood by other developers too.

Can leave software projects in better shape (if time allows).

If time allows, engineers who are maintaining existing code or projects should be willing to leave a project in better shape than they found it. This means making the code better, making sure that the documentation is up to date and accurate, cleaning up the environment so it’s easier for the next person to pick up, improving the team’s processes and culture over time, and growing as a professional developer by learning more about other languages/technologies/frameworks that are relevant.

They should also consider how their work impacts their immediate colleagues and everyone else in the organization and community. Identify individuals in your team who suggest cleaning up the surrounding code when working on an existing module. Ask them to review code written by other engineers so that they can mentor the others. When hiring a new team member, ask them to share examples of times when they improved the quality of a project that they worked on.

Is comfortable taking on new challenges.

An effective software engineer is comfortable taking on new challenges if organization or team requirements change. This could mean taking on a new project or additional responsibilities such as mentoring or reviews within the same project.

As technologies evolve, so do the requirements for the job. Flexibility and the ability to learn quickly will ensure that engineers can adapt when necessary and grow with the organization.

When enhancing an existing team, keep an eye out for team members who have been working on the same part of the code for a long time and assign them fresh tasks or responsibilities that encourage growth. This approach not only fosters growth and engagement but also helps engineers shed any fear of change, enabling them to comfortably embrace new challenges.

When hiring members for a new team, consider individuals who possess some of the required technical skills but also demonstrate openness to exploring new technologies or domains.

Can communicate effectively.

Communicating effectively within the team, with other teams, and with the customer is essential. This means that engineers must be able to communicate technical information effectively to peers and management. This quality is important because miscommunication may result in bugs or issues that need fixing.

When communicating with peers, engineers should use clear and concise language. They should also pay close attention to what their peers say to help them understand their colleagues’ perspectives and concerns.

Communicating effectively with other stakeholders, such as sales or marketing departments, is also essential. A software engineer should know what their product does, how it works, and why it benefits customers and users.

When communicating with customers, engineers should use simple language so the customers can understand them clearly without getting confused by technical jargon. Otherwise, customers will lose interest very quickly!

To improve communication in an existing team, encourage team members to share ideas freely, raise concerns, ask questions, listen actively, engage in constructive discussions, and value diverse perspectives. Also consider organizing workshops for those who need additional help with their communication skills.

If you are interviewing new engineers, consider candidates who can articulate technical concepts clearly and concisely. Evaluate their ability to listen actively and respond thoughtfully. Candidates who can adapt their communication style to different audiences and demonstrate an understanding of cultural nuances are able to adapt better in existing teams.

Diversity and inclusion

When building a new software engineering team or enhancing an existing one, aiming to have team members with diverse skill sets, backgrounds, and experiences makes a difference. This can include diversity in terms of race, gender, age, educational background, and work experience. For example, if you have a group of engineers who all come from an enterprise background, consider rounding out your team by finding someone who has experience building consumer apps as well.

By developing a diverse team, you’ll be able to tap into a broader range of perspectives and experiences, which can lead to better problem-solving and innovation.

Google Translate and other natural language processing products are testaments to how diversity in a software team results in a successful product. Computer scientists and linguists have worked hand-in-hand on the Google Translate team. The linguists on the team provided insights into the nuances of different languages and how they could be translated effectively. At the same time, computer scientists and engineers were able to develop the algorithms and technology needed to power the translation engine.

Having a diverse team alone is not enough. Building diverse teams requires intentional effort, overcoming biases, and navigating cultural differences. There is bound to be some friction, and enabling seamless collaboration among a group of individuals with distinct personalities is challenging. Yet, with patience, understanding, and a commitment to inclusivity, the initial friction can be overcome to build a strong cohesive unit. I have been fortunate enough to experience this firsthand.

It would help if you also created a culture of inclusion.

For example, at Google, we initiated a new team for building a new developer product. The diversity was palpable. We had members from four continents, ranging from fresh-out-of-college juniors to veterans with over a decade of experience.

However, the initial meetings were more like a monologue than a dialogue. The junior members, smart yet unseasoned, were reluctant to voice their ideas, often overshadowed by more experienced voices. I used to regularly hear comments like “I’m not sure that what I have to add is going to matter compared to what the senior engineers have to say.” I had to plan to overcome these challenges.

My first step was to create an environment where every opinion was valued equally. I initiated round-robin sessions, where each member, irrespective of their rank or tenure, was given uninterrupted time to voice their thoughts. This not only encouraged junior members to speak up but also helped senior members to listen actively.

Second, acknowledging and embracing our cultural differences played a pivotal role. I started having biweekly virtual “cultural exchange” meetups. Team members would share something unique about their culture—be it a local tradition, a festival, or even a coding practice unique to their region. This not only broke the ice but created a tapestry of cultural awareness and mutual respect.

Third, I promoted psychological safety through open forums. Psychological safety doesn’t sprout overnight. It’s a garden that needs constant nurturing. To this end, I established an “Ideas and Concerns” forum. Here, team members could anonymously post their ideas or concerns. Every week, we would address these in our team meetings, ensuring that each voice, however quiet, was heard and considered. This practice encouraged even the most introverted members to share their innovative ideas without the fear of judgment.

Finally, to further bridge the experience gap, I paired junior members with senior mentors. These mentorship relationships went beyond mere technical guidance. They included navigating workplace dynamics, understanding unwritten industry norms, and developing soft skills crucial for career progression.

These strategies transformed our team dynamics. The once hesitant junior members began contributing ideas that were out of the box and sometimes crucial to solving complex problems. The senior members, on the other hand, found fresh perspectives and renewed enthusiasm in mentoring. Our project not only met its deadlines, but subsequent releases went even more smoothly.

Through this journey, the most significant lesson I learned was that leadership in tech is not just about managing projects; it’s about nurturing an ecosystem where diverse talents can coalesce, grow, and create something extraordinary. This means creating an environment where all team members feel valued and respected, regardless of their background or identity. Some strategies for creating a culture of inclusion include:

Providing diversity and inclusion training for all team members to help them understand different backgrounds and practices
Encouraging open communication and feedback
Ensuring that all team members have equal opportunities for growth and development
Providing flexible work arrangements to accommodate diverse needs and lifestyles

To wrap it up, an effective software engineering team needs three important things: the right number of people, team members who have the right attitude for being effective both by themselves and as a team, and people with different skills and backgrounds. These factors together help you create a foundation for effective teamwork and success .

Enable a Sense of Team Spirit

Once your team has been assembled, the next step to building an effective team is enabling a sense of team spirit. A group of people has team spirit when they feel invested in reaching their shared goal and are there to support each other. It is more than just getting along or being helpful. As previously stated, by definition, a team is bound by shared responsibilities and goals. Members work together and share mutual accountability to solve problems and achieve common goals. With team spirit, members work together in harmony but are also willing to help each other accomplish tasks. A group that works in harmony can get more results in less time than one that does not.

Cultivating team spirit is all about building the key effectiveness factors of psychological safety and dependability that were identified in the Project Aristotle study.

You can cultivate team spirit by creating an environment for collaboration and communication. The foundation of this involves defining roles and responsibilities, establishing a shared purpose, and fostering trust among members.

Define roles and responsibilities

Defining roles and responsibilities within a team is a fundamental step toward effective collaboration. It isn’t just about assigning tasks; it’s about ensuring that each team member understands their specific duties, which in turn minimizes confusion, the risk of overlapping efforts, and undue frustration.

Software roles do have some overlapping responsibilities depending on context. For example, establishing responsibilities for different types of documentation such as requirement specifications, test cases, user guides, API documentation, etc., can be challenging.

My friend Alex was once assigned to lead a project where developers were efficient at churning out code but avoided updating design documents. Similarly, testers often found themselves struggling to decipher requirements generated by a collaboration between the business analysts and technical writers. Meanwhile, the technical writers themselves were swamped with internal tasks and did not have enough time for the user manual. The project was on fire and, in spite of having fully functional code, users were unhappy.

Alex knew the problem: misaligned responsibilities. He implemented ownership. Developers, empowered with clear expectations, penned their own docs and unit test cases. Business analysts worked with product owners to define clear requirements. Testers, equipped with solid requirements, focused on preparing clear test plans and finding issues. Technical writers, freed from internal burdens, turned their attention to crafting user-friendly guides.

The transformation was subtle but impactful. Collaboration replaced blame. The once-dreaded testing phase was now embraced as an opportunity to collaborate and improve the product. User manuals turned out to be informative and intuitive. Alex had successfully demonstrated the importance of ownership and role clarity.

Role clarity can thus help to cultivate a sense of team spirit and unity if you align responsibilities with individual strengths and skills. You must also highlight the interdependence of team members’ contributions, emphasizing the collaborative aspect of their work. This approach not only enhances efficiency but also fosters a culture of mutual support and shared achievement.

Moreover, role definition should allow for skill development and adaptation as the project progresses. It’s essential to recognize and appreciate the contributions of each team member, reinforcing their sense of value within the team. By periodically reviewing and adapting roles and responsibilities, you can ensure that they stay aligned with evolving needs and individual growth. In this way, defining roles and responsibilities becomes a dynamic process that not only promotes clarity but also nurtures team spirit and maximizes effectiveness.

Establish a shared purpose

Similar to having a shared goal, having a shared purpose drives the team to work together and overcome their differences. While goals help to convey what the team should be achieving, purpose articulates why they need to achieve these goals. I have seen many software engineering teams struggle to balance competing priorities, with architects focused on scalability and performance, developers on deadlines and code efficiency, testers on identifying edge case issues, and designers on aesthetics and experience. While each of these is important, teams need a shared sense of purpose to align on what to prioritize to create the best overall product. While focusing on all of these is essential to create a good product, a shared purpose is required to understand the priorities.

Without a shared purpose that balances ambition, quality, user experience, and design, these teams face challenges such as technical debt, scope creep, usability issues, and internal conflicts.

A leader who establishes a shared purpose is able to channel all the different energies to create a platform that’s both innovative and user-friendly, delivered with quality and efficiency.

To establish a shared sense of purpose, you can do the following:

Communicate the overall project purpose and goals: Clearly articulate the project’s purpose, target audience, and desired impact. Share user personas, mock-ups, or competitor analyses to create a tangible picture of the “what” and “why.” This provides a North Star for individual contributions.
Encourage team members to share their ideas and feedback: Organize brainstorming sessions, workshops, and regular check-ins where developers, testers, designers, and architects can freely share their expertise and concerns. This fosters a collaborative environment and surfaces diverse perspectives, enriching the shared vision.
Ensure that all team members understand how their work fits in with what their teammates are doing and into the larger project goals: Link individual tasks to specific features and user stories, and highlight how each team member’s contribution impacts the product’s overall functionality and user experience. This creates a sense of shared ownership and reinforces the “we’re in this together” mentality.

You can achieve these objectives via regular knowledge-sharing sessions or team-bonding exercises within or outside the office. These activities create opportunities for team members to come together, exchange ideas, and build rapport beyond their immediate tasks. It fosters a sense of belonging and reinforces the shared purpose, reminding everyone that they are part of a collaborative effort aiming for a common goal. As a bonus, these sessions can also ignite fresh perspectives and innovative solutions. By taking these steps, you will increase the chances of successfully delivering a product that meets user needs while achieving the team’s ambitions.

Foster trust among team members

An essential part of cultivating a sense of team spirit is building trust among team members. To understand this better, imagine there are two teams; let’s call them Team Open-Door and Team Silos.

Team Open-Door is known for its collaborative spirit and open communication. Shared knowledge and a culture of asking for help without judgment leads to faster problem-solving in this team. Trusting fellow teammates to do the right thing reduces stress levels and helps to boost morale. Open discussions lead to diverse perspectives, leading in turn to innovative approaches and unexpected features. It is a team that attracts top talent and accolades from clients and is trusted by management to handle key projects.

Team Silos, on the other hand, consists of highly skilled but isolated developers, each working on their own modules with minimal communication. Miscommunication and rework due to conflicting code and overlapping functionalities slow them down frequently. A “not my problem” attitude further delays the resolution of issues. Frustration and resentment fester in a blame game environment. The lack of trust hampers collaboration and leads to subpar results.

Overall, trust within a software engineering team isn’t just a feel-good factor; it’s a powerful driver of success. Open communication, shared knowledge, and a culture of collaboration can turn a team of individuals into a cohesive unit, producing outstanding results. Trust can also help to foster better work-life balance for individuals on the team. You are able to take short breaks from work and feel relaxed during these, when you trust other team members to fill in for you.

To foster trust within your team, you can:

Encourage open communication and feedback.
Provide opportunities for team members to get to know each other on a personal level.
Be transparent about project goals and timelines.
Reward teamwork and collaboration.

Working together toward a shared goal with fellow team members you trust to have your back goes a long way toward binding the team, enabling a sense of team spirit, and motivating it to stay on track. While such a team may seem auto-motivated, a leader is still needed to help clear roadblocks and provide mentorship and guidance. Let’s see what it takes to lead effectively.

Lead Effectively

To build an effective team, you must also be an effective leader. Although strong teams can function without a leader, effective leaders impact employee performance and satisfaction, decision-making skills, and collaboration, and they promote a positive work environment.²

The Project Oxygen research highlighted the crucial role that leadership plays in team effectiveness. You need to fulfill your core responsibilities, enable effective practices, and use strategic visibility. You’ll explore what it means to be an effective leader and enable effectiveness in the coming chapters of this book, but this section will touch upon the core responsibilities of a leader and the importance of strategic visibility.

Responsibilities of effective leaders

As a leader, your core responsibilities are to inspire, influence, and guide your team toward a shared goal. Effective leaders build successful teams by incorporating effectiveness practices into these core responsibilities. For example:

You are responsible for planning team roles and composition.
You help to set goals and priorities for the group/team members.
You ensure that everyone has what they need (tools/resources) to complete tasks effectively.
You leverage your experience to provide insights into where issues may arise so they can be proactively addressed before they cause significant problems.
You establish clear lines of communication using tools and processes that promote effective communication.
You communicate regularly via team meetings, status updates, and progress reports. Communication should be timely, transparent, and inclusive.

Notice that these responsibilities directly support the characteristics that are built into an effective team.

Strategic visibility

Strategic visibility is about communicating the team’s accomplishments and their impact on the business to internal and external stakeholders. This can involve highlighting how their work addresses a critical customer need, improves efficiency, or contributes to a larger product vision. By effectively showcasing their value through compelling stories and data, you ensure that the team gains recognition within the organization and is positioned for future opportunities, resources, and influence.

As previously discussed, motivation drives performance. Although people can be motivated by autonomy, mastery, and purpose, they are also motivated by recognition and validation. As a leader, make a point to publicly support the efforts of your team within your organization—without calling attention to your own involvement. Not only do organization-wide recognition and acknowledged success fuel team motivation, but they also showcase talent and unlock doors to future growth opportunities for your team members. Remember, you can be your team’s best cheerleader, inspiring them to reach new heights and achieve their goals together.

Here’s a real-life example to better illustrate strategic visibility. I once led a team of exceptionally skilled engineers. Despite our consistent delivery of high-impact work, we were like a hidden gem, often overshadowed by the more glamorous, high-profile projects within the company. This was the case even though (we thought) our contributions were integral to the overall product’s success.

Initially, I observed a tinge of frustration among my team members. They worked tirelessly, often solving complex problems, but they did not receive the recognition they deserved. As a leader, I knew it was crucial not only to acknowledge their work but to ensure it was seen and appreciated at a broader organizational level.

I realized that the key was not just working hard but working smart—aligning our efforts with the company’s top priorities. This didn’t mean abandoning our current projects but rather finding a way to connect our work to the larger narrative of the company’s goals.

We started by identifying a project that was directly tied to one of the company’s main objectives for the year. This project wasn’t just a high priority for the company; it was also a perfect match for our team’s unique skills and expertise.

We dove into the project, applying our deep knowledge of browser technologies and product engineering principles. We focused on not just completing the project but exceeding expectations, adding innovative features that we knew would make a significant impact.

I encouraged the team to document our process and outcomes meticulously. We shared regular updates not just within our team but with other teams and stakeholders. This transparency wasn’t just about visibility; it was about opening channels for collaboration and feedback.

The project was a success, significantly impacting the company’s goals. But more importantly, it put our team in the spotlight. Our work was recognized in company-wide meetings, and team members were invited to speak at internal tech talks and conferences. This recognition was a morale booster, and it fostered a sense of pride in our team.

Here’s what I learned about leadership from this experience. As a leader, you should do the following:

Align with broader objectives: Your work’s impact multiplies when it aligns with your organization’s primary goals.
Leverage your team’s unique strengths: Understand and utilize the unique skills and knowledge of your team.
Communicate effectively: Regularly share your progress and learnings. Transparency fosters recognition and collaboration.
Focus on impact, not just hard work: It’s not just about working hard but also about creating tangible impacts that align with organizational priorities.
Build a narrative around your work: Document and share your journey; it’s crucial for visibility and recognition.

In a nutshell, this experience taught me that, in the tech industry, being in the shadows doesn’t mean you’re not valuable. Sometimes, it just means you need a strategic approach to showcasing your value. By actively championing your team members, you cultivate a culture of trust, loyalty, and mutual support, ultimately empowering them to excel and contribute to the overall success of the team .

Sustain Effectiveness (A Growth Culture)

The final step to building an effective team is sustaining the culture that you have built via continuous growth. Establishing a shared purpose and open communication can foster a strong team culture, leading to an engaged and motivated team. Additionally, for team members to believe that their impact and contributions matter to the organization, leaders must create opportunities for team members to develop their skills and grow within their roles. Sustaining effectiveness over time (as seen in Figure 1-3) requires supporting the factors of agility, purpose, and impact that researchers have found to be key drivers of team success.

Learning and development opportunities

Growth opportunities can be great sources of motivation for team members, and, as discussed earlier in this chapter, motivation drives performance. On the other hand, lack of learning and development opportunities can lead to stagnation. A team that does not know how to improvise can get stuck in outdated methods. Imagine a team today that has not considered using AI tools to improve its processes. Stagnation can also breed boredom and frustration, leading to decreased productivity and talent drain.

Growth can also come in the form of learning opportunities, which can be created through training, mentorship, and coaching.

Agility

As discussed earlier in this chapter, research has shown that agility is critical for team effectiveness because it enables teams to respond quickly and effectively to changing business requirements, customer needs, and market dynamics. Agile teams are more adaptable to changing circumstances and can adjust their development plans when needed.

Here are some strategies for ensuring team agility:

Emphasize agile methodologies: Agile methodologies provide a framework for delivering software flexibly and iteratively. By implementing agile practices, such as Scrum or Kanban, teams can improve their ability to adapt to changing requirements and priorities. However, it’s essential that you tailor agile processes to meet your team needs rather than follow them blindly from a textbook.
Promote cross-functional collaboration: Encourage team members to work across functional boundaries, such as developers working with UI/UX designers. This can help break down silos, encourage sharing and reuse, and increase collaboration and communication, leading to more efficient and effective development processes.
Prioritize communication: Effective communication is critical for agile teams. Ensure team members have regular check-ins and meetings to discuss progress, challenges, and priorities. Encourage open and honest communication, and provide channels for feedback.
Build a culture of adaptability: Foster a culture that values adaptability and embraces change. Encourage experimentation and risk-taking, and reward teams for being responsive to changing circumstances and customer needs.
Implement continuous integration and delivery: Continuous integration and delivery practices can help teams deliver software faster and reliably. By automating the building, testing, and deployment process, teams can reduce the time and effort required to release new features and updates.

By implementing these strategies, effective teams can become more agile, adaptive, and responsive to changing business needs and customer requirements.

Continuous improvement

Effective software engineering teams are committed to continuous improvement. This means they constantly seek ways to improve their processes, tools, and skills. Teams should regularly evaluate their performance and identify areas for improvement. They should also seek feedback from other teams, stakeholders, and customers to identify areas for improvement. Encourage team members to be committed to continuous improvement and provide them with the tools and resources they need to be successful. This can include access to new technologies, feedback loops, and a culture of experimentation.

Continuous improvement requires a culture of learning and growth. The following tips can help to create such a culture:

Foster continuous learning: Encourage team members to learn new skills and technologies and provide them with opportunities for professional development. This can help team members stay up to date with industry trends and best practices.
Measure and monitor performance: Regularly track key performance indicators (KPIs) to assess team performance and identify areas for improvement. Use the data to inform decisions, prioritize work, and make adjustments to ensure the team meets its goals.

In an ever-changing technology landscape, software development teams must continuously adapt to meet evolving user needs, business requirements, and market demands. Agile methodologies can promote a culture of continuous learning and improvement within the team and enable software development teams to be more efficient and effective in delivering value to stakeholders .

Conclusion

Building an effective software engineering team takes work. As you’ve seen in this chapter, many factors can influence the success of a software engineering team.

The guidance provided in this chapter on building effective teams maps closely to the research findings on the key factors that drive team effectiveness. Composing a strong team builds the foundation for the right mix of skills and perspectives. Enabling team spirit fosters the psychological safety and dependability that allow team members to take risks and rely on each other. Effective leadership provides the direction and support teams need to do their best work. And sustaining a growth culture allows teams to continuously improve and adapt to new challenges.

Project Aristotle and other research on effective teams showed that enabling psychological safety, clarity of structure and communication, dependability, meaningful work, and agility can create an environment conducive to collaboration, innovation, and success. These factors recur throughout the chapter and bind teams together in their drive to be effective.

Effective teams share certain qualities or dynamics that enable them to be effective. Their performance is also driven by motivation. Therefore, to build an a new team that will be effective or develop an existing team to make it more effective, you must take certain factors into consideration. These factors include composing your team with the right number of people for a project, with diverse skill sets and backgrounds. It also includes developing an engineering mindset in each member, which creates a synergy that eases the way for collaboration and effective performance. This is further cemented by a sense of team spirit.

Although it may sound obvious, an effective team must be led by an effective leader. Set up your team for success by incorporating effectiveness practices in everything you do, and don’t be afraid of acknowledging your team’s efforts. Recognition is valuable, not just for morale, but for your team’s career growth.

Finally, to have an effective team, you must sustain a growth culture. This keeps the team agile, always improving, and better equipped to handle anything that comes its way.

These foundations can help us structure our teams for the best possible outcomes. These factors can help you create a motivated and productive team that consistently delivers high-quality results. With the right people, communication, and support, you can build a team that thrives and successfully completes even the most complex projects.

Measuring and monitoring effectiveness throughout a project’s lifecycle is as essential as enabling it. To correctly measure effectiveness, you need to understand how it differs from concepts of productivity and efficiency. The following chapter discusses the differences between these concepts and how they are measured.

¹ They called it Project Aristotle as a tribute to the Greek philosopher, Aristotle, who is often quoted as saying, “The whole is greater than the sum of its parts.”

² I’ll talk more in detail about the effect of manager behaviors in Chapter 4.

Get Leading Effective Engineering Teams now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial