# Is your engineering coordination tax eating delivery time? > Measure engineering coordination tax with calendars, chat threads, ticket handoffs, and waiting time to find payroll lost to avoidable work. Most engineering payroll does not disappear in bad code. It disappears in the space between people: waiting for a decision, translating a request, finding the owner, reopening a ticket because context was lost, and sitting through a meeting that exists because nobody wrote down the rule. That cost is measurable. You will not get a laboratory-grade number, and you do not need one. You need a credible estimate that separates necessary collaboration from work the team performs only because its operating model keeps creating avoidable dependencies. Call that estimate your coordination tax. The useful question is not whether engineers collaborate too much. Software teams must collaborate. The question is how much paid time goes toward moving work between people rather than advancing the work itself, and which recurring bottleneck creates the biggest bill. ## Coordination tax is paid time spent moving work Coordination tax is the payroll cost of arranging, clarifying, transferring, checking, approving, and waiting on work beyond the collaboration that the work genuinely requires. It includes scheduled meetings, but meeting hours are only the portion that shows up neatly on a calendar. A product manager explaining an ambiguous request to three engineers, an engineer asking where a configuration lives, a developer waiting for a review, and a staff engineer answering the same deployment question for the fourth time all create coordination cost. The people involved may work hard throughout. Hard work does not make the cost disappear. Keep three categories separate, because teams regularly blur them and then argue about the wrong thing: - **Direct progress** changes the product or reduces a known technical risk. Writing code, testing a fix, investigating a production failure, and making a design decision belong here. - **Necessary coordination** lets people make a decision or integrate work that cannot sensibly happen in isolation. A short design review for a risky change may save weeks of rework. - **Recoverable coordination** exists because responsibility, information, access, or decision rights are badly arranged. Repeated status meetings, approval queues with no stated standard, and handoffs into a black box belong here. The third category is the tax. It is recoverable because a different team design, operating rule, or technical boundary can reduce it without lowering engineering quality. Do not label every meeting as waste to make the estimate look dramatic. That is amateur accounting. A 45-minute incident review that stops the same outage from happening again is direct risk reduction. A 45-minute weekly status round where each person reads the same ticket board aloud is usually a reporting defect wearing a meeting invite. The same distinction applies to chat. A fast answer from the only person who understands a fragile subsystem may be necessary today. If that person gets the same question every week, the organization has chosen to keep knowledge concentrated. The interruption is then part of the tax, even if the answer itself is correct. ## Necessary collaboration has a clear output You can tell whether a coordination event earned its cost by looking for a durable output. Necessary collaboration ends with a decision, an assigned owner, a changed interface, a written acceptance condition, or a risk that somebody can now act on. Recoverable coordination ends with another request for context, another meeting, or a promise to circle back. This is why meeting counts are a weak proxy. A team can run more meetings and have less coordination tax if those meetings remove uncertainty early. Another team can protect calendars aggressively while burning days in fragmented chat threads and review queues. Use these questions when classifying a calendar event, thread, or handoff: 1. Could the person receiving the request have acted without asking this question if the team had documented the relevant decision or boundary? 2. Did the exchange produce a decision that remained available to the next person, or did the team have to rediscover it later? 3. Was the requester waiting because a particular individual had authority or context that nobody else could access? 4. Did this handoff reveal a real dependency in the product, or only a dependency in the organization? 5. Would the same work move faster if one person owned it from request through release? A yes to the first three questions is a strong signal that you have recoverable cost. The fourth question is where mature teams stay honest. A payment change may require finance, security, and engineering input because the product has real constraints. A frontend change should not need three approval layers because a manager wants visibility. Gene Kim, Jez Humble, and Nicole Forsgren make a related point in Accelerate: software delivery performance depends on both technical practices and the way organizations enable teams to work. Teams often read that as a case for better CI, more tests, or faster deploys. Those matter. But a fast pipeline does little when a ticket waits two days for a decision that no one explicitly owns. The DORA metrics are useful because they expose flow and reliability. They do not, by themselves, tell you why work sat still. A lead-time graph will show a long tail. Your coordination tax study should explain whether that tail came from testing, product uncertainty, review capacity, access requests, handoffs, or somebody's overloaded calendar. ## Use a two-week window and sample real work A two-week measurement window is long enough to catch recurring behavior and short enough that people can still reconstruct what happened. Do not announce a grand productivity investigation and ask everyone to log each minute. People will either perform for the study or revolt against it, sometimes both. Pick one product area, one delivery stream, or one cross-functional squad. Include completed tickets, tickets still in progress, and a few that stalled or reopened. You are looking for patterns, not a scorecard for individuals. Collect four artifacts for the same period: - Calendar events for people in the selected group. - Ticket history, including status changes, assignee changes, comments, and links to pull requests or incidents. - Chat threads that affected active work, especially threads with repeated questions, routing, and requests for approval. - A simple waiting ledger for sampled tickets. Start with a sample of 15 to 30 work items. Fewer than that can be distorted by one unusual incident. More than that often turns a first pass into a data-cleaning project, which is exactly the sort of work you are trying to stop creating. Do not sample only tickets marked Done. Finished tickets are easier to inspect, but unfinished work often contains the clearest evidence of queues and ownership gaps. Include work that crossed a team boundary, waited for review, required a product decision, or bounced between people. Those cases tell you where the team loses time. Create a shared sheet with one row per observed coordination event. The sheet is not elegant, and that is fine. It needs to make the evidence inspectable. ```text work_item,event_type,started_at,ended_at,people_involved,reason,classification,owner_of_fix PAY-184,review_wait,2026-07-07 14:10,2026-07-08 11:20,2,reviewer unavailable,recoverable,engineering manager PAY-184,clarification_thread,2026-07-08 11:20,2026-07-08 11:42,3,acceptance rule missing,recoverable,product owner PAY-184,threat_review,2026-07-08 13:00,2026-07-08 13:35,4,new data flow,necessary,security owner ``` Use actual timestamps from your tools. Do not ask people to estimate a thread from memory if the message history and ticket audit log exist. Memory consistently turns short interruptions into nothing and long, annoying meetings into the whole problem. You also need a rule for partial attention. If five people attend a 30-minute meeting, record 2.5 person-hours. If one person sends three messages over an hour while doing other work, do not record a full hour. Record the active reading, writing, investigating, and follow-up time. A rough but defensible ten minutes is better than pretending that elapsed time equals effort. ## Calendars reveal the visible floor Calendar analysis gives you the easiest number to calculate and the easiest number to misuse. It captures scheduled coordination, not the fragmented work that often ruins an engineer's day. Export two weeks of events for the sample group. Classify each event by purpose rather than by title. Meeting titles lie constantly. A session called Sync may contain a needed architecture decision; a session called Design review may be a weekly status recital. Use five buckets: - Decision and design work. - Planning and estimation. - Status reporting. - Incident and operational coordination. - One-to-one management and coaching. Count status reporting as recoverable unless the group cannot get the information another way. Count planning as necessary only when participants leave with an executable commitment, a priority decision, or a specific uncertainty removed. Count one-to-ones separately. They are management work, and they should not be used to make an engineering process look worse than it is. Then calculate person-hours, not meeting hours. A 60-minute meeting with eight engineers costs eight engineer-hours before anyone does prep or follow-up. If the meeting generates a decision that saves each of those engineers a day of wrong work, it earned the cost. If attendees merely report progress to a manager, the cost is obvious. A calendar check should also look at fragmentation. Four 30-minute meetings spread through a day often cost more than two hours. The calendar says two hours; the developer loses the deep work blocks around them as well. Do not invent a universal multiplier for this. Instead, ask the affected people to mark whether the events split their available focus blocks. Treat that as a qualitative finding until you can compare it against cycle time or output over repeated periods. The calendar failure I see most often is recurring meetings that nobody owns. They survive because canceling them feels risky. Give every recurring engineering meeting an explicit owner and a one-sentence test: what decision, risk reduction, or shared output does this meeting create? If the answer is vague, cancel it for two weeks and watch what breaks. Most teams discover that nothing breaks, except habit. ## Chat threads expose the work that calendars hide Chat creates a false sense of efficiency because each message is small. A 90-second interruption can be harmless. Ten such interruptions across a day can make a complicated task take twice as long, especially when the questions require the engineer to reload context. You do not need to read every message. Search a two-week period for threads connected to sampled tickets and look for a few signals: repeated requests for the owner, requests for approval, requests for status, questions answered by pasting old answers, and conversations that migrate work between channels. For each thread, record active coordination time rather than the full thread duration. Add the time spent writing, reading, locating evidence, and returning to the original task. Estimate conservatively. A thread with six participants does not automatically mean six people spent the same amount of time on it. The failure pattern worth finding is the relay race. It usually looks like this: 1. A developer asks whether a ticket includes a particular edge case. 2. A product manager redirects the question to a founder or customer-facing colleague. 3. The answer arrives in chat but never reaches the ticket. 4. A tester later finds the same edge case and asks again. 5. The developer reopens code because the original assumption was wrong. That sequence is not a communication problem in the abstract. It is an intake and decision-record problem. The fix may be a required acceptance rule on the ticket, a named product owner, or a short decision record attached to the work. Telling people to communicate better does nothing because they already communicated. They just left the answer in a place the next person could not find. Beware of measuring chat volume as a productivity metric. A quiet channel may mean people are focused, or it may mean they have moved the real conversation into private messages. Volume is only a clue. The tax is the paid time and waiting created by a thread, plus the rework that follows when the thread leaves no usable record. A practical check is to choose five questions that appeared in chat and ask whether a new engineer could answer them from the ticket, repository, decision record, or runbook. If the answer is no, record the question as a knowledge-routing event. If the same question appears more than once, give somebody ownership of removing it from the future workflow. ## Ticket handoffs show where work enters queues Ticket systems usually preserve enough history to show handoffs even when the team does not call them handoffs. Assignee changes, status changes, review requests, labels, and comment timestamps reveal where work stopped moving. For each sampled ticket, mark these timestamps: ```text requested -> ready for engineering -> started -> ready for review -> approved -> ready to release -> released ``` Then add the person or role that controlled each transition. This produces a much better discussion than a generic complaint that delivery is slow. A handoff has a cost even when it takes only a minute to perform. The receiver must understand the work, locate context, decide whether it is complete, and then fit it among competing priorities. If the sender must answer questions later, the work crosses the boundary twice. Little's Law gives useful language for this. In a stable system, work in progress equals throughput multiplied by cycle time. You do not need to turn your startup into an operations research seminar. The practical implication is enough: when work accumulates in review, approval, QA, or release states, cycle time rises even if engineers write code at the same speed. Track the reasons for each queue, not only the queue duration. A review queue can mean several different things: - A reviewer lacks capacity because too much work routes through one senior engineer. - The change is too large for a reviewer to assess safely. - The team has no expectation for review response time. - Reviewers cannot test the change without extra setup or missing context. - The ticket arrived at review before it met the team's stated definition of ready. Those causes need different fixes. Adding more reviewers to an unclear process can increase the tax. A second reviewer may catch a risky mistake; five reviewers on a routine internal change often create waiting with no matching reduction in risk. Separate transfer time from waiting time. Transfer time is the active effort to hand work over: writing context, reviewing, explaining, checking. Waiting time is the period when nobody works on the item because it sits in a queue. Both matter, but they point to different remedies. Better templates reduce transfer time. Clear capacity rules and ownership reduce waiting time. ## Waiting time becomes payroll cost when it blocks capacity A ticket waiting in a queue is not automatically wasted payroll. The assigned developer may pick up another useful task. The cost becomes real when waiting forces people to context switch, creates parallel partially finished work, blocks a customer commitment, or leaves a high-cost person idle because only one decision can move the work. Measure waiting in two columns. First, record elapsed queue time. Second, record the active cost created by the wait. That active cost may include a follow-up message, a status meeting, reopening context, duplicate investigation, or time spent choosing a substitute task. This distinction keeps the estimate honest. If a pull request waits overnight and the author moves to another well-defined task, you should not charge eight idle hours to the coordination tax. Record the queue time because it exposes a flow problem, but charge only the real paid effort and disruption that the wait caused. If a founder must answer every pricing, scope, architecture, and release question, the waiting cost can be severe even when nobody is idle. Engineers start adjacent work, make assumptions, or hold changes locally. The ticket history may show activity, but the team has shifted from planned delivery to expensive hedging. Use a simple blocked-work check for each sampled item: - Did someone need to ask for the status or owner of the item? - Did the author switch to lower-priority work because the next action was unavailable? - Did the team duplicate investigation while waiting for an answer? - Did the item require rework after the delayed decision arrived? - Did a customer, launch, or operational task wait behind it? The first four are direct evidence of payroll cost. The fifth may create business cost that exceeds payroll, but keep it out of the initial tax calculation unless you can document it. Mixing lost revenue guesses with labor evidence makes the entire estimate easier to dismiss. The ugly part of waiting is that it often hides under a busy team. People fill the gaps with tickets that look useful. Then a blocked item wakes up, and everybody has to reshuffle. The resulting work in progress increases review load, release risk, and the number of questions flying through chat. This is why a team can look fully utilized and still deliver unpredictably. ## Turn observations into a payroll estimate You need a calculation simple enough that a founder can inspect it and a skeptical engineering lead can challenge it. Do not claim precision you do not have. Use ranges when your sample includes judgment calls. For each event, calculate: ```text coordination cost = active hours x loaded hourly cost x recoverable share ``` Active hours are person-hours spent in the event or created by the event. Loaded hourly cost is annual fully loaded compensation divided by workable annual hours. Recoverable share is your classification judgment. Use 1.0 for clearly avoidable work, 0.5 for mixed events, and 0 for necessary collaboration. For example, assume an engineer costs $180,000 per year fully loaded and works 1,800 productive paid hours after holidays, leave, and normal non-project time. That is $100 per hour. A 45-minute status meeting with six engineers costs 4.5 person-hours, or $450. If you judge 80 percent of it recoverable, the event contributes $360 to the tax estimate. Do not force every person into one blended rate if your team has wide compensation differences. A founder, staff engineer, contractor, and junior developer have different payroll costs and different opportunity costs. If exact compensation data is sensitive, use role-based loaded rates approved by finance. Your sheet can use these columns: ```text active_person_hours | loaded_hourly_cost | recoverable_share | estimated_tax 2.50 | 100.00 | 0.80 | =A2*B2*C2 ``` Add the estimated tax across the two-week sample. Divide by the number of sampled people, then annualize cautiously by multiplying by 26 only if the period was typical. If the sample included a release, an incident, or a holiday week, say so and report a range rather than a single annual number. Also report the tax as a share of sampled engineering payroll: ```text coordination tax percentage = estimated recoverable coordination cost / sampled payroll cost ``` That percentage matters more than a dramatic dollar figure. A small team with a $50,000 annual tax may have a serious operating problem if it represents a large share of its engineering capacity. A larger team may have a bigger dollar number but a lower percentage and a different priority. Do not convert every hour of necessary coordination into tax simply because you want to cut payroll. That destroys trust. The goal is to create a more capable team with fewer blockers, not to make people afraid to ask for help. ## A worked example makes the weak points obvious Consider a six-person product engineering group over two ordinary weeks. The group includes four engineers, one engineering manager who still contributes technically, and one product manager. The team samples 20 tickets, including four that reached release, seven still in progress, and three that reopened after review or testing. The sheet finds the following recoverable work: - Recurring status meetings: 18 person-hours after classifying the useful decision portions separately. - Chat clarification and follow-up: 14 person-hours tied to missing acceptance rules and repeated routing questions. - Active handoff effort: 11 person-hours, mostly engineers reconstructing context for QA and review. - Waiting-related disruption: 17 person-hours, including status chasing, task switching, and reopened context after delayed decisions. - Rework directly linked to a late clarification: 10 person-hours. That totals 70 recoverable person-hours in two weeks. At a blended loaded cost of $95 per hour, the sample estimates $6,650 in coordination tax for the period. Annualized mechanically, that is $172,900. Treat that annual number as a planning estimate, not an invoice from physics. The more useful finding is why the 70 hours occurred. In this example, three patterns explain most of the cost: 1. Tickets entered engineering without a named decision owner for edge cases. 2. One staff engineer reviewed changes across several areas because nobody had clear review authority elsewhere. 3. The release process required a live confirmation from the engineering manager, even for routine changes covered by automated checks. The team should not start by banning meetings. It should change those three conditions and run the same sample again after a month. The first change is an intake rule: tickets that require product behavior decisions need an owner, acceptance examples, and a place where the final answer remains attached to the work. The second change is a review policy: assign maintainers by area, set a response expectation for ordinary changes, and require smaller pull requests when review regularly stalls. The third change is a release rule: automate evidence gathering and reserve live approval for changes that meet explicit risk criteria. Notice what this does not say. It does not say that the product manager, staff engineer, or engineering manager caused the problem. The team built a system where too much work depended on them. Replace any one of them without changing the rules and the same tax will return. ## Fix the largest recurring wait, then rerun the sample The best first fix is usually the recurring dependency that combines high payroll cost with frequent waiting. It may be a weekly meeting, a review queue, a missing product decision owner, or a founder who has become the only route to production knowledge. Choose one constraint. Write the new operating rule in plain language. Assign an owner. Then measure the same artifacts for another two weeks. If the number does not move, inspect your classification and the behavior that replaced the old process. Teams often remove a meeting only to recreate it as a sprawling chat thread. Avoid the popular recommendation to solve coordination by adding more process. More forms, more approval steps, and more dashboards can make the tax easier to observe while making it worse. Add a rule only when it removes a repeated question, a dangerous ambiguity, or a queue. If it merely proves that people were busy, it is overhead. This measurement also gives founders a better way to discuss headcount. Before hiring another developer to increase output, ask whether the current team is losing a material share of payroll to avoidable movement. An additional engineer can help when the bottleneck is truly capacity. If the bottleneck is decision routing or review ownership, the new hire often adds another person to coordinate. A Team & AI Audit is useful when the internal team cannot inspect its own habits without politics getting in the way. The work should end with a visible estimate, the constraints behind it, and a short list of changes that remove paid waiting rather than another slide deck about productivity. Measure the tax before you prescribe the cure. The spreadsheet will not be perfect, but it will force the conversation onto real events: this meeting, this queue, this missing decision, this interrupted engineer. That is enough to stop treating slow delivery as a personality problem and start removing the conditions that create it.