Don't Set Up ClickUp for Your Team (Do This Instead)

I used to think that the best way to roll out a new tool was to keep it simple: minimise disruption, concentrate ownership, and hand the team a finished system.

I was wrong.

After 14 years of rolling out ClickUp and other project management tools across teams under 50 people, I've noticed that the rollouts that actually stuck — where teams came to genuinely love the tool — all had one thing in common.

I didn't set up ClickUp for them.

I know that sounds counterintuitive. But stick with me, because it changes everything. I recorded a full breakdown video here if you'd rather watch than read — but this post will give you the full framework.

The Reframe You Need Before Anything Else

Here's the thing that most tool rollouts get wrong from the start.

Rolling out ClickUp is never just about the tool. It's a behaviour change project. Full stop.

Think about what you're actually asking people to do: check the tool instead of messaging you every 10 minutes. Write down key decisions instead of relying on verbal updates. Update their task status — consistently, correctly, without being nagged. These aren't technical skills. They're habits. And people have built those habits over years.

Understanding that you're trying to change behaviour is important. But it's not enough.

Most of us know that going to the gym is good for us. Some of us have even bought the membership. And yet. Knowing something is beneficial doesn't automatically make us do it. The same logic applies here: having ClickUp set up and having your team's buy-in on its benefits does not mean they will use it.

Behaviour change research is pretty consistent on this: people change when the benefit is obvious and the friction is low and something nudges them to start. You need all three. Not just the first one.

So the right question for any rollout isn't "did we implement the tool?" It's: "did we build the conditions for people to actually change how they work?"

These are completely different projects. And most rollouts only attempt to address the first one.

Why the Conventional Approach Has a 70% Failure Rate

There's research showing that around 70% of digital transformation projects fail. That number is not a coincidence.

Here's how most tool rollouts go: an external consultant (or an internal person with enough initiative) is tasked with setting up ClickUp. They map the workflows, build out the entire workspace, run a training session, and hand it over. Clean timeline. Clear deliverables. Feels efficient.

But it doesn't account for human nature.

The team inherits a system they didn't build. They don't fully understand how it works under the hood, so they can't maintain it themselves. Any change — a new hire, a restructure, a new workflow — and suddenly you need to call in help again. Remap the process. Redo the implementation. And in between those moments, people quietly slide back into old habits.

It's not that people are uncooperative. It's that the friction is too high, and behaviour doesn't change overnight. There's no such thing as a "clean rollout" when it comes to ClickUp. It will always be iterative.

To be fair — if you're implementing an ERP system for hundreds of people, there's almost no other way. The scale demands a centralised approach. But ClickUp teams are small. Hierarchies are flatter. People are more opinionated about how they work. And if the solution feels imposed rather than theirs, it won't last.

What Actually Works: The Coaching Approach

So after many rollouts across many different organisations, I've landed on an approach with by far the highest success rate.

I call it the coaching approach. And the core principle is simple: instead of building the system for the team, I build it with the team.

It's the old "teach someone to fish" idea — except applied to project management. Rather than handing over a finished ClickUp setup, I focus on teaching the key people — the changemakers within each team — how to set up ClickUp themselves.

Changemakers are usually the team lead of each function. If there's no clear team lead, it's the most technically confident person in that function. They become the internal experts. The owners. The advocates.

Here's the broad shape of how it works:

• I give them guardrails — which features to use, which to ignore for now. I deactivate anything that would create confusion. Each function gets a dedicated space they can configure autonomously.

• I run an initial training on what ClickUp is, how it works, and how to structure a space.

• I give each changemaker tailored suggestions for how their setup could look, based on their function and how their team actually operates.

• I define ownership, responsibilities, timings, milestones, and checkpoints clearly.

• And then I give them time to build it themselves.

Once they've built it, we work together to stress-test the setup and fine-tune. When we both agree the space is ready, each changemaker is responsible for onboarding their own team. They can ask me to sit in — or not. And then we reach our next check-in point, consolidate the feedback, and refine again.

It's a bit like university project work, minus the grades. (Thank god.)

The Four Things I Pay Attention To

My role in this approach isn't implementor. It's organisational coach for behaviour change — and that's not a passive role.

I think of it like being a football coach. Klopp or Guardiola don't play. The team does. But they decide who plays where and why. They design the game plan, run the training, and correct moves in real time.

That's exactly how I think about my four focus areas:

Positioning is about clarifying who owns what. Who trains whom. And — this is the part that surprises people — troubleshooting the underlying workflow before it ever goes into the tool. More often than not, I meet teams with either no clear workflow or one that's needlessly complicated. Both are a problem. If you try to translate a broken workflow into ClickUp, you just get a broken ClickUp setup. So we fix the workflow first, then the tool setup follows naturally.

Training means making sure people are genuinely equipped, not just given a one-hour onboarding and left to figure it out. That means tailored sessions based on someone's role — a changemaker who needs to understand the full structure has very different needs from a user who mostly needs to know how to assign and update tasks. I also maintain a shared resource library, keep a live FAQ document specific to that company's setup, and do one-on-one coaching where it's needed.

The Game Plan is about how ClickUp shows up in the company's actual day-to-day. I work with teams to create what I call "Ways of Working" — the agreed norms for how the tool gets used. How tasks get named. When statuses get updated. When something goes into ClickUp versus when it stays in Slack. And critically: how ClickUp gets embedded in existing meetings. Is it open on screen during standups? Is the weekly review run directly from the workspace? Getting the tool woven into existing rituals is one of the most underrated levers in a successful rollout.

Correcting is the ongoing work — and the part most rollouts skip entirely. I pay attention to drift. When task descriptions start going missing. When decisions aren't being recorded. When someone's reverting to the spreadsheet that was supposed to be phased out. Catching that early and correcting it quickly (without making people feel attacked) is what keeps the system alive. I also design periodic reviews with the team so they can make adjustments themselves over time. The system evolves alongside the team — which means it actually survives.

Why This Works (Beyond the Obvious)

People own what they build. When a team lead has personally set up their own ClickUp space, they have pride in it. They'll advocate for it. They'll onboard new team members into it without being asked. That ownership is incredibly hard to manufacture from the outside.

It also removes pressure from me in the best way. Team leads know their processes better than I ever could. I'm not coming in pretending to be a functional expert in their marketing workflow or their finance processes — I'm the ClickUp and change management expert, and they're the functional experts. Combining those two things builds trust on both sides.

There's also a psychological piece that's easy to underestimate. People get their backs up when someone external comes in to tell them how to do their job better. With this approach, I'm not doing that. I'm more like a friendly neighbourhood ClickUp consultant — there to support them, not to impose.

And practically: it saves significant time. In my experience, around 80% of teams under 50 people don't have their processes documented anywhere. If an external consultant is handling the implementation alone, they first have to capture all that knowledge — usually as SOPs — before building anything. That becomes very time-consuming, very fast. But if I'm working directly with team leads to recreate their workflows inside ClickUp, we skip that entire step. The tool becomes the documentation.

When I eventually step back, the knowledge stays in the organisation. Multiple people are trained. People hold each other accountable. And there's a continuous adjustment cycle baked in, so the tool and the processes around it actually evolve as the team does.

That creates a cultural shift. More people start examining their own workflows. They get comfortable combining process and tools. And at some point, you can't quite imagine going back to how things were before.

The Honest Trade-offs

This approach is not perfect, and I want to be clear about that.

It's messier. Different teams move at different speeds. Some team leads will nail their ClickUp setup in a week. Others will need three check-ins just to get their first list structure right. You have to be okay with that unevenness.

It takes longer to reach a "live" state than the conventional top-down approach. For a team under 50, expect at least three months.

It requires more from whoever is running the rollout — not just ClickUp knowledge, but the ability to coach, to read the room, to correct behaviour gently. It's not a junior role. Whether you're doing this yourself or bringing someone in, be honest about whether those skills are actually there.

And it requires genuine commitment from the team. Learning to set up your own space takes time and effort. It's more work upfront than inheriting a finished system.

But you're trying to change human behaviour. The mess is temporary. The efficiency gains and the cultural shift on the other side? Those are long-lasting. And in my experience, very much worth it.

One Last Thing

Everything in this post is anchored to ClickUp, but the same approach applies to any project management or team productivity tool. Asana, Monday, Notion, Linear — the principles transfer.

But here's the thing: this post isn't really about ClickUp. It's about what actually gets people to change how they work — and why handing someone a finished system almost never does it. The tool is just the visible part. The behaviour change is the whole project.

If you want to see how this plays out in practice — how to actually identify your changemakers, structure the rollout phases, and handle the people who are (let's be honest) going to resist the whole thing — STAY TUNED because I’ll be covering that in the upcoming post (or even better, subscribe to my Youtube channel 😉)