How Uwchlan Does Work

Part 1: Operating Rules Reference

This is the short version. If you only read one section, read this one.

What Linear is for

Linear is Uwchlan’s shared system for deciding, tracking, and communicating work.

We use it so any team member or guest can quickly answer:

• What matters most right now?
• What should I work on next?
• What is active versus not started yet?
• What changed recently?
• What needs clarification, ownership, or a decision?

Linear is not just a place to store issues. It is our operating system for prioritized work.

Our default hierarchy

We use Linear in this order:

• Initiatives for major strategic themes or big bets
• Projects for grouped, short-lived, visible pushes
• Issues for the actual units of work
• Docs for lightweight context and decisions
• Project updates for weekly visibility

Most work happens at the issue level. Projects are used when work needs grouping, coordination, and visibility. Initiatives are used sparingly.

Our common workflow

All teams use the same workflow:

• Triage
• Backlog
• Todo
• In Progress
• In Review
• Done
• Canceled

Status meanings

• Triage: New work that has not been fully evaluated yet
• Backlog: Accepted work, but not ready to start
• Todo: Ready to be worked on soon
• In Progress: Actively being worked on
• In Review: Awaiting review, approval, feedback, or final check
• Done: Completed
• Canceled: No longer worth doing

Triage is our intake layer

By default, new work should enter through Triage.

Triage is where we decide:

• Is this worth doing?
• Is it clear enough?
• Who owns it?
• How important is it?
• Should it stay a standalone issue or become part of a project?

Work should not sit in Triage indefinitely. Triage exists to process incoming work, not store unresolved ambiguity.

Nearly every open issue should have a priority

Priority is how we make personal work selection easy.

For most open issues, priority should be set intentionally:

• Urgent: Immediate, exceptional, disruptive work
• High: The small set of most important next work
• Medium: Normal planned work
• Low: Useful, but not important right now
• No priority: Mostly acceptable only in Triage or intentionally parked work

Priority guidance

• Urgent should be rare
• High should stay very limited
• Medium should be the default for most real work
• If too many issues are Urgent or High, priority stops being useful

Strong guidelines

• A person should usually have 0–1 Urgent issues, and this should almost always be 0.
• A person should usually have no more than 2 High issues
• Going above these guidelines should feel like an exception that needs explanation

How people decide what to work on

Each person should mostly work from their own assigned issues.

When deciding what to do next, this is the order:

1. Urgent assigned issues
2. High assigned issues
3. Medium assigned issues in active work
4. Low priority work only when higher-priority work is blocked or complete

People should not need to scan the whole workspace to figure out what to do. The system should make the answer obvious.

When to create a project

Not every issue needs a project.

Create a project when work needs grouping, visibility, and coordination. As a rule of thumb, create a project when two or more of these are true:

• the work spans multiple issues
• the work will last more than 1–2 weeks
• the work needs visibility across people
• the work needs weekly status communication
• the work has a meaningful outcome
• the work needs a shared doc for scope or decisions

Keep work as standalone issues when it is operational, independent, or easy to understand on its own.

What an active project must have

Every active project should have:

• an owner
• a clear status
• a short summary
• a lightweight doc
• weekly project updates

Projects should be short-lived and outcome-oriented. If a project is active, it should represent a real current push.

Active vs. not started

We only want a small number of truly active projects at one time.

As a guideline:

• In Progress = active now
• Backlog = important, but not started yet

If a project is not actually active, it should not be marked active just because we care about it.

Guests use the same system

Guests and collaborators should be able to work from the same system as internal team members.

That means our setup should be:

• clear
• consistent
• easy to read
• not dependent on internal knowledge

Projects, docs, and updates should make work understandable to anyone with access.

Weekly rhythm

At minimum, we maintain this rhythm:

• Review Triage regularly
• Keep priorities current
• Keep active projects limited
• Post a weekly update for every active project
• Close or cancel stale work instead of letting it drift

---

Part 2 — Full Operating Manual

Purpose

Uwchlan uses Linear as the shared system for managing work across teams, collaborators, and guests.

The purpose of the system is not to document every possible activity. The purpose is to create clarity. A good Linear setup should make it easy to see:

• what work exists
• what work matters now
• who owns it
• what grouped efforts are underway
• what changed recently
• what can wait

Our goal is to build a system that is structured enough to support collaboration and visibility, but light enough that people will actually use it consistently.

We are intentionally optimizing for:

• clear project priority
• strong personal prioritization
• lightweight but real visibility for leaders and guests
• a system that can mature over time without needing to be reinvented

Design principles

Linear is a decision system, not just a tracker

We do not use Linear as a passive storage location for issues. We use it to support decisions about:

• what to do now
• what to do next
• what not to do yet
• what no longer matters

Shared clarity beats personal cleverness

Our setup should be understandable to a new teammate, a collaborator, or a guest. We prefer consistent practices over personalized systems that only make sense to one person.

The issue is the basic unit of work

Most work should exist as issues. The issue is where work is assigned, prioritized, and executed.

Projects are meaningful containers, not mandatory wrappers

Projects are useful when work benefits from grouping, shared context, visibility, and weekly communication. They are not required for all work.

Priority must remain scarce to remain useful

Priority is only valuable if it meaningfully distinguishes work. We therefore treat Urgent and High as scarce categories, not as compliments.

Active work should be obviously active

A small number of projects should be active at once. A small number of issues per person should be truly high priority. The system should visibly reflect reality.

Lightweight process is better than performative process

We want enough structure to support execution, not enough structure to create maintenance theater.

How we model work

Initiatives

Initiatives represent large strategic themes, major bets, or cross-project outcomes.

We use initiatives sparingly. Not every project needs one.

Use an initiative when:

• several projects roll up into a larger strategic outcome
• leadership needs a top-level view of a major effort
• the work is clearly bigger than one short-lived project

Do not use initiatives for routine work or as a default layer of organization.

Projects

Projects represent grouped, short-lived, outcome-oriented pushes.

Projects exist to provide:

• visibility
• coordination
• shared context
• an owner
• a home for weekly updates

Projects are especially useful when work spans multiple issues or people.

Projects should be:

• bounded
• legible
• actively maintained
• closed when the push is over

We expect only a small number of projects to be actively running at the same time.

Issues

Issues are the main unit of execution.

An issue should represent a real piece of work that can be understood, prioritized, assigned, and moved through the workflow.

Most operational work should stay at the issue level unless it needs grouping.

Docs

Docs are lightweight knowledge containers. They are used to capture enough context for others to understand the work.

Docs are not expected to be overly formal; they are expected to reduce confusion.

Useful doc content may include:

• scope
• goals
• key decisions
• open questions
• links to supporting material
• definitions of done

Project updates

Project updates are our weekly visibility layer.

They exist to help teammates, leadership, collaborators, and guests understand:

• what changed
• what matters now
• what risks or blockers exist
• what is likely next

Updates should be short, useful, and current.

Workflow definitions

All teams use the same workflow:

• Triage
• Backlog
• Todo
• In Progress
• In Review
• Done
• Canceled

Triage

Triage is the intake stage for new work.

An issue in Triage has not yet been fully processed. It may still need clarification, prioritization, ownership, grouping, or a decision on whether it should exist at all.

Questions we answer in Triage:

• Is this valid work?
• Is it clear enough?
• Which team owns it?
• Does it need an assignee now?
• What priority should it have?
• Does it belong in a project?
• Should it be deferred or discarded?

Backlog

Backlog is for accepted work that we want to keep, but are not ready to start.

Backlog should not mean “forgotten.” It means “real, but not now.”

Todo

Todo is for work that is ready to be worked on soon.

A Todo issue should be reasonably clear and should not need major triage decisions.

In Progress

In Progress means active work is happening now.

This status should be used honestly. It should not become a parking lot for partially owned work.

In Review

In Review means the work is effectively done from the doer’s perspective and is waiting on review, approval, QA, feedback, or final validation.

Done

Done means complete. Use it promptly when work is actually finished.

Canceled

Canceled means we intentionally decided not to do the work, or no longer need it. This is a healthy status, not a failure status.

Triage operating rules

Default intake policy

By default, new work enters through Triage unless there is a strong reason to place it elsewhere immediately.

What triage should accomplish

Triage should turn incoming work into one of a few clear outcomes:

• clarified and accepted
• given a priority
• moved to Backlog or Todo
• grouped into a project
• canceled if not worth doing

What should not happen

Triage should not become:

• a graveyard of vague issues
• a second backlog
• a place where unowned work sits forever

Triage review habit

Triage should be reviewed on a regular cadence so work does not accumulate without decisions.

Issue standards

Every open issue should be clear enough that someone else can understand it.

Minimum expected quality for open issues

Most open issues should have:

• a clear title
• a priority
• enough description or context to understand the ask
• an assignee or an intentional decision to leave it unassigned

Exceptions

The main exceptions are:

• very new issues still being processed in Triage
• intentionally parked work
• quick capture items that are awaiting clarification

These exceptions should be temporary, not the norm.

Priority system

Priority is the core tool for personal work selection.

Urgent

Urgent is for truly exceptional work.

Examples:

• production incidents
• client-critical blockers
• time-sensitive failures
• work that is actively blocking several people
• same-day commitments that cannot slip

Guidelines:

• most people should usually have zero Urgent issues
• occasionally someone may have one
• more than one should feel abnormal and worth revisiting

Rationale: Urgent means the normal system has been interrupted.

High

High is for the small set of most important next work.

Examples:

• the next critical deliverables in an active effort
• the few issues a person should reach for before normal Medium work
• work whose completion meaningfully advances an important current outcome

Guidelines:

• a person should usually have no more than 2 High issues
• in unusual situations, 3 may happen briefly
• if someone has many High issues, the priorities need to be cleaned up

Rationale: High should help focus attention, not replace judgment with noise.

Medium

Medium is the default priority for planned, legitimate work.

Most real open work should be Medium.

Low

Low is for valid work that is not currently important.

Low should be used intentionally, not as a polite version of backlog.

No priority

No priority is acceptable mainly for:

• items still in Triage
• intentionally parked work
• items not yet ready to enter the active decision system

For most normal open issues, no priority should be temporary.

How people should use priority day to day

People should primarily work from their assigned issues.

A typical decision order should be:

1. Urgent assigned issues
2. High assigned issues
3. Medium assigned issues connected to active work
4. Medium assigned issues in normal queue order
5. Low priority work only when appropriate

This approach depends on discipline:

• do not mark too many things High
• use Medium confidently
• revisit stale priorities regularly

The system works best when the answer to “what should I do now?” is visible without a meeting.

Assignment and ownership

Individual issues

Where possible, issues should have a clear owner. If an issue is intentionally unassigned, that should be a conscious decision, not drift.

Projects

Every active project should have a clear owner. That person is responsible for maintaining clarity, not necessarily for doing all the work.

Unassigned work

Unassigned work is acceptable in limited cases:

• early intake
• shared queue work
• work pending triage
• work that is clearly valid but not yet claimed

But unassigned work should not become the default state of important active work.

When work should become a project

Projects are not required for every important issue. They are required when grouping creates value.

Recommended threshold

Create a project when two or more of these are true:

• the work spans multiple issues
• the work will likely last more than 1 week
• the work involves multiple people or handoffs
• the work needs stakeholder visibility
• the work will benefit from weekly updates
• the work has a defined outcome or push
• the work needs a shared doc for decisions and context

Keep work as standalone issues when

• it is routine operational work
• it can be understood independently
• it is small enough not to need coordination
• visibility needs are low
• no grouped narrative is needed

Why this matters

This keeps projects meaningful. If everything becomes a project, the layer stops helping. If nothing becomes a project, active work becomes hard to see.

Project standards

Every active project should have enough structure to be legible.

Required expectations for active projects

An active project should have:

• a clear owner
• a status
• a short summary
• a lightweight doc
• a weekly update

Summary

The summary should make it obvious what the project is trying to accomplish.

Doc

The doc should provide enough shared context to reduce confusion. It does not need to be long.

A good lightweight project doc may include:

• objective
• scope
• constraints
• links
• key decisions
• open questions
• success criteria

Status

Project status must be trustworthy.

• In Progress means active now
• Backlog means not started yet
• Done means complete
• Canceled means intentionally stopped

Updates

Every active project should receive a weekly update, even if the update is brief.

This creates a reliable visibility rhythm for:

• team members
• leadership
• collaborators
• guests

Project updates

Why we require them

Weekly updates force active projects to stay real and visible.

They reduce the need for status meetings by making the current state visible in the system itself.

What a good update includes

A good update should cover:

• what changed
• what was accomplished
• what matters now
• any risks or blockers
• what is likely next

Tone

Updates should be human, concise, and useful. They should not be padded with generic status language. Prefer clarity over grammar.

When an update matters most

Updates are especially important when:

• multiple people are involved
• guests are participating
• leadership needs visibility
• the project has risk or uncertainty
• the project is high priority

Docs as a lightweight knowledge base

Linear can also serve as a lightweight knowledge base.

While Linear is not the primary, long-term knowledge base for Uwchlan, it is important that a person can do work without needing to frequently leave Linear to gather important context.

We are not trying to turn every issue or project into a fully documented system. But we do want enough written context that work survives handoffs and context switches.

Good uses of docs

• project briefs
• decision records
• implementation notes
• client-facing context
• process notes
• links to external material

Standard

If a project is active and important, there should be a doc someone can read to get oriented.

Guests and collaborators

Guests should be able to use the system the same way internal team members do.

That means:

• statuses must mean the same thing across teams
• projects must be understandable
• priorities must be credible
• docs must provide orientation
• updates must help people catch up asynchronously

We should not rely on invisible norms that only internal people understand.

Recommended operating habits

Individual habits

Each person should:

• work primarily from assigned issues
• keep issue status current
• keep issue priority honest
• avoid overusing High and Urgent
• close completed work promptly

Team habits

Teams should:

• review Triage regularly
• review active projects weekly
• keep project statuses current
• post weekly project updates
• clean up stale issues and stale priorities

Leadership habits

Leadership should:

• look at active projects to understand current focus
• use project updates for weekly visibility
• challenge systems where too much work appears Urgent or High priority
• ensure project count stays intentionally limited

What we are intentionally not optimizing for yet

We are not trying to impose maximum process immediately.

For now, we are not optimizing for:

• heavy project bureaucracy
• exhaustive documentation everywhere
• complex labels and taxonomies
• rigid planning overhead

We are optimizing for:

• consistent intake
• clear priorities
• clean active work
• useful project visibility
• a system that can mature naturally

Future concepts we may use more over time

These are useful concepts to keep in mind for future maturity, even if we do not fully adopt them immediately.

Cycles

Cycles may become useful later if we want a stronger planning cadence or more deliberate short-term commitments.

We are not treating cycles as core yet.

More structured saved views

Over time, each person and team should likely have a small set of saved views that support their work.

Examples:

• my active issues
• triage queue
• unassigned open issues
• active projects
• planned projects
• active issues with no project

Stronger initiative usage

As the organization matures, initiatives may become more useful for grouping multiple related projects into larger business bets.

Governance rules for keeping the system clean

A clean system depends less on perfect rules and more on consistent maintenance.

We close things

Completed work should move to Done. Work that no longer matters should move to Canceled.

We do not let priority drift forever

If an issue has been sitting for a long time, its priority should be reconsidered.

We do not let active status become aspirational

If a project or issue is not actively moving, it should not remain marked active indefinitely.

We do not let Triage become a graveyard

Triage should process work forward.

We keep our active set small enough to believe

If too many things are active, the system is lying. A smaller active set is more useful than a flattering one.

Practical summary

At Uwchlan, the system works like this:

• new work comes through Triage
• nearly all open issues get a priority
• people mostly work from their assigned issues
• Urgent is rare
• High is limited and protected from abuse
• most work stays as standalone issues
• grouped, visible, outcome-oriented pushes become projects
• every active project gets a doc and a weekly update
• all teams use one common workflow
• the system should be readable by teammates, collaborators, and guests