Task forces

When critical deliverables grind to a halt, most project managers reach for familiar tools: more status meetings, tighter deadlines, and additional resources. Yes, I can feel you rolling your eyes already. We all know these tactics only make things worse—and yet we see leadership reach for them. Every. Single. Time.

Let me tell you a story about how I broke the cycle, and why the solution worked better than I could have possibly expected.

The Problem: Cross-Team Deliverables Without Clear Ownership

Last year, while leading a major architectural overhaul project, I was watching three critical deliverables languish despite having capable teams and adequate resources: go-live planning, performance testing, and data migration. These all cut across team boundaries with no clear ownership—and if there's one thing I know about project leadership¹, it's this: when you don't have a singular person accountable for making sure something gets done, it doesn't get done.

I knew I couldn't just arbitrarily assign these deliverables to existing teams—they'd have too many dependencies on other teams and would inevitably get stuck again. But I also couldn't take on planning and executing these myself; I'd become the ultimate bottleneck.

The solution hit me when I started thinking about matching communication structures to the work itself. If the work cut across team boundaries, why not create structures that did the same? So I decided to try something different: task forces.²

The Experiment: Cross-Functional Task Forces

For each stalled deliverable, I approached a capable team lead and asked them to assemble a dedicated cross-functional team. The conversation was easier than I'd expected—these team leads were already aware of and concerned about the deliverables that weren't progressing. They were keen to try a different approach, and frankly, they were excited about the additional responsibility.

Here's how I structured it—and this is where things got interesting. Each task force lead got their mandate—deliver X by Y date—and the freedom to negotiate for their own team members. They couldn't just conscript engineers; they had to kōrero with the other team leads to take some of each team's capacity, with the understanding they'd have to give it back if they weren't utilising it effectively.

That negotiation requirement turned out to be more of a feature than a bug. It created natural tension that put a check on task force size and ensured teams would grow or shrink as needed. But more importantly, it got the team leads talking and coordinating with each other constantly, which became the real game-changer.

How Task Forces Actually Operated

The task forces operated as lightweight teams, running regular standups, planning, and refinement meetings, but at a lower cadence than regular teams. Engineers often weren't 100% allocated, so they'd split time between their regular team mahi and task force mahi. Each task force lead represented both their team and their task force during project status meetings, and that way during my weekly check-ins with them, I could focus on providing guidance and coaching rather than directing activities.

What surprised me most was how little active leadership these task forces needed from me. Because the team leads had to negotiate regularly for resources, they were also planning together and learning from each other constantly. There was far less reliance on me to get into the details with them. Similarly, because engineers from multiple teams were also working together on technical challenges, information was flowing freely, and silos that had existed for months started breaking down naturally.

Why It Worked: Systems-Level Change

Now, I need to confess something: at the time this was absolutely one big experiment. I had a hunch it would work, but I didn't fully understand why until I started reading about systems thinking later. It turns out that what we'd stumbled onto was something systems thinker Donella Meadows calls high-leverage intervention points. Instead of trying low-impact changes like adding more people or tightening deadlines, we'd fundamentally altered how the system operated.

The task forces changed the purpose of work units from maintaining departmental boundaries to achieving specific outcomes. They increased the power of self-organisation by letting teams develop their own rhythms and decision-making patterns. And they altered authority structures by empowering task force leads to negotiate for resources across traditional hierarchies. Looking back, it's no wonder the approach felt so different from typical project management interventions—we were working at a completely different level!

The results bore this out. All three deliverables were completed on time and to high quality standards...but the real transformation went deeper:

• The constant negotiation between team leads created new information flows across the entire project.

• Developers who'd never worked together began collaborating regularly.

• Technical decisions that previously required lengthy approval chains happened in real-time.

• Knowledge gaps that would have surfaced during testing were identified and addressed weeks earlier.

• Task force leads developed new leadership skills that served them well beyond this project—they learned to navigate competing priorities, build consensus across departments, and drive results without formal authority.

The broader project reflected these improvements too: we went live on schedule, doubled the performance of the previous system, and completed the data migration well ahead of the deadline.

When to Use Task Forces

So when should you try this approach? Task forces are particularly powerful when your project's challenges are structural rather than operational. Look for situations where multiple teams or departments need to coordinate closely, traditional reporting lines create bottlenecks, or success requires both deep technical expertise and broad organisational knowledge.

Rather than fighting against organisational constraints, task forces work with systems thinking principles to create new structures purpose-built for complex, cross-functional challenges. Sometimes the most effective intervention isn't working harder within existing constraints—it's changing the system itself.

1. Or rather, if there's one thing that this near-disaster taught me about project leadership...

2. Or cross-functional teams, if you prefer a term that absolutely does not roll off the tongue.