Where Work Used to Wait: How We Designed a System That Moves on Its Own

Why we replaced single-assignee tasks with multi-step pipelines, dependencies, and built-in reviews, and what changed in how the studio actually ships work.

It usually started with a message.

Not a task notification. Not a system alert. A person pinging another person to say: hey, I think that thing you were waiting on is done. Or: did anyone pick this up after the design was signed off? Or the quieter version — no message at all, just a deliverable sitting completed while the next step waited for someone to notice.

The studio was working. Projects were shipping. But there was friction everyone had quietly accepted as the cost of running a small creative team. It lived in the spaces between people — between design and development, development and review, any step and the next. The system was built around individuals finishing their part. It was not built around the work moving forward.

The handoff was entirely human-managed. The alignment meetings existed to cover it. When we looked at what those meetings actually contained, almost all of it was information that already existed somewhere. The design was done. The files were there. What was missing was the signal: the automatic passing of context from one step to the next, and the notification that said now it is your turn.

We noticed the pattern. We built a different system.

A task is no longer a single thing assigned to a single person. It is a flow, an ordered pipeline of steps, each with its own assignee, its own department, and its own deliverables. Design, development, story, motion, review. Each step belongs to someone. The flow itself belongs to the objective.

When a step is completed, the next person is notified automatically. There is no empty space. The work does not wait to be discovered. It moves.

But the notification is only part of it. The more important change is visibility. Everyone in a flow can see every step, regardless of which step they are responsible for. The developer can see what the designer did, what was decided, what the deliverables were. The reviewer can see the full sequence of work that preceded their review. Someone joining a project mid-way can open the flow and understand exactly where things stand, without a briefing call and without asking anyone to catch them up.

The flow holds the context. The system holds the handoff. The people hold the craft.

Our first instinct was strict linear blocking. Step two cannot start until step one is done. Step three waits on step two. It felt logical, and for certain types of work it was.

Then we ran into the natural exception. Two developers working on two independent parts of the same build. No functional reason to make one wait for the other. The system was creating friction where none existed in the actual work.

So we flipped the default. Steps in a flow are free to begin in parallel unless a dependency is set. Dependencies are added manually, where they actually exist. The result is a system that mirrors how creative work actually moves: sometimes sequential, sometimes simultaneous, never artificially blocked.

The one exception is review. Review steps are automatically blocked by everything that comes before them. This is the only place the system is opinionated about order, and the reason is obvious: reviewing work before the work exists is not review, it is guessing. We made the system hold that one constraint firmly so no one has to remember to set it.

Review used to be a badge. You would attach it to an existing task, mark it for review, hand it to someone, and call it done. The work was the same task. The review was metadata on top of it.

That model broke in practice for several reasons. Reviewers had no dedicated space for their own deliverables. The original assignee's context bled into the reviewer's, or got lost entirely. And critically, you could not plan reviews when creating the work. They happened reactively, which meant they could be forgotten, delayed, or skipped.

Now a review is a step in the flow. It is planned when the flow is created, alongside every other step. It carries its own deliverables, defined in advance, so the reviewer knows exactly what they are assessing. It sits in sequence with design and development, with the same notification behavior and the same visibility.

We initially tried giving review its own dedicated department — a designated reviewer role that only certain people could hold. It was too rigid. The right reviewer for a piece of work is not always the same person, or the same type of person. Sometimes it is the founder. Sometimes it is a peer in a different discipline. Sometimes it is the person who wrote the brief. Opening review to everyone made it a function of the work, not the org chart.

Each step in a flow belongs to a department. Design, Development, Story, Motion. This is not administrative categorization. It is how the studio understands and communicates the nature of each piece of work.

When you look at a flow, you can see at a glance which disciplines are involved, in what order, and who from each discipline is responsible. You can see whether a project is design-heavy or development-heavy. You can see where the handoffs are. You can see whether motion or story is part of the deliverable at all.

Departments make it possible to scale this model without manually managing who needs to know what. The structure carries that information automatically.

Open a flow and you see the whole picture at once. The name of the flow at the top. The client and milestone it belongs to. A row of steps laid out in order, each one showing the assigned person, the department, and the current status. Below that, a status row with priority, duration, and a progress bar. And below that, a deliverables block for the current step, where each item is checked off as the work gets done. We wanted it to feel less like a ticket system and more like a shared understanding of what the work actually is.

The progress bar is not an estimate. It is the percentage of deliverables completed across the active step. One out of three checked means thirty percent. The number is factual, not projected.

Revisions are built into the same structure. If a design step needs a second pass after review, a revision step is added to the flow. The flow extends. The history stays intact. The work continues from exactly where it is, not from a clean-slate assumption that the first version was final.

There were two things we built and then rebuilt, and both of them taught us something.

The first was linear blocking. We started by making every flow strictly sequential: you cannot begin step two until step one is complete, no exceptions. In practice it created unnecessary waiting in situations where two steps had no real dependency. We removed the default and made dependencies opt-in. The system got out of the way.

The second was the review department. We created a dedicated department for review, which meant only certain people could be assigned to review steps. But it made review a bottleneck and a title rather than a behavior. Opening review to everyone preserved the structure while removing the gate.

Both changes came from the same observation: the system works best when it handles the things that should always be true, and stays out of the way on everything else.

The alignment meetings changed first. The ones that existed purely to relay status shrank significantly. The system was answering those questions continuously. The meetings that remained were the ones that should have been meetings all along: creative decisions, client strategy, things that genuinely require a conversation.

People started having a more complete picture of the work they were contributing to. A developer working on one step could see what the designer had done before them and what the reviewer would be checking after them. That context changed how they worked. Not because they were told to think about those steps, but because they could now see them.

And when someone is unavailable, the flow does not lose its context. The next person steps in and sees everything: what was done, what was decided, what is next. The knowledge stopped living exclusively in people and started living in the work itself.

The reason we are writing about this is not that we built a tool. The reason is that the tool came from noticing a pattern, and the pattern is the part that matters.

We look at how things work, find the places where they depend on memory or manual coordination or individual heroics, and ask what it would look like if the system handled that instead. We do this with the studio's own operations. We do it for every client we work with.

When we build a custom website, we are not just designing screens. We are asking: where does this product depend on a person doing something manually that could be handled by structure? Where does the flow of the experience ask too much of the person moving through it, because the system did not do enough thinking in advance.

The same questions apply to brand identity. A brand that depends on a specific person to apply it correctly will drift the moment that person is not in the room. A brand that lives in a system, with defined rules and documented decisions, moves with the team regardless of who is holding it.

And it applies to web and mobile applications too. The best products we have built are the ones where the architecture anticipated how the team would grow, where the design system made consistency automatic rather than deliberate, and where the product itself held enough context that anyone could understand it without needing to ask the person who built it.

The pattern underneath all of it is the same: reduce dependence on heroics, increase dependence on structure. Not because people are unreliable, but because structure scales and people have limits. The goal is a system where the work can move, even when the people are busy.

The flow system described in this article is part of the Hooman Dashboard, the studio's own internal tool for managing work, clients, communication, and team coordination. We built it because every external tool we tried got us partway there before running out of room. The full picture, client communication, milestone tracking, file management, internal workflows, could not be handled in one place without requiring us to maintain bridges between systems.

We wrote about one specific application of this thinking in our work with Maisōn Harry George: a case where the right technical decision was the one that anticipated how the client's team would manage the product after launch, not just how it would perform at launch. The same principle. Structure that works without heroics.

The dashboard is available beyond the studio. Our clients get access to it as part of working with us. It is also available independently for studios and teams who want to run on the same model.

The flow is not a feature. It is a way of thinking about how work moves through people. Once you see the empty space, you cannot unsee it.