Task Forces can solve (some of) your cross-functional challenges

Sometimes organizational boundaries make it hard to coordinate. There are too many leaders involved, or you have various groups that can’t align their work or activities. In this case, you often want a Task Force.

When you talk with older leaders, they’ll often talk about “putting the people in the same room” to work together. Task Forces are the equivalent of that, optimizing for high quality communication. You form a temporary team that lives for the duration of a project.

When to use Task Forces

Task Forces are always for cross-functional work. They are for urgent or important work.

Use a Task Force when you know it’s more important than the alternative, and you’re okay with the waste and chaos that it might cause. In particular, you should think carefully through the tradeoffs. You’re probably going to underestimate the disruption you’re causing. These are especially acute for full time Task Forces.

So think through these concerns:

• Task Forces disrupt roadmaps. They usually take some of the most experienced and capable people from projects, and move their focus to something else. This means all of the other roadmaps will be disrupted.
• Task Forces are often high pressure. While many people like to work on something that is perceived as high value, they may not appreciate the pressure. It also creates pressure on the team they came from.
• You can have issues with boundaries. Teams that have high ownership boundaries will feel like their boundaries are being violated if they need to support the work after the Task Force leaves. If you’re encouraging “high ownership” teams, this is directly opposed to high ownership.
• You’re adding work in progress. Although you’re locally creating more focus, you are adding to the total amount of work going on. Instead of focusing on less, you’re doing more.
• Participation in Task Forces can be political. If someone is selected for a Task Force, that often looks like they are “high performing”. Depending on your work culture, this can create a lot of morale issues.

If you see your organization always reaching for a Task Force, you might want to look deeper at why the Task Forces are necessary. There can be other issues, such as a poor organizational design, poor coordination and communication, or other issues. (Let me know if you want my help figuring it out!)

Different types of Task Forces have different levels of disruption. Setting up a weekly meeting often isn’t disruptive. But sometimes the Task Forces are a good signal of where other communication or coordination is lacking.

Examples of using a Task Force

To give you an idea of how Task Forces can be helpful, I’ll tell you two examples of using a Task Force.

A full-time Task Force to deliver something quickly

The first story is from earlier in my career when I was a VP of Engineering at New Relic. New Relic had waited too long to introduce distributed tracing. You don’t need to know what that is, but the end result was that the product was starting to feel stale compared to competitors.

Six weeks before our user conference, we decided to address this deficiency: we would demo a working example of distributed tracing. **This meant we had six weeks to deliver a working version of distributed tracing. **The problem with this was that historically this type of work had taken much longer than six weeks. We didn’t have a detailed plan for how to implement distributed tracing. The work had to be done across several teams. We needed to add “agent” support, APIs for the data, and data ingest. Each of the teams had highly different skillsets and quality concerns. For example, the “agent” team had an extremely high quality bar, because they could break the software of our customers. Each team also had their own roadmap and leadership. Coordinating work across these teams was complex.

With work like this, you often see a lot of integration pain. Technologists often like to take a problem like this and decompose it into separate problems that each team solves independently. They see the challenge as figuring out the boundaries between each team, and having each team work on their part of the project. Put them all together, and voila!

The problem with this approach is that it usually doesn’t go as you would expect. Invariably, you find that you’ve missed something. And your understanding of the problem evolves as you build the solution. I’ve almost never found the “decompose the problem” and integrate approach to work. Frequency of communication overwhelms speed of execution, every time.

I considered that approach. One variation could be to have a strong program manager leading and synchronizing between all the subprojects. With a lot of attention to detail, that could work. But it felt risky.

Another solution I thought about was to take one of the teams where most of the work was going to be, and steal a couple of people from other teams to work with them. This was pretty close to doing a Task Force, but the problem was the team was already a pretty large effort, and there was a way that this didn’t feel urgent enough. It kind of felt like business as usual, except they were working on a new project, with a few guests.

I was talking over this problem with Belinda Runkle, and she suggested creating a Task Force. Instead of creating this out of existing teams, cherry pick a team to focus exclusively on this project. Clearly, that was the solution.

We started out by figuring out who should be on the task force. And then I proceeded to craft what was the best kickoff meeting I’ve ever run. I had a vacation immediately after the kickoff that I couldn’t reschedule. My problem was: I have to kick this off so well that it will work without me for a couple of weeks. I put together a solid agenda and practiced the heck out of the content. And it worked, even better than I expected.

We spent the day going over what the market was like, what our customers were looking for, what we needed for the conference, and how to think about tradeoffs over the coming weeks. We talked about where we were going to sit, how we were going to work together. And we walked out of the meeting with everyone 100% on the same page about what we were doing.

The result was impressive. Our CEO demoed the feature at our conference. It went flawlessly, and our customers were excited to see the results.

Obviously the team did the work, and delivered the results. I can’t claim credit for all that work. But setting it up correctly was part of the success of this work. I credit Belinda for thinking of the right way to structure it, myself for the kickoff, and the team for the great work that delivered so well in such a short time. I think of it as some of my best management work.

A part-time task force to solve an overwhelmingly complex problem

I had another occasion recently when I saw a Task Force be employed, to very good results. Kaari Casey introduced a Task Force for a topic that a lot of leaders had been talking around. As soon as I saw it introduced, I kicked myself for not doing it myself.

I was in an Interim VP of Engineering and Product role at a company. They had recently gone through a merger. This meant that there were duplicative processes and technology across every department. From a technical perspective, we knew that we wanted to migrate everyone to one of the technical platforms. But we also knew this wasn’t going to be easy: there were a lot of processes and workflows that our platform didn’t support.

The technical work was inseparable from the process work. Each department needed to merge its processes, and some of that depended on technical work to support them. Yet the technical work would go a lot slower if I as product leader was directly leading the process changes. It needed a more coordinated approach.

Kaari came to this conclusion before I did. She said, “Clearly this is a big discussion, and we’re going back and forth about this. Let’s set up a weekly meeting to hammer out the plan and coordinate our work”.

She set up a great agenda, and in the first meeting we all walked out with action items and next steps. In retrospect, this seems completely obvious, but nobody else was doing it. I didn’t.

So that’s the beauty of a Task Force. You assemble a temporary team to solve a particular problem. It’s a valuable tool to have in your management toolbox.

When using Task Forces

• Decide whether the Task Force should be full-time or part-time. Usually part-time Task Forces are some sort of regular meeting. The downside to part-time Task Forces is that they can take a long time to produce results. Consider whether scrunching it to a day long meeting or offsite is warranted. If it’s urgent, that can produce results faster.
• Think through who will own the work. Because the team you create is temporary, it may not be clear who owns the work after the Task Force is done. Who will support the work afterwards? Can you make that clear? It can be good to think about future risks as well. For example, if the work is software, who will help out if there is an outage?
• Kick off the Task Force like your life depends on it. You’re creating a disruptive Task Force that is taking very talented people away from the valuable stuff they were already doing. Make it worthwhile! Kick off the Task Force well. Use an offsite if you can. Make sure everyone walks out of that kickoff meeting on the same page.
• Borrow legitimacy to bless the task force. You can sometimes get the Task Force blessed by someone higher up in the hierarchy. You might have them start the kick off meeting. Or you might have them bless the effort. Task Forces can be a sneaky way to use the resources of other departments. But other departments might feel bad about it if you don’t get the effort stamped as important.
• Select the right participants. Make the Task Force as small as you can, but make sure all fo the right people are there. I spend time thinking about who should attend, and test my thinking with other people.

Task Force versus other coordination models

These are some closely related models to the Task Force that you might consider:

• Merged Group is when you merge two groups together that were previously separated (like merging an operations and engineering team, or a frontend and backend team). This is a full time change, and makes sense when there were previously handoffs or dependencies. Often a Merged Group is then divided again along different lines, if it is too big. Merged Groups are more permanent in nature than Task Forces, but you might consider a Merged Group if your Task Forces are actually pointing in the direction of “vertically sliced” teams.

• Away teams are when you use your team in another team’s territory. They’re useful when the other team is too busy to help you out. Away teams are more for handling dependencies than for better coordination.

• Tiger teams are permanent Task Forces. They are similar in that they usually have a defined purpose. But since they are (fairly) permanent, they have an explicit “go anywhere” mandate.

Coordination models

Task Forces are one of many Coordination Models. I’ve written these up as a pattern language for coordinating humans in large groups.

See also

I had a Decoding Leadership podcast on Task Forces. A Youtube version of that is here.

Feedback

I think that’s all I have to say today about Task Forces. Let me know if you have any questions!

Thank you

Belinda Runkle suggested the first Task Force. Kaari Casey spun up the second Task Force. Juan Ignacio Sánchez Lara helped me flesh out the section on the tradeoffs of Task Forces. He suggested a number of factors I hadn’t thought of.

Image by Dimitris Christou from Pixabay