The Timebox

About

FatBeehive is a digital agency working with charities and nonprofits. The clients are mission-driven, the budgets matter more than most, and every hour billed is an hour the cause doesn't get to spend somewhere else.

When I joined as UX & Strategy Lead, I wasn't asked to design anything. I was asked to investigate. The brief, on the surface, was simple: figure out why projects keep running over. The reality, once I started looking, was that they weren't running a bit over. They were running 80% over, on average.

For an agency working with cause-led clients, that's not just a financial problem. It's a sustainability problem, for both sides.

Challenge

The pattern was easy to see in the numbers but harder to explain in the standups. Nobody was slacking. The team was working hard, and the work itself was good. But every project, sooner or later, blew through its budget by roughly the same margin.

At first glance this looks like an estimation problem: people are quoting too low. But the team had been doing this for years. Their estimates weren't naive. The deeper question was what made the actual work take so much longer than the planned work, consistently, across very different projects.

Investigation

I spent the first weeks doing what I usually do at the start of work like this. I observed.

I sat in on standups across teams, looked at retrospectives, talked to designers and project managers individually, reviewed how time was being logged and where it was being lost. I looked at how projects flowed end to end, what happened at handovers, what 'finished' actually meant on a given day.

What I was trying to find wasn't a single broken step. It was the texture of the working day, the bit that doesn't show up in a Gantt chart. Where designers actually spent their cognitive effort, not just where the clock said they were.

The methods were familiar from my research practice: lots of open observation first, then targeted interviews to test what I was seeing, then a pass through the timesheet data to check whether the patterns I'd noticed in conversation also showed up in the numbers. They did.

Diagnosis

The pattern that emerged was about context, not capacity.

Designers were carrying too many active projects at once. The agency model rewarded high concurrency: keep everyone billable across multiple clients, fill the calendar with blocks of an hour here and ninety minutes there. That looked efficient on paper. In practice, every time someone switched from project A to project B, they paid a cost: rereading the brief, recovering decisions, finding their place in a Figma file they hadn't opened in three days.

That cost is invisible. It doesn't show up in any timesheet, because the time spent re-orienting is logged against the project that was switched into, not against the cost of leaving the previous one. But across a team, across a month, across a portfolio of charity projects, it added up. And when I worked through the maths, the gap it accounted for looked very close to the 80% overspend the agency was seeing.

The hours-centric model wasn't wrong on its own terms. It was wrong about what it was actually measuring. It counted minutes in a calendar, not minutes of effective work.

Proposal

I proposed a different model: timeboxing.

Instead of fragmenting designers across many concurrent projects, run fewer projects at once, but run them in dedicated timeboxes. A small team commits a defined block of working time to a single project, finishes that scope, and only then moves on. Less concurrency, more focus. Less context-switching, more momentum.

The argument I made wasn't speculative. It was the inverse of the diagnosis. If context-switching is what's costing 80%, then removing context-switching is what gets most of that back. The maths follows the structure of the problem.

The trade-off this asks an agency to accept is a hard one. It looks, on the surface, like the team is doing less. Fewer projects in flight at once. Calendars that aren't fully booked across multiple clients. The gain only shows up when you measure outcomes per pound, not hours per week. That's a different way of running a services business, and the case I built had to make that shift legible to leadership before any of the operational changes could land.

Impact

The benefit of timeboxing, when it works, accrues to everyone in the chain. The agency stops eating overspends. The clients, who are charities running on tight budgets, get more of what they paid for and get it sooner. The designers themselves stop losing their working day to re-immersion and stop arriving at 5pm wondering where it went.

The deeper outcome of this work, for me, was a different one. It clarified that the most useful design skill I have isn't always design. It's the willingness to sit with an operational pattern long enough to see what's underneath it, and then make the case for changing the thing that's actually wrong rather than the thing that's most visible.

Reflection & what's next

What this project clarified for me is that the most valuable work I do is sometimes not design at all. I was asked to come in and investigate, and what the work needed wasn't a Figma file or a wireframe. It was someone willing to sit with the operational pattern long enough to see what wasn't on the timesheet.

Where I'd push harder next time is on the change itself. Diagnosing the problem was the easy part once I knew where to look. Getting an organisation to commit to a different way of working, against the gravity of a model that's been profitable for years, is a different job entirely. The case has to be made not once but repeatedly, in different rooms, to people whose incentives don't all point the same way.

What I'm carrying forward is a clearer sense of where I want to operate. I want roles where the brief is allowed to expand into the operational layer when that's where the answer is, not just the screen. That's the kind of role I'm looking for next.