Containers and Rules: A Better Way to Think About Productivity

Containers and Rules: A Better Way to Think About Productivity

Every few years, a new productivity system arrives with the promise that this one will finally fix things.

The tool changes. The branding changes. The conference talks change. What stays the same is the cycle: adoption, hope, partial implementation, quiet abandonment, and the search for the next thing.

I've watched organisations spend six figures on software that solved nothing, because the problem was never the software. I've watched individuals spend more time configuring their task manager than doing the work it was supposed to support.

Here is the idea I keep returning to, because it cuts through almost all of it:

Every productivity system — every single one — is just two things.

A container. And a set of rules.

That's it. Once you see it, you can't unsee it. And once you can't unsee it, you stop chasing tools and start asking better questions.

What a container really is

A container is the place where work lives — or more precisely, where work is represented.

A Kanban board is a container that shows work in flow. A Gantt chart is a container that maps work across time. A calendar is a container where work is scheduled. A to-do list is a container that holds tasks. A notebook is a container that captures intentions.

The work itself doesn't live in any of them. What lives there are labels, notes, priorities, states — representations of work, not the work itself.

This matters because containers make work visible. And what we can't see, we can't manage, prioritise, or compare. The value isn't in the tool. It's in the visibility the tool creates.

What rules really are

Rules define how work moves through the container. They decide how things begin, progress, pause, and finish.

On a Kanban board, rules might limit how much work can be in progress at once. In a calendar, rules might protect certain hours for thinking rather than meetings. In a project plan, rules define handovers, ownership, and what done actually means.

Good rules reduce the need to renegotiate reality every day. Without them, every task becomes a fresh decision. With them, the system does the deciding and your attention goes elsewhere.

This is why rules matter as much as the container. A well-designed container with poor rules is just an expensive to-do list.

What every system is actually trying to do

Strip away the methodology branding and every productivity system is attempting the same small set of things:

Make work visible. Help you choose what matters. Show you when something is finished. Help ideas become value.

That's the whole job. Which means the real question is never "which tool is best?" It's always: do these containers and rules actually help work flow?

Is all the work in the container?

The most common reason productivity systems don't work is simple: not all the work is in them.

Tasks live in inboxes, in chat threads, in half-finished conversations, in someone's head. The system shows a partial picture. Decisions get made on incomplete information. Things get dropped, duplicated, or quietly deprioritised because nobody can see the whole.

Invisible work is unmanaged work. Making work visible isn't administration — it's respect for everyone's reality, including your own.

Do the containers talk to each other?

Organisations accumulate containers almost by default. Each team adopts the tool they know. Each tool has its own rules. This works reasonably well until work crosses boundaries — which it always does.

Then leaders lose sight of progress. Teams lose coherence. And the typical response is to layer another system on top: a reporting dashboard, a weekly update meeting, a PowerBI report, a programme manager whose entire job is to translate between containers that don't speak to each other.

I've seen companies hire small armies of project managers to do nothing but reconcile data between systems. All week, every week, generating reports that are usually already out of date by the time they're read.

At some point the question has to be asked: do we actually need this many containers?

Do the rules serve the purpose?

Systems are often installed before problems are understood. Tools get chosen because others are using them. Methods get copied without examining whether the context matches. Software gets bought in the hope that the right behaviour will follow the purchase.

It rarely does.

The order matters: first study the work, then design the system. The question is always the same — do these rules help ideas become value, or do they merely create motion?

I once worked with a Scrum Master who wanted to change a process that was working well because it didn't align closely enough with the Scrum guide. There was no evidence anything was wrong. The team was delivering. The system was clear. His objection was philosophical, not practical.

We'd built rules that worked for our actual context, not rules that matched someone else's certification scheme. That's often the right call — and it's worth defending.

The power of coherence

There is a radical simplicity in choosing one primary container and placing all work into it.

It will never be perfect. No tool is. But coherence beats fragmentation almost every time. Clarity beats cleverness. The best organisations don't optimise tools — they optimise understanding.

One container, understood by everyone, consistently used, with rules that reflect how work actually moves: that will outperform six beautifully integrated systems that nobody fully trusts.

A gentler definition of productivity

Productivity isn't about collecting systems. It's about creating clarity, building alignment, generating momentum, and releasing value.

When containers make work visible and rules help it flow, attention is freed to go where it belongs: to the work itself.

Find containers and rules that genuinely serve your work. Then trust them. Then return your attention to what they were designed to support in the first place.