Nice notebook, shame about the method

Containers and rules: a better way to think about work

Some years ago I found myself in the business-class lounge at Heathrow for the first time, and I want to be honest about how much it meant to me. A client had agreed to a business-class British Airways ticket – they didn't even flinch at my nervous ask for the upgrade, just said "fine, no problem" – and now here I was; posh showers and clean toilets; a free buffet; reclining armchairs the size of a my first car. It was great. I was drinking a glass of champagne at an unwise hour too. I was, frankly, smitten.

I pulled out a notebook to make a small note about the whole fabulous, wonderful moment. And a voice to my left said: "Nice notebook — shame you're not doing bullet journaling, though."

Half compliment, half criticism, delivered with the remarkable confidence of someone for whom bullet journaling was not a method but the one true way of life. I smiled, passed a few pleasantries, and spent the flight mulling it over – not the notebook, the assumption. Because she'd accidentally put her finger on something I'd been pondering for years: about notebooks and productivity systems and the vast, unending battle riddled world of work-management software, and why we argue about all of it so much, and so pointlessly and with so much passion.

You see, a notebook is a container. Bullet journaling is a set of rules for how work and information moves through it. And that – a container, and some rules – turns out to be what every productivity system on earth actually is, whether it's a tidy dotted-grid journal, my scruffy field notes book, or the £2m enterprise platform a company on floor three are arguing about buying.

Because we do argue. I once sat in a meeting where one half of the room held strong opinions about one tool and the other half held equally strong opinions about a rival that did, as far as anyone could tell, precisely the same job. Both were flexible where it mattered, both were perfectly good, and the two camps annoyed each other for a full hour, which is what people with strong opinions tend to do. All delivered with the gusto of people defending a preference they've mistaken for a principle.

Not once did anyone ask what the tool was actually for – which is simply to hold the activity set, and work needed, to take an idea and turn it, through the effort of the people involved, into something worth having. That's the whole job of the thing. And there we were, on a wet Tuesday in London, arguing about the box instead of what goes in it, and what's supposed to come out the other side. The same mistake, exactly, as the woman in the lounge.

Once you see work as containers and rules, you can't unsee it, and it fundamentally changes the questions you ask.

A container is just the place where work is represented — a Kanban board showing it in flow, a Gantt chart spreading it across time, a calendar slotting it into hours, a to-do list holding it as a list, a notebook catching it before it escapes. The work itself never lives in any of them; what lives there are labels and states and notes and models, a picture of the work rather than the work. Which sounds like a technicality or label until you notice why it matters: the container's entire value is that it makes work visible, and you can't prioritise, compare, or safely let go of a thing you can't see.

The rules are how work moves through the container, and they matter every bit as much – they decide how a thing starts, progresses, waits, expands, is shared and counts as finished. On a board, a rule might cap how much can be in progress at once. In a calendar, a rule might defend certain hours for thinking rather than meetings, and the obvious one, you can't be in two places at once. In a bullet journal, the little symbols, method and process are the rules.

And here's the part most people miss: the rules very often don't live in the tool at all. They live in us – in our habits, routines, our ways of working, the agreements we make as a team. A good container with bad rules is just an expensive data repository. Good rules save you from renegotiating the way value is created every morning; without them, every task is a fresh decision on what to do with it, and you spend your best attention deciding instead of doing.

Strip the branding off any of it – the certifications, the methodologies, the app of the month, the all in one paper planner – and every system is aiming for the same modest handful of things: make the work visible, help you choose what matters, show you when something's actually done, and help ideas become value. That's it. Which means the question is rarely "which tool is best?" It's the far more useful, remarkably less exciting one: do these containers and rules actually help the work flow and fit who we are?

And once that's the question, a few simple ones tend to follow.

The most obvious reason any system fails to help you isn't the tool; it's that not all the work is in it. Half of it is sitting in an inbox, a chat thread, a conversation you half-finished, someone's head, a post-it note on your monitor. So the container shows a partial picture, decisions get made on it anyway, and things get dropped or duplicated because nobody could see the whole. Invisible work is simply unmanaged work, and putting it where it can be seen isn't admin at all – despite what many people will say – it's respect for everyone's finite resources of time, energy and attention, your own included.

Then there's the mess that appears the moment work crosses a boundary to someone else, which it always does in workplaces. Organisations collect containers the way the rest of us collect notebooks – every team brings the tool it knows, each with its own rules, each with it's strong opinions on why it's better than everything else — and it all holds together right up until a piece of work has to travel between them. At which point friction accumulates, and the usual fix is to pile another container on top: a dashboard, a weekly update, a report, another tool that ingests stuff from every other tool, sometimes a whole person whose entire job is to translate between systems that won't speak to each other. I've watched companies hire small armies to reconcile data between tools all week, every week, producing reports already out of date by the time anyone reads them. Nobody ever seems to ask the obvious thing: do we actually need this many containers?

And do the rules serve the work? A deeply fascinating question to sit with. Systems get installed before the problem's understood, tools get chosen because everyone else has them, methods get copied without anyone checking the method will solve the problems we have (if we've even taken the time to identify that), software gets bought because the vendor said it would improve everything, like everything, it will, really. It rarely does.

The order, probably, should run the other way: study the work first, then design the system for it. I once worked with a Scrum Master who wanted to change a process that was working perfectly well, for the sole reason that it didn't match the Scrum guide closely enough. No evidence anything was wrong – in fact, the evidence pointed entirely the other way – the team was delivering, the system was working, value was being shipped often. His objection was theological, not practical, and we kept the rules that fit our actual world rather than someone else's certificate. Which is nearly always the right call, and worth holding the line on.

All of which leads us at something that's embarrassingly simple. Pick one main container. Put the work in it. Create rules that support you. It won't be perfect – nothing is – but one container everyone understands and actually uses, with rules that reflect how the work really moves, will outperform six beautifully integrated systems nobody fully trusts, every time. Especially when we need 10 people just to get them to talk to one another.

Coherence beats fragmentation. Clarity beats cleverness. The strongest teams I've seen weren't optimising their tools; they were optimising their understanding, which is always cheaper and a typically a great deal rarer.

Because productivity is not about collecting systems, personal or otherwise. It's about getting things done. It's about making the work visible, agreeing how it moves, and then trusting the thing enough to look away from it and back at the value it was only ever there to serve.

Find the container and the rules that fit how you work. Then stop fiddling with them. The woman in the lounge had found hers, which was, in fact, wonderful for her. She'd just mistaken it for everyone else's.