Working in Teams (Next Level)

When Grunna is small, ownership and decisions often stay naturally clear. As you grow, one kind of problem shows up again and again: friction about who owns what, who decides, and how work moves between teams.

This page describes how Grunna works when you scale to many teams — without adding meetings, consensus rituals, or a planning hierarchy. The goal is simple: keep work calm, keep priority local, and kill conflicts fast — while still allowing meetings when they are the fastest way to clear ambiguity.

The Core Rule

A List DO decides the order of work in their list. Always.

That includes:

what is done next
what is delayed
what is dropped
what interrupts existing work

No one outside the list can override that. Not another List DO. Not a project function. Not a stakeholder.

You can always ask another team to do something, but you can never prioritize in someone else’s list.

Roles (Only Two That Matter)

Grunna does not need a role hierarchy for planning. It only needs clarity on two decision rights.

1) List DO (List Decision Owner)

Each list has exactly one List DO.

The List DO owns:

priority and order of work
acceptance of outcomes
whether a request becomes real work
tradeoffs when something “comes in between”

If it’s in the list, the List DO decides when it happens.

2) Ownership DO (Org DO or Project DO)

This role exists for one single purpose:

To decide ownership when teams disagree about who should own a todo.

That’s it.

Ownership DO does not decide:

what is done next
deadlines inside a list
how a list is managed
who should be pulled off current work

Ownership DO only answers:

Which team/list owns this todo?

Once ownership is decided, the relevant List DO is fully in charge of when.

Org DO vs Project DO (No Planning Hierarchy Required)

You don’t need a hierarchy like Org DO → Project DO → List DO.

Use whichever is simplest:

Project DO: if you want an ownership referee per project.
Org DO: if you want a single ownership referee across the organization.

Both do the same job: ownership arbitration only.

If you grow large enough, you may skip Project DO entirely and use Org DO as the sole ownership referee.

Ownership is a Verdict, Not a Consensus Ritual

When ownership becomes unclear, teams tend to negotiate, argue, or loop in more people. Grunna avoids that by making ownership a fast decision.

The goal is not to make everyone agree. The goal is to end the argument and keep work moving.

Sometimes the best way to get clarity is a short discussion. That discussion is input — the decision is still a decision.

A disagreement appears: “Should this todo live in Team A or Team B?”
A short discussion may happen to surface constraints, risks, and options.
The Ownership DO makes the call: “This is owned by Team B.”
Done.

No “we’ll decide later”. No endless back-and-forth. If it turns out wrong later, ownership can be moved by the same mechanism.

Cross-Team Work Without Forcing Priority

Even when another team owns the domain, work can still move forward without constant coordination — as long as ownership and priority remain clear.

Grunna uses two patterns for cross-team work:

Do + Owner Review (Default Pattern)

This is the default way to work across teams.

The idea is simple:

Team A can execute the work (even if it touches Team B’s domain).
Team B remains the owner of correctness and acceptance.
Team B is not asked to “do 10%” that never gets prioritized.
Team B only needs to review and decide: accept or request changes.

The review is tracked as a cross-team subtodo owned by Team B’s list.

A cross-team review subtodo should include:

Owning list (Team B)
Reviewer (default: Team B’s List DO or a named reviewer)
Acceptance criteria (what “correct” means)
Result must be one of: Accept / Changes requested

There is no “Reject”. The owner team cannot block the entire todo by refusing a review. If something is not acceptable, the outcome is always “Changes requested” with concrete requirements.

Reviews go to the top (like bugs)

A review is not “help”. A review is part of owning a domain. Because of that, review subtodos behave like bugs: they go to the top of the owning list.

Rule: reviews must be handled before starting new “normal” work. This prevents the classic 90/10 problem where a todo is 90% done and then waits forever for the last decision.

This does not mean other teams can force you to build features. They can only force you to decide whether a proposed change is acceptable inside your domain.

What a review can return

Accept — the change meets the acceptance criteria.
Changes requested — the change does not meet the criteria yet. The request must be specific and actionable.

“Changes requested” must map to the acceptance criteria. It cannot be used as an endless “I don’t like it” loop.

A review must be ready to jump the queue

If reviews always go to the top, they must be cheap to process. A review request that is incomplete is treated as “Changes requested” on the request itself.

A review request is only ready when it includes:

Acceptance criteria (what “correct” means)
What changed (short summary)
Where to review (PR/spec/link)
What decision is needed (what you want the owner to confirm)

If this is missing, the owner team returns “Changes requested: make the review request complete”.

Review debt is a signal

If a team constantly has many reviews at the top of their list, that is not a scheduling failure. It is a structural signal:

the team owns too much surface area, or
the team is becoming a bottleneck, or
other teams are pushing too many changes through that domain.

In Grunna, that signal is valuable. It tells you where ownership boundaries or autonomy are not working.

Escalation when review loops or is abused

Sometimes review will loop, or teams will try to use reviews as disguised work requests (“please implement this for us”).

When that happens, do not turn it into endless async arguments. Run a short alignment discussion to clarify the acceptable approach, and let the Ownership DO set the final acceptance criteria if needed.

After that, reviews become mechanical: accept when criteria are met, request changes when they are not.

Capability Loan (When Competence is Missing)

Sometimes Team A cannot realistically do the work themselves. This is not a review problem — it is a competence problem (access, risk, deep specialization).

In that case, Grunna does not try to solve it with negotiation between teams or by forcing priority in another list. Instead, it uses a capability loan.

A capability loan is a decision made by the Ownership DO: a temporary capability is allocated from Team B to Team A so the todo can finish.

Rules:

The Ownership DO can stop a todo by refusing a capability loan. This is intentional. If the organization is not willing to allocate the required capability, then the todo is not important enough to be done right now.

This does not mean the Ownership DO controls list priority. It means the Ownership DO controls whether scarce cross-team capability is allocated at all.

The Ownership DO may allocate a capability loan.
A capability loan never breaks ongoing work. The person finishes their current todo first.
The loan is scope-based: it is defined as a concrete contribution (a specific change, a specific review, a specific implementation step, or a specific decision).
The loan is not time-based. Grunna does not allocate “two hours” or “one day”. Either the capability is allocated to complete the required part, or it is not allocated.
The loan does not give Team A the right to prioritize Team B’s list. It is separate from list priority.
The loan exists to remove blockers caused by competence gaps, not to create a new service queue.

This keeps the system calm: it replaces negotiation with a clear decision, without turning the Ownership DO into a planning manager.

Meetings Are Allowed (But Never Required)

Grunna is not anti-meeting. Meetings can be the fastest way to clear confusion, especially when the cost of being wrong is high or async discussion is already wasting time.

The difference is that Grunna does not treat meetings as a “everyone must agree” ritual. Meetings are used to surface constraints and options. Decisions are still decisions.

If a meeting happens, it exists to improve the decision — not to replace it.

1) Ownership Clarification Meeting

This is the most common “worth it” meeting: a short discussion to figure out which team should own a todo when it’s not obvious.

Participants: involved List DOs (and specialists if needed).
Goal: clarify boundaries, risks, access constraints, and the cheapest path forward.
Outcome: the Ownership DO makes the ownership verdict.

The meeting can influence the decision, but it does not require consensus.

2) Design Alignment When “Review” Is Not Enough

Most cross-team issues can be solved with “Do + Owner Review”. Sometimes that is not enough, because the shape of the solution itself is unclear and multiple domains must agree on a single approach.

A short design alignment meeting can be worth it when:

there are multiple valid approaches and the wrong one would cause rework for multiple teams
interfaces/contracts are being created or changed in ways that affect many consumers
risk is high (security, stability, data loss, platform-wide impact)
review would otherwise turn into a long loop of “changes requested” without convergence

This meeting should end with a clear decision: which approach is acceptable and what the acceptance criteria are. Then work continues async, with review as the guardrail.

3) Capability Loan Negotiation (Only to Define the Loan)

If a capability loan is needed, a short conversation may be useful to define what is being loaned: scope, constraints, and the smallest useful unit (one session, one change, one review).

The Ownership DO still makes the final call.
No ongoing work is broken.
The loan is defined to reduce disruption and prevent “open-ended help requests”.

After the decision, the owning List DO still decides when things happen in their list, and the loan happens when the loaned person completes their current todo.

Definition of Ready for Cross-Team Todos

Cross-team work becomes chaotic when teams start work without clarifying what they need from others.

For any todo that crosses competence or ownership boundaries, the todo is not “ready” until:

Ownership is clear (which list owns the domain and acceptance).
The cross-team interaction is chosen:
- Do + Owner Review (default)
- Capability Loan (only when competence is missing)
The required review/decision is written as a subtodo with acceptance criteria.

This is not a negotiation step. It is a clarity step. It prevents the “90% done, 10% forever” problem before it starts.

Handling Interruptions (“Things That Come In Between”)

Interruptions are inevitable. The rule stays the same:

Only the List DO can interrupt their own list.

If something must cut the line, the List DO makes the tradeoff visible:

something else moves down
something else is paused
something else is removed

This avoids hidden scope creep and protects focus.

If something comes in, something else must move out.

Avoid the Micro-List Trap

When teams grow, a common reaction is to create many small lists to reduce ownership and localize responsibility.

It feels clean — but it creates a hidden problem:

you lose the ability to prioritize across related work
progress becomes fragmented
completion is harder to see, because “done” is spread across too many queues
work gets stuck in dependencies between small lists

Many small lists don’t reduce complexity — they distribute it.

Micro-lists often exist because people want less responsibility, less conflict, or fewer hard tradeoffs. But those tradeoffs still exist — they just become invisible and harder to resolve.

Prefer Fewer, Larger Lists

Grunna scales better when lists are large enough to own a meaningful slice of reality.

A larger list makes it possible to:

prioritize tradeoffs inside the same queue
see what is finishing soon (real progress)
avoid constant negotiation between small owners
keep “what matters” visible

A list should own an area, not a task type.

If a list becomes too big, split it by autonomy — not by convenience.

Split by Autonomous Blocks

The most stable way to divide work is into autonomous blocks:

clear boundaries
minimal dependencies
each block can move forward without waiting on others most of the time

A block can be:

a product area
a service or domain boundary
a client surface + its backend
an internal capability (billing, identity, search)

The goal is not perfect isolation — the goal is low-friction ownership.

Platform / DevOps Teams (Working Across Everything)

Some groups naturally work across the whole stack — typically platform, infrastructure, DevOps, security.

They are not a problem. They’re a reality.

But they still need the same clarity:

they should have their own lists
they should still operate with a List DO
they should avoid becoming a general “catch-all queue” for everyone’s problems

A strong platform/devops group often has the capability to solve almost anything — and that’s valuable. The risk is that everyone starts routing work through them because it’s easy.

To keep this healthy:

use platform work as enablement (tools, patterns, pipelines, self-service)
use cross-team reviews and integration points
keep ownership in the domain teams whenever possible

Platform teams should remove bottlenecks — not become the bottleneck.

When to Split a List

Split a list when the current list can no longer operate as a single priority queue without constant internal conflict.

Good reasons to split:

Autonomy is real: two areas can move forward independently most of the time
Different definition of done: acceptance is consistently owned by different domains
Priority is constantly contested: the List DO is forced into two unrelated priority games
Cross-team reviews dominate: most work requires decisions from another internal group
Ownership decisions are frequent: you often debate which team owns this todo

When you split, split into autonomous blocks — not into smaller responsibilities.

When NOT to Split a List

Do not split a list just to make it feel smaller or cleaner.

Common bad reasons:

“This is a different type of work” (bugs vs features)
“We want less ownership pressure”
“We want to avoid hard tradeoffs”
“This will reduce conflicts”
“This matches our internal reporting structure”

Splitting to avoid decisions usually creates more conflicts later, because priority becomes impossible to compare across lists.

If splitting reduces arguments today but increases dependencies tomorrow, it’s a bad split.

A Simple Litmus Test

Before creating a new list, ask:

Does this list own an autonomous block?
Will this list be able to prioritize meaningful tradeoffs internally?
Will this list make progress more visible (what is finishing soon)?

If the answer is “no”, you’re probably creating a micro-list to avoid ownership — and you’ll pay for it later in coordination.

Example: Finishing a Cross-Team Todo Without Consensus Planning

Context: Team A owns “Project UI” and needs a small change in an auth claim owned by Team B (“Platform”). Team B is not interested in the feature and will not prioritize a small “10% task” just to help Team A finish.

Step 1: Team A creates the parent todo in their list

Todo (Team A list): “Add new project overview screen”
Cross-team risk: “Requires auth claim change owned by Platform”

Step 2: Team A chooses the default pattern (Do + Owner Review)

Team A implements the change themselves (code/spec/PR). Team B is only asked to review correctness.

Review subtodo (Team B list): “Review auth claim change for project overview”
Acceptance: “Backwards compatible, matches platform rules, does not break existing clients”
Outcome must be: Accept / Changes requested

Step 3: When review is looping, a short alignment meeting happens

If the review turns into repeated “changes requested” and the teams are not converging, they do not keep looping in async arguments. They run a short design alignment meeting to decide what “acceptable” means and to lock the acceptance criteria.

The meeting improves the decision. It does not require everyone to agree.

Step 4: If Team A cannot execute, they request a capability loan

If the change requires access or deep expertise Team A doesn’t have, Team A requests a capability loan instead of starting and hoping someone else will later do the last part.

Team A requests a loan from the Ownership DO: “We need one Platform session to implement/validate claim change.”
The Ownership DO allocates a capability loan (without breaking ongoing work): “Platform will provide one session after the current todo completes.”
The loan is scoped: one change / one session / one review decision.

Outcome: The todo finishes without consensus planning. Either Team A completes and Team B reviews, or competence is temporarily allocated by decision — without turning into endless negotiation or meetings.

Summary

List DO decides order. Always.
Ownership DO decides who owns a todo only when there’s conflict.
Default cross-team pattern: Do + Owner Review with outcomes Accept / Changes requested (no “Reject”).
When competence is missing: Capability Loan is a scope-based allocation decided by the Ownership DO (never breaking ongoing work).
The Ownership DO can stop a todo by refusing a capability loan. This is intentional: it means the todo is not important enough to allocate scarce capability.
Meetings are allowed when they reduce waste, but they are never required for “everyone to agree”.