Tips for Effective Town Halls

Recently I joined a Twitter conversation on organizational town halls. The observation was that many employees don’t find these town halls valuable—especially virtually. It’s my experience that this doesn’t have to be the case. So here are a few suggestions (based on my organizational experience) for your consideration.

Think of the town hall as a special GATHERING or a CONVENING. You are bringing people together for something special.

Make town halls optional. Don’t force employees to attend them or “bribe” employees with food or other gimmicks. If you have to do that, then you need to question the value of the town halls. Of course, food is fine where there are celebrations.

Ensure your town hall invitation clearly communicates the benefits of attending the town hall. Provide an agenda outlining high-level topics.

Focus the town hall content on the invitees (and not the inviters). Good hosts know the gathering is not about them. It’s about those they’ve invited. Answer questions like: “how is the organization performing?” and “what challenges is the organization facing?”

Share information that employees “at every level” can connect with. Too often, the town hall information is only understood by a select few in the audience.

Address stuff that is on employees’ minds. If you don’t know what’s on employees’ minds, you shouldn’t have a town hall in the first place.

Allow and encourage employee participation in the town hall when and where it makes sense. I’ve conducted live polls in town halls to get live feedback. You can also use polls to lighten up the mood.

Be brief. The longer any single person speaks (especially now that many town halls are remote) the more likely it is that people will check out. It’s not about the quantity of words, it’s about the QUALITY of the words.

Present a “call to action.” What do you want employees to do with the information you shared with them?

I’m of the opinion that “no town hall” is significantly better than a “poorly executed town hall.” Effective town halls require intentionality and planning. If you’re not ready to make such an investment in planning for a town hall, then don’t do it.

And yet, it would be remiss of me to not state that in any organization of meaningful size, there will always be employees who complain about town halls. You can’t please everyone. But you can try to put your best foot forward.

PS. If you’ve enjoyed this post, I believe you will enjoy my book “Becoming a Leader In Product Development.”

Apress: https://www.apress.com/us/book/9781484272978

Amazon: https://www.amazon.com/Becoming-Leader-Product-Development-Evidence-Based/dp/1484272978/

Managing Self-Managing Teams

Managing self-managing teams sounds like an oxymoron. I assert that it isn’t. Hear me out.

Central to my position is an understanding of management (managing), self-managing, and the manager role.

Management refers to the collection of activities required for the healthy functioning of an enterprise. These activities include planning, organizing, measuring, budgeting, coordination, etc. We can lump these activities under the umbrella of “managing.”

Researchers (as far back as the 1970s) have described self-managing teams as groups of individuals who can self-regulate on whole tasks. Dr. Richard Hackman developed a typology that includes self-managing teams. Other team types include manager-lead teams, self-designing teams, and self-governing teams. Hackman’s typology below describes teams based on their management responsibilities.

Last but not least, a manager is anyone assigned managerial responsibilities (and not just people with “manager” in their job title). This means that a Vice-President in a software development firm is a manager because they have management responsibilities. I will not wade into the nonsense I consider the manager-leader distinction. That will have to wait for another day.

Bringing this home to product development, a self-managing team has responsibility for executing the team task and monitoring and managing work process and progress. “Executing the team task” requires little explanation and is pretty straightforward to understand—the team has full responsibility for completing the task required to achieve desired outcomes.

Self-managing teams also have responsibility for managing how they get their work done and monitoring their progress on their work. Of course, the team must have the competencies to do this well. It’s not enough to declare a team self-managing and expects that they can now magically “monitor and manage work process and progress” effectively. Self-managing is not without its challenges, and anyone who suggests its a panacea is not being truthful.

(While I have you, let me share that I prefer self-managing over self-managed because it speaks to the ongoing nature of the management activities the team is responsible for.)

Hackman’s model makes it clear that “other-managing” will focus on other aspects of management, i.e., “setting overall direction“ and “designing the team and its organizational context.” A self-managing team is not focused on these aspects of management. These aspects can be the responsibility of a manager. It will be the responsibility of some individual(s) outside the self-managing team.

The effective manager of a “self-managing” team will continually ensure the self-managing teams have the resources needed to succeed. The manager will address external friction impeding team progress. The manager’s role is to provide external managerial support so the team can self-manage. And this is managing—managing a self-managing team.

Now it’s easy to try and establish a clear separation between the focus on the manager and the focus of the self-managing team based on typology. Doing this would be a mistake. While the responsibilities are distinct and can be analyzed separately (to a degree), the responsibilities interact and influence each other.

For example, when direction or organizational context changes (and it will), the self-managing team needs to know to adapt their processes appropriately. Conversely, the self-managing team needs to make its progress transparent so the manager can use this information in direction-setting and organizational context conversations. 

These interactions don’t change the locus of responsibility. Rather the interactions remind us that everything is connected and the importance of healthy feedback loops.

I firmly believe that many product development contexts would benefit from (at least) self-managing teams. We know that the more autonomy people have over their work, i.e., what they do, and how they do it, the more meaning and fulfillment they derive from work. The more committed we are, the more we positively contribute to our organizations.

Self-managing teams are rare in product development organizations despite many senior leaders claiming them. I believe a key reason for this is that many senior leaders in organizations do not understand how to foster self-managing teams. They often give mixed messages. On one hand, they tell teams they want them to be self-managing, and on another, they tell managers they are accountable for “monitoring and managing work process and progress.” Well, what do you think happens? 

Many managers feel a strong desire to control. It’s a natural expression for many of us. Additionally, our organizational socialization leads us to believe the only way to control is to take over the responsibilities of self-managing teams. Without proper training in other management areas, while enabling self-managing teams, managers focus on what comes naturally. So manager-led teams continue to dominate the landscape.

Organizations need managing. While self-managing teams manage critical aspects of their work, they will also need management support if they are going to achieve organizational goals. Managing self-managing teams is not an oxymoron.

In Praise of Mandates

I have come to praise mandates and not tear them down.

This post is a response to a lengthy Twitter thread by Noah Sussman on the necessity of quality mandates from the top for product development organizations to deliver “quality.”

Hypothesis: Organizations that have a healthy quality culture MUST also have an executive mandate to center quality in their day-to-day work. https://t.co/xNOf7TfHh3

— Noah Sussman (@noahsussman) July 23, 2022

The thread went in various directions, as threads are wont to do. The conversation spurred a desire to write a follow-up to the conversation about the role “mandates” play in organizational life and how we can use mandates effectively.

It is common for some people to suggest we abandon certain practices because they are misused. Let’s toss out estimates and measurements because people routinely misuse them. While sympathetic to this viewpoint, taking such thinking to its logical conclusion will have us getting rid of humans!

And so, I understand that organizational leaders routinely weaponize and misuse mandates. I get it. I aim to offer thoughts on how leaders can use mandates effectively in their organizations.

A mandate is a directive speech act in which the one mandating (the requester) wants the one receiving the mandate (the receiver) to do something for the requester. In many cases, based on the requestor’s authority. The request is non-negotiable and could be considered a command. The desired result of a mandate is that the “world should match the word.” 

We deal with mandates all the time. In many cases, we are not bothered by them. However, we tend to notice them when the mandate asks us to do something we disagree with or do not want to do.

Sometimes mandates gain a level of notoriety in a community, as Jeff Bezos’ “API Mandate” did in the software engineering community some years ago. Mandates show up in all domains and functional areas of organizations. When your company directs everyone to use a new system for one activity or the other, that’s a mandate.

So mandates are a constant in organizational life.

When can we use mandates, and what can we use them for? And how do we determine what should become a mandate?

When to Use Mandates

There are two situations where I find the use of mandates beneficial. The first situation is when we’re trying to increase clarity and reduce organizational ambiguity around what (or what does not) matter.

Organizations of meaningful size grapple with ambiguity and confusion. There are times when it is unclear what people should do. Confusion can also exist around what matters (and does not matter). Organizations can use mandates to indicate what does matter and what people need to give their attention to. For example, a “No Meeting Fridays” mandate makes the organizational position about meetings on Friday clear. It gives people the right to decline meetings scheduled on Friday.

Mandates are also valuable for establishing governing constraints. Organizations have reason to limit or constrain options, and mandates clarify the options. Jeff Bezos’ API mandate falls into this category.

What to Mandate

We can only mandate desired behaviors and actions. We cannot mandate outcomes. For example, you cannot mandate quality. You can mandate specific actions and behaviors that you believe will produce quality.

And this is where those issuing mandates must be careful because mandating the wrong actions or behaviors will lead to unexpected and undesirable results. We must remember that mandates have the side effect of reducing variety and stifling innovation.

Another way we create mandates without realizing it is through our measurement, evaluation or assessment programs. What we measure leads to unspoken mandates, resulting in behavior we didn’t anticipate. I once worked in an organization where Product Owners had to write X number of stories in a Sprint. Many of the stories provided no value.

How to Create Mandates

As a general principle, I believe that the more a mandate directly affects HOW an individual or team achieves their goals, the more vital it is that the individual or team have the opportunity to participate in creating the mandate. If the organization is too large such that it’s not practical to involve everyone (even using large system intervention methods), then use a representation-based approach.

For example, software engineers should participate in creating mandates that will significantly alter how they perform their roles. Don’t have managers represent (for example) software engineers.

And yet, because this is life, there will always be exceptions. Sometimes urgency demands that senior leaders immediately create mandates in the organization’s best interest. In other cases, it is the functional responsibility of specific individuals to create the mandate, e.g., the organizational strategy may not be the purview of everyone in your organization, and that’s probably okay.

I encourage leaders to adopt an invitation-based approach (even when they have functional authority) to create mandates. When people create a mandate, they are more likely to commit to it. And once they are committed, they will do all they can to make “world will match word.”

Other Considerations

I’ve focused on mandates’ why, what, when, and how; however, while mandates may be necessary, they are often insufficient for change. Unfortunately, many leaders often blame individuals and teams for not following organizational mandates. The truth, however, is that the same leaders have made other organizational decisions that discourage individuals and teams from fulfilling the mandate. I know this because I’ve made this mistake.

Other things that must be in place to support the mandate include:

• It must be easy to fulfill the mandate. Too often, leaders issue “difficult to follow” mandates. Organizational friction makes it impractical, rendering future mandates hollow.
• There cannot be mixed messages, i.e., messages that lead to internal conflict—for example, mandating certain quality practices while simultaneously mandating software delivery by a specific date, thereby encouraging shortcuts. 
• Mandates without sanctions are a joke. If leaders mandate some behavior or action, the expectation should be that there are consequences for not following the mandate without good reason.
• Even though the mandate’s purpose is to clarify, mandates are still subject to diverse interpretations, so mandates require continued clarification.

These considerations (and several others not mentioned) reinforce the need for thoughtfulness when establishing mandates, especially when they affect how people do their work daily. Leaders must understand the conditions required for the mandate to succeed and must commit to eliminating organizational obstacles to the mandate. Leading by fiat is rarely a sustainable approach.

So, yes, I have come to praise mandates. It’s up to us to use them wisely.

Business Capabilities and Jobs to Be Done

A recent tweet post by John Miller got me thinking about the relationship between Jobs to Be Done and Business Capabilities.

For those familiar with the Milkshake #JobsToBeDone story, a mockup of a simple competitive analysis based on Customer Outcomes (not features). pic.twitter.com/QNdDINT0wx

— John Miller (@agileschools) January 21, 2022

A valuable perspective to adopt when thinking about business capabilities is the Jobs to Be Done (JBTD) perspective, and specifically the Jobs-As-Activities frame. In the Jobs-As-Activities frame of JBTD, a job is a task or activity that an individual wants to accomplish. In fairness, Clayton Christensen provided the Milkshake more as an example of the Jobs-As-Progress frame, but it still works for Jobs-As-Activities.

Clayton Christensen offered the following as the job people hire the Milkshake for: Help me stay awake and occupied while I make my morning commute more fun. Businesses that produce milkshakes can help people accomplish this job. Hence we could consider business capabilities as the WHAT a business does to help people with their jobs.

So let’s say I open a milkshake store to help people complete the job of “staying awake and occupied while making their morning commute…” My business needs to (at least):

• Offer customers a variety of milkshakes to choose from.
• Acquire ingredients to make milkshakes .
• Be able to sell milkshakes. This might seem obvious, but if we cannot conduct a sales transaction, I will not be able to help customers complete their jobs.

My store needs business capabilities such as Milkshake Production, Ingredient Acquisition, and Sales.

Let’s look at an example that involves product development.

The US tax season is right around the corner, and many people will have the job of “do my annual taxes.” Let’s assume I want to start a tax software preparation company; my company will need a competent Product Development capability. (Of course, we will need other supporting capabilities such as Marketing and Sales to ensure that the customer finds and keeps customers.)

But what about if I develop tax preparation software for tax preparers, i.e., another business with the job of performing taxes on behalf of its paying clients? Do I need to concern myself with the tax preparers Tax Preparation capability? Do I need to be interested in how my client, the tax preparer, helps its clients accomplish their jobs?

Well, I believe it’s advantageous to do so. Deeply understanding how my clients’ clients expect the tax preparer to help them with their job “do my annual taxes” provides me with insight into how I can provide a product that improves my clients’ overall Tax Preparation capability quality.

Your Product Development organization can benefit from adopting a capability-based approach with JBTD.

Let me know what you think or if you’ve tried this in your organization.

Product Development, Uncertainty, and Forecasting

A number of people discourage forecasting (in any form), on the basis of uncertainty. In their opinion, the work and the future is uncertain, so any form of forecasting is a waste of time.
I beg to differ.

Note, I am using the word “forecast” colloquially in the sense of predict or estimate. You can substitute with your word of choice.

Uncertainty is always present. There is little we can guarantee (except what we have done and even our stories of what we did is subject to bias). We can’t guarantee that a flight will take off or arrive at its designated time. Something unexpected can always happen. Surprises can always occur. And yet we forecast what we will do in the next few hours.

This is because despite the uncertainty we still know the possible outcomes for many things in life. For example, either my flight will either depart on time or it will not.

And because the possible outcomes are known, my concern shifts to the likelihood of each possible outcomes. This is why we have probabilities on how often a particular flight departs on time. Or why we make statements like “it’s most likely he’ll go to the gym,” because he has a track record of working out every day.

So what about product development? What about the situations where we need to forecast. (Of course if you are of the opinion that there is never a need to forecast, then what follows next would be of little interest to you.)

I would offer that the outcomes (at least) for solving a problem by a particular date are either:
Outcome 1: Solve the problem by a particular date
Outcome 2: Solve the problem after a particular date
Outcome 3: Fail to solve the problem

The likelihood of the outcomes is largely influenced by the nature of the problem to us. There are frameworks for assessing the nature of a problem and many readers are probably familiar with Cynefin, so let’s use that. If you are not familiar with Cynefin, please go here: https://thecynefin.co/about-us/about-cynefin-framework/

You could start with placing the product problem (or aspects of the problem) in the domain(s) of clear, complicated, complex, and chaotic.

Some people claim anything and everything product development is complex–in a complexity theory way. That doesn’t match my experience working in various contexts and industries. Sometimes the work is straightforward, sometimes it involves many difficult steps, sometimes we need to figure out what we need to do, and sometimes we’re clueless.

No, a product development problem is not complex solely because humans are involved–the work matters. I often hear: “well if it’s not complex, it’s not product development.” I’d offer that product development is a mixed bag.

Because something is clear, doesn’t mean we couldn’t be surprised. I’ve had many situations where I was doing something identical to something I had done before and encountered a surprise e.g., a data type change causing different behavior in a function. As mentioned earlier, uncertainty, is technically always present.

This is no different from when the gentleman who repaired my AC was surprised by some wiring that wasn’t in the right place. That surprise was not beyond the knowledge required to solve the problem. The AC repair problem was still clear and was solved with little difficulty even though there was a surprise.

We can forecast clear and complicated problems because we possess the information and knowledge required to do so. However, we need to use the appropriate forecasting techniques. Unfortunately, this is an area where many product development teams could benefit from improving their skills. A post for another day.

How about when we’re faced with a problem that is predominantly complex? Can we forecast when we don’t have a clue about how we will solve a problem? I think not. No.

In these situations, we need to get to a position where we know our options. There are several software engineering and product management techniques and heuristics that can help us get to a point of clarity. Also a post for another day.

So before punting on forecasting, take the time to understand the nature of the problem. Many problems consist of clear, complicated, and complex aspects. Don’t assume it’s complex because it’s product development.

Why the Use Of “Best” Doesn’t Bother Me

Whenever I use the word “best” in the context of product development/software engineering, some people remind me we can’t know what’s “best” because we haven’t conducted scientific studies on these methods. And then they quickly add “there are no best practices.”

Putting “best” aside for a moment, why doesn’t this same scientific thinking apply to what we deem as “bad” or “good” practices? How are we deciding that a specific practice is good and effective? What is the rigorous scientific process we use?

Recently, I watched as someone learned how to make pounded yam more effectively (and efficiently). When they were done, they exclaimed, “this is the best way to make pounded yam.” Clearly, they had learned a method superior to anything they had used in the past.

Was this the best method for making pounded yam known to humankind? Who knows. What was true is that this new method had supplanted this individual’s former best. So much so, they discarded the previous method.

My exposure to Agile over two decades ago introduced me to several practices I consider best for software development in the contexts I work. Say goodbye to “big design up front,” and hello to working in smaller increments with code that is easy to change (for example).

Some people suggest that “best” is anti-learning. My “pounded yam” story shows that it doesn’t have to be. Because this person was open to learning, a new best emerged for them in their context. A new best emerged because they were able to quickly compare the new way with the previous way.

A continuous improvement attitude doesn’t simply settle for what is considered “best” at the moment. I’ve adopted new practices as part of learning.

We don’t need rigorous “scientific studies” to determine that a specific product development method is more effective than alternatives. We need a willingness to try multiple approaches to see which one emerges as more effective for us. And if a certain method does, we stick with it. It is best for us.

Unfortunately, too many organizations and teams spend too much time arguing and too little time evaluating.

My rules are simple:

When there is only one good way to do something, at that time, it’s the “best.”
When there are multiple practices equally effective at yielding the same results, at that time, those practices are the “best.” It doesn’t matter which one you use.

Of course, if your viewpoint is that there can only be one best and you have no way to determine what it is, I understand.

In the meantime, I’ll continue to use the best available to me in my work. I’ll encourage others to do so as well. And I’ll do this as a social scientist.

And while I have you, check out my book: Becoming a Leader in Product Development

On Human Error and Mistakes in the Workplace

Photo by CHUTTERSNAP on Unsplash

Last I checked, people routinely make mistakes. We make errors. At home. At school. At work. Everyone does at every level in the organization. The CEO does, and the entry-level employee does. No one is immune to making mistakes or errors. It’s part of living.

I consider workplace mistakes and errors predominantly accidental and non-intentional, i.e., employees do not deliberately make errors. For example, the developer did not intentionally delete the configuration file to cause the application to fail because it no longer had its application settings. The accountant did not intend to leak confidential information when she sent a report to the wrong Bill in the firm. The nurse did not want the patient to have an adverse reaction when he gave the patient the wrong medication. These were errors and mistakes and not acts of deliberate harmful deviance.

Unfortunately, my observation is that our societal response to human error acts like the individual desired to make an error. When a child makes a mistake at home (like breaking a plate), the default response for many a parent is to blame the child and act as if the child intentionally set out to break the plate. In many cases, the parent then punishes the child for their carelessness. We find this response in the school system and the workplace. In the workplace, the parent is a manager (or someone with formal authority), and the child is the employee who made a mistake.

The intriguing thing about this dynamic, though, is the rules are different for parents. When parents break plates, it is an accident, and we have good reasons for it. We can explain it away. Funny how we see the same sort of behavior in companies. The higher we go up the corporate ladder, the more adept we become at explaining away our mistakes and errors. 

And yet, assigning fault to human error is often shortsighted and prevents meaningful learning and improvement. The “human error” approach ignores the fact that work i.e., our system and its processes produces errors. (While we’re here, we also need to consider our achievements a product of the system and its processes as well). 

A systems view on errors leads us to ask questions such as: how does the way we work allow this error to occur. For example, what about our process allows someone to delete a configuration file? Or what about our process prevented us from detecting the file deletion before our customers? And what can we change to prevent such an error from happening again?

These questions require us to change the way we look at errors in the first place. We need to consider errors a product of our work, We need to adopt a complex systems view of the workplace. And this is hard. Many (most) of us are conditioned to point at other people. We simply know of no other way.

In my view, every leadership development curriculum needs to include content on complex adaptive systems if we’re going to evolve how leaders approach errors in organizations. Because until we do so, the default response to errors will be to look first for the supposed human cause.

Some readers will say, “but Eb, people do make mistakes and errors.” You’re right. Re-read the first paragraph of this post. “But what if I have someone who keeps making the same mistake over and over again?” Well, assuming you’ve set this person up to succeed and yet they consistently make the same errors, it means they are in the wrong role. When people know what to do and deliberately decide to do something different, it’s no longer an error or mistake, and it’s now your job to address this situation. Maybe your hiring this individual was a mistake. Again, we all make mistakes.

We will (continue to) make mistakes and errors. Business management philosopher Russell Ackoff posits learning requires mistakes—I suggest there is some wisdom in this perspective. Effective leaders focus first on understanding what systemic conditions allowed for mistakes and errors to occur and then address these systemic conditions. 

Anytime you’re tempted to reduce the cause of an incident down to human error, think again. It’s entirely possible (and highly likely)  that you’re looking in the wrong place. Maybe that’s human error.

PS. If you’ve enjoyed this post, I believe you will enjoy my book “Becoming a Leader In Product Development.”

Apress: https://www.apress.com/us/book/9781484272978

Amazon: https://www.amazon.com/Becoming-Leader-Product-Development-Evidence-Based/dp/1484272978/

Beyond Empowerment

Image by Jill Wellington from Pixabay

Someone asked me recently why I dislike the word empowerment. Well here we go.

I’m not a big fan of the word “empowerment.” Well, let me rephrase this. I am not a big fan of how popular press corporate literature promotes “empowerment. It has become one of those overused corporate words (like transformation) now a staple of corporate speak. 

My reservations about applying empowerment (in corporate settings) have to do with what it might convey. You see, empower means to “give (someone) someone the power to do something. It implies the empowered individual (Person A) lacks some power. The empowering individual (Person B)  has this power, so Person B gives the power to Person A. In the lexicon of power relationships, we would refer to this as “power-to.” This transaction ends up with Person A now having the ability to do something they couldn’t do before.

On paper and in practice, this makes sense. There are times in the workplace when people get power they do not typically have. For example, if a specific action requires VP-level approval and the VP asks a Director to approve on their behalf, they have at that moment empowered the Director, i.e., they gave the Director power they did not have previously. Some might refer to this as delegation, and some texts use the terms interchangeably.

It is important to note that “power-to” relations have an implicit “power-from” aspect. If I can give you power, then it means I can take power away from you as well. It begs the question of whether the empowered individual truly has power. At any point, the VP could withdraw the power the Director now has to approve specific actions. So the power, at least in the delegation case, is potentially temporary.

Empowerment also, albeit innocuously, gives the impression that the empowered individual should not, by default, have the power they are receiving. Empowerment is understandable when their job does not require this power, but what about when their job does? Why don’t competent individuals have the power to do the jobs organizations hired them to do in the first place? And why do we need to empower them for this to happen? If corporations have to empower people before people can do their jobs, what does this tell us?

An individual hired into a role that requires them to do A, B, and C, should, by default, have the power to do A, B, C. The power needs to come with the position. We should not term giving people the power required to do their jobs “empowerment” because that’s not what it is. Instead, we are giving the people the freedom to do their jobs. We need to let people responsibly exercise power found in their roles. And remove any obstacles constraining the power the role should have. 

A great way to think through this is to establish the power inherent in any position in your organization and then make sure people in those roles can exercise those powers (again responsibly). There are many good reasons (beyond the scope of this article) you want to make the breadth of power as extensive as it can reasonably be.

As mentioned earlier, empowerment does have its place. It can show up in stretch assignments where people might need to exercise more power than they usually have. Training programs that equip people with new competencies empower them and with permanent new powers! These are great applications of empowerment, in my view.

However, moving beyond empowerment means having a workplace where positions inherently have the power required to do the job. Effective leaders spend a portion of their time removing obstacles preventing people from exercising their positional power responsibly. In many places, we need to move beyond empowerment to true liberation and freedom.

If you enjoyed this article, I think you will enjoy my book “Becoming a Leader in Product Development.”

Apress: https://www.apress.com/us/book/9781484272978

Amazon: https://www.amazon.com/Becoming-Leader-Product-Development-Evidence-Based/dp/1484272978/

What Type of Sport Is Your Product Development Team Playing?

I asked the following question on Twitter:

Is software development ALWAYS team sport?

— Eb (@eikonne) July 22, 2021

It’s not uncommon to find people who assert software development (and by extension product development) is a team sport. And while, to paraphrase, George Box, a model could be useful even though wrong, I do think that this assumption has a lot of nuance to it and depending on the team sport you’re a fan of, could shape your thinking on what product development team interaction needs to look like.

Significant social scientific literature on the concept of team exists so there is no need for me to rehash definitions. Suffice it to say that we can consider team a group of interdependent people working together towards the achievement of a shared goal. Team sports are characterized by multiple people working together to win a game (the shared goal). At the heart of team sports is competition. And while business may be competition (to some), product development teams are not necessarily in competition with each other so that notion of being a “team sport” speaks more to the expectation of how teams should work. That is, how should team members work together in support of accomplishing their shared objective.

So what sport should teams model their collaboration after? I’m glad you asked because the question provides us an opportunity to explore some sports team interaction styles. We can then compare those styles with the styles we observe on product development team. We can develop some archetypes that we can model. In all cases, everyone on the team has the shared goal of winning the game; however, how team members work together to win the game differs. The following is by no means exhaustive or complete. It is a reflection of the team sports I’ve played or I’m familiar with. Please feel free to provide feedback and thoughts and I’ll keep updating this.

I’ve taken a semi-recreational posture on these sports meaning, while I thought about professional aspects of the sports, the recreational engagement dominated my thinking (I think). Some other important notes:

• Communication, cooperation, coordination, and collaboration happen in all team sports. How team members perform the 4Cs may differ.
• The “ball” serves as an object of interest when thinking about how team members interact.

Team Sport Archetype	Team Sport Interaction Styles	Product Development Team Application
Tennis Doubles	Each team member does their part to hit a winner on behalf on the team. Team members do not actually pass the ball to each other. Team members can cover for each other when one team member is out of position.	Each individual focuses on their task and may cover/help one another if the case arises. Executive and management teams tend to work this way.
Baseball	Team members have specialized positions and specific tasks/focus areas. They may pass the ball to each other if required. Team members cover for each other when one team member is out of position.	A team of specialists with some overlap. Each team member has a particular task they need to accomplish. Task collaboration in spots. There are people whose preferred interaction style is one of high independence.
Beach Volleyball	Each team member has to play to play both offensively and defensively even though one team member might be a better defensive player and one team member might be a better offensive player. Team members pass the ball to each other to give themselves the best opportunity to score points. They also cover for each other.	Specialization is not as important here as it is in other sports. Skill sets are similar and team members have little to know problem filling in for each other. Team members may or may not collaborate on the same task. I’ve observed of the product development teams I’ve been around take a beach volleyball approach.
Curling	There are specific roles on the team. However, each team member has to throw and sweep at some point. So everyone has to play all positions before the game is over. Team members work together (sweeping) consistently on the stone.	Specialization has a place; however, each team member must be multi-skilled. Team members work together on a shared task and at the same time. They intentionally rotate positions as well. Teams that invest in “ensemble programming” as Tim Ottinger and Maaret Pyhäjärvi would describe it are probably like curling teams.
Football (Soccer)	Team members pass the ball to each other throughout the game, moving up and down the field or court depending on whether they are trying to score or defend. Team members cover for each other and can rotate positions.	Team member specialization exists. Team members work together on a shared task. A lot of work is done on team chemistry. I’ve been part of teams that interacted like a football team.
Basketball	Similar to football (soccer); in many cases, roles shifts more fluid.	Like football mentioned; however, team members regularly take on different roles while working on a task.

Team Sports

So what do you think? What’s missing? What type of team sport best reflects how you see product development teams interact?

Decision-Making Reading List

Johanna Rothman asked for a decision-making reading list that managers can use in their work.

Better decision-making is something that I’m highly interested in. We often have to make decisions while dealing with risk (unknown outcomes and known probabilities) and uncertainty (unknown outcomes and unknown probabilities) according to Gerd Gigerenzer. My objective is not to ever make a “bad” decision; instead, it is to improve how I (and those I interact with) can make better decisions for better outcomes. This applies to all aspects of my life.

So without further ado, here are some of my favorite books on decision-making.

• Annie Duke, Thinking in Bets, https://www.amazon.com/Thinking-Bets-Making-Smarter-Decisions/dp/0735216355
• Gerd Gigerenzer, Risk Savvy: How to Make Good Decisions, https://www.amazon.com/Risk-Savvy-Make-Good-Decisions/dp/0670025658
• Chip Heath and Dan Heath, Decisive: How to Make Better Choices in Life and Work, https://www.amazon.com/Decisive-Make-Better-Choices-Life/dp/0307956393
• Douglass Hubbard, How to Measure Anything, https://www.amazon.com/How-Measure-Anything-Intangibles-Business/dp/1118539273
• Daniel Kahneman, Thinking Fast and Slow, https://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/0374533555
• Gary Klein, The Power of Intuition, https://www.amazon.com/Power-Intuition-Feelings-Better-Decisions/dp/0385502893
• Gary Klein, Seeing What Other’s Don’t, https://www.amazon.com/Seeing-What-Others-Dont-Remarkable/dp/1610392515
• Greg Mckewon, Essentialism, https://www.amazon.com/Essentialism-Disciplined-Pursuit-Greg-McKeown/dp/0804137382/
• Matthew Syed, Black Box Thinking, https://www.amazon.com/Black-Box-Thinking-Marginal-Performance/dp/1473613809

I hope you find these resources helpful. Some (like Hubbard and Kahneman) focus more on probabilities and statistics while others (Klein and Gigerenzer) focus on heuristics and “rules of thumb. I believe managers will benefit from understanding both approaches.

All the best.

PS: My book, Becoming a Leader in Product Development is now available for preorder on Amazon here: https://www.amazon.com/Becoming-Leader-Product-Development-Evidence-Based/dp/1484272978