Some principles are so straightforward that once you encounter them you think: How did I operate so long without this?
Here’s one of them:
Breaking down tasks into parts improves your prioritization across all tasks.
I was recently inspired by one of Calvin French-Owen’s blog posts, The Secret of the Weekplan, which includes this story from Good Strategy, Bad Strategy:
It was 1890, and there was a cocktail party here in Pittsburgh. All the movers and shakers were there, including Carnegie.
He held court in the corner of the room, smoking a cigar. He was introduced to Frederick Taylor, the man who was becoming famous as an expert on organizing work.
‘Young man,’ said Carnegie, squinting dubiously at the consultant, ‘if you can tell me something about management that is worth hearing, I will send you a check for ten thousand dollars.’
Now, ten thousand dollars was a great deal of money in 1890. Conversation stopped as the people nearby turned to hear what Taylor would say.
‘Mr. Carnegie,’ Taylor said, ‘I would advise you to make a list of the ten most important things you can do. And then, start doing number one.’
And, the story goes, a week later Taylor received a check for ten thousand dollars.
Inspired, I gave it a shot. I made a list of my top 10 priorities, and to raise the stakes, I made this list public and editable to all my colleagues. It worked remarkably well and I was rewarded with a surge of clarity and focus.
Then something strange happened.
At some point the task that floated to the top of my list was fixing our documentation. It was clearly hurting us in several ways—anyone landing on our site likely left confused. The docs were written from an engineer’s perspective, not a user’s. So I proposed a full rewrite and restructure.
To move faster, I split the project: I’d do the restructuring first, and others could help rewrite pages afterward.
But here’s the kicker: just restructuring the docs solved most of the problem.
Yes, the writing still needed work. But the core issue was structure. Once that was fixed, the urgency around rewriting dropped. It no longer deserved a top slot on my list—and it wouldn’t have been clear unless I’d broken the task into parts.
Had I treated “fix the docs” as a single monolith, I would’ve kept burning time on rewrites, thinking I was working on the top priority. But in truth, I would have been chasing the long shadow cast by poor structure. And it certainly wouldn’t have been my first time doing this as an engineer. I can only cringe at all the hours I spent tending to nits on a humongous PR because I hadn’t separated the nits from what was truly important.
Fractionalizing tasks surfaces the real priorities and helps everything else on the list breathe easier.