Programming note: instead of our usual The Pulse on Thursday, today we peek inside a book that I wrote the foreword for. Our regular schedule — and The Pulse — returns next week.

Addy Osmani is a software engineer and engineering leader. He’s worked at Google for 12 years, and is currently the Head of Chrome Developer Experience. Addy regularly shares insights on software engineering and engineering leadership, and is the author of several software engineering books.

When I was visiting the Bay Area, we met up with Addy, who gave a tour of the Chrome offices:

As we talked, he shared how he’s been working on a book about engineering leadership – collecting a decade of lessons learned in motivating and leading engineering teams. The lessons span Addy’s earlier days – when he was a software engineer, and was mentoring fellow devs – through working as a tech lead manager (a specialist role present in larger tech companies like Google – all the way to leading larger engineering teams. I was intrigued, and asked for an early look. In the end, not only did I read the book ahead of release, but I found it such a neat mix of “theory” and “practice” that I volunteered to write the foreword.

The book is now out, and I asked Addy if he’d be open to sharing two relevant parts with all newsletter readers. Addy said yes, and so in this issue we take a look inside the book, covering:

1. Context on the book. Why write this book, how long it took, and Addy’s favorite part of it.

2. What Makes a Software Engineering Team Effective? No company invested more research in this area than Google. A brief summary of Project Aristotle and Project Oxygen, and a collection of other useful team dynamics research.

3. Leadership roles: tech lead, engineering manager, and tech lead manager. A look at how these three roles overlap, and also differ. The tech lead manager (TLM) is unique to Google, and a few similar companies, and is the most unusual of the three.

Get the full book

My usual disclaimer: as with all my recommendations, I was not paid to recommend this book, and none of the links are affiliate ones. See my ethics statement for more details.

1. Context on the book

How did the idea for writing this book come around? This is what Addy told me:

“The idea for the book started percolating a few years back. I'd been in the trenches of engineering leadership at Google, and I was seeing patterns – ICs, leaders and managers all cared about being effective, but there wasn't a well defined resource on this topic. I would email folks guidance whenever they would ask, but there was a real disconnect between the academic world of management and the gritty reality of leading high-performing engineering teams. 

People were hungry for practical guidance, not just theoretical frameworks. That's when I realized there was a need for a book that could bridge that gap. 

So I started working on my notes that would eventually turn into this book.”

Writing a book takes a long time, and I was curious how much effort this one took. It was 1.5 years to write – plus the many years of experience to have something worthwhile to pen down. From Addy:

“Writing the book was a longer haul than I expected. Writing a book is a bit like building a complex software system - it requires careful planning, execution, and constant iteration. 

While the actual writing took about a year and a half, the foundation was years in the making. It was essential to blend my personal experiences with rigorous research. I wanted to ensure the book wasn't just a collection of anecdotes but a practical guide backed by data and insights. I think as a team (O'Reilly, our editors and tech reviewers as well) we were able to land on something in the end that we all felt proud of.”

The book has seven chapters, and I was curious as to what Addy’s favorite part is, if there’s any. Addy said:

“The 3 E's framework (enable, empower, expand) is undoubtedly the cornerstone of the book. It's something I've been refining over years of leading teams. I'm particularly proud of how it provides a practical approach to building high-performing engineering organizations.

What excites me most is how the model can be adapted to different team sizes and company cultures. It's not a one-size-fits-all solution, but a flexible framework that can guide leaders at various stages of their career. I'm eager to see how others apply it and share their experiences.”

With this added context, let’s dive into two chapters of the book.

The below sections are from Leading Effective Engineering Teams, by Addy Osmani. Copyright © 2024 Addy Osmani. Published by O'Reilly Media, Inc. Used with permission.

2. What Makes a Software Engineering Team Effective?

The below is from the beginning of Chapter 1 in the book.

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.

3. Leadership Roles: TL, EM, TLM

The below is an excerpt from the middle of Chapter 7: Becoming an effective leader

Organizational structures in software engineering organizations differ widely depending on their culture and priorities. After a person has served as an engineer or senior engineer for a few years and gained the necessary expertise, there are typically two tracks open to them: technical or managerial. Each offers distinct leadership opportunities and requires individuals who can coach and guide their teams through challenges.

In this section, you will look at some typical roles across the industry and what they usually entail in terms of effective leadership. Note that these aren’t the only leadership roles in an organization.

Leadership roles in a team depend not only on the overall organizational structure but also on the size and complexity of the project. Larger teams could have one or many technical leads leading the development of different parts of a project. Additionally, such teams would have architects synchronize the efforts led by the technical leads and managers to plan and organize resources. You could also have a product manager who articulates what success looks like for a product and guides the team to make it a reality. Conversely, in small teams, these roles may be combined to have a manager with the technical expertise to lead the team.

Figure 7-2 shows how some of the different types of leadership roles may coexist in a software engineering team.

Let’s take a closer look at some of these leadership roles.

Technical Lead

A technical lead is a hands-on role where you provide technical guidance and direction to the engineering team. The designation itself may vary across organizations. It may be a formal title in some workplaces, while it exists more informally in others. In some organizations, the position may be identified as a “software architect,” while in others, it may be referred to by titles like “principal engineer” or “lead software engineer.”

Irrespective of the name, tech leads play a crucial role in architectural decisions, code reviews, and mentoring junior team members. Technical leads often bridge the gap between the development team and management, ensuring alignment between technical strategies and business goals. Some of the responsibilities of a technical lead include the following:

Guide technical design and architecture

Tech leads play a vital role in shaping the technical direction of the project by providing guidance on design and architecture. A tech lead must leverage their expertise to ensure that the chosen technical solutions align with the project’s goals and adhere to industry best practices.

Set coding standards and best practices

Tech leads should take the initiative to establish coding standards and best practices within the development team. The tech lead role involves defining and enforcing these guidelines to contribute to overall code quality, maintainability, and consistency.

Lead troubleshooting of complex bugs and issues

Someone in the tech lead role leads the investigation and resolution of intricate technical issues and bugs. Their deep understanding of the codebase empowers them to troubleshoot effectively, ensuring the stability and reliability of the software.

Make key technical decisions with engineering trade-offs

Tech leads are responsible for making critical technical decisions, carefully weighing engineering trade-offs to align with project objectives. They consider factors such as performance, scalability, and maintainability to ensure the overall success of the software.

Do hands-on coding alongside the team

Despite their leadership role, tech leads often find themselves actively engaging in hands-on coding alongside their team members. This approach helps them mentor other engineers while staying connected with the codebase.

Serve as a mentor for development skills

Tech leads also act as overall mentors, guiding team members to enhance their development skills. They lead by example to foster a culture of continuous learning and professional development within the team.

Ensure deliverables meet the quality bar

Tech leads are accountable for the quality of deliverables, ensuring that the software meets established standards and requirements. They conduct thorough reviews and quality assessments to guarantee that the end product aligns with the defined quality bar.

Depending on the size of the project, the scope of these responsibilities will vary—from overseeing a single development team to having cross-team responsibilities.

Engineering Manager

An engineering manager typically oversees a team of software engineers, ensuring the successful delivery of projects. They are responsible for project planning, resource allocation, team productivity, performance, and career development, including that of the tech lead. This role often involves a mix of managerial tasks, such as performance evaluations and career development, along with technical oversight. In some companies, engineering managers may also be referred to as “development managers” or “technical managers.” To recap, an engineering manager’s key responsibilities include the following:

People management

Engineering managers should gear up to develop their skills in hiring, talent development, coaching, and mentoring. Engineering managers actively engage in the recruitment process, nurture their team members’ potential, provide guidance, and foster a culture of continuous learning within their team.

Manage processes

Engineering managers orchestrate critical processes such as sprint planning, retrospectives, and regular one-on-ones. They should ensure these processes are not just executed but tailored to their team’s needs, promoting collaboration, communication, and continuous improvement. They need to check that processes are not sidestepped.

Align team with organizational priorities

Engineering managers must ensure that their team is aligned with the broader organizational priorities. This involves effectively communicating context, goals, and expectations to team members while also shielding them from unnecessary distractions. By serving as a bridge between the team and the larger organization, the engineering manager helps team members focus on their work and deliver value.

Unblock resources

Engineering managers must actively work on unblocking resources needed for execution. They liaise with other departments, manage dependencies, and ensure that their team has the necessary tools, resources, and support to deliver on their commitments.

Technical oversight

While the engineering manager may not have any hands-on coding time, they should maintain their technical acumen. They engage in architecture discussions, ensuring technical decisions align with best practices and organizational goals. This technical oversight helps them guide their team to find sound technical solutions.

Stakeholder interaction

Engineering managers should engage with stakeholders, including having direct interactions with customers. They must understand project requirements, ensure proper communication channels, and act as a conduit between their team and external stakeholders. Engineering managers ensure that the team receives clear requirements from stakeholders.

Strategic work prioritization

Engineering managers must strategically prioritize work aligned with their team and company’s vision. This involves balancing project commitments with essential operational work, addressing technical debt, performing and maintenance in line with the organization’s strategy.

As you take on an engineering manager role, remember that you must broaden your responsibilities to include comprehensive people management, process leadership, and strategic alignment with organizational goals in addition to technical oversight. Unblocking your programmers is also an essential but slightly underrated aspect of managerial responsibilities.

Joel Spolsky, the cofounder of Stack Overflow and creator of Trello, once said, “Your first priority as the manager of a software team is building the development abstraction layer.”1 He further explains that if a developer is directly exposed to infrastructure issues like access to the project repo on GitHub or overriding a firewall for necessary project work, then the abstraction has failed.

Tech Lead Manager (TLM)

Tech lead managers (TLMs) are rare in many organizations. In Google, small or nascent teams usually have a TLM who can oversee a group of engineers, guiding them in project execution and ensuring the team’s productivity. This role involves a mix of technical leadership, project management, and people management. You will need a solid technical background to take up this role and should be able to contribute to technical discussions easily. You should be involved in technical design and communicate relevant design decisions to other teams and stakeholders.

TLMs are responsible for setting priorities, resolving technical challenges, and fostering a collaborative team culture. This role offers the opportunity to do both technical execution and people leadership. But it also comes with the challenge of balancing the two areas while not shortchanging either one. To help with this, TLMs will usually have a smaller number of direct reports as compared to engineering managers. TLM responsibilities include the following:

Blending people management with hands-on technical leadership

TLMs must balance their responsibilities as people manager and technical leader. This involves not only overseeing the professional development of the team but also actively participating in the technical aspects of projects, setting an example for team members.

Coach and develop engineers on coding skills

From a people management perspective, part of the TLM’s responsibility is nurturing their team, coaching, providing constructive feedback, and guiding engineers to enhance their technical proficiency. TLMs must also ensure individual contributors are challenged in their work and are on track to reach their personal career goals.

Establish technical standards and architecture

TLMs are responsible for setting technical standards and architecture. This entails defining and maintaining coding practices, architectural principles, design, and code reviews.

Help unblock developers when they are stuck

TLMs play a crucial role in unblocking developers when they encounter challenges. This involves providing technical guidance, removing impediments, and keeping upper management appraised of the project’s progress and resource needs.

Focus on higher-priority technical work

Sometimes, TLMs may need to concentrate on higher-priority technical initiatives. This could even involve hands-on coding or debugging. TLMs may have to delegate specific people management tasks to balance the other demands of their role. This strategic delegation ensures that both aspects of their role receive adequate attention.

Advocate for the team while coordinating cross-functionally

As the advocate for their team, TLMs engage in cross-functional coordination. This includes representing their team’s interests, ensuring effective communication across departments, and fostering collaboration to achieve collective goals.

Make technical decisions weighing various constraints

TLMs are decision makers in technical matters, which involves considering multiple constraints. This includes assessing factors such as project timelines, resource availability, and technical debt to make informed decisions that align with both short-term goals and long-term sustainability.

Provide mentorship and guidance

TLMs play a crucial role in mentoring and guiding team members to enhance their technical skills and professional development. By dedicating time to mentorship, TLMs foster a culture of continuous learning and growth within the team.

As you can tell from the preceding list, having really strong technical aptitude is critical in a TLM role. A TLM often asks intelligent questions and pushes the team to find answers. TLMs communicate a lot with various people, some of whom are purely technical and others of whom are business oriented. TLMs will thus have to switch their communication style constantly. A sign of success as a TLM is effectively balancing all the responsibilities while finding some extra time to write some code occasionally.

While there may be other roles or other names used to refer to these roles among software organizations, I have tried to discuss the key responsibilities of a team leader or manager in an engineering team in this section. However, responsibilities don’t dictate your ability to perform them. How do you know you have what it takes to lead your teams effectively? Find out by assessing yourself on key leadership traits in the next section.

Parting thoughts

In the preface of the book, Addy outlined who he wrote this book for:

“This book is for engineers wanting to move into leadership roles or engineering leaders who want evidence-based guidance to improve their effectiveness and that of their teams. It is a comprehensive guide to the strategies, frameworks, and best practices that I have found to be most effective in unlocking the full potential of engineering teams and driving transformative results. By sharing real-world examples, practical insights, and actionable advice, I aim to empower you with the tools and knowledge you need to become an exceptional engineering leader in your own right.

At the heart of this book lies a deep exploration of the key traits and behaviors that distinguish highly effective engineers and engineering leaders from their peers. These are the individuals who consistently deliver outstanding results, inspire their teams to reach new heights, and make a lasting impact on the projects and initiatives they lead. By understanding and embodying these characteristics, you, too, can set yourself apart and make a meaningful difference in your role.”

It’s a great time to transition into engineering leadership roles: as there are more and more in-depth resources where engineering leaders like Addy share their hard-earned experience, and way of thinking. Additionally, this book offers a peek at how effective managers at Google operate, and philosophies that are likely to be more common at Google – like the importance of physiological safety, balancing complex interpersonal dynamics, and empowering team members to take ownership of their work.

I hope you enjoyed this deepdive into a more theoretical overview of what we know about effective engineering teams, and a look at how companies like Google think about the TL, EM and TLM roles.

To read on, you can get the book (or e-book.)

And for more reading do check out some of Addy’s other books – including the free e-book titles Software Engineering: The Soft Parts, and The Developer Experience Book. You can also follow Addy on LinkedIn, where he shares learnings on software engineering several times per week. 

As related reading, see these past The Pragmatic Engineer articles:

• Engineering leadership skillset overlaps: how staff engineers, EMs, PMs, TLMs and TPMs overlap in Big Tech and high-growth startups.

• Engineering career paths at Big Tech and scaleups. Levels at Big Tech, the most common software engineering career paths, and what comes after making it to Staff Engineer.