To measure how fast your company decides, take the last 15 decisions someone had to wait for, write down when each was asked for and when it was accepted, and note how much of that time anyone was actually working on it. Three numbers come out of it: how long decisions wait, how often they get sent back, and how often work is redone because someone used outdated information. You need a spreadsheet, about 90 minutes and the honesty to include the slow ones.
Most companies never do this. They know how fast individuals work, because the output is visible. They don't know how long a decision sits between people, because that time belongs to nobody. This guide gives you a way to see it in a week. It builds on why AI is fast but handoffs are slow.
What counts as a decision
A decision here is a choice that other people have to act on: a price, a scope, a hire, a launch date, which vendor to use, whether to take a customer's request. Skip choices only you act on.
Start the clock when someone needs an answer to keep going. Stop it when the answer is accepted and the people it affects can see it. That second condition matters. A decision made in a meeting that nobody wrote down has not finished: the next person will ask again.
Step 1: Pick 15 recent decisions
Take the last 15 from one place you can look back through, such as a project board, a chat channel or your calendar. Don't hand-pick. If you choose the ones you remember, you'll choose the dramatic ones and the picture will be wrong.
If your team works in different ways, such as some people remote and some in the office, pick at least five from each group. The split is often the most useful part of the result.
Step 2: Write down seven things for each
Copy this table into a spreadsheet and fill one row per decision. Use working hours, not calendar time, and ask the person who owned the decision for anything you can't read from the records.
| Decision | Asked | First useful answer | Accepted | Hours of real work | Sent back? | Redone later? |
|---|---|---|---|---|---|---|
| Discount for a new customer | Mon 10:00 | Mon 15:30 | Wed 11:00 | 2 | Once | No |
This row uses a made-up decision. The columns do three jobs:
- Asked, first useful answer, accepted give you the waiting. The gap between asked and the first useful answer is context waiting. The gap between that and accepted is approval waiting.
- Hours of real work lets you separate time spent working from time spent waiting. Ask the owner, "how many hours did you actually spend on this?" A rough answer is enough.
- Sent back and redone later catch the two costs that never show up as delay: an approver asking for something that was missing, and work thrown away because the plan had changed.
Step 3: Work out three numbers
1. Decision wait. For each row, subtract the hours of real work from the time between asked and accepted. Then take the median of the 15 results, and also note the slowest quarter. Use the median, not the average. Waiting times are lopsided: in one large study of email, the median reply took 47 minutes while the average was nearly 20 hours (Kooti and others, 2015). A few long waits drag an average up and hide how a typical decision goes.
2. Send-back rate. Count the decisions that were sent back at least once and divide by 15. Each send-back is another trip through the queue, plus the work of fixing whatever was missing.
3. Redo rate. Count the decisions where someone later redid work because they were using an old plan, an old price or an old answer, and divide by 15. This is the most expensive of the three, and the one people forget, because it looks like progress until it's thrown away.
The same measures work for how long a new task takes to start. Add one more column, "assigned to first real work", if you want that number too.
Step 4: Read what you found
Look for patterns before you look for blame.
- Concentration. Do most long waits end at the same one or two people? That's usually a queue, not a performance problem. It is the fastest thing to fix.
- Missing context. Do the first useful answers keep arriving late because someone had to find out what was decided before? Count those. They are the handoffs a shared record of decisions would remove.
- Work style. Compare your groups. Remote, hybrid and in-office teams often wait in different places. Time-zone gaps add a day when a question lands after someone has logged off.
- Send-backs by approver. If one kind of request keeps coming back, the request is missing the same thing each time.
Don't count deliberate thinking as waiting. A decision that took three days because the owner was weighing a hard trade-off is slow for a good reason. Count only time when nobody was working on it.
What other studies found
Published studies measure different things in different settings, so none is a benchmark for your company. They do show that gaps of this size are real.
- At Google, a code change waits a median of under four hours for review. Studies of other organisations found medians of roughly 15 to 20 hours for the same step (Sadowski and others, 2018).
- In one telecom company, work spread across several sites took about two and a half times as long as comparable work at one site (Herbsleb and Mockus, 2003).
Make it a habit
Do the 15-decision sample once, then repeat it every month or two with the newest 15. You're looking for the trend, not a perfect number, and the trend is what tells you whether a change helped.
Three habits make the numbers better, whichever tools you use:
- Write decisions down once, where everyone can see them. A decision that is accepted and visible doesn't get asked again. In OrgSync, accepted decisions are shared updates that every teammate's AI app can answer from, with citations, and each carries a status of current, proposed or replaced, so an old plan doesn't pass as the new one.
- Make approval a quick yes. OrgSync asks the approver in their own AI app, about the exact draft, so a decision doesn't wait for a meeting.
- Make requests explicit. A request with a recipient, a due date and a clear finish, such as the one
/orgsync:requestcreates, is harder to lose than a message in a chat.
A short weekly review, with /orgsync:review, is also a natural moment to look at the three numbers. For the wider picture, read what a company brain is or visit Help.
Kaustubh Dhotre, Co-founder, OrgSync