How I Use Notion to Organize Thinking, Not Tasks

Names and details have been changed. The situations are real. The people are not the point.

The problem with most productivity systems

I use Notion as a thinking system, not a task manager. Four stages (capture, process, decide, act) turn scattered thoughts into clear decisions. The system feeds directly into architecture reviews, hiring plans and team roadmaps. Here’s how it works and why most productivity setups miss the point.

It was a Monday morning in January. Q1 had just started, and work was dense. A replatforming project, two new hires onboarding, a roadmap review due that week. I opened my laptop, pulled up my task list, and stared at it. Everything was there. Every ticket, every deadline, every dependency, neatly tagged and colour-coded. And I had absolutely no idea what mattered. The list was complete and completely useless. I could see thirty things I needed to do. I couldn’t see which five would actually move anything forward. I closed the laptop, went to make coffee, and stood in the kitchen thinking: the system isn’t broken. The system is the wrong system. I’d built something that tracked tasks but never made me think about them.

Every few months, someone on my team sends me a “life-changing” productivity setup. A Notion template with 47 linked databases. A second brain in Obsidian with colour-coded tags. A Getting Things Done implementation so thorough it needs its own getting-started guide. I appreciate every one of those messages. They come from people who found something that works for them and want to share it. That generosity is real, even when the system isn’t right for me.

They all share the same flaw. They optimise for output. More tasks completed, more items checked off, more things captured and categorised. The assumption is that if you can just organise everything, clarity follows.

It doesn’t.

The problem isn’t organisation. The problem is thinking. Most productivity systems skip the hard part, the messy uncomfortable work of sitting with a problem until you understand it, and jump straight to execution. You end up efficiently doing the wrong things. The same principle applies to how I choose restaurants in a new city. The ones with the longest menus are usually the worst. Clarity comes from constraint, not from options.

I needed something different. Not a better task manager. A thinking system.

Why Notion specifically?

Before I explain how this works, I want to be clear about something. Notion is incidental.

The system I’m about to describe would work in Obsidian. It would work in a paper notebook. It would work in a spreadsheet, a folder of plain text files, a whiteboard on your wall. I’ve run versions of it in most of those.

Notion happens to fit how my brain works. Databases give me structure without rigidity. Pages give me space for depth. Links let me connect things across contexts. I can zoom out to see patterns and zoom in to think through specifics without switching tools. That matters more to me than any individual feature.

But the principles are what matter. If you read this and immediately start recreating my Notion setup, you’ve missed the point. Understand the system first. Then pick whatever tool lets you actually use it.

What are the four stages of a thinking system?

My system has four stages. Everything I capture moves through them, in order, at its own pace. Some things move through in a day. Some take weeks. Some get discarded halfway through. That’s fine. Not everything deserves to survive the process.

Capture

The first rule: get it out of your head. The second rule: don’t try to organise it when you capture it.

This is harder than it sounds. My instinct is to file things immediately, to decide as I’m writing something down where it belongs and what it means. But that instinct is the enemy of good capture. The moment you start filtering, you start losing things. Ideas that feel unimportant in the moment turn out to be important a week later. Observations that seem disconnected turn out to be the same problem wearing different clothes.

So the inbox is messy. Voice notes, half-formed thoughts, links, screenshots, quotes from conversations. No tags, no categories, no hierarchy. Just raw material.

Process

Once a week, I sit down and go through everything in the inbox. This is the weekly review, and it’s the most important habit in the system.

Processing means asking two questions about each item. First: what does this relate to? Sometimes the answer is obvious. A note about a technical decision relates to the project it concerns. Sometimes the connection is surprising. A frustration I wrote down about a meeting turns out to be the same communication pattern I noticed in a code review. Those connections are the whole point. It’s like discovering that two streets you walk every day in London actually connect through a courtyard you never noticed.

Second: is this actionable? Not everything is. Some things are observations. Some are questions I don’t have enough context to answer yet. Those go into the Thinking Log, timestamped entries on problems I’m working through, where they sit until I have more to say about them.

The things that are actionable get moved forward. The rest get connected, filed or deleted.

Decide

This is where most systems fail. And where mine earns its keep.

Having a clear list of actionable items isn’t enough. You need to decide which ones matter right now. Not which ones are urgent. Urgency is usually someone else’s priority leaking into your week. Which ones actually move things forward.

I use two lenses. The first is a simple priority matrix: important and urgent, important and not urgent, urgent and not important, neither. Most people know this framework. Very few actually use it honestly. It’s uncomfortable to admit that something urgent isn’t important, especially when someone is waiting on it. I’m not always honest about this either, if I’m being real.

The second lens is energy mapping. I know when I think best. Mornings, before the day fragments into meetings and messages. I know when I’m good for execution. Afternoons, once the thinking is done. I know when I’m useless for anything demanding. Late evenings, Fridays after a long week. Matching work to energy isn’t a productivity trick. It’s honesty about how I actually function.

Act

The whole system exists to make this stage boring. If I’ve captured everything, processed it, decided what matters, then acting is just following through.

One thing at a time. Finish it or consciously stop it. Ship, then next.

The temptation is always to run multiple things in parallel. Start three tasks, switch between them as energy fluctuates. That feels productive. It isn’t. Every switch has a cost, and the cost isn’t just time. It’s clarity. You lose the thread of what you were thinking, and you have to rebuild it every time you come back. I’ve gotten better at resisting this but I still catch myself doing it more than I’d like.

So the act stage is deliberately simple. A short list. No multitasking. The constraint is the feature.

What does my Notion workspace look like?

The theory is nice. Here’s what it looks like in practice.

Four main databases.

Reading List. Everything I want to read, with a status column: to read, reading, finished, abandoned. Each entry has a page where I write notes as I go. Not summaries. Reactions. What I agree with, what I disagree with, what changes how I think about something I’m working on. If I finish something and have nothing to write, it probably wasn’t worth reading.

Thinking Log. Timestamped entries on problems I’m actively working through. Not tasks. Problems. “How should we structure the platform team?” is a Thinking Log entry. “Hire a platform engineer” is a task. The log captures reasoning as it evolves. I can look back at an entry from three weeks ago and see how my thinking has changed. That context becomes invaluable when I eventually make a decision, because I can trace how I got there instead of just defending where I ended up. One entry from last autumn is just three lines: “The team keeps asking for more process. But the real problem isn’t process. It’s that they don’t trust the priorities. Process is the symptom.” I came back to that note six weeks later when I was preparing for a roadmap review, and it completely changed what I presented. I stopped adding process. I started explaining the why behind the priorities. The noise dropped within two sprints.

Decision Record. Every significant decision gets an entry. The format is consistent: context, options considered, decision made, reasoning, and what would make me revisit it. This isn’t bureaucracy. It’s insurance against the moment, three months from now, when someone asks “why did we do it this way?” and nobody remembers. Last spring a stakeholder pushed to revisit a build-vs-buy decision the team had made in Q4. The conversation was heading toward reopening the whole thing. I pulled up the Decision Record entry. The context was there. The options we considered were there. The reasons we chose to build were specific: the vendor’s API didn’t support our auth model, the migration cost was higher than the build estimate, and the team had domain expertise the vendor couldn’t match. Fifteen minutes of reading that entry saved us from a month of re-evaluation.

Project Board. The closest thing to a traditional task manager. Projects with status, priority, a linked page for notes and subtasks. But the board is downstream of everything else. Things only land here after they’ve been through capture, process and decide. The board is never the starting point.

The whole thing isn’t pretty. The databases have too many properties. The views are utilitarian. There are pages with three lines of text and pages with three thousand words. Doesn’t matter. The system is functional, and functional beats aesthetic every time.

The weekly review

Sunday. Thirty minutes. Coffee. No distractions.

This is the keystone habit. Everything else can slip. The inbox can overflow, the project board can get stale, the decision record can fall behind. As long as the weekly review happens, I can recover.

The process is the same every week.

Go through the inbox. Process everything. Delete what doesn’t matter. Connect what does.

Update the Thinking Log. What did I learn this week? What changed? What questions am I sitting with?

Review priorities. Look at the project board and ask: is this still the right order? What happened this week that changes what I should do next week?

Plan the week ahead. Not a detailed schedule. Three to five things that matter.

That’s it.

One Sunday in March, during the review, I noticed something I’d missed all week. Two separate inbox items, one about a recurring deploy failure and one about a team member’s frustration with the release process, were the same problem. The deploy failure was a symptom. The frustration was the signal. If I’d handled them separately I would have fixed the pipeline and missed the real issue: the team didn’t have ownership of the release process. That connection only surfaced because I sat with both items side by side, outside the noise of the working week. I restructured the on-call rotation the following Monday. The deploy failures dropped. The frustration disappeared.

The weekly review isn’t a productivity ritual. It’s a gift I give myself — thirty minutes of quiet before the week starts pulling me in every direction. The output isn’t a task list. The output is clarity. When I sit down on Monday morning, I know what matters and why. That’s worth thirty minutes.

How does this connect to engineering leadership?

I didn’t build this system because I’m an engineering lead. But being an engineering lead is why I can’t function without it.

An engineering lead who can’t organise their own thinking can’t organise a team’s priorities. If my head is full of unprocessed noise, I make worse decisions about what the team should work on. If I haven’t thought carefully about a technical direction, I give vague guidance that wastes people’s time. If I haven’t structured my reasoning before an architecture review, I end up reacting to what other people present instead of driving the discussion where it needs to go. Does that matter if you’re smart enough to improvise? Yes. Because the people in the room deserve your preparation, not your performance. I’ve been in that position before. It doesn’t feel good.

The system feeds directly into my work.

The Thinking Log is where I prepare for architecture reviews. I write through the problem before the meeting, so I arrive with a position instead of an open question.

The Decision Record is how I structure feedback. When I tell someone “we should do X instead of Y,” I can explain the reasoning, not just the conclusion.

The weekly review is where I plan hiring. Not the process, the thinking behind it. What capability is the team missing? What would change if we had it? Is this a hire or a skill-development problem? This pairs with how I approach agile. The thinking system feeds the team process, not the other way around.

The Project Board is how I decide what the team works on next quarter. By the time I present the roadmap, I’ve already worked through the priorities in my own system. The conversation with the team is about refinement, not discovery.

This isn’t separate from the work. It is the work.

The honest part

The system breaks down every few months.

The inbox overflows. I stop doing the weekly review because a deadline is consuming all my time. The Thinking Log goes untouched for three weeks. The Decision Record falls behind, and I make two important decisions without writing them down.

This used to bother me. I’d see the mess, feel the guilt, try to fix it all at once in a marathon catch-up session that took hours and felt exhausting. Then I’d be diligent for two weeks before the cycle repeated.

Now I think about it differently.

The system isn’t the habit. The habit is coming back to it. The inbox will overflow. Fine. The weekly review will get skipped. Fine. What matters is that when things calm down, I sit back down and start again. Not from zero. The structure is still there. I just need to clear the backlog and reconnect with what I was thinking.

I don’t have this figured out. I probably never will. Nobody told me that was an acceptable answer when I started leading teams. But I’ve stopped expecting to.

Perfection isn’t the goal. Clarity is.

I structure the problem before I touch the solution. Alone first, then together. That principle doesn’t require a perfect system. It requires a system I keep returning to. Claude Code fits into this workflow as the execution layer. Once the thinking is clear, delegation to AI becomes straightforward.

This is mine.