EOS & Operations · September 28, 2026 · 8 min read

Your Operating System Breaks Where Your Leadership Keeps Making Exceptions

A complete scorecard and a clear agenda cannot compensate for the exceptions a leader keeps making. Examine how your own behavior affects the six components of EOS.

A weekly scorecard can be complete while a difficult decision stays untouched. Every number has an owner. Every meeting has an agenda. Yet the same customer problem keeps returning, and the founder still gets pulled into work someone else supposedly owns.

That gap deserves attention before another tool gets added. I want to know what the leadership team does when the system exposes something inconvenient. Do we examine it, or do we make an exception that allows everyone to carry on?

The six components of EOS give us a useful way to examine the business: Vision, People, Data, Issues, Process, and Traction. They address direction, responsibility, objective information, problem-solving, consistency, and execution, all part of the work described in Kairos EOS implementation.

My concern is what happens after those ideas become familiar. You can learn the vocabulary and still protect the habits that create confusion. I would rather examine one uncomfortable exception honestly than celebrate a complete collection of documents nobody is willing to follow.

Vision and People Need Decisions the Founder Will Honor

I want a company's vision to help someone make a choice without waiting for the owner to become available. If the stated direction cannot guide a tradeoff, the leadership team has more work to do. Agreement needs to reach beyond the words on the page.

Consider a hypothetical company that says it wants to serve a clearly defined customer. A new opportunity arrives outside that focus. The owner accepts it because the revenue looks attractive, then asks the team to fit unfamiliar work into an already committed schedule.

The problem deserves a real discussion. Perhaps the opportunity is worth pursuing. Perhaps the original focus needs revision. But quietly overriding the direction teaches the team that the actual strategy depends on whichever possibility captures the founder's attention.

I would put the tradeoff in plain language. What existing work will receive less attention? Which capability does this require? Who will carry the additional responsibility? What evidence would justify changing direction?

Once a choice is made, I want the owner to honor it when another appealing opportunity appears. Otherwise, the team is being asked to commit to a direction the founder has reserved the right to ignore.

The People component brings a related challenge. I want responsibility and authority to make sense together. Assigning a manager an outcome while personally reversing every meaningful decision leaves that person accountable for work they cannot genuinely direct.

That does not mean an owner must surrender judgment or tolerate poor performance. It means decision boundaries need to be explicit. Identify what the manager can decide, when consultation is required, and what circumstances require escalation.

I would also examine whether loyalty is preventing an honest conversation about role fit. Respect for someone's history should influence how you handle that conversation. It should not make the current responsibilities impossible to discuss.

Before blaming a person, check the assignment. Was the outcome clear? Were the resources available? Did the leader provide the authority the role required? Accountability becomes fairer when the leader is willing to answer those questions first.

Data and Issues Require More Honesty Than Explanation

I want a number to help the team see reality, especially when reality challenges the explanation I prefer. A scorecard loses usefulness when the conversation becomes an exercise in defending why every missed target should be treated as acceptable.

There can be legitimate reasons for a miss. A delayed shipment, a staffing interruption, or an unusual customer request may matter. I would hear those facts without allowing the explanation to end the examination.

Suppose a hypothetical team tracks overdue customer follow-ups. The number rises for several weeks. Each week, someone explains that the business has been busy. That explanation may be accurate, but it leaves the leadership decision untouched.

Is capacity insufficient? Is the handoff unclear? Does the team agree on when a follow-up becomes overdue? Has somebody been assigned work that conflicts with the expectation? Those questions are more useful than another general reminder to communicate better.

I would first confirm that everyone means the same thing by the number. A measure needs a clear definition, a dependable source, and an owner who can explain what it represents. False precision will not improve a difficult decision.

Then I would separate what is known from what is assumed. The customer has not received an update is an observation. The account manager does not care is an interpretation. Acting as though the second statement has already been proven can damage both the decision and the relationship.

This is where I want the Issues work to become specific. Name the problem in language the team can investigate. Avoid labels so broad that any solution could appear relevant.

If the issue is that no one owns the handoff after a proposal is approved, say that. Assigning a handoff owner and testing the agreement gives you something concrete to review. Asking everyone to show more initiative may leave the same gap in place.

I also want the leader to ask whether their own behavior contributes to the issue. If employees bring problems early and receive irritation in return, examine that response before demanding more candor. Make it possible to tell the truth without first preparing a defense.

Process and Traction Depend on What Happens Under Pressure

A written process should help a person complete real work. I would test it against a recent job rather than judge it by how organized the document looks. Can the person doing the work use it without relying on instructions that exist only in someone else's head?

Choose a recurring activity with a visible consequence: bringing on a customer, handing a project to delivery, approving an invoice, or responding to a service problem. Follow one example from beginning to end.

I would ask where people become uncertain, what information arrives late, and which decisions repeatedly return to the same person. The goal is to find the points that need clarity, then make the agreed approach usable.

There is a leadership test here, too. When an important customer requests special treatment, does the owner quietly bypass the process? When the schedule becomes tight, does a required check disappear without anyone deciding whether the risk is acceptable?

Some exceptions are necessary. I want those exceptions visible, with a reason, an owner, and a review. An exception that remains unnamed can become a second operating method that only certain people understand.

The Traction component raises the question of whether priorities survive contact with the week. I want commitments small enough in number to receive actual attention and clear enough that people can tell whether they are complete.

Imagine a leadership team agreeing that fixing customer onboarding is a priority. Then the owner adds several unrelated projects without removing anything already assigned. At the next review, the owner expresses disappointment that onboarding has not improved.

Before asking for greater effort, I would examine the decisions that consumed the available capacity. A priority needs protected time, a responsible person, and a clear definition of completion. It also needs someone willing to decline competing work.

I would ask the team to state what will stop or wait. That answer makes the commitment more credible. If nothing changes on the calendar and every old obligation remains, the new priority may only exist in the meeting notes.

Follow-through includes reviewing the result without rewriting the original commitment. If the work changed, acknowledge the change. If the deadline was missed, understand why. Keep the evidence clear enough to learn from it.

Your Own Exceptions Belong in the Review

I would begin an operating-system review with a question directed at myself: where am I asking the team to follow an agreement that I routinely override? The answer may be more useful than a broad complaint about accountability.

Perhaps I interrupt the person who is meant to facilitate a meeting. Perhaps I make commitments to customers without consulting the person responsible for delivery. Perhaps I expect accurate reporting while reacting badly to numbers I do not like.

Those are examples to examine, not admissions about a particular company. The point is to make leadership behavior part of the review rather than treating the system as something employees need to obey.

I would bring one recurring failure to the table and trace it through all six components. Is the direction clear? Does the right person own the responsibility? Do we have reliable information? Have we named the real issue? Is there an agreed method? Are we following through?

Do not turn that exercise into six simultaneous improvement projects. Identify the first decision that would remove a meaningful obstacle. Assign the work and choose a date to examine what changed.

The Five Bridges help me consider what this work asks of the leader. The Internal Bridge calls for consistency between the standard I describe and the standard I practice. The Relationships Bridge calls for direct conversations that preserve another person's dignity. The Environment Bridge asks whether the structures around people support responsible action.

I want a business where an employee can understand the assignment, raise a concern, make an authorized decision, and know what follow-through looks like. That requires tools, but it also requires leaders who accept the same discipline they ask of everyone else.

Action Items From Today

  1. Choose one recurring breakdown. Bring a specific missed handoff, delayed decision, or repeated customer issue to your next leadership meeting. Describe what happened without assigning motives.
  2. Trace the breakdown through all six components. Write one sentence each for Vision, People, Data, Issues, Process, and Traction. Identify where you have evidence and where you still need information.
  3. Name your own exception. Identify one way you override an agreed priority, decision boundary, or process. Tell the affected person what you will do differently and when that change begins.
  4. Make one responsibility executable. Confirm the outcome, owner, authority, available capacity, and definition of completion. Ask the owner to explain the agreement back in their own words.
  5. Schedule the evidence review. Set a date to examine the actual result, including whether your leadership behavior changed. Bring the work or decision to the review, not only an impression of progress.

Five Bridges Challenges

  • Internal: Which standard are you enforcing more consistently on your team than on yourself? Choose one visible behavior to practice this week, and invite a trusted colleague to tell you when you miss it.
  • Relationships: Who needs a clear conversation about responsibility or authority? Arrange that conversation, acknowledge any confusion you created, and leave with an agreement both people can explain.
  • Environment: Where does your operating structure make good work unnecessarily difficult? Follow one real handoff, identify the missing decision or information, and test a practical correction before adding another tool.

If your team needs help examining how its operating system works in practice, explore EOS implementation with Kairos. Bring a real recurring issue and a willingness to examine your own part in it.

Inspire & Impact,

Josh