Decision rights map for software teams under ten people

Why small teams stall on simple calls

Small teams rarely slow down because a decision is hard. They slow down because several people feel close enough to the decision to weigh in, but nobody knows who has the final say. A team of six or nine people can sound aligned in a meeting and still get stuck on basic calls by Wednesday.

The first sign is repeated asking. A product manager checks with the founder, then the engineering lead, then the person who last spoke to the customer. If those answers differ even a little, people stop trusting the process and start collecting permission.

Scope gets messy in the same way. A new request lands on Tuesday, someone calls it a small change, and the work slips into the week without a clear tradeoff. By Friday, planned work has moved, the deadline feels shaky, and nobody can point to the person who approved the change.

Incidents expose the problem faster. An alert fires, people jump on a call, and the first few minutes disappear while the team figures out who can roll back a release, post an update, or contact a vendor. The delay often comes from uncertainty, not the bug itself.

Vendor calls create a quieter version of the same mess. One teammate asks for pricing, another asks for a trial, and someone else tells the vendor the team will decide next month. The company sends mixed signals because nobody owns the relationship or the final yes or no.

This is common in early teams because people rely on memory and proximity. They assume they can sort things out in a quick chat or by asking whoever is online. That feels fast for a while. Then it starts wasting hours every week.

A decision rights map fixes that drag. It does not add layers. It does not slow people down. It tells the team who decides on scope, who owns delivery, who acts during incidents, and who speaks for the company when a vendor needs an answer.

What belongs on the map

The map should cover the decisions that slow people down every week. If nobody can answer in 30 seconds who decides something, it probably belongs on the page.

Start with recurring decisions, not edge cases. Focus on the small set of choices that block planning, coding, releases, support, and spending. Most teams under ten need the same core areas:

• scope changes during active work
• release timing and readiness
• incidents and outages
• vendor choices, renewals, and tool spend

Be specific. "Product direction" is too broad to help. "Can we cut this feature from the next release?" is clear. "Who can approve a new monitoring tool?" is clear too.

Each line on the map needs three labels: one person who decides, the people who give input before the call, and the people who need to know after. That keeps ownership simple without cutting out useful context.

One owner matters more than a committee. A founder can still ask for advice, but one person must make the final call on scope, delivery, incidents, or vendor questions. When two people share the last word, work usually pauses until they agree.

Keep each decision short. A simple format works well: decision, owner, input, informed. For example: "Move release date by more than one week | CEO decides | engineering lead and product give input | team and support are informed."

Short maps work better than complete ones. If people need ten minutes to scan it, they will stop using it. Aim for one page that a new hire can read in two minutes.

A quick test helps. Take four common situations and see if the owner is obvious: a late feature request, a production bug, a vendor discount that expires today, and a promised customer date. If the answer still feels fuzzy, the map is too vague.

Pick the decisions that need one owner

Most teams make this bigger than it needs to be. You do not need a map for every possible choice. You need one for the calls that come up every week or every month, slow work down, and send people into Slack asking who can say yes.

Good candidates include:

• adding or cutting work during the current sprint
• moving a release date
• declaring an incident and pulling people into response
• approving a new tool or renewing an existing one
• accepting a workaround when the ideal fix will miss the deadline

Each decision needs one owner, not a pair. Shared ownership sounds fair, but it often means two people wait for each other or settle the argument in private while the team waits.

That only works if you separate advice from approval. An engineer can explain risk. A product person can explain customer impact. A founder can explain business pressure. Those views matter, but they are not the same as final approval. Write both roles down so nobody confuses influence with authority.

Absences matter more than teams expect. If the owner is away for two days and nobody knows the backup, work stops or people route around the process. Add one backup for each decision and say when that backup steps in: vacation, sick leave, or no response within an agreed time.

Leave rare exceptions out of the first draft. If a decision happens once or twice a year, skip it for now. Cover the few calls that create most of the daily friction. You can add the strange cases later.

Build the first version in one session

Maps like this go stale fast when people build them across Slack threads and half finished notes. Get the founder, product lead, engineering lead, and the person who owns operations into one live session and finish a first draft in 60 to 90 minutes. If one person wears two hats, keep both roles in the discussion anyway.

Start with real friction. Open a shared page and list the ten decisions that caused delay, rework, or quiet confusion in the last few weeks. Write them in plain language, such as "who cuts scope when a release slips" or "who approves a new tool that costs money each month."

Then move through each item quickly:

• read the decision out loud
• pick one owner
• note who gives input
• set a time limit if the call often drags
• move on without polishing the wording

Do not leave any item with "shared ownership." That usually means nobody wants the final call, so the team waits for a hallway guess or for the founder to step in.

Add a few rules for ugly moments. If production goes down after hours, the person handling operations should not wait for a group vote to act. If a vendor outage affects customers, decide who contacts the vendor, who updates customers, and who approves temporary spend. Keep these rules short enough that someone can remember them at 2 a.m.

The first version will have gaps. That is normal. Run it for one sprint and watch for the same signs of trouble: repeated pings to the wrong person, decisions that bounce between two leads, or issues that still end up with the founder by default.

At the end of the sprint, spend 20 minutes fixing weak spots. Remove decisions nobody actually makes, split the ones that are too broad, and rename vague items until a new team member could follow them without asking three people first.

Set clear rules for scope and delivery

A small team moves fast until someone slips in "one quick thing" halfway through the week. Then nobody knows whether to stop planned work, delay the release, or cut something else. The map should make these calls boring and clear.

Write the rules in plain language so a new person can understand them in five minutes.

• One person owns scope after a sprint starts. In most teams, that is the product lead, founder, or CTO. Anyone can suggest work, but only that owner can add it to the current sprint.
• One person can move a release date. Keep that right narrow. If three people can delay a launch, the date will drift.
• One person accepts tradeoffs between time, scope, and quality. Engineers estimate the cost. The owner decides what to cut, delay, or fix now.
• Engineers can push back on late changes when those changes raise risk, reduce testing, or add support load. They should explain the consequence in plain terms.
• The founder keeps a short list of calls: company direction, major customer promises, budget, and hires. Daily delivery decisions should stay with the team.

This last point matters a lot. If every scope change waits for the founder, the team slows down and the founder becomes the bottleneck. If the founder hands off every call too early, the team can ship work that misses the business goal. Draw the line on purpose.

A simple rule works well: the founder decides why and when it matters to the business, the delivery owner decides what fits in the release, and engineers decide how to build it safely.

Late changes also need a clean path. Engineers should be able to say no to work that creates hidden risk, but they should offer options. That might mean a smaller version now, a full version next sprint, or a swap with another task. That keeps pushback practical instead of personal.

Assign incident and vendor decisions

Outages get worse when nobody knows who can make the call. Your map should remove that pause. Name one person who can declare an incident, one person who can stop change, one person who sends updates, and one person who approves vendor spend.

Give one person the authority to say, "This is an incident," even when the cause is still unclear. In a team under ten, that is often the engineering lead, CTO, or current on call owner. Anyone can raise the alarm, but one named person starts the response, sets severity, and pulls in the right people.

Do the same for deploys and rollbacks. Do not wait for a group vote while errors climb. If the release owner is available, that person can pause the deploy or roll it back. If not, the incident lead takes over.

Communication needs one voice too. During an outage, one person should speak to customers, partners, or internal teams. That might be the founder, support lead, or account manager. The incident lead should approve the facts first so nobody sends guesses or half fixed explanations.

Vendor decisions need the same clarity. Small teams lose time on trial tools, surprise renewals, and awkward budget questions. Split the call by cost and risk, then write the threshold down.

Bring extra people in only when the tool creates real exposure:

• security joins when a vendor touches production data, customer data, access, or code
• finance joins when spend crosses your limit, adds a long contract, or duplicates an existing tool
• legal joins when terms cover data handling, IP, liability, or customer commitments

A simple rule usually works: one owner approves the trial, one budget owner approves the spend, and specialists join only when the tool creates a real issue. Teams that cover a lot of ground with few people need this kind of discipline. If you write these calls down now, the next outage or vendor pitch takes minutes instead of a long Slack debate.

A simple example from a nine person team

Take a nine person product team: one founder, one engineering lead, five engineers, one designer, and one customer lead. They move fast when ownership stays narrow. They slow down fast when two people both think they have the final call.

The founder owns product direction. She picks the problem to solve, the goals for the quarter, and the order of larger bets. She does not swap sprint work on a Wednesday because a customer sent a loud message. If she wants a change, she brings it to the engineering lead, who decides whether it waits for the next planning session or replaces something already in flight.

Release decisions sit with the engineering lead. He decides if the build is ready, if test results are good enough, and if the team should ship, delay, or roll back. That rule matters most under pressure. When errors rise after a release, he can roll back in minutes instead of waiting for founder approval.

During office hours, one engineer on rotation leads incident response. That engineer opens the incident channel, pulls in the right people, keeps a short timeline, and says when the incident is over. Others help fix the problem, but one person owns the response while the issue is live.

Vendor choices caused another kind of drift. The founder had strong opinions on tooling, especially when cost or lock in looked risky, but the team gave one person final signoff. In this case, the engineering lead chose development and infrastructure vendors after hearing input from the founder. The founder stopped becoming the last minute bottleneck on small purchases.

This map did not appear on day one. The team wrote it after two avoidable problems: they missed a deadline because the founder changed scope midweek, and they had a noisy outage because two engineers both waited for the other to lead. After that, they updated the map whenever a miss exposed fuzzy ownership. The document stayed short, but the rules got sharper.

Mistakes that create new confusion

A decision rights map fails fast when two people think they own the same call. If the product lead can approve scope, but the tech lead can also overrule it, nobody knows which answer sticks. People wait, reopen old debates, or ask both and follow the reply they prefer.

Another common mistake is making the page too big to use. A team of eight does not need a giant chart with dozens of rows, color codes, and approval labels. They need a short page that answers plain questions: who decides, who gives input, and who fills in when that person is out.

Backup owners matter more than most teams expect. Holidays, sick days, and family emergencies always hit at the worst moment. If only one person can approve a rollback, pick a vendor, or sign off on a release delay, work stops the second that person disappears.

Role drift causes quieter damage. A founder takes over product, an engineer becomes team lead, or a contractor starts handling operations. The team keeps the old map because it is "mostly right." Mostly right is enough to send people to the wrong owner and create messy handoffs.

Some teams make a different mistake: they use the map to avoid hard priority calls. A document cannot decide whether the team should fix churn, ship a feature, or clean up a brittle service. People still need to discuss tradeoffs. The map should show who makes the final call after that discussion, not replace it.

One quick test exposes the problem. Ask three people, "Who decides if we cut scope, delay delivery, or replace a vendor?" If you get three different answers, the map is unclear. If you get one answer and everyone hates it, the issue is not documentation. It is ownership.

Quick checks and next steps

A usable map removes hesitation in ordinary work. It should not become another process page that nobody opens. If a teammate still pauses and asks, "Who can approve this?" for the same issue twice, the map is not clear enough.

Run a short reality check with the team. Ask each person, on their own, who can order a production rollback. If you get different answers, fix that first. Rollbacks are time sensitive, and confusion there usually means other decisions are fuzzy too.

Then test the outside edge of the team. Pick one active vendor and ask a simple question: can that vendor get one final answer from your company in one day? If sales talks to them on Monday, engineering on Tuesday, and finance on Wednesday, you do not have ownership. You have delay.

Scope change is another fast test. During a sprint, who can add work, remove work, or trade one item for another? Teams often assume everyone knows this. They usually do not. Write the rule in plain words, including who can say yes and who must be told after the change.

A short review catches most gaps:

• name one owner for rollbacks, with one backup
• name one person who gives vendors the final answer
• state who can change scope during a sprint
• keep the map in one short document, not scattered across chat and tickets
• add it to onboarding so new hires learn the rules in their first week

One page is enough for many teams under ten. If you need a meeting to explain every line, the map is trying to do too much.

If roles still blur after a few weeks, an outside review can help. Oleg Sotnikov at oleg.is works with startups and small companies as a fractional CTO and advisor, and this kind of ownership cleanup is often one of the fastest ways to remove daily friction.