Before You Look at the Team, Look at the System

You may remember from my last post that I was part of a group of kayakers who pushed off on a river trip a few weeks ago. There were bald eagles, we had perfect weather, and it was a beautiful and peaceful trip. What I didn’t say was that when we pushed off, things didn’t look so peaceful. Some people had kayaked many times before, some were beginners, and I had a moment of panic when I almost left the dock without a paddle while my kayak was filling up with water. Not the most organized-looking team, by far! If you’d been watching from the other bank, you probably would have grinned and wondered how the trip was going to go.

The guide was wonderful about it. She quickly handed me a paddle, calmly explained that scupper holes are actually designed to let water in and drain right back out, keeping the kayak stable. She also gave everyone a warm and encouraging rundown of what to expect on the river, and just like that we were off, laughing about it already and genuinely excited for everything ahead.

Same people, same river, completely different energy, all because we had the right information, the right tools, and someone who made sure we were set up for success.

That morning on the river stuck with me, because it’s the same dynamic I’ve watched unfold on program teams more times than I can count. A project gets off to a rocky start, a deliverable is late, decisions are taking longer than they should, and the client starts asking questions. And the first place a lot of leaders look is the team. Is someone not pulling their weight? Does someone need coaching? Do we have the right people in the right seats?

Those are fair questions, but before you start answering them, it’s worth slowing down and taking a closer look at what you’re actually seeing. The person watching from the far bank that morning would have seen a group of people who looked like they needed to get organized and learn how to steer. What they couldn’t see was the missing paddle, the confusion about the equipment, and the fact that nobody had been given directions yet.

From a distance, a people problem and a structure problem look almost exactly the same. The difference isn’t what you observe on the surface. It’s what’s underneath, and getting to that takes more than a quick read from across the river.

What I’ve learned over the years is that talented people don’t consistently struggle in a system that’s working well. When good people are performing inconsistently, it usually means the system around them isn’t giving them what they need to succeed. If you look closely enough, you’ll often find that nobody gave them the basic tools to run the work, a RACI chart, a clear approval path, guidance on how decisions get made, the foundational structure that tells the team who owns what and how work is supposed to move from one stage to the next.

Without those things in place, even experienced people struggle, and from the outside, struggling looks a lot like underperformance.

Once you get those tools in place, watch what happens. Same team, same client, same deadlines, and suddenly the work starts moving the way it should.

Steps for leaders

• Before assuming a performance issue, do a quick audit of the infrastructure. Does the team have a RACI? A clear approval path? Written guidance for how recurring work gets done?

• Talk to the team directly and ask what’s slowing them down. The answers are usually pretty specific and almost always something a leader can quickly address.

• Build the missing tools or assign someone to build them. Don’t expect the team to construct the infrastructure while simultaneously trying to deliver on the contract.

• Once the tools are in place, revisit performance. If things improve, you had a structure problem. If they don’t improve, at least now you have much better information to work with.

• Revisit the infrastructure frequently, because what worked last quarter may not cover everything the team is being asked to do as client needs evolve.

Basic tools every program team needs

• A RACI chart. This spells out who is responsible for doing the work, who is accountable for the outcome, who needs to be consulted before decisions get made, and who just needs to be kept informed. Without one, tasks get picked up by whoever happens to notice them or quietly dropped because two people each assumed the other had it covered.

• An approval workflow. This lays out how a deliverable or decision gets signed off, including who needs to approve it and in what order. Without one, work sits in a holding pattern waiting for someone to realize it needs a decision, and deadlines slip for reasons that have nothing to do with how hard the team is working.

• Best practice guides. These capture how the work should actually get done day to day, not just what the contract requires on paper. They take what your most experienced people already know and put it somewhere a newer team member can actually find and use it.

• Standard operating procedures for recurring tasks. Things like travel approval requests, visitor request forms, conference presentations, and invoicing, all require SOPs to make sure they follow contract requirements and get done consistently, the same way every time, regardless of who happens to be handling them.

None of these are complicated to build, and what they all have in common is that they take the knowledge sitting in one or two people’s heads and put it somewhere the whole team can access it.

Getting the right structure in place from the beginning is the leader’s job, the same way reading the river and mapping the route was the guide’s job that morning. She didn’t just hand us paddles and wish us luck. She made sure we knew what we were doing and what to expect, and that warmth and preparation made all the difference in how the whole trip unfolded.

The team will tell you what’s broken. The leader is responsible for fixing it.