“Workflow” is one of those words people toss around until it means nothing. So let’s pin it down like an engineer would. Or, a tag team in wrestling, lol.
A workflow is the repeatable path that turns intent into a deliverable. Not motivation. Not “I feel organized.” A workflow is the plumbing between idea and shipped. If that plumbing leaks, you don’t just lose time—you lose trust in yourself, and then the whole machine starts slipping.
Every real workflow—whether you’re running a factory, writing a book, or rebuilding a tractor—has the same major elements:
Inputs (new projects, requests, obligations, opportunities, interruptions)
Constraints (time, energy, money, tools, health, attention span, dependency on others)
Deliverables (the thing that must exist when you’re done)
Bandwidth (what you can actually push through the system per day/week without breaking)
If you want a single sentence that explains why most time tools fail for serious operators, it’s this:
They help you capture inputs, but they don’t help you honor constraints while producing deliverables inside a fixed human bandwidth.
That sentence will matter later, because “time-management” isn’t really about time. It’s about throughput under constraint.
Constraints, deliverables, and bandwidth: the holy trinity
If you’ve ever had a week where the calendar looked reasonable and yet everything still blew up, you’ve met the enemy: hidden constraints.
Most people only acknowledge the visible constraint—hours on the clock. But the constraint stack is deeper:
- Cognitive bandwidth (how much deep focus you have before your brain turns to oatmeal)
- Context-switch costs (what it costs to jump from “markets” to “web dev” to “garden” to “legal”)
- Energy variability (some days are 100% days; some days are 40% days; pretending otherwise is self-sabotage)
- Dependency delays (waiting on emails, shipping, approvals, weather, other people)
- Tool friction (login, navigation, “where did I put that version?”)
Now add the difference between work and deliverables.
A deliverable is not “worked on.” A deliverable is done enough to count. Published. Filed. Shipped. Installed. Paid. Harvested. Tested.
And bandwidth? Bandwidth is the uncomfortable truth:
You can only ship so much per week. Period.
A single operator who is effectively CEO of a small empire—writing, publishing, maintaining systems, keeping a household running, tracking markets, doing shop work—doesn’t have a “task problem.” They have a throughput problem.
Which brings us to the most useful planning tool ever invented, and the most commonly abused: the WBS.
The WBS: Work Breakdown Structure as sanity
A Work Breakdown Structure (WBS) sounds corporate, but it’s as old as humans building things. It’s the act of breaking a deliverable into parts until the parts are small enough to execute.
If you’re building a deck railing, the WBS might be:
- Design
- Materials
- Cut
- Drill
- Assemble
- Finish
If you’re writing a column for a website – something fresh, new, and well researched:
- Premise
- Supporting facts
- Structure
- Draft
- Tighten
- Publish (Notice how I skipped the research?)
In other words, WBS is how you reduce “project blur.” It’s the antidote to that mental fog where you know you should be doing something, but you can’t see the next step clearly enough to start.
Workflows Made Personal
In my own workflow, it looks like this:
New project arrives
- Capture it immediately (so it stops rattling around in the head)
- Basic WBS (a few decomposition steps—just enough to see the shape)
- Tier cards (levels 1…n depending on complexity)
- Daily scheduling (what gets done today, tomorrow, this week)
This is where the workflow stumbles in most tools—not because WBS is hard, but because the software forces you to choose between two different “truths” about work.
The Brisqi “hole” isn’t a missing feature. Brisqi is a great Kanban tool. It’s a domain mismatch.
This week I sent a note to Ash at Brisqi, because Brisqi is excellent at what it is: fast capture, visible flow, and day-to-day movement. But my use case exposes a gap that’s broader than Brisqi.
Here’s the short version of the product idea:
- A top-level card defines concept + deliverable
- One click opens into tiered child cards (WBS levels)
- Any card at any tier can be slid onto a day runner (Today/Tomorrow/This Week/date)
- Sliding it schedules it—it does not clone it
- The card retains lineage: you can always see where it came from
Most tools fail at that last part. They “solve” planning and execution with two separate universes:
Object domain (structure / WBS): a project is a thing with parts, parent → child → subchild. A containment graph.
Space domain (time / dayrunner): a day is a place you put work, Today/Tomorrow/Tuesday. A temporal surface.
When software moves between those domains, it usually does it by:
- Duplication (clone the task into the calendar)
- Teleportation (move it out of the project context)
Both break lineage. Lineage is what answers the questions that keep a system stable:
- “Why am I doing this?”
- “What is this part of?”
- “If I stop now, where do I resume?”
- “If I complete this, what does it unlock?”
So the cleaner statement of the “hole” is:
A task should be a single object that can have both a structural coordinate (WBS location) and a time coordinate (dayrunner placement). Scheduling is assigning a time coordinate—not creating a second object.
If you want the engineer punchline:
WBS is topology. Dayrunner is geometry. Time tools need a mapping between the two—without cloning the world.
Now we’re ready for the bigger question: once you can map structure to days cleanly, how do you schedule honestly inside a normal human lifetime?
WBS sorting: the moment structure becomes execution
A WBS can be perfect and still useless if it doesn’t convert into runnable work. The conversion step is where “project management theater” becomes “shipping.”
The conversion requires sorting tasks by a handful of attributes that normal tools either hide or force you to manage manually:
Effort size (5 minutes, 30 minutes, 2 hours, 6 hours)
Energy requirement (low-focus vs deep-focus)
- Dependency state (blocked, unblocked)
- Context (writing, admin, shop, garden, studio)
- Deadline / time window (hard date vs soft window)
- Leverage (does this unlock other tasks or reduce future pain?)
Once you add those, something interesting happens: the dayrunner stops being a “list.” It becomes a bandwidth allocator.
That’s the pivot from childish productivity to adult production:
Childish: “What do I feel like doing?”
Adult: “Given my constraints and bandwidth, what can I ship today that moves the deliverable forward?”
George: “Can I get a beer, yet?”
Which leads to the final piece: scheduling inside a normal lifetime.
The biggie: scheduling within a normal lifetime
Most people schedule as if time is infinite and energy is constant. Both assumptions are false, and they create guilt-driven systems that eventually collapse.
A workable Time-Engineering schedule respects three realities:
- Bandwidth is finite
- Energy varies
- Context switching is expensive
So instead of “maximize tasks,” you do this:
1) Define your throughput units
Not hours. Units.
For writing, a throughput unit might be:
- one section drafted
- one chart explained
- one piece tightened and published
For shop work:
- one measured/cut/assembled subtask
For life admin:
- one phone call handled
- one bill batch processed
The point is to measure what actually moves deliverables.
2) Build a “Minimum Viable Day”
This is a lifesaver. You decide what counts as a successful day when energy is low.
Example:
- One publishable paragraph
- One essential admin item
- One health/sleep protection move
If you can do more, great. But the minimum day prevents the all-or-nothing crash.
3) Schedule by energy blocks, not clock blocks
Most calendars are fantasy novels. Instead:
- Put deep-focus work in the highest-energy window
- Put low-focus work in the low-energy window
- Cluster by context (don’t bounce domains all day)
4) Protect the “return to flow”
After interruptions, you need a re-entry ritual:
- open the draft
- write one paragraph
- outline the next section
Five minutes is enough to keep the thread warm. This is how you keep multiple streams alive without drowning.
5) Keep lineage intact
This loops back to the Brisqi hole.
When today’s work is linked to its WBS parent, you don’t waste cognitive cycles re-deriving purpose. You don’t drift. You don’t duplicate. You don’t lose the plot.
What this means in practice for a single operator
If you’re running multiple sites, multiple deliverables, and you’re doing it with one human body and one brain, you don’t need more “productivity.” You need a system that survives real life.
That system has a few non-negotiables:
- Capture fast
- Break down into WBS tiers quickly
- Schedule without cloning
- Execute on a dayrunner that respects bandwidth
- Recover after disruption without losing context
Most modern tools make you choose between structure and action. The opportunity—whether you build it yourself in your habits or a software company builds it into a product—is to unify them:
One object. Two domains. Lineage never breaks.
And once that mapping exists, the rest of Time-Engineering becomes possible: honest scheduling, survivable systems, and steady output inside the only constraint that matters—the limits of a normal human lifetime.
What we haven’t gotten into yet is what I think of as the “Tinme Domains of Workflow.”
That is a much larger discussion. But to give you the idea (so you and noodle in in your spare wetware clicks) consider that:
- Life is long – and so there are lifetime-length deliverables. (“What did I do with my Life?”)
- And at the short end “Just feel the next breath as you fight for it.”
This is the heman/carbon’s “Time Engineering” framework. Vast, wide-open country. But once you see it, you will understand how Timew Engineers are genuinely shaping the future of the whole world.
Right now.
Consider yourself empowered,
George
Comments are always welcome!