Think before you build: why we do pragmatic planning

Wasted engineering effort usually starts with: “We’ll figure it out as we go.” An engineer builds and shares something, and then the feedback lands: you forgot about x, it won’t scale because y.

By then, changing the written code is a mission. The team fumbles to patch a flawed foundation because the cost of starting again is too high.

You don’t avoid delay by skipping alignment — you just move the delay to the end of the project when it’s much more expensive to fix.

The cheapest time to think is before you build. That’s why we do pragmatic planning: it’s cheaper in the long run.

What pragmatic planning is (and isn’t)

Pragmatic planning is getting the right people together to map things out before writing a line of code. It maintains laser-focus on scoping the right thing to build.

It’s informal: one to two hours with a whiteboard. You think through the problem. What do you need to consider first? What are the impacts? What does a sensible API look like?

If you’re familiar with agile practices, it’s like swarming at a strategic level. (You’re figuring out the approach, not doing the work.)

It’s not dogmatic. There are no story points or heavyweight processes.

When to use it

Pragmatic planning is ideal for small, complex UI problems. It’s not for major architectural work or building a design system from scratch — those need more structure.

The scope might range from extending a component’s API to building v1 of a new component. The solution should be non-obvious but the scope nicely contained.

Usually there aren’t clear triggers. A good indicator is when your spidey-sense says “this is a problem — what have I done in the past?”

This ambiguity isn’t a bad thing. Rigid triggers would turn it into the kind of heavyweight process it’s meant to avoid.

Use it when it helps, not because you should.

How to do it

Here’s how we go about pragmatic planning.

1. Get the right people together

   Who do you need in the room? Participants will vary by task. Sometimes it’ll be obvious that it touches someone else’s work. Loop them in, or if they’re away, have a proposal ready for when they’re back.

   The pragmatic part is doing the best with what you’ve got. There’ll always be someone away or some other constraint. Don’t let it become a blocker.

2. Use a whiteboard

   Use a physical whiteboard. It stops people wandering off, physically and mentally. It’s an artefact you can come back to.

   If you need to meet remotely, use digital whiteboards. They’re less effective, but they’re better than chatting for an hour with nothing to focus on.

3. Make it useful

   Planning conversations tend towards idealised solutions. People drift towards the notionally perfect when they’re not yet dealing with real constraints.

   Take the opportunity to talk about trade-offs. What are you willing to compromise? What’s essential? Asking these questions now means fewer surprises later.

What success looks like

The advantages of pragmatic planning can be immediate.

Say you sketch out an API for your component and someone says, “that doesn’t really make sense — what about doing this?” The feedback loop is immediate, and it comes before you’ve built anything. You’ve moved the thinking up front rather than doing it once the work is done and the costs are real.

Sometimes you need to do the work to understand the problem space, and that’s fine. But when you can think it through first, you avoid that sunk cost.

Why it can fail

Pragmatic planning is hard if people aren’t empowered to solve problems. When Scrum or Scrum-like agile becomes ingrained, it’s more about getting work done than solving problems well. Pragmatic planning is about making the solution stick.

Practical blockers matter too. If you’re doing this in person, but don’t breakout spaces or whiteboards, that’s a challenge.

For distributed teams, tooling can be an issue. Zoom/Teams/Slack can sap humanity and spontaneity — screen-sharing shrinks faces to postage stamps and a lot of signal gets lost.

It’s easier in person, but not impossible remotely — especially with people who’ve done it together before. But with a new team, doing it in person is best. The informality gets people talking, and there’s more bandwidth for multi-way communication.

Build the habit

We’ve found that ingraining pragmatic planning is a bit like using sourdough starter. You build culture in an organisation by bringing a bit of culture with you. If one person has experience, there’s a pot of techniques they can introduce gradually.

If you build a positive culture, people will share their own techniques, and take away what they’ve picked up and apply it elsewhere.

You’ll see individual culture shape team culture and eventually the organisation’s culture — and without anyone having to channel influencer vibes.

Keep it simple

Pragmatic planning is fuzzy by design. It’s not a prescribed process with definitive entry and exit criteria. It’s a tool you reach for when it feels right.

You’ll come to know when upfront thinking saves more than it costs. It forces a moment of consideration. You might even avoid building something that doesn’t work at all. That’s an hour or two very well spent.