Building a workflow stack without collecting tools
Five stages, one tool each, and one rule about replacement. Most stacks are not too small. They are too overlapping.
Nobody sets out to own eleven productivity tools. It happens one reasonable decision at a time, and each decision is defensible on its own.
The five stages
Work of almost any kind passes through the same five stages on its way from a thought to a finished thing. They are not a methodology and there is nothing proprietary about them. They are just the places where work can get stuck, and naming them is useful because it gives you somewhere to put each tool you own.
Capture
Getting the idea, the message or the recording into a system at all, before it evaporates. The only requirement is speed. A capture tool that is slow is a capture tool you route around.
Process
Turning raw input into something you can act on: sorting, tagging, deciding what it is. This is the stage people skip, and skipping it is why capture systems fill up and stop being trusted.
Create
Producing the real output. The document, the reply, the piece of work someone else reads. This is the only stage that generates value; the other four exist to protect it.
Automate
Removing repeated manual steps, once the process has stopped changing. Late by design. Automating an unstable process encodes a rule that is still moving.
Review
Noticing what went wrong and deciding what to change. The stage with no immediate payoff, therefore the first one dropped, therefore the reason stacks drift out of fit without anyone noticing.
The point of naming them
Not to add ceremony. To make it obvious, when you are about to adopt something, which step it lands on and what is already standing there.
One tool per stage
The rule we would defend is simple to state and uncomfortable to apply: one tool per stage, and adopting a new one means naming the one it replaces.
Not “complements”. Not “is better at some things”. Replaces, with a date after which you do not open the old one. If you cannot name that tool, you are not improving the stack. You are adding to it, and the addition will be paid for at every future decision about where something goes.
The rule is not really about tidiness. It is about a specific cost that grows non-linearly: every additional tool at a stage adds a decision to every item that passes through that stage. Two note apps do not mean twice the capacity. They mean that every note now carries the question of which one it belongs in, and that question is asked far more often than either app is opened.
The overlap tax
Most people assume the problem with their stack is a gap. In our experience the problem is nearly always an overlap, and it presents as three specific symptoms.
- You search twice. When you look for something, there is more than one place it could be, so you check both. This is the clearest single indicator of an overlap and it is easy to notice once you are looking for it.
- You have a rule you cannot state. There is a distinction between the two tools, you follow it, and you cannot explain it in a sentence. An unstateable rule is one you will apply inconsistently, which is how items end up in the wrong place.
- Something is stored in both. Two copies means neither is authoritative, and from then on every use requires deciding which one is current.
The reason overlaps accumulate is that each one arrived for a good reason. A tool was better at a thing, so it got adopted for that thing, and the old tool stayed for everything else. Repeat that four times over two years and you have a stack where the tools are individually excellent and collectively expensive.
The seams are where work is lost
Once a stack has more than one tool in it, which is all of them, the interesting question stops being the tools and becomes the joins between them.
Work is lost at handoffs. Something is captured and never processed. A draft is finished and never gets to where it needed to go. A decision is made in one place and recorded in another, or in neither. Almost none of this is a failure of the individual tools, and all of it is invisible if you evaluate tools one at a time, which is how everybody evaluates tools.
Three questions for a seam
- Who moves the thing? If the answer is “me, when I remember”, that seam will leak, and it will leak exactly on the weeks you are busiest.
- Is there a moment it is guaranteed to happen? A weekly pass, an end of day habit, or an automation. Seams that depend on noticing do not survive a bad week.
- What happens to the thing that does not get moved? If the answer is that it stays in the capture tool forever, your capture tool is slowly becoming a place things go to be forgotten, and eventually you will stop trusting it.
This is the strongest practical argument for fewer tools that most people will encounter: not that tools are bad, but that every tool boundary is a seam, and seams are where the work you did gets quietly dropped.
Auditing a stack you already have
Nobody starts from nothing. Here is a way to audit an existing stack that takes about half an hour and does not require you to change anything while you are doing it.
-
List every tool you opened last week
From memory first, then check. The gap between the two lists is itself informative: the tools you forgot are candidates for removal, and the ones you use without remembering are the load-bearing ones.
-
Put each one on exactly one stage
Force the choice even when a tool spans two. You are looking for the stage it earns its place on. Any stage with more than one tool is where your next hour should go.
-
Mark the seams
Draw the handoffs between them and mark each one as automatic, habitual, or hopeful. The hopeful ones are your leaks, and they are usually the ones you would have described as fine.
-
Find the tool you are keeping for one thing
There is almost always one, kept alive by a single feature or a single archive. Decide explicitly whether that one thing is worth a whole tool. Sometimes it is. Often it is worth moving the one thing instead.
-
Remove exactly one
Not a redesign. One removal, with a date, and a note of what would make you bring it back. Removing one tool cleanly teaches you more about your stack than adding three, and unlike a redesign you can actually finish it this week.
What a good stack looks like a year in
Not impressive. That is the main thing worth saying about it.
A stack that is working is boring to describe: a small number of tools, each with an obvious job, joins that happen without being remembered, and one place to look for any given thing. Nobody makes a video about it. Its main quality is that you do not think about it, which is also why it is hard to recognise as an achievement and easy to disturb by adopting something interesting.
The failure mode is not a stack that is too small. It is a stack that gets rearranged often enough that no part of it becomes automatic, so the effort of running it never falls, so it keeps feeling like the tools are the problem. If a stack has been stable for six months and you are still fast in it, that is the outcome. Adding to it needs a better reason than the tool being good, and our piece on what switching actually costs is the arithmetic we would run first.
How to read this
The five stages are a description we use across this site to talk about where a tool sits, not a framework we are claiming to have validated. Everything above is editorial judgement built from reasoning about how these systems fail, not from a study, a survey, or measured data. It is offered as a way of thinking that we find useful, and it should be argued with rather than adopted.