If Product Development is a Team Sport, Where the Heck are our Team Coaches?

Photo by Tim Mossholder on Unsplash

In the book Trillion Dollar Coach: The Leadership Playbook of Silicon Valley’s Bill Campbell, we get a rare behind-the-scenes look at how the legendary former-football-coach-turned-executive-coach helped to build some of Silicon Valley’s greatest companies, including Apple, Google, and Intuit.

Having benefited directly from Campbell’s coaching at Google, the authors, Eric Schmidt, Jonathan Rosenberg, and Alan Eagle, set out to memorialize Campbell’s teachings by: 1) interviewing over eighty Silicon Valley leaders Campbell had coached, 2) identifying common themes amongst their stories, 3) distilling them into teachable leadership principles, and 4) sharing them with the world using the most salient stories curated from the interviews and from their own experiences working with Bill Campbell.

In addition to publishing the book, the authors also published a free slideshare entitled Open-sourcing the leadership playbook of Silicon Valley’s Bill Campbell. I would encourage you to download this free slideshare as a handy reference.

Having spent most of my 30-year Silicon Valley career in my favorite role of Product Management “player-coach”, I did not need to be convinced that product development is a team sport — I know it in my bones. Therefore, Bill Campbell’s leadership principles, born from his earlier career as a football coach and adapted for Silicon Valley, resonated with me immediately.

Although the book was published in 2019 and is filled with timeless wisdom, I find it has special relevance in today’s crazy world where tech companies want you to believe you are family one day yet lay you off via an impersonal email the next. This book, backed by a trillion-dollar business case, should serve as a reminder to companies to treat those who are being let go with dignity, to avoid breaking the trust with those who stay behind. Impacted teams will no doubt also need more coaching than before to navigate the rough waters we are in. Thus, I figured there is no better time for me to write about this book, even though I am four years late.

Since the slideshare already provides a great summary of the book, I will not provide a book report style summary here. Instead, I will leverage my 30 years of practitioner experience to assess where Bill Campbell’s teachings can most benefit product teams and explore how we can operationalize his teachings within our existing organizational structures. Here is my game plan:

• Provide a brief intro to Bill Campbell and his “team first” leadership philosophy and coaching approach, which is considered by the authors to be his secret sauce.
• Draw a distinction between employee coaching and team coaching and where they apply in our matrix organizations
• Explore how we can best operationalize employee coaching and team coaching within our matrix organizations, including where it will be simple and straightforward, where it will likely be challenging due to structural issues, and how we might be able to overcome those challenges.

Let’s get started….

Bill Campbell the Team Coach

Before reading the book, I had only come across Bill Campbell’s name in passing, and usually in the context of him being some famous Silicon Valley executive’s coach. So that was my impression of Bill Campbell going into the book — he must be a very influential executive coach who is really good at what he does.

However, as I read the book, I quickly learned Bill Campbell was, at his core, not just a 1-on-1 executive coach, but a team coach. This is not surprising coming from a former football coach, but quite a novel concept in Silicon Valley.

Bill Campbell’s “team first” philosophy was integral to both how he coached and what advice he gave.

In terms of the how, Bill Campbell often went above and beyond the customary 1-on-1 coaching sessions with his coachees. He is known for his generosity and willingness to coach additional members of a coachee’s staff (e.g. as in the case of the co-authors from Google) and for attending a coachee’s staff meeting from time to time to help assess the health of their executive team. When Bill Campbell coached multiple members of an executive team, he would use the 1-on-1 sessions to triangulate issues across team members, help bridge any communication gaps, and nudge those who needed to take action. This team coaching approach really set Bill Campbell apart from other executive coaches who mainly provided 1-on-1 coaching.

In terms of the what, we have only to examine his leadership principles to see how prominently his “team first” philosophy is featured in his teachings. In the exercise below, I examined the leadership principles enumerated in the free slideshare, one-by-one, and I categorized whether each principle was geared toward employee coaching, team coaching, or both. This is definitely not an exact science, but I think the big picture is clear. Although many of Bill Campbell’s leadership principles apply to both employee coaching and team coaching, almost all of them (31/33) apply to team coaching. No wonder team coaching is considered to be his secret sauce.

Bill Campbell Leadership Principles for Employee Coaching vs. Team Coaching

While we already have the list on the page, and it is a pretty long list, let me take this opportunity to summarize them into a few common themes (reverse-engineered by yours truly). At this point we no longer have to draw a distinction between employee coaching and team coaching. My goal is to help convey “the spirit” of Bill Campbell’s teachings, as a backdrop for the rest of this story:

• Respect, develop, motivate, and care for your people
• Build the right team for the mission, build strong relationships and a sense of “community” within the team, manage the “Aberrant Geniuses” within the team
• Promote diversity and fostering safe, open, effective communication within the team
• Create a structure for effective decision-making within the team and help the team with tough decisions when necessary

Reviewing these themes, it is easy to see why both employees and teams would stand to benefit greatly from Bill Campbell’s leadership principles.

Next we will see where employee coaching and team coaching is needed in a product organization.

Mapping to Matrix Organizations

To see where employee coaching and team coaching is needed in our product organizations, we need to consider how our product organizations are structured.

The Matrix Organization

In our tech industry, the matrix organization is the de facto standard for how we organize our product teams. In a matrix organization, there are two different kinds of teams:

• Functional teams — these teams are organized by function and typically each team has a “line manager”. E.g. a PM manager managing a group of PMs, a Dev manager managing a group of developers, a UX design manager managing a group of UX designers, and so on and so forth. The image below shows a simple example of an enterprise software product organization. On the left is a platform team that develops shared services to support the needs of various application teams. On the right is an example of an application team. The platform team and application team will each have multiple PM teams, Dev teams, and UX teams, but I only show one of each in the image for simplicity.

Product Team Organization Structure

• Cross-functional project teams — these teams are organized by project/mission and this is where most of the “real work” gets done inside a product organization. These cross-functional teams require a mix of resources and skills from the different functional areas and are therefore created by pulling in team members from the various functional teams. E.g. to develop a new Product X, we may form a cross-functional Agile Scrum team consisting of PM (Product Manager / Product Owner), UX designer, software developers, and QA/QE engineers; and to prepare for the product launch, we may create a cross-functional GTM (go-to-market) team consisting of PM, sales, marketing, service, legal, finance, and IT. The image below illustrates how cross-functional Agile Scrum teams are formed.

Product Team Matrix Organization

Aligning Type of Coaching with Type of Team

In the previous section about Bill Campbell and his leadership principles, we said his leadership principles could be applied in two different types of coaching: employee coaching and team coaching. When we look at the two types of teams in a matrix organization, the functional teams and the cross-functional project teams, we find there is a natural alignment:

• between employee coaching and functional teams
• between team coaching and cross-functional teams

Let’s discuss these one at a time….

Employee Coaching in Functional Teams

When we look at a functional team, e.g. a team of PMs reporting to a PM manager, this is where employee coaching happens. Although the team of PMs is often called a “team”, it would be more accurate to call it a “group”, because other than the fact that each PM owns a product or feature within the product portfolio, there is usually not too much intricate teamwork happening within this group of PMs. Thus, team coaching plays a limited role here.

While most of the employee coaching occurs in 1-on-1 meetings, the manager may also provide some coaching in their staff meetings. However, the fact that the coaching is happening in a group setting at a staff meeting is incidental, the substance of the coaching is still employee coaching. In the image below, I included some of Bill Campbell’s leadership principles that would apply in this employee coaching context.

Leadership Principles for Employee Coaching in Functional Teams

(Note: it is worth pointing out software engineering teams are an exception to the pattern discussed above for functional teams. Unlike PMs, software developers within a functional team do often work closely together on common projects, so team coaching is very applicable to them. In other words, the manager must provide both employee coaching and team coaching when managing a functional team of software developers.)

Team Coaching in Cross-functional Project Teams

When we look at a cross-functional project team, e.g. an Agile Scrum team or a GTM team, this is where team coaching is needed.

Cross-functional project teams are the real workhorses of the product organization. They are the ones facing all the tough challenges and must work well together as a team to get the job done, and it is the kind of fast-paced, high-stakes environment where coaching would be needed most and would have the biggest impact.

Looking at Bill Campbell’s leadership principles, although some of them apply to functional teams, the majority of them are clearly intended for cross-functional project teams, where team make-up, team morale, effective communication, and sound decision making are paramount.

In the image below I highlight some of Bill Campbell’s leadership principles that apply in this context. As you can see, it is quite a bit more substantive than the previous list.

Leadership Principles for Team Coaching of Cross-functional Project Teams

Now that we have seen how, in our matrix organizations, employee coaching is applicable to functional teams, and team coaching is applicable to cross-functional project teams, in the next sections we will discuss how we can operationalize these two types of coaching in their respective teams.

Operationalizing Coaching

In this section, we will start by looking at the authors’ recommendation on how we should operationalize coaching in our product organizations. Then we will assess how well their recommendation would work for functional teams and for cross-functional project teams.

The Authors’ Recommendation on How to Operationalize

Although the book did a great job sharing Bill Campbell’s leadership principles, it doesn’t give us much guidance regarding how we should operationalize Bill Campbell-style coaching in our organizations. In fact, the reader has to wait until Chapter 6, the final chapter, to see any recommendation at all.

In the final chapter, the authors acknowledge that, unlike the top executive teams at Google, Apple, and Intuit, most of us will not have access to a dedicated coach, much less a legendary coach like Bill Campbell. (I take it as their kind way of saying we cannot afford it, and I would have to agree.)

Instead, the solution they suggest is the following:

“We were lucky to have a Bill Campbell acting as our team coach [at Google], but most teams aren’t so lucky, which is fine, because the best person to be the team’s coach is the team’s manager. Being a good coach is essential to being a good manager and leader. Coaching is no longer a specialty. You cannot be a good manager without being a good coach. The path to success in a fast-moving, highly competitive, technology-driven business world is to form high performing teams and give them the resources and freedom to do great things. And an essential component of high performing teams is a leader who is both a savvy manager and a caring coach.” — Trillion Dollar Coach

Let’s see how we can put this recommendation to work for our two types of teams.

Operationalizing Employee Coaching in Functional Teams is Straightforward

As we saw earlier, functional teams have managers, so it is easy to follow the authors’ recommendation and ask the managers to coach their teams by adopting Bill Campbell’s leadership principles.

Furthermore, most functional teams are already quite mature in their employee coaching practices in terms of having regularly scheduled 1-on-1 meetings, staff meetings, and some form of voice-of-the-employee or employee satisfaction survey program. Assuming the manager buys in to the value Bill Campbell places on recruiting the right employees (who are coachable and team players), treating them well, and developing them, operationalizing the leadership principles would simply require extending or refining what most managers already do:

• Adapting the 1-on-1 meetings (e.g. use “5 words on the white board”, build trust, practice free-form listening, etc.)
• Adapting the staff meetings (e.g. “start with trip reports” to make them fun and build community)
• Re-doubling efforts in existing voice-of-the-employee or employee satisfaction survey programs

It all seems very natural and doable. So far, so good.

Operationalizing Team Coaching in Cross-functional Project Teams is NOT so Straightforward

Unfortunately, when we apply the authors’ recommendation to cross-functional project teams, we immediately hit an unexpected roadblock. The authors’ recommendation to simply ask the teams’ managers to become their teams’ coaches is based on the basic premise that every team must have a manager to begin with. But what if the team doesn’t have a manager?

The Missing Link

In our matrix organizations, cross-functional project teams get their team members from multiple line organizations; thus, they typically do not have a manager of their own, so a strategy that relies on the team’s manager becoming their team coach would not work here.

In other words, in their recommendation for how to operationalize team coaching, the authors seem to have forgotten about matrix organizations and cross-functional project teams that do not have managers.

This seems like a gross oversight, but actually it is quite understandable when we consider the book is based on Bill Campbell, and Bill Campbell mainly worked with CEOs and their executive teams, and these executive teams are invariably cross-functional teams that do have a manager, namely the CEO. It is therefore easy to see how the authors may have overlooked the fact that outside of the CEO’s staff, most other cross-functional project teams lower in the organization may not have a manager.

This is an important missing link, especially when we consider that:

1. Unlike with our functional teams, where we already have mature coaching practices in place, cross-functional project teams is where we currently lack any formal team coaching discipline and would stand to gain the most from adopting a set of best practices, such as Bill Campbell’s leadership principles.
2. Bill Campbell’s leadership principles, stemming from his football coaching career and further adapted to Silicon Valley to help CEOs build and develop their cross-functional executive teams, seem like they were tailor-made for our fast-paced, high-stakes cross-functional project teams. It would be a shame if our cross-functional project teams couldn’t take advantage of his wisdom.

The authors may not have shown us all the ways we need to operationalize team coaching throughout our product organization, but they have nonetheless given us a great gift by showing us what great team coaching looks like. It is now incumbent upon us practitioners to figure out how to operationalize their teachings, leveraging our intimate knowledge of how product teams actually work.

Operationalizing Team Coaching for Cross-functional Project Teams — in Our World (not in Bill Campbell’s World)

Let’s face it — this is not going to be an easy exercise. We will have to overcome one of the biggest forces preventing change — Inertia.

Our cross-functional project teams have been operating for decades in our matrix organizations without formal managers or formal team coaches. During that time, they have developed their own coping mechanisms, and judging from the overall success of our tech industry, one can only conclude they have been doing a pretty decent job.

Does that mean there is no room for improvement? Of course not, but we cannot take it as a given that everyone would agree there is a need for change and have an appetite for change. To overcome this inertia, we must build a strong case for change, starting with why we should even bother considering team coaching when our cross-functional project teams seem to be doing just fine without it.

Why We Need Team Coaching

Here is a really nice quote from Trillion Dollar Coach on why we need team coaching:

“To be successful, companies need to have teams that work together as communities, where individuals integrate their interests and put aside differences to be individually and collectively obsessed with what’s good and right for the company. Since this doesn’t naturally happen among groups of people, especially high-performing, ambitious people, you need someone playing the role of a coach, a team coach, to make it happen. Any company that wants to succeed in a time where technology has suffused every industry and most aspects of consumer life, where speed and innovation are paramount, must have team coaching as a part of its culture.” — Trillion Dollar Coach

To support this assertion, the book provides many examples where Bill Campbell helped the executive teams he coached in profound ways by applying his leadership principles. Unfortunately, the examples in the book, although fascinating to read, may not be immediately relatable to those of us who have never operated at that top-tier executive team level.

To supplement the book, I decided to draw upon my own experience working in and with cross-functional project teams to create a list of real-world challenges commonly faced by teams at the worker bee level most of us operate at. I have seen these real-world challenges enough times to call them common team failure modes.

For this exercise I mainly focused on cross-functional Agile Scrum teams typically consisting of a Product Owner from product management, a team of developers, a UX designer, and a QE/QE engineer. (An equivalent exercise could be done for other product teams such as a cross-functional GTM (go-to-market) team or any other product team.). Here is the list of common team failure modes I was able to come up with:

• Unclear desired outcome / goal, and how it’s measured
• Unrealistic goal
• The team is critically dependent on another team but the two teams do not have shared KPIs (key performance indicators)
• Lack of understanding of the project “critical path” and risk management (over-reliance on Agile Development’s incremental and iterative approach)
• Inadequate upfront project “rough framing” in terms of scope, design, and architecture
• Forming the wrong team; team lacks certain critical skills
• Team goes through many false starts due to unclear roles & responsibilities, ground rules, and expectations; e.g. team did not following the forming, norming, storming best practices and rushed into storming phase without taking the time to normalize expectations.
• Power imbalance within the team (E.g. PM dictating UX design, Dev dictating product direction, QE/QA pressured to give the green light, etc.)
• Prima Donna on the team
• Bully on the team
• Weak link on the team
• Communication issues — bad meetings, bad collaboration (real-time and asynchronous)
• Key decisions not made in a timely manner; team does not stick to decisions after they are made
• Time zone challenges
• Too many changes; poor change management
• Lack of documentation- things are “in people’s heads” — difficult to recover from losing a team member, no efficient way to onboard new team members, and no transparency to stakeholders
• Technical debt accumulation
• Planning / execution rhythm is off; always not enough time to do proper planning in between releases
• Suboptimal team velocity — retrospectives not taken seriously or corrective actions not taken to improve team velocity
• Unclear leadership on key issues — who’s driving the bus?
• Unmet expectations / disappointment between team members (quality, quantity, and/or speed)
• Unclear, untestable product requirements
• Software scalability and performance are an after-thought, blowing up the project schedule late in the game
• Poor product quality (usability, reliability, serviceability)
• Low team morale
• Team burn-out sustained over multiple releases
• Heroics culture (rewarding team member who pulls all nighters to fix bugs rather than team members who follow best practices and avoid breaking the code in the first place)
• Team is dealing with a difficult/demanding/rude customer but does not have adequate protection by the account team nor adequate air cover from upper management
• Team is not adequately protected from executives — too many high priority interrupts, changes in priorities, work overload, micromanagement overhead
• Scope creep
• Same team members (e.g. QA/QE) always squeezed at the end of each release
• Process overload
• Redundant and/or inconsistent status reporting by team members to different stakeholders
• Lost sight of the customer (lacking discipline for frequent product validations)

This is far from a comprehensive list, and it is already pretty long. Fortunately, most teams will only find themselves afflicted by a few of these issues. However, given the long list of potential failure modes, can we realistically expect the average product team to have the self-awareness to promptly detect budding issues while going 100 mph (160 kph)? And even if they could, can we expect them to have the wherewithal, in terms of knowledge and experience, to properly diagnose the symptoms and address the issues? Lastly, can we expect them to have prevented the issues all together?

I think we can all agree that would be a pretty tall order for most product teams. Clearly, there is a need for team coaching.

But how can be give these teams the coaching support they need?

So How are Product Teams Coping Today?

We have mentioned a couple different types of product teams so far — Agile Scrum teams and GTM teams — but there are plenty more, such as strategy teams, planning teams, M&A teams (mergers and acquisitions), etc. Invariably all of them are cross-functional project teams that operate like sports teams, yet do not have ready access to a team coach. Nor do they have a formal team manager who, as the authors suggest, could readily take on the role of team coach.

So how are they coping today? They must be coping somehow because such cross-functional project teams have been around for decades.

Actually, their coping mechanisms can be quite varied. In this story we will explore the two most common patterns I’ve seen, as exemplified by:

• Agile Scrum teams that strive to be self-directed, and
• GTM teams that follow a more traditional project/program management approach

There are certainly other popular approaches, such as Kanban, that teams are leaning on to help them organize as a team and get work done. I do not have as much direct experience with them, but hopefully what I cover in the following sections could be extrapolated to those other teams as well.

Agile Scrum Teams — Self-directed Teams

Software development teams have widely adopted Agile Development, specifically Scrum, so they can become self-directed teams, minimizing the need for active coaching from the sidelines as you would see in team sports.

This is one of the features I love most about Agile Development (and what drew me into becoming a part-time Agile/Scrum coach about ten years ago). Through daily stand-up meetings team members identify blockers early-and-often and work together to address them with a sense of urgency and team ownership. Through periodic retrospective meetings, the team has the space to reflect and find ways to improve their performance.

Working closely as a team, catching issues early, addressing them promptly, and working to continuously improve team performance — aren’t these some of the same holy grail results we would want to get from team coaching?

That’s right! Although we never formally gave our Scrum teams a coach, we did invest heavily to help them develop into self-directed teams.

Even so, Scrum teams do need coaching from time to time, and although they do not formally have a team coach, they are able to get some coaching from a patchwork of informal coaches: an Agile coach, the Scrum Master, senior team members, line managers who are helping their team members from the sidelines, program/project managers (if they are involved)), and for mission critical projects, the team may also have access to an executive sponsor.

Throughout my 30-year product management player-coach career, I have played every one of the coaching roles mentioned above, and I have been on the receiving end of coaching under these different arrangements. From both vantage points, coach and coachee, I will admit the combination of self-direction under Agile and support from a patchwork of coaching resources does work to a certain extent, but there are still some problems:

• Inefficient — too many cooks in the kitchen: when there is not one coach, but a patchwork of coaches, things can get pretty messy when an issue arises. Multiple coaches may want to get involved and would all need to be brought up to speed. Once everyone has the necessary context, the different coaches may have differing opinions about how to proceed. Sometimes politics also get involved when the issue involves team members from different line organizations. This is extremely inefficient.
• Inconsistent quality of coaching: the team has access to a patchwork of coaches, but there is no guarantee any of them are actually good team coaches. Remember, we can now use Trillion Dollar Coach as a yardstick to measure the quality of our coaches. Having coaches who are experienced in dealing with the common team failure modes I listed earlier would also be very helpful. However, these are pretty high standards for a coach (and arguably rightly so), and many teams may not have access to anyone so well qualified.
• Reactive rather than proactive: although self-directed teams generally possess a decent level of self-awareness of their team health, such as morale, communication, decision making, etc. there is just no substitute for the astute observation of a team coach. Also, whereas a team might be inclined to settle for “good enough”, a coach would nudge the team to strive to be the best they could be.

GTM Teams — Traditional Project/Program Management

GTM teams, on the other hand, have a different coping mechanism. GTM teams do not require as much day-to-day interaction as a software development team. Their main job is to make sure every aspect of a successful product launch is ready by the launch date, so they tend to lean on methodologies like RACI charts and good old fashion project timelines. RACI charts are a popular way to ensure roles are clearly defined, down to the role of each team member relative to each task: Responsible, Accountable, Consulted, or Informed. The project timelines are used to track milestones and dependencies. In most mature companies, new GTM teams may even have access to RACI and timeline templates for their business, and with the help of a program manager tracking status, things tend to run like clockwork.

Having participated in my fair share of GTM teams, I appreciate the familiarity of a cookie cutter approach and the reassurance from seeing tasks getting checked off every week, but I often felt like there was little room for free-form discussion, creativity, and innovation. Due to the procedural focus of GTM readiness status meetings, many important issues are taken offline, rather than solved in the team.

For GTM teams and other teams that are more procedural in nature, the challenge is to not let the efficiency of a cookie cutter approach stifle the kind of team interaction needed for creativity. A team coach could help the team strike that balance.

Team Coaching Opportunities

Looking back through the years at both my coaching roles and coachee roles, both on Agile Scrum teams and on GTM teams, I would say there were issues the teams could manage on our own, and there were issues the teams were unable to fix on our own, and in some cases, we didn’t even realize there was a problem. In general, teams were able to manage day-to-day operational issues. Yes, we made mistakes, but we would identify them, fix them, and move on. For these kinds of issues, as an advocate for self-directed teams, I think our existing patchwork of coaching resources is adequate and do not see a need to get additional coaching support.

In general, where we felt powerless and needed help, or where we might have a blindspot, was when the issues had something to do with the team itself. We could call them “team health issues”. These are the kinds of problems that, if they occurred in our personal lives, might prompt us to seek the help of a therapist: a toxic team member, relationship issues, communication issues, stress and burn-out, low motivation and morale, unclear purpose, etc. Since we don’t have therapists at work, we tend to just live with these issues.

Wait! Doesn’t ignoring these team health issues run counter to many of Bill Campbell’s leadership principles? It seems like a really bad idea to ignore these issues.

A Straw Man Proposal for Operationalizing Team Coaching for Cross-Functional Project Teams

Fortunately, we don’t have to go very far to find a similar type of problem, for which we already have some best practice solutions. Outside of the cross-functional teams, back in the comfort of our line organizations, most organizations have already implemented weekly 1-on-1’s between managers and employees, as well as annual employee satisfaction surveys. Why do we have these? It’s so line managers can keep tabs on their employees’ well-being and keep them happy, motivated, and operating at peak performance.

As much time as we all spend working in cross-functional teams, isn’t it about time we implemented an equivalent set of best practices for monitoring and managing the well-being, motivation, and performance of our cross-functional teams?

What if we could? What would it look like? Here’s what I would propose:

• Give each team access to a clearly designated team coach (who is a shared resource amongst many teams), whose main responsibility is to manage the team’s health — i.e. the team’s well-being, motivation, and performance. (NOTE: in teams that have a senior member on the team who is well qualified to be the team coach, is motivated to play the role, and has bandwidth to do so, it could be a viable option. Another variant could be a line manager or executive sponsor who is qualified, motivated, and has bandwidth.)
• Like Bill Campbell, the team coach would meet with the key leaders of the team (e.g. the Scrum Master, Product Owner, Dev lead) on a regular basis, say once every couple weeks or once a month, to monitor team health and provide coaching advice.
• Like Bill Campbell, the team coach could also join a team meeting once in a while to observe team health
• The team coach would also have an “open door policy” to provide help to all team members on an as needed basis.
• Periodically, say every 6 months, each team member fills out a Team Health Survey (analogous to a voice-of-the-employee survey) focused on assessing the well-being of the cross-functional project team. The team coach reviews the feedback from the survey with the team and facilitates corrective actions.
• Depending on the nature of the corrective actions, the team coach schedules follow-up meetings with the team (and with individuals if needed) to check-up on status and to hold the team accountable.
• If the team coach decides additional corrective actions need to be taken outside the team (e.g. to work with line management to replace a toxic team member), the coach works behind the scenes to do so.

In short, the team coach is responsible for monitoring and managing the health of cross-functional teams, the same way a line manager monitors and manages the health of their employees.

I believe the above proposal would deliver most of the benefits of team coaching in a way that: 1) complements (rather than disrupts) how teams are working today, 2) re-uses concepts people are already familiar with by borrowing from employee well-being best practices and applying them to teams, and 3) minimizes cost by sharing the team coaches across many teams (or by re-using existing resources).

Nevertheless, this proposal still requires the adoption of a team coaching culture similar to what is suggested in Trillion Dollar Coach. After all, without buy-in and cooperation from management and from the teams, it would be difficult to bring a team coach into the fold in any capacity. Hopefully, teams will see this as an investment in their success. And with many companies beginning to invest in “executive coaching” for their high potential employees, perhaps the door is already a little bit open for investment in team coaching as well.

Since we are venturing into uncharted territory, I would be arrogant to think the proposal above is the only solution or the best solution. My goal is merely to propose a straw man to get the conversation started. I am certain fellow practitioners can embellish my proposal or propose completely different approaches of their own.

Many questions remain. Where do we find qualified team coaches? Aren’t they prohibitively expensive? (Bill Campbell, the best there ever was, coached for free as a way to give back after a lucrative career in tech. Are there others willing to do the same, or perhaps at nominal rates? Is there an opportunity to retain senior employees as coaches, who are otherwise planning to retire early from the rat race? I for one would have considered it.) If we wanted to implement a team wellness survey, what questions would be put on it? Etc. These are all important questions we will have to explore as a community.

As with any new initiative, we should not expect to have all the answers going in. I would love to see this community get started with a few small-scale pilots and share as we go.

Closing Thoughts

I am aware I took the liberty to make a lot of generalizations in this story. I do understand organizational structures vary from company to company, and even common concepts like matrix organizations, Agile Scrum teams, and GTM teams come in many shapes and sizes and operate in different ways. I also expect the list of common team failure modes I shared may not fully represent the issues you see in your organization.

Nevertheless, I hope my generalizations were mainstream enough I didn’t alienate anyone. I also hope they served to show my thought process trying to connect the valuable lessons from Trillion Dollar Coach to our teams who would benefit most from them.

In closing, I would like to share why I was motivated to write this story. Even though I am now retired, I couldn’t help but get excited about the opportunity in front of us.

If Bill Campbell was able to unlock over a trillion dollars of value by coaching a number of executive teams using his “team first” approach, imagine the value we could collectively unlock across our industry if we could figure out how to help ALL our teams perform better through effective coaching.

THE END