Work Formation

Tracking work is easier than ever. Systems like Linear make it effortless to create issues through frictionless interfaces and a rich layer of integrations. You can forward emails in, create issues from other services like Zendesk, and even mention “@Linear” in chats in Slack or Teams. You can also use the Linear MCP or Linear AI to generate issues for you. No more do you have to wait for the “product person” to show up as a taskmaster, tracking work through endless discussion threads. If you have a thought, you can just as easily track it in a system—your Work Registry.

Work flows into the system at a faster rate, so you rely on the powers of agentic coding to complete the work at an equal or higher rate.

But what about reviews? There’s a new bottleneck on humans in the loop reviewing the work of agentic code. Our team still has humans guiding and reviewing the work because an AI review alone isn’t enough. The models are good and getting better at an exponential rate, but quality still lives in the details. Skilled senior engineers with deep domain knowledge maintain coherence in the system. AI provides the speed; humans provide the quality, stability, maintainability.

So more issues need faster execution and better reviews. Direction before execution and review after execution are still integral points for human intelligence to step in. Knowing what to build, what not to build, and when to build it is of crucial importance. I’m intentionally shifting more of my time to shaping work to steady the direction. Work is increasing at a faster rate, so it needs filters, throttles, and governance. If you build everything just because you can, you lose focus on creating real value and make a product for nobody.

Once issues are flowing through the Work Registry, pressure is redistributed. Instead of making sure work is tracked, you have to apply focused energy to find the signals, shape them, and deliver them in bursts of rapid iteration and feedback.

Everyone is adding work to Linear. The “add to linear” meme has done its job. The loss of friction in creating issues removed the barrier to add an idea. And while AI certainly helps, it takes an intuitive energy to find the clusters of ideas, determine where to apply pressure, and continually cultivate an emergent environment of value growth.

This idea is called Work Formation, which lives in the Clarity Current of the Claritorium and Strategic Momentum of Equilio.

The three pillars are:

1. Aggregation when ideas form clusters.
2. Activation when clusters form structures.
3. Stabilization when structures strengthen.

Aggregation

From January to March of this year, we saw a 27% increase in Linear issues created.

Why? Well, there are a few reasons. For one, I’ve instilled the idea as a cultural norm for the team. If something needs to be worked on, it must live in Linear. But the second reason is because there are more entry points that reduce friction in adding issues:

• Directly adding to Linear.
• Automatically forwarding emails.
• Creating issues from team chats.
• Using the Linear MCP with Claude.
• Other native tool integrations.

This is good! The first step of Shape Mapping is to surface everything. This is the list of possibilities. It’s raw potential. Potential energy in a system is stored energy. When you add a steady flow of ideas, you’re inducing a high-energy state, like water molecules dispersed in vapor before they become droplets and later raindrops.

Linear’s Triage Intelligence suggests and adds metadata like labels and related issues, which builds a rich taxonomy so you can begin to identify clusters of information.

If you take the time to build your Product Landscape with Regions, Zones, and Context—including mapping them to labels in your issue-management system—you establish a high-fidelity identification system. You can then use AI to quickly parse and map similar ideas, forming clusters of related work. But don’t forget about your human judgement. If you pay attention and tune your intuition, you’ll notice when ideas begin to cluster. I’m notified of every single issue coming into Linear. I need to see every signal, to understand it, and map relations in the system. Software is a complex system of dependencies, so it helps to monitor the inflow to spot what work affects and is affected by other work.

Aggregation is when ideas form clusters of coherent groups of work. Eventually there’s an inflection point where a cluster reaches a critical mass.

Work either activates into a new state or entropy develops, forcing the issue out of the system. In Linear, any issue without activity in the past 30 days is automatically canceled. If you want to overcome entropy—the tendency of a system to drift toward disorder and dispersion—then apply a consistent energy to move ideas forward to the next level. That only works when you know what ideas are worth applying energy to.

At this stage, you don’t create any formal groups of work. You watch for patterns:

• Password reset emails not being delivered.
• Users confused about an interface change.
• A higher error rate in a part of the product.

I spend time every day cultivating the work, like pruning and watering a garden. When it’s easy to add work, you need to spend more of your energy weeding. And once you see clear signals as clusters, you can name them and move to the next step.

Activation

Ideas form clusters when you apply the right energy. Once you identify clusters of ideas, then it’s time to harden the structures. Different clusters require different types of energy, as well as different structural containers for the work.

Activation is when the clusters form one of two types:

1. Batches for a collection of small and focused fixes and improvements.
2. Streams for a collection of experiments designed to resolve a tension.

Streams are part of the Product Current. Batches are a new idea. Both of them can be precursors to projects (the most hardened structure)—or solved and dissolved without ever moving past the current structure. The water vapor in the cloud forms droplets.

Batches

Batches are the first structure I reach for when organizing work. Just recently, there were a collection of 7-8 issues on a specific part of the Product Landscape: Search + Mobile. So I created a new parent issue called “Mobile Search Fixes”, labeled it as a Batch, and then grouped all the sub-issues within the parent. The Batch emerged. I assigned an engineer to the entire Batch so they could focus on related issues and build momentum. When engineers work on fixes and improvements—small bugs and enhancements that are a day or less of work—they build momentum when working in similar parts of the product and codebase. They also build domain knowledge and ownership of that part of the product, which means they’ll create new issues and refactor uglier parts of the code. With agentic coding, this accelerates. We’ll often refactor entire areas when working on a Batch. It’s like a mini project.

How is a Batch different than a project? The commitment level and the scope of work.

Both are flexible. The commitment level is low because resources can be pulled at any time for other, higher-priority work. And the scope of work is easy to change. You just remove work. It sounds simple because it really is that simple. A Batch is a collection of independent issues that, when completed together, create focused energy on a single product surface. But there’s no scope requirement to meet beyond improving that product area. Projects are not like that.

I was working on a set of new landing pages recently. I worked with design to build a template, created the template components with Claude Code, and then rapidly iterated through a set of key pages. This led to a larger main navigation change, as well as more ideas for more landing pages. Product work is generative. Doing work generates more work. Scope will always increase as you add more surface area. You add more, you see more, you want more. Once the core pages were done within the “New Landing Pages” Batch, I removed the additional ideas from the Batch and closed it. Why? We added the key landing pages and I needed to focus my energy on other areas. A Batch is a lightweight unit of focused attention.

Streams

In the Product Current, I talked about how Streams establish tensions. You identify larger strategic themes to set a direction for the work. Then you build Streams (no more than 3) to run concentrated experiments against. You test, learn, and iterate until:

1. Resolution: The tension is resolved and you disband the Stream.
2. Escalation: The tension is unresolved and you escalate it to a larger bet.

For the past few months, we’ve tracked three Streams. One of them, “Funnel Optimization”, was designed around the tension of removing friction in the product funnel to increase signups, trials, and subscriptions. Streams are intentionally designed around key product metrics so you can quantitatively measure improvements. Experimentation is most successful when there’s clear success criteria to gauge progress and grade outcomes.

We ran 30 experiments for the Funnel Optimization Stream. We saw improvements in the funnel and related metrics, but the core tension remained. Through the work, we identified a few key bets we could place to increase the likelihood of resolving the tension. There’s less risk in the bet when you spend time experimenting, probing, and surfacing signals. The project work that follows becomes clearer and more strategic.

Batches are lightweight containers for focused improvements.

Streams are intentional containers for focused experimentation.

Together, they help you activate the mass of information into actionable outcomes. But even with concentrated energy applied to the issues, problems grow. They need even more focused energy to solve the problem.

That’s when you turn towards the core unit of work: projects.

Stabilization

Water vapor condenses into droplets around particles in the air, constantly forming and evaporating. The ones that grow larger through condensation and collision reach a point where they continue growing into raindrops. The smaller ones dissipate.

Moving from ideas to clusters to batches to streams and projects works the same.

It’s no surprise nature provides the vehicle of understanding how ideas and information moves through natural and synthetic systems.

As Max Bennett says in A Brief History of Intelligence, “Nature has, throughout the history of human innovation, long been a wondrous guide.” There’s a reason Leonardo da Vinci spent time studying the flow of water as a transitive path toward understanding how to paint hair. In his notes, he said:

Consider the movement of the surface of water. It behaves like hair, which has two motions: one conforms to the weight of the mane, the other to the wandering of the locks. Likewise water has its eddying movements, one part of which follows the principal current, the other the random and reverse motion.

I often reach for analogies in nature to understand knowledge work. Information moves and flows through channels like much natural phenomena. If it worked for someone as brilliant as Leonardo da Vinci, it can work for us, too.

Aggregation and Activation are like the condensation of water vapor into droplets.

Stabilization is where droplets turn into raindrops. Raindrops create rain, which cleans the air, lowers atmospheric temperatures, and fosters biodiversity in the environment.

Small changes, massive impact.

That’s what the right projects can do for a product. Unlike clusters, batches, or streams, projects concentrate massive energy on a fixed point. All the work before you make a bet shapes the work to focus the impact. Ideas emerge, shapes are created, and progress is built iteratively into the final output.

Funnel Optimization generated a “Trial Onboarding” project to build a cohesive onboarding flow for users in the 7-day free trial. Running the Stream for a few months let us confirm the depth necessary to resolve the tension. If we jumped into the project too early, we risked building the wrong thing, introducing more complexity, and either:

1. Not solving the problem.
2. Solving the wrong problem.
3. Introducing a brand new problem.

The Project Engine is the process for defining, executing, and iterating on projects:

1. Align: Align on the problem, team, and the boundaries (constraints).
2. Clarify: Develop a shared, first-principles understanding of the core problem.
3. Model: Explore solutions, sketch flows, and converge on a viable direction.
4. Build: Deliver the solution through iterative forging and refining.
5. Learn: Measure impact and feed insights back into the system.

The work in Activation actually moves you through steps 1-3 much faster. Then it’s really about executing on the work through rapid iteration and feedback.

If you make improvements in Batches and Streams, you isolate the scope of work. The project you work on is more concentrated, effective, and deliberate.

The system begins to stabilize.

The Practice

So how do you turn Work Formation into a practice? This is the process I go through to move information from ideas to delivered projects.

Here are the three time horizons I work against:

1. Daily rhythms to review new issues, tag them, and look for early signals.
2. Weekly rhythms to identify clusters worth acting on (streams or batches).
3. Monthly rhythms to review streams and escalate opportunities into projects.

And the process generally follows:

1. Capture: Track ideas and get everything into the Work Registry.
2. Sense: Identify clusters by looking for repetition, proximity, and relations.
3. Shape: Turn each cluster into a batch (clear fixes) or a stream (requires experimentation).
4. Structure: Create the batches, streams, and projects with standardized structures.
5. Iterate: Execute, iterate, and learn by turning the work back into more ideas.

Many AI tools use “skills,” which are prompts you can trigger to complete specific tasks. I think this is an interesting mental model for executing standard processes. Here’s a list of skills you can use in Linear’s AI chat or Claude or another tool to help with Work Formation.

Skill 1 — Cluster Identification

Analyze the following issues and identify meaningful clusters based on shared themes, affected product areas, user intent, or underlying problems.

For each cluster:
	•	Provide a clear, concise name
	•	Describe the underlying pattern or tension
	•	List the grouped issues
	•	Note any signals of urgency or impact

Also highlight:
	•	Any outliers that do not belong to a cluster
	•	Any clusters that appear weak or lack sufficient signal

Skill 2 — Batch Formation

Given the following cluster of issues, determine if it should be formed into a Batch.

If yes, create a Batch structure:
	•	Batch name (clear and scoped to a product surface)
	•	Parent issue description (what area is being improved and why)
	•	Grouped sub-issues (organized logically)
	•	Suggested owner and execution approach
	•	Clear boundaries (what is included vs excluded)

Ensure:
	•	The scope remains flexible
	•	The work consists of independent improvements
	•	The goal is to increase quality, not introduce new capabilities

Skill 3 — Stream Formation

Given the following cluster of issues, determine if it should be formed into a Stream.

If yes, define the Stream:
	•	Stream name (clear and tension-oriented)
	•	Core tension (what problem or friction exists)
	•	Target metric(s) (how success will be measured)
	•	5–10 initial experiments to run
	•	Expected signals (what would indicate progress or failure)

Ensure:
	•	The problem is not yet fully understood
	•	The goal is learning and iteration
	•	The work is structured around measurable outcomes

Skill 4 — Project Definition

Based on the following Stream (or cluster), determine whether it is ready to be escalated into a Project.

If yes, define the Project:
	•	Problem statement (clear and specific)
	•	Proposed solution direction
	•	Desired outcome (user + business impact)
	•	Scope boundaries (what is included/excluded)
	•	Key milestones or phases
	•	Risks and unknowns

Ensure:
	•	There is sufficient clarity and confidence
	•	The work requires coordinated effort
	•	The outcome represents meaningful product value

Skill 5 — Formation Orchestration

Review the following set of clusters and determine the optimal Work Formation strategy.

For each cluster:
	•	Assign a Work Form (Batch, Stream, Project, or defer)
	•	Explain the reasoning based on clarity, scope, and impact

Then:
	•	Identify the top 1–3 Streams to prioritize
	•	Identify any immediate Batches to execute
	•	Identify any Projects ready for commitment
	•	Recommend what should NOT be worked on right now

Ensure:
	•	Focus is maintained
	•	Work is balanced across improvement, exploration, and delivery
	•	The system avoids overloading with too many active Streams or Projects

The Throughline

It’s exhilarating to complete complex work in alarmingly short amounts of time. But it’s not endless upside. AI is an accelerant. The more work it does, the more work it creates. Yes, it can take massive amounts of data like user feedback, analyze it for themes, and then generate a bunch of issues for you to work on. It can even take those issues, write the code, and then review and deploy it. But there’s a benefit to slowing down, to being involved in the process. If you remove yourself from the equation, what’s the point? The process is where you evolve, grow, and improve. Humans are still directing and reviewing, but what happens when AI independently directs and reviews? It’s already happening. I’ve talked to engineers who work on teams where all of the output is reviewed by AI autonomously. It’s like the human engineers just become chaperones at a high school dance. They’re only there to make sure nobody is doing anything they shouldn’t.

Work Formation is a collaborative effort—with your team and with AI. It requires combined intelligence working intentionally together to move work forward effectively.

Ideas form clusters; clusters form batches and streams; batches and streams form projects. Work moves forward intentionally when there’s human oversight to shape it.

Use your energy wisely.