How to Fix “Team Creep”

Legal teams face more data and more scrutiny than ever. They need AI built for both. Relativity is the AI platform for legal work, delivering defensible AI that handles the tedious tasks so judgment stays where it belongs with you. Learn more at relativity.com/ideacast.

Marketers know how it feels to invest in something that seemed incredible but didn't live up to the hype. We optimize for impressions, but then don't see any revenue. Instead, get the highest ROAS of all major ad networks with LinkedIn Ads. Spend $250 and get a $250 credit. Just go to linkedin.com/ideacast. Terms and conditions apply.

On May 20th, join me at HBR's Annual Leadership Summit with masterclasses, interviews with the CEOs of AT&T and Mattel, and an interactive case discussion led by Harvard Business School Professor Karim Lakhani. For 25% off, be sure to grab your early bird ticket by April 14. To learn more, go to hbr.org/leadershipsummit. See you there.

Welcome to the HBR IdeaCast from Harvard Business Review. I'm Sarah Greene Carmichael. Here's the old way of working. One person on, say, 3 projects, all with the same team. And the new way? That one person with those 3 projects, but now working with 3 different groups of people, AKA multi-teaming. At its best, multi-teaming lets us learn from different departments. At its worst, bouncing between groups stretches us thin. But today's guest says multi-teaming organizations are running a bigger risk than employee burnout. Putting one person on projects that are otherwise unconnected means that if that person is tied up with one project, all the other projects stall. Mark Mortensen is here to talk about how managers can get the benefits of multi-teaming without leaving their staff stressed out. He's an associate professor at INSEAD and an expert on organizational collaboration. He's also the co-author, along with Heidi K. Gardner, of The Overcommitted Organization. It's in the September-October 2017 issue of Harvard Business Review and on hbr.org. Marc, thanks so much for being here today.

Thank you so much for having me.

So how do managers react when you tell them about that kind of risk?

This is a topic that comes up quite a bit in executive sessions or consulting with companies. And we start talking about these issues. And the interesting thing is, when I lay this out, what I typically hear is a whole lot of silence, a whole lot of wide-eyed silence of, we're not really measuring that. And then usually a few scribbled notes of maybe we should. And for me, I found this fascinating. This is also a big motivator of why we wanted to write this piece is I think this is actually a very important thing and an important message to get out there as something for organizations to be thinking about. This occurs primarily because the person who has the best understanding of the teams and the projects that any given individual is on is that individual themselves. And the way in which we staff projects today very often is almost on a dyadic relationship, right? A manager says, hey, I really need you on this project. Can I have 20% of your time? And what happens as a result is people have these relationships. I'm on this project 20%, this project 20%, this project 40%. A, they don't always check that the math works. Sometimes they end up with 137% dedication, and that's obviously a problem. B, nobody knows, nobody has the big picture, or very often nobody has the big picture sense of what are all the projects and all the teams that somebody is working on.

Let's just run through what are the pros for the organization.

So for the organization, as we said, there's this, this idea of efficient use of resources. If I am only needed 50% on one project, why not use the other 50% of my resources? And But also the learning argument, the information transfer argument, particularly at the level of the organization. If you want the organization, different parts of the organization to know what's going on, having those people cross-staffed across different projects and different teams is a really good way for doing that.

And the cons?

Obviously, a lot of the cons come at the individual level or at the team level, and they get aggregated up. The one con that's really an organizational level challenge is what I call human capital interdependence. So you can think of it as there's a new type of risk on the block that we haven't really been thinking of. Managers for years have been thinking about their processes, have mapped them all out in excruciating detail to figure out if I do X and what's going to happen after that, what is it going to be? Y? Is it going to be Z? How do I understand that? And part of that is also to understand the risks, right? If I have a failure at this point in my process, what's going to happen downstream? Now, this is always framed in terms of the— this particular task I'm doing, how does it affect the next task, right? And this may be, this is an input to that task. This could be, this is a competitor to that output, whatever it might be. What's coming into play here is we may have interdependencies based purely on the fact that we share individuals, even though the work we're doing on these teams is totally separate. If I have a production, a designer, automotive designer, They might be doing work on a car. They also might be doing work on a truck. They also might be doing work on a motorcycle. Now, every one of those projects, if it shares that one person, is now interlinked. There's nothing that has to do between those projects. There's no strong reason that those projects have to be kept lockstep. But now that there's one person who's shared across them, all of a sudden they find that they are. And what happens, and this is where we see this new risk coming, is an issue that comes based on the motorcycle project or on the, the car project, right? There's a safety recall. Suddenly all hands on deck. Everybody has to try to fix this problem. Well, that takes all those people away from their other projects. That may mean that suddenly the truck project is on standby because we're missing our two key engineers because they were pulled away. There's nothing about the car and the truck that on paper look connected. There's nothing about them that actually means that they have to stay together. But because they share people now, they find that they're actually bound very tightly. That's a new type of risk that we face.

Who is the most likely person to be on multiple teams and kind of suffer from the sort of too much of a good thing that this can lead to?

So it's a tough question. I think different people at different levels and different roles are on it for different reasons. People who are very, very specialized, they have great expertise. They are the deep knowledge on a particular task. I have seen this very, very often also in R&D teams. Right? Somebody who has advanced degrees, a lot of deep knowledge in a particular thing. That person gets pulled on many different projects because I need somebody with this incredible expertise. Now, very often those people are also very, very expensive. They're very expensive because they're so specialized that the cost-benefit trade-off doesn't quite work, right? For me to own that person 100%, for me to have that person 100% on my project is very, very expensive when I only need 10% of them. So one reason this happens is people with deep expertise get allocated on many, many teams because lots of teams need at least a little bit of what they've got, and they're the only one who has that skill. Now, there's another very different role that happens, which is more of an administrative role. I mentioned before, my colleague and co-author Heidi has done a lot of work in professional service firms. If you're a senior partner and your job is maintaining the relationship, you may be that point person, that relationship manager on multiple different projects. And so you're being pulled in even though you're not doing deep analytical domain work on the particular piece. You own that relationship and you have that. One way to think of it, it's actually two sides of the same coin. In the one case, it's deep technical knowledge. In the other case, it's deep relationship knowledge. It's the people who have something unique and they need to be stretched across multiple projects.

Teams seem to sort of gradually expand. And there's this kind of feeling of, oh, we can just add one more person to this email or one more person to this meeting or one more person to this project. And that often actually results in an exponential increase in coordination costs.

So you're raising a really good point. It's an ideal world scenario when I say, oh, this only happens because people have this incredibly deep knowledge and they're the unique contributors in that way. Sometimes it also happens purely from a sort of a horsepower argument. We need more people. We have a certain number of resources, and it may not necessarily be specialized skills or specialized knowledge, but we actually just need more hands. We need more hands on deck. And so we have people who are more exchangeable resources in that regard. But I think you're also raising a really good point. Phenomena like team creep is— at least that's the way that I often talk about it in my sessions— this happens all the time, right? Saying, oh, it would be really great to get somebody with X point of view, or it would be really great to get somebody from this part of the organization because we want to make sure that we've got buy-in. We want to make sure that they're on board, that they understand what's going on. As we said, this is a conduit for information transfer. That's a really valuable thing. Maybe we want to make sure that we have as many of these pathways as possible. So it's not always that we're designing teams sitting with the playbook. Martin Haas and I wrote an article that came out last year where we were talking about how do you design teams. And we know from a long history of research a lot of things that go into designing teams well. We don't always follow that advice. We often end up in a situation where little incremental changes along the way end up with a big— a little bit more of a big mess. So I think what we see is a combination, both teams that are designed the way they are for a very good reason and ones that kind of have evolved in that way and nobody's really been paying attention and, and it often happens that later on we stop and take a look and say, wait a second, maybe we need to revisit this and, and think about it a little bit differently.

Yeah. So there has been a pretty well-documented, uh, look at that phenomenon that switchtasking and switching from one thing to the next is really draining. It's stressful and it's not very efficient. And there's sort of costs to all that switching. So why then do organizations still think it somehow makes sense to have someone spending, you know, 10% of their time sort of peanut buttered across a lot of different things.

So unfortunately, as a manager, as a leader, we also— we're not thinking day to day about the experience of our employees. Very often that's the case. So I may be doing my job. I may say, you know what, I need you on task A or task B. And I allocate people because it doesn't register. I don't actually know in my head how many other tasks are you working on, how many other projects. It's not done maliciously by any means. Part of it is just a lack of information. And the benefit that I get as a team lead or as a division lead or as a vice president, whatever it might be, the benefits I get from having my people working on many different projects, those are easy to see. They come out on the bottom line. The costs aren't always as easy to see because that comes down to somebody being stressed, overworked, tension, burnout. And it's hard to necessarily draw that line back to where does that actually come from.

How did we get here? Why do people decide gradually over time in different locations, in different companies, that the way to go was to have these kinds of overlapping teams where, you know, instead of just having like, yep, this is my team, we're in a silo and we're fine with that. Like, we're not going to try to bust up this silo.

I think a main issue with this is it's just global competition. The world is becoming much, much faster paced, right? We have lots of evidence that just the general pace of change is increasing. At the same time, the world is becoming much more heavily interconnected. We see this in, in our executive programs. I mean, we have an incredibly diverse set of people coming from different industries, different geographic regions, but they're all facing the same sorts of problems because they're all now playing in a truly global environment. That environment is forcing the hands of organizations who realize they can't continue to compete in the same way if they keep themselves in these very traditional hierarchical lockstep sorts of structures.

Ever invest in something that seemed incredible at first but didn't live up to the hype? Marketers know that feeling, optimizing for impressions and then not seeing revenue. Instead, invest in what looks good to your CFO. LinkedIn Ads generates the highest ROAS of all major ad networks. Spend $250 and get a $250 credit. Just go to linkedin.com/ideacast. Terms and conditions apply.

So if one of the challenges to fixing this problem is that the work itself is sort of invisible to managers and they don't realize person A is doing 15 things and person B is socially loafing and doing 2 things or something, how can managers make the work more visible? Or at least get a better handle of what's going on?

I think there are actually two different things, two different ways of going about it. One is trying to make visible what people are actually doing. And so here's where, for example, billable hours or other systems that actually log that information are a good step towards creating clarity. Now, having that data is different than having that data be visible. Many organizations have it, but it's not always visible to everybody. It goes into a system. HR is aware of it. We use it at the end to take a look at bonuses. We use it at the at the end to figure out who's been allocated to what. That doesn't necessarily mean that there is a running dashboard of here's all the different things that a given person is working on. So having that stuff be more visible is one way, and having it be more publicly visible, that public visibility I think can play an important role because it can actually help people in dealing with and coping with the stresses and the tensions of doing this sort of work.

I am so interested in this, and I feel like there's pros and cons to making the work visible. In an organization with low trust, you could end up with lots of resentment and a perception this is all political and people feeling threatened by, oh, I don't have as many things on the board that I'm working on. Or you would think, what's wrong with so-and-so? She has 40 things on her. She can't possibly be good at any of them. There would create all these issues. On the other hand, it seems like such an elegant solution that would resolve so many issues.

Absolutely. And I think this is just a tension. This is, this is the reality, unfortunate reality that we've got. I don't think there is a yes or no answer to it. There's no question that when you make it more visible, you increase the likelihood or you increase the possibility that people can actually game the system and can find ways to do that. On the other hand, if we don't have that sort of clarity, then we're basically sitting with blinders on, right? We're in the dark. We don't actually see what's going on. And this is the reality that we have. And I think, at least when I've talked to people about these topics, the topic really resonates. This sense of being overcommitted and being stretched too thin, this is a pain that people feel. So to one extent, we just need to make a call as to what do we feel is worth the cost, right? If we want to try to move the needle, if we want to try to get better at helping people to manage this process, manage being on multiple teams and multiple projects, manage the stress that comes along with it, manage the organizational risk that comes along with it. We're going to have to accept that this data, you know, data can be used for good. The data can be used for evil.

So creating this kind of open public dashboard could be one way to address this problem. What are some other things that you've seen work?

Honestly, the main tool at this point, because most organizations don't have the data in the kind of format to have a dashboard sort of format, The main tool is conversation. The cases where I've seen organizations make real improvements is when they've gone back to the office and said, okay, let's start, take the first step to just mapping this stuff out, right? At the very least, saying, I'd like all the team leads to go back to their teams and just have a conversation. Let's have one meeting, doesn't have to be long, 15 minutes, 30 minutes, where we go around and talk about how many other projects and what other projects are you on. If nothing else, even if the team leader doesn't have all of the pieces mapped out, when your colleagues in your team know about how many other projects and what other projects, it actually allows the system to adjust itself a lot more smoothly and a lot more easily. I see that you're stressed out, and I know that you're also on the beta project, and that gives me the sense that maybe, you know what, I can take a little bit extra slack because I know my other project isn't in as bad a shape. So having that transparency and just having that conversation at the level of the team can help for a lot more sort of mutual adjustment of the way in which things are working. The benefit of not having everything so transparent is it does actually allow flexibility. And so in the age where we talk about organizations needing to be very nimble, very dynamic, people are on multiple teams also because they're on teams for a very short period of time. I have you for a day a week, or, you know, or for a short period of time, for 2 weeks, and then you rotate off this team. And onto something else. To maintain that flexibility, the more bureaucracy, the more structure you put in, the less flexibility you have in that kind of a system. So this is the downside risk, right? Making it more visible allows you to better manage the process. At the same time, you can overmanage the process and you can create a lot more rigidity and a lot less flexibility in the system. And this is a trade-off that managers unfortunately have to make.

It does also seem if trust is so important to solving this problem, that one of the challenges people have to figure out how to overcome is how to build trust when you only have this group of people maybe together for 10% of the week.

So this issue of multi-teaming and multiple team membership, I see it actually as part of a broader suite of changes and transitions that a lot of organizations are going through. The staffing people on multiple projects is one. The fluidity and the dynamism moving people from project to project is another. Geographic distribution and virtual work is a third, and new forms of work. All of these are changing pretty fundamentally the way in which we think about how we do our work and the team as an entity, the team as a construct. And this is something that we have used as a way of organizing ourselves for the last 100 years and grew tremendously in the late '80s into the '90s into the 2000s as the way in which we organize everything. Now, one of the challenges is with people working on multiple teams and moving from project to project and working globally and virtually, what the team is, is starting to become a whole lot more fuzzy and a whole lot harder to put your finger on. And then, as you said, a lot of the dynamics that we've come to rely on, right? A team is great because it's the way you build trust. A team is great because it's a way that you can actually promote exchange of ideas inside. You can use that to create, as Amy Edmondson's work has shown, psychological safety. And a real— it allows you to create environments in which people feel open, etc. All of this stuff starts coming a little bit more into question when the team itself is this dynamic and overlapping and fluid entity. And this is one of the things that I think we're going to really have to do a lot of thinking about. And we're, we're working on trying to push the envelope with research.

Is there some way that individuals could raise a white flag if they're overstaffed on too many projects? Without sounding like they are trying to shirk their responsibilities?

Well, I think this is one of the challenges that we need is we need greater recognition and visibility of this as a challenge and of this as being a very real problem that organizations face to make it something that somebody can safely raise. When in many organizations today, because there isn't an awareness of this idea and they're not really thinking about the challenges of being this badly overcommitted, If somebody says, hey, wait a second, I'm stretched way too thin, the immediate sense is, ah, what are you? Are you weak? You're not capable. You're not pulling your weight. You're lazy. What's wrong with you? What we need is we need a recognition and an acceptance that, you know what, this is the reality that we're in. It's not good or bad. It's the reality. We need to deal with that. And because of that, we need to be sensitive to recognizing when somebody is stretched too thin or not. And if somebody raises a white flag and says, hey, I need help, we're ready to help and step in. One of the things that we've talked about in the article is, is the creation of slack resources. This doesn't mean that you have a whole bunch of resources sitting unused, but you have some protocols in place to say, look, when we do run into a situation where we desperately need more resources on a given project, we've given some thought to where those resources can come from. So we're ready, we're sitting ready with the the water bucket. So in case there's a fire, we know we have it at hand and we can throw it on the fire to put it out.

When you are launching a new project, what are the things you should do before you launch it to make sure that it's not going to run into any of these traps that we've been talking about?

First of all, assuming that you can get away from all the traps is probably not going to happen, right? The reality is, and I'm only saying that from the standpoint that I think managers have to recognize there's going to be points where it chafes. There are going to be places where it doesn't work as smoothly because this is, this is a very complex mapping problem of work and personalities and all this stuff. Before the actual launch of the project, I think one of the things that managers can really do is spend some time sitting down and really thinking about the project overall. What are the resources that they're going to need? Where are they planning on getting those? Also thinking about the ebbs and the flows of the project. Where are there going to be peak times? Where are there going to be valleys? So that when they start thinking about how are we going to staff this project, we actually staff it intentionally. We start thinking about not just where can I get a resource that can solve the particular problem, because today's organizations often find they have multiple resources they could apply to a given problem. Now we want to add into the mix that you may actually want to choose one versus another based on the other projects and the tasks that they're working on.

And what about the kickoff meeting? Because sometimes projects have a kickoff meeting, sometimes they don't. Should you have one?

Absolutely. I'm a big proponent of kickoff meetings. I think they play a really, really important role for many reasons, some that have to do with multiple team memberships, some that have to do with just good team design. The kickoff meeting really serves to do a few things. It sets ground rules about the way in which we want to function, we want to operate. It helps people to understand why we're here, right? And one thing we know from coming back to Richard Hackman's work on where teams— where team effectiveness comes from and how do we get it, You know, the core foundational element is knowing what are we here to do and having an agreement about that. So having that initial meeting is really, really important because that also plays into understanding how are we going to deal with working on multiple teams and multiple projects. If we really have a good core understanding of what we're here to do, that helps us to allocate and decide when do I need to really be 100% focused on what we're doing here in this team versus when I can go back and forth. And then it's about sharing and establishing what are the norms, right? What are the expectations? How do we make sure that people feel open and comfortable enough that they can say, you know what, I can't actually work on our project right now because I have two other projects and they're higher priority. You need to be able to share and have those discussions in order to be able to manage these processes. And you're not going to have those unless the team dynamic and the norms are really in place.

Are there some projects or types of projects that just really aren't suited to multi-teaming, and people on that team should just be allowed to do one thing and do it really well.

The more that a given project requires very deep and complex interactions from a set of people over time, the harder it is for those people to switch in and out, right? If we have to have established a rhythm and a routine, there's a lot of back and forth that has to go on between the work that you're doing and the work that I'm doing. It's really hard for me to then jump out to another project for a while and jump back in and resume without having to invest a lot of time to get caught back up to speed, to find out what progress have you made, where do we need to work on things, how should I allocate my resources?

You have studied so much about this topic. What do you wish you knew about it that we don't yet have evidence for?

I think we really don't understand enough about the reality of how people cope with this sort of situation, all the different flavors of it. How do they cope with managing the transparency issue? How do they cope with dealing with being stretched too thin on multiple different projects? How do they cope as a manager with trying to allocate resources when you have pressure to do it, and at the same time, you can see your employees are stretched too thin and overcommitted and burned out? I think one thing we really need is a better understanding of the mechanisms people use to deal with it so that we can try to facilitate and support those within an organization overall.

Mark, this has been so interesting. Thank you again for coming in today.

My pleasure. Thank you for having me.

That's Mark Mortensen. He teaches organizational behavior at INSEAD, and he's the co-author of The Overcommitted Organization. Read it in the September-October 2017 issue of Harvard Business Review. Or at hbr.org. Thanks for listening to the HBR IdeaCast. I'm Sarah Green Carmichael.