<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <title>Stiven Catalyst</title>
  <subtitle>Stiven Catalyst is an independent publication about leadership, operations, people, systems and practical change.</subtitle>
  <link href="https://stivencatalyst.com/feed.xml" rel="self"/>
  <link href="https://stivencatalyst.com/"/>
  <id>https://stivencatalyst.com/</id>
  <author><name>Stiven Janaqi</name></author>
  <updated>2026-09-23T00:00:00Z</updated>
  <entry>
    <title>Fix the handoff before you blame the person</title>
    <link href="https://stivencatalyst.com/insights/fix-the-handoff/"/>
    <id>https://stivencatalyst.com/insights/fix-the-handoff/</id>
    <updated>2026-09-23T00:00:00Z</updated>
    <summary>A task can be done by one team and still be lost before the next team can use it.</summary>
    <content type="html">&lt;p&gt;One shift leaves a note. The next shift reads it and still does not know what to do. A team marks its task complete, but the next team is waiting for one missing detail. By the time the problem becomes visible, it is tempting to ask who failed.&lt;/p&gt;
&lt;p&gt;Often each person did the part they understood. The missing piece was the transfer between them.&lt;/p&gt;
&lt;p&gt;In a hotel, a room issue can pass from night audit to the morning desk without a clear next action. In a warehouse, an order can pass from picking to loading with a bag still missing. The details differ, but the weak point is the same: the work changed hands before its state was clear.&lt;/p&gt;
&lt;h2&gt;Define what a complete handoff contains&lt;/h2&gt;
&lt;p&gt;A useful handoff answers five questions. What is the item or issue? What is its current state? What has already been tried? Who owns the next action? By when does that action need to happen?&lt;/p&gt;
&lt;p&gt;“A guest complained” leaves the next person to reconstruct the story. “A guest reported low water pressure; engineering was informed; morning desk to confirm the repair before the guest returns” is a handoff someone can act on. Use only the details the next person needs, and handle guest information according to the property&#39;s rules.&lt;/p&gt;
&lt;p&gt;The handoff is complete when the receiving person can name the next action. A sent message alone does not prove that ownership moved.&lt;/p&gt;
&lt;h2&gt;Watch the boundary&lt;/h2&gt;
&lt;p&gt;If the same problem returns, follow one real example across the boundary. Compare what the sending team believed it passed on with what the receiving team actually got. Look at the form, the system status and the time available. A field that is optional in the system may be essential in the work.&lt;/p&gt;
&lt;p&gt;Do this without turning the review into a search for the last person who touched the task. Repeated misses across different people usually mean the transfer itself is too easy to misunderstand.&lt;/p&gt;
&lt;h2&gt;Make the next shift easier&lt;/h2&gt;
&lt;p&gt;Agree one owner for each open item and keep the handoff short enough to be read while the shift is moving. Separate facts from assumptions. Mark what is urgent and what can wait. At the next overlap, check which items were closed and which bounced back.&lt;/p&gt;
&lt;p&gt;The &lt;a href=&quot;https://stivencatalyst.com/tools/shift-handover/&quot;&gt;Shift Handover tool&lt;/a&gt; gives this a simple structure, but the habit matters more than the form. A good handoff lets the next person continue the work without starting the investigation again.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title>Standards fail when nobody owns the follow-through</title>
    <link href="https://stivencatalyst.com/insights/standards-follow-through/"/>
    <id>https://stivencatalyst.com/insights/standards-follow-through/</id>
    <updated>2026-09-22T00:00:00Z</updated>
    <summary>A new checklist can be clear on launch day and invisible a month later. The missing part is often the way it is checked and improved.</summary>
    <content type="html">&lt;p&gt;A new standard is easy to announce. It goes into a document, appears in a meeting and is sent to every shift. For a few days, people remember it. Then the operation gets busy, a new colleague joins, or an old exception returns. The instruction remains in the folder while the work moves another way.&lt;/p&gt;
&lt;p&gt;This is rarely solved by sending the same reminder again. The useful question is what has to happen after the announcement so the standard becomes normal work.&lt;/p&gt;
&lt;h2&gt;Make the standard observable&lt;/h2&gt;
&lt;p&gt;“Be more careful” is not a standard. “Check the room status before assigning the key” is something a colleague can perform and another person can verify. The same applies to closing a loading gate, scanning chilled goods inside the cooling area or recording an unresolved guest request before the next shift arrives.&lt;/p&gt;
&lt;p&gt;Write the critical action in plain words. Say when it happens, who does it and what evidence shows it was done. Show an example of a correct result. Keep the instruction close to the place where it is used, not only in a long manual.&lt;/p&gt;
&lt;p&gt;If a step has several exceptions, name the common ones. People working at speed will meet the exception before they return to the document.&lt;/p&gt;
&lt;h2&gt;Give the follow-through an owner&lt;/h2&gt;
&lt;p&gt;Someone must see whether the standard survives a real shift. That person does not need to watch every action. They need a small, regular check and a way to hear about friction. For example, a shift lead can review a few handovers, spot-check a gate at the end of loading or ask a new colleague to demonstrate the step.&lt;/p&gt;
&lt;p&gt;The owner also needs authority to change something when the check fails. If the required action takes more time than the process allows, repeating the rule will not create time. The manager may need to move work, adjust a tool or decide which competing demand has priority.&lt;/p&gt;
&lt;h2&gt;Learn from the misses&lt;/h2&gt;
&lt;p&gt;When a step is missed, ask what happened before it. Was the instruction unclear? Was the tool unavailable? Did two people each think the other owned it? Was the team measured on speed while the standard required a pause?&lt;/p&gt;
&lt;p&gt;Record the pattern, change the condition and check again. A single miss may need coaching. The same miss across different people or shifts points to a system that needs attention.&lt;/p&gt;
&lt;p&gt;A useful standard has a short life cycle: explain it, demonstrate it, check it in real work, adjust what gets in the way and check again. That follow-through is the part that turns an announcement into a reliable way of working.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title>Why good managers spend time on the floor</title>
    <link href="https://stivencatalyst.com/insights/good-managers-on-the-floor/"/>
    <id>https://stivencatalyst.com/insights/good-managers-on-the-floor/</id>
    <updated>2026-09-21T00:00:00Z</updated>
    <summary>A report tells you that something changed. The people doing the work can often show you where it changed.</summary>
    <content type="html">&lt;p&gt;A manager can spend an entire day discussing an operation without seeing it. The dashboard is open, the reports are current and every problem has an owner in the meeting. Yet the question that would change the decision may be waiting beside a loading gate, at a reception desk or in a handoff between two shifts.&lt;/p&gt;
&lt;p&gt;Numbers tell us where to look. They cannot show the full sequence of work. A delay may begin long before a vehicle leaves. A guest complaint may begin before check-in. If you only see the final result, the last person in the chain can look like the cause.&lt;/p&gt;
&lt;p&gt;Spending time on the floor gives a manager a chance to test that assumption.&lt;/p&gt;
&lt;h2&gt;Observe the work, not just the worker&lt;/h2&gt;
&lt;p&gt;Start with one process and follow it from beginning to end. What was supposed to happen? What actually happened? Where did someone have to wait, improvise or ask for help? Which step works on a quiet day but fails at peak time?&lt;/p&gt;
&lt;p&gt;The aim is to understand the conditions in which people make decisions. Standing behind someone with a checklist changes their behaviour. Walking alongside them and asking what slows the work down gives you better evidence.&lt;/p&gt;
&lt;p&gt;Ask a question that can be answered with a real example: “Show me the last time this happened.” Then compare that example with the standard and the data. A repeated workaround is information about the system, even when the workaround should eventually stop.&lt;/p&gt;
&lt;h2&gt;Listen for the gap between the plan and the shift&lt;/h2&gt;
&lt;p&gt;People closest to the work usually know which instructions conflict, which tool is unreliable and which handoff loses information. They may not have the authority to change those things. A manager&#39;s job is to separate a one-off mistake from a pattern the team has learned to live with.&lt;/p&gt;
&lt;p&gt;That means listening without promising an instant fix. Write down the observation, check it against another shift or day, and identify who can change it. If the answer is training, make the critical step visible. If it is capacity, compare the workload with the hours available. If it is process design, change the route the work takes.&lt;/p&gt;
&lt;h2&gt;Close the loop&lt;/h2&gt;
&lt;p&gt;A floor visit loses value when every conversation ends there. Tell the team what you learned, what you changed and what still needs a decision. Return later to see whether the change held under normal pressure.&lt;/p&gt;
&lt;p&gt;One useful rhythm is simple: choose one problem, observe one complete cycle, agree one action with an owner and check the result on the next shift. You do not need a ceremonial walk or a long report. You need evidence that can alter a decision.&lt;/p&gt;
&lt;p&gt;The point of being close to the work is to see the system more clearly and make it easier for people to do good work again tomorrow.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title>The KPI is not the problem. The process behind it is.</title>
    <link href="https://stivencatalyst.com/article-kpi.html"/>
    <id>https://stivencatalyst.com/article-kpi.html</id>
    <updated>2026-09-20T00:00:00Z</updated>
    <summary>A bad number creates urgency. But urgency without diagnosis often produces pressure instead of improvement.</summary>
    <content type="html">&lt;p&gt;Managers are trained to watch numbers. Delays, damage, conversion, loading time, guest satisfaction, labour cost, quality, productivity. The language changes by industry, but the pattern is familiar.&lt;/p&gt;
&lt;p&gt;When a number turns red, attention increases. Meetings get sharper. Messages become more frequent. Teams hear that the KPI has to improve.&lt;/p&gt;
&lt;p&gt;Sometimes that pressure works for a day. It rarely fixes the system.&lt;/p&gt;
&lt;h2&gt;The number is an outcome&lt;/h2&gt;
&lt;p&gt;A KPI is usually the final visible result of many earlier decisions: planning, training, capacity, layout, handoffs, tools, staffing, communication and standards.&lt;/p&gt;
&lt;p class=&quot;pull&quot;&gt;If the process stays the same, asking for a different number is mostly asking people to compensate harder.&lt;/p&gt;
&lt;p&gt;That is why strong operational management starts one level deeper. Instead of asking only, “Why is the KPI bad?”, ask, “What sequence of events reliably creates this result?”&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;The useful question is not who touched the problem last. It is where the process first became unstable.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2&gt;Move from pressure to evidence&lt;/h2&gt;
&lt;p&gt;Look at the work where it happens. Follow the handoff. Compare the expected process with the real one. Separate one-off mistakes from repeated patterns. Then decide whether the cause is skill, capacity, clarity, design or ownership.&lt;/p&gt;
&lt;p&gt;This changes the management conversation. People stop defending themselves against a number and start contributing evidence about the process.&lt;/p&gt;
&lt;h2&gt;Better systems make better behaviour easier&lt;/h2&gt;
&lt;p&gt;The goal is not to remove accountability. It is to make accountability useful. People should own their decisions, but managers should also own the systems that shape those decisions.&lt;/p&gt;
&lt;p&gt;A good KPI tells you where to look. It should not tell you who to blame.&lt;/p&gt;
</content>
  </entry>
</feed>
