<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Systems on John Schultz</title><link>https://johndschultz.com/tags/systems/</link><description>Recent content in Systems on John Schultz</description><generator>Hugo -- 0.155.3</generator><language>en-us</language><lastBuildDate>Tue, 02 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://johndschultz.com/tags/systems/index.xml" rel="self" type="application/rss+xml"/><item><title>The Shock Absorber Trap</title><link>https://johndschultz.com/essays/the-shock-absorber-trap/</link><pubDate>Tue, 02 Jun 2026 00:00:00 +0000</pubDate><guid>https://johndschultz.com/essays/the-shock-absorber-trap/</guid><description>Customer support is a trailing indicator of poor systems. When systems break, our instinct is to throw human shock absorbers at them, masking the pain rather than fixing the design.</description><content:encoded><![CDATA[<p>I was listening to a podcast episode of No Priors recently where Palo Alto Networks CEO Nikesh Arora said something that stopped me. Customer support, he argued, exists because we build bad products. If we build great products, why would we have to have customer support? It&rsquo;s too complicated, it&rsquo;s hard to onboard, it&rsquo;s got too many dials. That&rsquo;s why it takes so much time to make, and eventually it&rsquo;s not efficient.</p>
<p>It&rsquo;s a blunt, uncompromising way to look at product design. It frames customer support not as a service department, but as a tax you pay for bad engineering. If your user needs an explainer or a help desk, you didn&rsquo;t finish designing.</p>
<p>At first, that sounds like typical Silicon Valley idealism, a luxury for simple consumer software. But when you look closely, the principle is deeply diagnostic. It forces you to ask: which parts of your business genuinely require human interaction, and which parts are just friction you haven&rsquo;t had the courage to design out?</p>
<h2 id="the-silence-of-a-ringing-phone">The silence of a ringing phone</h2>
<p>There&rsquo;s a deep ideological divide in how we define a healthy business.</p>
<p>One worldview, the traditional one, measures operational health by contact. A ringing phone is proof of life, relationship, and hustle. To an old-school operator, silence means death. It means nobody is buying, nobody is calling, we&rsquo;re not growing.</p>
<p>The other worldview, the platform one, measures health by silence. A phone call is an alarm. It means a user is lost, a workflow is blocked, or a default was wrong. In this view, a support ticket is a trailing indicator of a system failure upstream.</p>
<p>This is a fundamental clash of worldviews. When your business partner looks at a quiet room and thinks there must be problems, and you look at a ringing phone and think the same thing, you&rsquo;re not even running the same company. You are operating on two different definitions of trust. One relies on human presence to smooth over the bumps. The other relies on a seamless system to prevent the bumps in the first place.</p>
<h2 id="the-shock-absorber-trap">The shock absorber trap</h2>
<p>But here&rsquo;s the trap. Even when you believe in the system-first worldview, your behavior often defaults to the other side.</p>
<p>I know this because I live it.</p>
<p>I make sure that every negative review and every low net promoter score comment from our customers comes directly to my personal email inbox. They don&rsquo;t go to a support queue. They land in front of me, and they get a personal response from me. It&rsquo;s a grueling, exhausting process. It&rsquo;s frustrating, overwhelming, and draining.</p>
<p>For a long time, I told myself this was craftsmanship. I was the CMTO, staying close to the ground, keeping my hands on the wheel.</p>
<p>But if I hold my own actions up to the system-first principle, the truth is much less heroic. By routing those failures to my personal inbox, I&rsquo;m not fixing the company. I&rsquo;m acting as a human shock absorber. And even worse, I&rsquo;ve been using those reviews as a personal shield. It feels like craft and responsibility, but it&rsquo;s actually an escape. By personally responding to each complaint, I avoid the much harder, more exhausting work: aggregating those failures, sitting down with our executive team, and forcing us to develop the systems and processes to fix them at the root.</p>
<p>When you throw yourself into the gears of a broken system to keep it running, you&rsquo;re not solving the problem. You&rsquo;re just masking it. And as long as you&rsquo;re willing to absorb the friction, the organization has no incentive to redesign the engine.</p>
<h2 id="the-concrete-floor-of-physical-operations">The concrete floor of physical operations</h2>
<p>This trap is easy to spot in software, but it gets incredibly messy when your platform meets physical reality.</p>
<p>At Grafe Auction, we run industrial liquidations. Our software handles registration, bidding, and payment processing. But eventually, the digital platform hits the concrete floor of a physical warehouse. That&rsquo;s the post-auction removal process. It&rsquo;s where buyers show up with trailers, forklifts, and rigging contractors to claim heavy equipment.</p>
<p>This is a massive point of friction. Buyers get frustrated. Subcontractors get brash. People argue about lot locations and missing parts.</p>
<p>Our instinct is always to throw more humans at the problem. I&rsquo;ve spent hours wondering if we should place a Grafe customer success person on every site. We&rsquo;d find a &ldquo;softer&rdquo; person, someone who understands hospitality, to act as a buffer between the brash contractors and the frustrated buyers.</p>
<p>But that is the shock absorber trap all over again. It treats the friction on site as an unchangeable law of nature.</p>
<p>When we look past the personalities, the actual failure is a system design issue. The removal site is a poorly managed situation. It&rsquo;s a custody and verification failure. Because there are no physical checkpoints or clear verification systems, buyers can switch lot tags, take the wrong items, or damage assets.</p>
<p>Putting a polite success person on site doesn&rsquo;t fix the custody loop. It just gives the frustrated buyer a nicer person to complain to while they stand in the middle of the chaos. We tried to fix a fundamental security and layout failure with a scheduling tool, requiring appointments to try and slow the process down. But appointments are just a speed limit on a broken road. They don&rsquo;t fix the holes.</p>
<h2 id="the-internal-cost-of-external-simplicity">The internal cost of external simplicity</h2>
<p>So why do we do it? Why do smart, system-minded leaders repeatedly choose human shock absorbers over system redesigns?</p>
<p>Because throwing humans at problems is easier than doing the hard work of system building.</p>
<p>Redesigning a physical or digital process requires time, energy, and relentless effort. It means holding people accountable. It means creating better tasks, workflows, and strict verification gates. And most of all, it requires getting buy-in across an entire enterprise.</p>
<p>Getting that buy-in is exhausting. When you&rsquo;ve fought to get everyone on the same page and watched it fail repeatedly, you get tired. Over time, you become jaded toward change. Change is hard.</p>
<p>That&rsquo;s when the shock absorber trap becomes incredibly seductive. Personally replying to a negative review or putting a success person on site takes energy, but it&rsquo;s a closed loop. You control it. You don&rsquo;t have to negotiate with anyone. You don&rsquo;t have to fight for buy-in. You just do the work.</p>
<p>In that light, the shock absorber trap is not a design mistake. It&rsquo;s an executive coping mechanism. We build human shields to protect ourselves from the exhausting work of getting everyone on the same page.</p>
<p>But the cost of that shield is compounding. As long as we keep absorbing the shock, we keep renting our growth. We spend our days firefighting, and the systems stay broken.</p>
<p>The real work of leadership is not being a hero in the support queue. It is having the courage to step out from behind the shield, aggregate the failure data, and force the organization to sit down and redesign the system. If we want to build a platform that scales, we have to stop smoothing over the bumps and start fixing the road.</p>
]]></content:encoded></item></channel></rss>