Problem owner: who fixes what, and by when

A problem owner is the one person who answers for a problem until it is solved. Not the person who does every task. Not the person who complains loudest. One name, one problem, one date. This post shows you how to name a problem owner, set who fixes what and by when, with a template you can copy and a way to track it.

What a problem owner is and what they are not

The owner is accountable for the outcome. They make sure someone picks a fix, that the fix gets tried, and that the result is written down. They may do the work themselves, or they may ask others to help.

An owner is not:

• The person who caused the problem.
• The most senior person in the room.
• A committee. "The team" is not an owner.
• Someone who was never asked.

The same idea works outside of work. A leaking tap in a shared flat, or a tool that keeps breaking at a makerspace all need a name next to them. In a shared workshop, the same pattern shows up in makerspace tool problems.

Why problems stall when nobody owns them

Everyone sees the problem. Everyone assumes someone else is on it. Weeks later it is still there, and now it has company.

Three things usually go wrong:

• Diffusion. When five people could act, each waits for the others.
• No next step. The problem is named, but nobody wrote down what to try first.
• No memory. A fix was tried, failed, and nobody recorded it. Someone tries it again.

An owner fixes the first two directly. A written record fixes the third.

How to choose the right problem owner

Pick the person who can act, not the person who is easiest to blame. Ask three questions:

1. Who is closest to the problem and feels it first?
2. Who has the access or authority to try a fix?
3. Who has enough time in the next two weeks?

If one person answers all three, you are done. If not, choose the person with authority and time, and let the closest person feed them details. Ask the person first. An owner who never agreed is an owner in name only.

Set the fix and the deadline

An owner without a fix and a date is just a label. Write all three parts in one line.

Dana will test a second invoice reminder by Friday 24th.

That sentence has a who (Dana), a what (test a second reminder), and a by when (Friday 24th). The "what" should be a single thing you can try, not a plan to think about it.

Keep the first fix small. If you have several ideas, do not launch them all at once. Try one, record the result, then move on. The post on testing one change at a time explains why. If you want to keep several options alive before you commit, read about set-based thinking.

Pick a date that is a check-in, not a promise that the problem will be solved. "By Friday I will have tried it and written down what happened" is a date an owner can keep.

A simple problem owner template you can copy

Paste this into any note, ticket or chat:

• Problem: one line, in plain words.
• Owner: one name.
• First fix to try: one action.
• Check-in date: a specific day.
• Outcome: worked, partly, or failed, plus one sentence on what you saw.
• Next step: keep, change, or drop.

A filled-in example:

• Problem: Customers pay invoices late.
• Owner: Dana.
• First fix to try: Send a reminder three days before the due date.
• Check-in date: Friday 24th.
• Outcome: Partly. Two of five paid earlier.
• Next step: Keep it, and try a phone call for the other three.

That example is made up to show the format. Use your own numbers.

Check progress and handle missed dates

On the check-in date, ask only two questions: did the owner try the fix, and what happened? Do not ask why it is not solved yet. That mixes up trying with succeeding.

If the date is missed, look for the reason before you change the owner:

• Too big. Split the fix into a smaller one.
• Blocked. Something the owner needs is missing. Name it and make it its own problem.
• No time. Reassign, and say so openly.
• Not agreed. The owner never took it on. Ask again.

A failed fix is not a missed date. It is a result. Write it down as failed so nobody repeats it. A fix that failed three times is useful to the next person who looks at the problem.

One problem, one owner, one first fix, one date, and the outcome.

Owner vs. assignee vs. stakeholder: what is the difference?

• Owner: answers for the outcome of the whole problem.
• Assignee: does one task that helps. A problem can have several assignees and still one owner.
• Stakeholder: is affected by the problem or its fix, and wants to be kept informed. They do not do the work.

If you cannot tell who the owner is, you probably have stakeholders and assignees but no owner. Fix that first.

Frequently asked questions

Can a problem have more than one owner?

It is better to have one. Several owners tend to bring back the old habit of each waiting for the others. Name one owner and list the others as helpers.

Should I be the owner of my own problem?

Yes, for personal problems you are the owner by default. A date still helps, because it turns "I should deal with this" into a check-in you can keep.

What if nobody wants to own it?

Make the first fix smaller until someone can say yes. If it still has no owner, the group has decided it is not a priority, and it is better to say that out loud.

How long should the deadline be?

Short enough to feel real, usually a few days to two weeks for the first fix. The date is for a check-in on what you tried, not for the final answer.

Get started: track every problem owner in Problem Graph

Problem Graph is a journal that draws itself as a map. You write the problem down in one line, put it in a lane (personal, work, expert or scientific), and attach the solutions you try. For each one you record the outcome: worked, partly, or failed. The graph remembers what happened, so a failed fix stays on the map as a failed fix, and anyone who looks can see it before deciding what to try.

For owners, a few features help. Mark one problem as a main node, and you can share it into a private network (a team, a family, a study group) by giving a few people the invite code. Members of that network see it. Keep in mind that the app says anyone with the invite code can join, so only hand the code to people you want in. Only a main node can be shared. A problem you only link to it stays home with the rest of your graph. You can also put a main node out for everyone, so others can link their own problems and borrow solutions that worked.

Put the owner and the date in the problem line or in the solution text, for example "Late invoices: Dana, reminder test, by Fri 24th". Then record the outcome when the date arrives.

Try Problem Graph: it is free, and you can look around the public network without an account. Write one problem down in a line and attach the first thing you will try. You can open the app directly at problemgraph.vlvd.net/app.