I changed my newsletter workflow in January last year. New tool, new routine, new Sunday. By February, I was telling other operators that it saved me two hours on an issue.
I should be honest about where that number came from. I made it up.
It happened by accident. I felt faster, the Sunday block felt lighter than it used to, and my brain reached for a round figure that matched the feeling. Two hours is what it produced.
I never ran a stopwatch. I never logged a single issue before or after the change. The two-hour assumption was a sensation wearing the costume of a measurement.
Most newsletter workflow time savings work the same way. You change something. It feels quicker. The feeling hardens into a fact, the fact becomes advice you pass to other operators, and at no point did anyone check a clock.
The feeling of speed is the cheapest thing a new tool produces, and the only number most operators ever record.
So, this is about the gap between the savings you feel and the savings you can prove. The gap is wider than you’d guess, and a handful of well known effects keep it open. By the end, you’ll have a way to close it, using two issues and a timer.
Your Sense of Time Is Not a Measuring Instrument
Start with the uncomfortable part. You’re bad at estimating how long your own work takes, and so is everyone else.
The pattern has a name. Psychologists Daniel Kahneman and Amos Tversky called it the planning fallacy, the steady tendency to underestimate how long a task will take, even when you’ve done the same task many times.
In one study, students predicted their thesis would take about 34 days. Most blew past their own estimate. The telling detail is that experience did not fix it. People who had missed the estimate on the previous project missed it again on the next project.
If you can’t reliably predict how long a task will take, you can’t reliably estimate how much time a change saved you. Both skills run on the same broken gauge.
Your before number lives in memory, and memory is a storyteller working without a stopwatch.
A related effect makes speed claims even shakier. Researchers studying how people judge speed found that we routinely misjudge how much time a faster method actually returns. We overrate the gain from speeding up something that was already quick, and underrate the gain from speeding up something slow. Applied to your workflow, the stage that feels like the big win is often the wrong place to have looked.
Not your fault. Nobody hands a solo operator a stopwatch on day one.
So the first move is to trade the feeling for the clock. The trouble is that even the clock will mislead you if you read it wrong, and the rest of this post is about the specific ways it does.
Does Automating Part of Your Newsletter Actually Save Time?
Sometimes. The answer turns on a question most operators skip: which part did you speed up, and was that part the thing holding up the whole week?
A principle from manufacturing settles this cleanly. Eliyahu Goldratt laid it out in his 1984 book The Goal, and it became known as the theory of constraints. Every process has one bottleneck that sets the pace for everything around it.
Speed up a step that sits before or after the bottleneck, and the total output stays flat. The work just piles up in front of the slow part. The one change that shrinks total time is a change to the constraint itself.
Newsletter production is a chain of stages, and the bottleneck varies by operator. I mapped where the weekly hours actually go in an earlier post on production time.
For some operators, the slow part is source monitoring. For others, it’s the long tail of work after the draft. For the rest, it’s the writing itself.
This is why so many time-saving claims fall apart. The tools that feel most impressive tend to speed up drafting, because drafting is the visible, dramatic stage where words appear on a screen. If your bottleneck was never the drafting, a faster draft buys you a pile of saved minutes that sit idle while the real constraint runs at its old pace.
A faster drafting step buys you nothing when the slow part of your week sits somewhere else. The clock tracks the entire pipeline, and your favorite stage is only one part of it.
This is also why operators so often reach for the wrong fix. The stage that feels slow and the stage that’s slow are often two different stages, and the feeling wins because it’s louder.
Why Does a New Tool Feel Faster in the First Week?
Because you are paying attention to it, and attention alone changes how you work.
In the 1920s, researchers at the Western Electric Hawthorne plant tried to find the lighting level that made factory workers most productive. Productivity rose when they turned the lights up. It also rose when they dimmed the lights.
The thing moving the output was the study itself. Workers behaved differently because they knew they were being watched. The pattern got named the Hawthorne effect.
In fairness, economists Steven Levitt and John List reanalyzed the original data in 2011 and found the effect was weaker than the legend, which is its own lesson about trusting a result that confirms what you wanted to believe.
The newsletter version is simple. The first week with a new workflow, you are alert. You are curious. You watch the clock because the change is fresh.
You move with a focus you do not usually bring to a Sunday. The week comes in fast, and you credit the tool.
Then week four arrives. The attention has worn off, the focus is back to baseline, and the issue takes about as long as it always did. The tool sits exactly where it sat in week one.
Think about which week you based your own time-saving claim on. The fresh one, most likely.
This is the first way the clock misleads you. A single fast week after a change is evidence that you were paying attention, which you will stop doing by next month.
Why Doesn’t Saving Time on One Task Shrink Your Whole Week?
Because the time you free up gets eaten. Almost immediately.
In 1955, the historian Cyril Northcote Parkinson published a short essay in The Economist that opened with a line now known as Parkinson’s Law: work expands so as to fill the time available for its completion. Give a task a full afternoon and it takes the afternoon. Give the same task ninety minutes and it somehow fits.
The law runs in reverse on saved time. You shave twenty minutes off formatting. Those twenty minutes become twenty more minutes of subject line tinkering, because the subject line is right there and you now have room to fuss over it. Total time per issue holds steady while the saved minutes quietly relocate to the next most fussy task.
Work expands to fill the time you free up, so the hour you saved disappears unless you give it a new job before Sunday.
I wrote about where a reclaimed hour should actually go in a post on the return on reclaimed time. The short version is that a freed hour has value only when you point it at something on purpose. Left undirected, it gets absorbed back into production, and your total Sunday looks identical to the one before the change.
You felt the saving. You filed the feeling as a fact. A stopwatch was never involved.
The most direct proof of this comes from outside newsletters. Atlassian’s 2025 State of Developer Experience survey of thousands of developers found that 99% now report saving time with AI tools, and 68% say they save more than 10 hours a week. The same developers reported losing roughly the same amount of time to inefficiency elsewhere in their week.
Atlassian summarized the result plainly: saved ten hours, lost ten hours, back where they started. The research firm DX has a name for the broader pattern, false velocity: more activity, more reported speed, no matching gain in real output.
Saved ten hours. Lost ten hours. Net zero. Congrats!
Let that sit before you reach for the next tool.
Four Reasons Your Newsletter Workflow Time Savings Look Bigger Than They Are
Pull the threads together and you get four specific traps. Any one of them can make a useless change look like a winner.
The first is the feeling itself. Your sense of elapsed time is unreliable, so any saving you did not time with a clock is a guess dressed as a result.
The second is novelty. The first week or two after a change runs fast because you are watching it, and that speed fades on its own.
The third is the bottleneck. You measured the stage you sped up and felt good, while the constraint that actually sets your weekly pace never moved. Remember the bottleneck from two sections back? This trap is its quieter cousin.
The fourth is reabsorption. The minutes you freed got spent back inside the issue, so the saving was real at the task level and invisible at the week level.
A fifth trap hides underneath all four, and it’s the reason single comparisons are so dangerous. Your weeks are not identical. The week you tried the new workflow might have had an easier topic, fewer interruptions, more sleep, or a lighter news cycle.
If you switched tools right after a brutal week, the next week was going to be easier, no matter what you did, because brutal weeks are usually followed by average ones. Compare one good week against one bad week and you will credit the tool for the weather.
This is the exact problem that the discipline of controlled experiments was built to solve. In Trustworthy Online Controlled Experiments, the standard text on A/B testing by experimentation leaders from Google, LinkedIn, and Microsoft, the authors are blunt about it. A difference between two runs counts as evidence only when you changed one variable, held the conditions steady, gathered enough data points to rule out luck, and stayed skeptical of results that look too good. A single before and after across two different weeks fails every one of those tests.
My cofounder Eren asked a sharper question earlier in this series, in his piece on why speed is the wrong goal. He’s right that chasing speed for its own sake can cost you the work.
If you are going to chase a time saving, at least measure whether you caught one.
How Do I Actually Measure If a Workflow Change Saves Time? Run the Two Issue Workflow Test
You don’t need software to run this. You need a timer, a notepad, and the willingness to time four issues honestly. Most operators have never once measured a workflow change against a control, which is why most operators can’t tell you whether their last three tools did anything.
Surprising? Only if you have timed a workflow change before, and almost nobody has.
The test borrows the logic of a controlled experiment and shrinks it to fit one person. Run all five steps in order.
Step 1: Name the one thing you are changing. Write it in a single sentence. “I’m letting a tool draft the first version.” “I’m automating source monitoring.” One variable. Change three things at once and you’ll never learn which one moved the clock, which puts you back to guessing.
Step 2: Measure your control. Before you touch anything, produce two issues your normal way and time them with a stopwatch, start to send. Log the total, and log each stage separately: source work, selection, drafting, the post draft tail, distribution. Two issues, so you can see how much your normal weeks already vary. That spread is your margin of error, and it matters in step five.
Step 3: Run the treatment. Make the one change, then produce two more issues exactly as you logged the control. Same stopwatch. Same stages. Keep the conditions as close as you can manage: similar topics, similar news weeks, similar energy. You’re changing one thing and holding the rest still.
Step 4: Measure the whole pipeline. Looking only at the stage you changed is how most self-tests go wrong. Compare the total time per issue across all four, control against treatment. Then check whether the freed minutes left the building or just moved. If drafting dropped by thirty minutes while your total time per issue held flat, the saving reabsorbed, and you have caught Parkinson’s Law operating inside your own Sunday.
Step 5: Apply the skeptic’s checks. Three questions, before you believe anything. Did the saving hold across both treatment issues, or did it shrink from the first to the second as the novelty faded? Was the gap between control and treatment bigger than the normal week-to-week variation you measured in step two, or could it be ordinary noise? And were the two treatment weeks genuinely comparable to the control weeks, or did you simply get an easier run? A saving that survives all three is real. A saving that fails any of them is a feeling.
A workflow test that runs for a single issue measures your luck that week. Four issues measure your tool.
The test takes four weeks because it has to. A single issue cannot separate the tool from the weather, the novelty from the gain, or the stage from the system. Four issues, timed honestly, can.
The output is a number you can defend. Most operators run this land in one of two places. Either the change saved real time at the pipeline level, in which case keep it and point the freed hours somewhere deliberate. Or it saved time at one stage that vanished into the rest of the week, in which case the tool was theater, and now you know.
Where Tools Fit, Once You Can Measure Them
A test like this also changes how you shop. Once you can measure a change at the pipeline level, you stop buying tools on the strength of how impressive the demo feels and start buying them based on whether they move your specific constraint.
This is the honest way to evaluate something like HeyNews, which automates the mechanical layers of production, the source monitoring, the first draft, the analytics review, while the editorial calls stay with you. I wrote about the case for handing off that mechanical layer in a post on automating without hiring.
The claim attached to any such tool, ours included, is that it gives you back hours. The right response to that claim is to run the Two-Issue Workflow Test against your own archive and your own bottleneck, and read the number.
If the tool moves your constraint, the clock will show it across four issues. If it doesn’t, no demo should talk you out of the clock.
That’s the whole point of measuring. It turns every tool claim, ours among them, into something you can check for yourself.
In a Nutshell
- Your sense of how long work takes is unreliable, so any time saving you did not measure with a clock is a guess. The planning fallacy means you misjudge how long a task will take, even for work you’ve done for years.
- Speeding up one stage does nothing for your week if that stage was not your bottleneck. Total time per issue is the only number that proves a saving, and it’s the one most operators never check.
- A new workflow runs fast in week one because you are paying attention to it. That novelty boost fades, so judge any change across several issues. The first issue alone proves nothing.
- Freed time gets reabsorbed unless you assign it a new job. You can test this for free by timing total production before and after a change and watching whether the saved minutes actually leave your Sunday.
- The only honest measure is a controlled comparison: change one variable, time several issues each way, measure the whole pipeline, and stay skeptical of any result that looks too clean.
What to Measure Next
Go back to the last workflow change you made, the one you’re sure saved you time. Try to name, in minutes, what you measured. If the honest answer is that you measured nothing and felt a great deal, you’re standing where I stood in February with my invented two hours. The good thing is that the automation I tried eventually led us to build HeyNews, to create a real time-saver.
The fix costs four issues and a stopwatch. Pick the change you are least sure about, run the Two-Issue Workflow Test, and let the clock settle the argument your memory has been winning by default. The operators still publishing in five years will be the ones who learned the difference between a tool that feels fast and a tool that is, because only one of those two buys back time you can spend somewhere better.
See what editorial intelligence looks like when you measure it against your own archive: heynews.co
