The Upstream Leadership
Team Performance Fixer

The 3-part framework for solving team performance problems.

Team performance problems are frustrating to solve, in part because the most obvious diagnosis is rarely where the problem started. The real source and the fix are almost always upstream. Part of the Upstream Leadership™️ practice. For founder-led service teams in the $2M to $6M range.

Karen Sergeant

Karen Sergeant is the creator of Upstream Leadership™ and a fractional and advisory COO for owner-led B2B service teams.

"They're just not accountable."

You've said it, or thought it, about the team member who keeps missing their deadlines, or who turns in work that isn't close to what you asked for. You've given them the task and told them when it's due. They keep under-delivering. You're mystified, frustrated, and looking for answers.

I've heard every version of this problem from founders over the years. It often comes with a lot of emotion and exasperation — and a verdict already formed.

Yet what I've found, consistently, is that the "they're just not accountable" diagnosis comes too quickly.

The performance conversation feels like the obvious next step. It usually isn't.

We have to go digging, first.


Why You Can't Call It an Accountability Problem (Yet)

Accountability is actually the last in a chain of three steps that need to be in place for good work to get done. And it can only do its job properly when the other two are in place.

If they aren't, you're probably not looking at an accountability problem. You're looking at something that merely showed up as one.

The two steps are transparency and agreement. If either is missing, that's where the problem is, and the fix is different from the conversation you're gearing up to have.

Here's how each one works.


Transparency, Agreement, Accountability

The three operating principles run in sequence: each one sets up the next. They apply everywhere in your business — quarterly priorities and individual tasks, big project handoffs and small daily asks. Anywhere work moves from one person to another, all three need to be in place.

Transparency: Make expectations and constraints explicit.

When "done well" lives only in your head, the team has no reliable way to perform against it. They can't see your quality bar, your format preferences, your timing expectations, or the small things you'd notice immediately if they were off. So they make their best guess, turn in the work, and find out later whether they guessed right.

This isn't carelessness on your part or theirs. It's the natural residue of your early-stage business — when it was all you, or people with daily access to you, getting work done. Learning to articulate goalposts before the work starts is a skill, and it's one you absolutely need to develop.

The right move is to make all expectations visible: specs, standards, style, constraints — whatever you're using to evaluate the work needs to exist somewhere the team can reach it without asking you first.

This is the necessary first step. The next one confirms that everyone is on the same page.

Agreement: Build explicit buy-in, not assumed compliance.

Putting a name on a task with a due date and moving on is throwing it over the wall. The person receiving it has their own workload, their own competing priorities, and possibly several other people tasking them at the same time. You can't see any of that from where you're sitting.

The Team Performance Fixer Framework

Real agreement means giving the person a genuine opportunity to review what's being asked, confirm they have what they need, and say yes to the timing after factoring in everything else they're carrying. That yes has to be earned through actual back-and-forth — and it has to include the real right to push back on any part of the ask, including the due date. It doesn't have to be a lengthy or convoluted process, but it does need to be baked into assignments large and small.

This informed consent is a different animal from an assumed yes. It is the necessary ingredient for accountability to land on something real.

Accountability: Do what you said you'd do.

Accountability is the simplest of the three to define: do what you said you'd do, by when you said you'd do it. And now, with transparency and agreement in place, you've removed the two upstream sources of the problem. If the work is still not coming in on time or on spec, now you're looking at something real — a performance issue or an accountability issue — and at that point, you know exactly what you're dealing with.

Since accountability means honoring the agreement made, it runs both ways. If you change the spec after agreement was reached, you owe the team a new agreement cycle. No fair changing the goalposts without getting people back on board.

That's the framework. Here it is in client work.


Where This Helps

It helps when your team can't make a decision without you.

The complaint: A client of mine had her customer service team forwarding complaint emails to her with "what would you like to do here?" as the entire context. Every email meant reading the full thread herself, then going back to her team with questions about the customer history, the order, whatever wasn't in the email. It was eating her day in tiny bites.

The transparency fix: A short template her team filled in before forwarding — different questions for different kinds of complaints. Customer, order, what had already been tried, what the customer wanted. With the situation laid out up front, she had what she needed to decide the moment the email landed.

It helps when you keep finishing your team's work.

The complaint: Another client was getting briefs from her team that were pretty good — but always had formatting issues, the occasional typo, and details that hadn't been coordinated with the other team members involved. She'd been quietly fixing all of that herself, every time, for so long it didn't register as her doing the team's work anymore. It was just her routine.

The transparency fix: A five-item checklist the team had to confirm before submitting a brief: format, proofread, coordination with the people who needed to weigh in, the deadline, the destination. The team member had to state explicitly that they'd run through it. With her quiet standards finally on the page, the cleanup she'd been absorbing dropped off — the team was now checking for those things themselves.

It helps when "she should know" isn't enough.

The complaint: A client hired a senior person specifically because she was experienced enough not to need hand-holding. Thirty days in, the new hire wasn't meeting the company's expectations for project timing. My client framed it as a performance issue — she'd hired senior to avoid this kind of thing.

The transparency fix: When we dug in, what we found was that the company had its own rhythm for project milestones, and that rhythm had never been communicated to the new hire. She was a professional, she'd done this kind of work before, and she had her own sense of pacing — but she had no idea the company expected something different. It was a silent yardstick. A single conversation — here's how we time projects and why it matters — and the issue resolved itself.

It helps when due dates keep slipping despite plenty of runway.

The complaint: A client came to me with what looked like a textbook accountability problem. One of her team members was getting tasks assigned in the project management tool — well in advance of the due dates — and missing them anyway. The tasks would sit there untouched until the day they were due, at which point the team member would realize she had questions or didn't have what she needed. By then, late was already inevitable.

The agreement fix: A dedicated half-hour each morning for the team member to review newly assigned tasks. The deal: a thumbs-up in the software meant "I've read this, I understand it, I have what I need, and I agree to the date." Anything other than a thumbs-up triggered a question in the task before the deadline got close. That single thumbs-up was the moment of real agreement the previous setup had never asked for — and once it existed, she was significantly more invested in following through on what she'd said yes to.

Anywhere you catch yourself thinking "they're just not delivering" — or worse, "she's just not the right fit" — that's your cue to run the framework first. More often than not, what looks like a personnel problem is a transparency or agreement gap that hasn't been closed yet. Close it, and most of the time the work starts showing up the way you wanted.


Either It Solves the Problem, or It Isolates It

Running the framework on a performance problem leads to one of two outcomes, and both of them are useful.

Most of the time, the problem dissolves. The work starts coming in on time and on spec, and what was being called an accountability failure turns out to have been an unclear standard, a deadline that was never truly agreed to, or a spec that lived only in your head.

Once those upstream gaps close, the performance conversation never needs to happen.

And, sometimes the problem doesn't dissolve. The specs are clear, the agreement are real, the person has what she needs — and the work still isn't there. But now you know what you're dealing with. Every upstream explanation has been eliminated — and what's left is a real performance issue that you can now address.

Either way, you have an answer you didn't have before — and a clearer next move.


Where to Start

Start where the friction is loudest. You probably already know where that is — the handoff that keeps coming back, the team member you keep finding yourself fixing for, the recurring conversation that ends with you doing the work yourself.

Take that one spot and run the framework through it. Ask yourself two questions:

Area alls expectations explicit? Or have you been holding them in your head and asking your team to read your mind?

Did the person actually agree to what they're being held to — with full visibility into their own workload — or was their name added to a task and the agreement assumed?

If the answer to either question is "I assumed," you've found the place to start. And in all likelihood, you've found the problem.

You don't have to fix everything at once. Start with the friction you can already feel, get the framework in place there, and let it compound. The work of making your standards explicit and your agreements real isn't quick, but it pays back faster than most of what you've tried — and the rest of the team, and the rest of your week, starts to come back into focus.