Amy Porterfield's podcast recently unpacked a Fast Company piece on "anti-time management," and the thesis is straightforward and slightly heretical: stop managing time, start defining what success looks like after you have hit the goal, and time organizes itself.
It is a useful frame for anyone running sprints, content calendars, or a small team, where the real waste is rarely clock-watching.
What "anti-time management" actually means
The framing Porterfield highlights is that you do not anchor your schedule to the task, you anchor it to the result you want once the task is done. If you know what "after success" looks like, the work in the middle stops being a debate about hours and starts being a debate about decisions.
It sounds like wordplay. It is not. The argument is that time management tends to optimize the wrong variable—the number of hours spent—instead of the variable that actually matters: the shape of the outcome.
Our analysis
The idea is not new. It echoes the agile principle of outcomes over output, and the lean principle of defining done by the customer, not by the clock. What is novel is packaging it as anti-time management, which cuts through in a culture that treats calendars as productivity.
Who benefits:** Managers who currently run their team's day by the hour, and end up over-scheduling junior work and under-scheduling thinking. **Who loses:** People whose value is measured in hours billed, since the framing quietly suggests the bill is the wrong metric.
Trade-off:** Focusing on the result makes it easier to skip steps that look productive but are not. That is good when you are cutting meetings. It is bad when you skip the boring review that would have caught the bug.
What to watch:** Whether this framing spreads into project tooling. Calendars reward time blocking; tickets and outcomes reward result defining. The tools will shape which frame wins.
Decision checklist: Applying the anti-time management filter
Use this when planning any project or sprint:
- [ ] **Define the post-success result first.** What does "done" look like for the end user, not the deliverable?
- [ ] **Cut the hours-based plan.** Replace it with the smallest decision that produces that result.
- [ ] **Stop estimating "hours to build X."** Start estimating "decisions needed to retire X."
- [ ] **Re-scope around the result.** Drop activities that do not move toward the outcome.
- [ ] **Preserve the boring reviews.** Do not cut the step that catches bugs just because it is not "productive-looking."
Worked example: applying it in a sprint
Say you are running a two-week sprint and the team is burning hours on a content calendar update that will be obsolete in a quarter. Apply the anti-time management frame:
- Define the post-success result: a calendar that the content team can update without engineering help.
- Cut the hours-based plan and replace it with the smallest decision that produces that result.
- Stop estimating "hours to fix the layout" and start estimating "decision to retire the layout."
- Re-scope the work around the result and drop the activities that do not move it.
You will probably find the team spends the same number of hours, but on different work, and finishes with something the content team can own.
Bottom line
Time management answers "how long should this take?" Anti-time management answers "what should this produce?" If your team cannot answer the second one, the first one is irrelevant.
Key takeaways
- Anchor planning to the outcome you want, not the hours you can fill.
- Hours-based plans often optimize for the wrong variable, which is presence.
- This framing is consistent with agile's outcomes-over-outputs idea.
- Re-usable tasks still pay off, so do not skip the boring review.
- The right tools make the right frame easier to use.
Frequently asked questions
What is anti-time management?
It is the idea, drawn from a Fast Company piece and unpacked by Amy Porterfield, of planning around the result you want rather than the hours you can spend.
How is this different from regular time management?
Regular time management optimizes for hours spent. Anti-time management optimizes for the shape of the outcome, which usually changes the hours.
Does this work for agile teams?
Yes. It lines up with the agile preference for outcomes over output and a clear definition of done.
Is this just a relabel of "focus on outcomes"?
Mostly, but the packaging as anti-time management is the part that gets attention in a calendar-mediated culture.
What is the risk of this approach?
Cutting hours-based plans can also cut the boring review work that catches bugs, so apply it carefully to knowledge work, not to regulated process.