<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Jono Herrington</title>
    <description>Thoughts from The Builder's Leader on team transformation and the frameworks behind high-performing teams.</description>
    <link>https://www.jonoherrington.com</link>
    <atom:link href="https://www.jonoherrington.com/feed.xml" rel="self" type="application/rss+xml"/>
    <language>en-us</language>
    <lastBuildDate>Sun, 05 Apr 2026 00:00:59 GMT</lastBuildDate>
    
    <item>
      <title><![CDATA[Adoption Metrics Are Not Skill Metrics]]></title>
      <description><![CDATA[When I reviewed my team's AI adoption dashboard last quarter, every number was moving in the right direction. What the dashboard couldn't show me was who had stopped understanding the systems they were shipping. Adoption metrics and skill development metrics are not the same thing. I had been treating them like they were.]]></description>
      <link>https://www.jonoherrington.com/blog/adoption-metrics-are-not-skill-metrics</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/adoption-metrics-are-not-skill-metrics</guid>
      <pubDate>Sat, 04 Apr 2026 00:00:00 GMT</pubDate>
      <category>AI Leadership</category>
      <category>Engineering Management</category>
      <category>Metrics</category>
      <category>Skill Development</category>
      <category>Chapter 4</category>
    </item>
    <item>
      <title><![CDATA[The Mandate Had No Return Address]]></title>
      <description><![CDATA[More than 500 engineers described what happened when their companies chose mandates over conversations. The dashboards showed adoption. The engineers showed compliance. What didn't appear anywhere was what wasn't working.]]></description>
      <link>https://www.jonoherrington.com/blog/the-mandate-had-no-return-address</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/the-mandate-had-no-return-address</guid>
      <pubDate>Fri, 03 Apr 2026 00:00:00 GMT</pubDate>
      <category>AI</category>
      <category>Leadership</category>
      <category>Engineering Culture</category>
      <category>Team Management</category>
      <category>AI adoption</category>
    </item>
    <item>
      <title><![CDATA[When You Push for 3x]]></title>
      <description><![CDATA[Jono Herrington pushed for higher velocity. The team delivered. Then he sat at a lunch table bragging about doubled output while his engineers knew exactly what they'd done to produce that number. The same pattern is playing out in every AI productivity mandate right now.]]></description>
      <link>https://www.jonoherrington.com/blog/push-for-3x</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/push-for-3x</guid>
      <pubDate>Thu, 02 Apr 2026 00:00:00 GMT</pubDate>
      <category>engineering leadership</category>
      <category>AI productivity</category>
      <category>velocity</category>
      <category>technical debt</category>
      <category>engineering management</category>
    </item>
    <item>
      <title><![CDATA[Your AI Rollout Didn't Create Inconsistency. It Revealed It.]]></title>
      <description><![CDATA[Six weeks after giving our team AI coding tools without guardrails, the codebase looked like a junk drawer with a CI/CD pipeline. Our first instinct was to fix the AI config. The right answer was to fix the humans first.]]></description>
      <link>https://www.jonoherrington.com/blog/ai-rollout-revealed-inconsistency</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/ai-rollout-revealed-inconsistency</guid>
      <pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate>
      <category>AI</category>
      <category>Leadership</category>
      <category>Engineering Culture</category>
      <category>Architecture</category>
    </item>
    <item>
      <title><![CDATA[Your Code Is Moving. Your Judgment Is Not.]]></title>
      <description><![CDATA[GitHub found developers complete tasks 55% faster with AI tools. Nobody measured what happened to the evaluation cycle. That asymmetry is where the real risk lives.]]></description>
      <link>https://www.jonoherrington.com/blog/your-code-is-moving</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/your-code-is-moving</guid>
      <pubDate>Tue, 31 Mar 2026 00:00:00 GMT</pubDate>
      <category>AI Leadership</category>
      <category>Staying Technical</category>
      <category>Engineering Leadership</category>
      <category>Chapter 4</category>
    </item>
    <item>
      <title><![CDATA[The Atrophy Problem]]></title>
      <description><![CDATA[Engineers who spend their days directing AI agents and reviewing generated output are experiencing the same skill decay that managers hit years ago. This is not a tooling problem. It's an atrophy problem.]]></description>
      <link>https://www.jonoherrington.com/blog/atrophy-problem</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/atrophy-problem</guid>
      <pubDate>Mon, 30 Mar 2026 00:00:00 GMT</pubDate>
      <category>AI</category>
      <category>Leadership</category>
      <category>Management</category>
      <category>Staying Technical</category>
      <category>Engineering Career</category>
    </item>
    <item>
      <title><![CDATA[Engineering Is a Team Sport. Your Incentives Aren't.]]></title>
      <description><![CDATA[Most teams attack PR bottlenecks with better tooling, shorter PRs, and review rotation schedules. None of it sticks. The bottleneck isn't the process. It's what you're rewarding.]]></description>
      <link>https://www.jonoherrington.com/blog/engineering-team-sport</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/engineering-team-sport</guid>
      <pubDate>Sun, 29 Mar 2026 00:00:00 GMT</pubDate>
      <category>engineering-culture</category>
      <category>team-performance</category>
      <category>metrics</category>
      <category>leadership</category>
    </item>
    <item>
      <title><![CDATA[AI Is Shipping Your Blind Spots]]></title>
      <description><![CDATA[AI doesn't have blind spots. You do. When you prompt from one angle, AI ships those blind spots at scale. The feedback loop is the problem. Better prompts won't close it.]]></description>
      <link>https://www.jonoherrington.com/blog/ai-shipping-your-blind-spots</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/ai-shipping-your-blind-spots</guid>
      <pubDate>Sat, 28 Mar 2026 00:00:00 GMT</pubDate>
      <category>AI</category>
      <category>engineering leadership</category>
      <category>systems thinking</category>
      <category>productivity</category>
      <category>leadership</category>
    </item>
    <item>
      <title><![CDATA[Velocity Is Up. Ask Why Your Team Is So Quiet.]]></title>
      <description><![CDATA[AI adoption at speed is erasing the orientation senior engineers spent years building. The throughput is real. The sustainability is not something you can see on the board. The quiet is the data.]]></description>
      <link>https://www.jonoherrington.com/blog/the-quiet-after-velocity</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/the-quiet-after-velocity</guid>
      <pubDate>Fri, 27 Mar 2026 00:00:00 GMT</pubDate>
      <category>engineering-leadership</category>
      <category>ai</category>
      <category>team-health</category>
      <category>sustainability</category>
      <category>leadership</category>
    </item>
    <item>
      <title><![CDATA[Your Best Engineers Are Tired]]></title>
      <description><![CDATA[AI tooling compresses the low stakes work out of an engineer's day. What fills the gap is not rest or recovery. It's more evaluation. The leaders who miss this are running depletion schedules, not engineering orgs.]]></description>
      <link>https://www.jonoherrington.com/blog/ai-cognitive-load</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/ai-cognitive-load</guid>
      <pubDate>Thu, 26 Mar 2026 00:00:00 GMT</pubDate>
      <category>ai</category>
      <category>engineering leadership</category>
      <category>cognitive load</category>
      <category>team health</category>
      <category>productivity</category>
    </item>
    <item>
      <title><![CDATA[AI Didn't Break Your Culture. It Exposed It.]]></title>
      <description><![CDATA[When an engineer says 'ChatGPT recommended something else' to close a technical debate, that's not a technology problem. It's a culture problem you already had. AI just gave it a name.]]></description>
      <link>https://www.jonoherrington.com/blog/ai-didnt-break-your-culture</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/ai-didnt-break-your-culture</guid>
      <pubDate>Wed, 25 Mar 2026 00:00:00 GMT</pubDate>
      <category>engineering-leadership</category>
      <category>ai</category>
      <category>engineering-culture</category>
      <category>decision-making</category>
    </item>
    <item>
      <title><![CDATA[Get in the Dirt]]></title>
      <description><![CDATA[I spent time in a thread with 500+ engineers saying AI destroyed their love of coding. The pattern wasn't the tool. It was the rollout. Here's the difference between a mandate and a leader who actually shows up.]]></description>
      <link>https://www.jonoherrington.com/blog/get-in-the-dirt</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/get-in-the-dirt</guid>
      <pubDate>Tue, 24 Mar 2026 00:00:00 GMT</pubDate>
      <category>AI</category>
      <category>engineering leadership</category>
      <category>team culture</category>
      <category>adoption</category>
      <category>builder's leadership</category>
    </item>
    <item>
      <title><![CDATA[How to Write Architecture Decision Records That Actually Get Used]]></title>
      <description><![CDATA[An engineer on my team pulled up an ADR we'd written months earlier, realized the constraints still held, and saved two weeks on a migration that didn't need to happen. Here's the template, the repo layout, a scaffolding script, and the mistakes I made running ADRs across distributed teams.]]></description>
      <link>https://www.jonoherrington.com/blog/how-to-write-adrs-that-actually-get-used</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/how-to-write-adrs-that-actually-get-used</guid>
      <pubDate>Mon, 23 Mar 2026 00:00:00 GMT</pubDate>
      <category>architecture</category>
      <category>documentation</category>
      <category>engineering leadership</category>
      <category>ADRs</category>
      <category>teams</category>
    </item>
    <item>
      <title><![CDATA[Jargon Doesn't Make You Senior]]></title>
      <description><![CDATA[A dev posted on Reddit about their manager's manager demanding more productivity while adding more meetings. Used terms like 'o3' for one on one and 'N+2' for skip level manager. The top reply was 'Speak English brother.']]></description>
      <link>https://www.jonoherrington.com/blog/jargon-doesnt-make-you-senior</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/jargon-doesnt-make-you-senior</guid>
      <pubDate>Mon, 23 Mar 2026 00:00:00 GMT</pubDate>
      <category>engineering</category>
      <category>leadership</category>
      <category>communication</category>
      <category>culture</category>
    </item>
    <item>
      <title><![CDATA[Your Team Is Performing for You]]></title>
      <description><![CDATA[Three meetings before anyone says a real thing. That's not dysfunction. That's theater. And the leaders never see the mess. They see the performance.]]></description>
      <link>https://www.jonoherrington.com/blog/performing-for-you</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/performing-for-you</guid>
      <pubDate>Sun, 22 Mar 2026 00:00:00 GMT</pubDate>
      <category>engineering</category>
      <category>leadership</category>
      <category>culture</category>
      <category>meetings</category>
      <category>management</category>
    </item>
    <item>
      <title><![CDATA[I Added a Meeting to Feel Like a Leader]]></title>
      <description><![CDATA[A release broke payments for 10 minutes. So I added a meeting. Release retrospective. Every deployment gets a review. Sounds like leadership. The fix came from reading logs. Not from a meeting.]]></description>
      <link>https://www.jonoherrington.com/blog/meeting-to-feel-like-leader</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/meeting-to-feel-like-leader</guid>
      <pubDate>Sat, 21 Mar 2026 00:00:00 GMT</pubDate>
      <category>engineering</category>
      <category>leadership</category>
      <category>meetings</category>
      <category>incidents</category>
      <category>culture</category>
    </item>
    <item>
      <title><![CDATA[You Stopped Growing Two Years Ago]]></title>
      <description><![CDATA[You've mastered the stack. You know every corner of the codebase. You could do the work in your sleep. And that's exactly the problem. The five year wall is real. It happens because growth stopped and nobody noticed. Not your manager. Not your skip level. Definitely not you. Because everything still works.]]></description>
      <link>https://www.jonoherrington.com/blog/year-five-wall</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/year-five-wall</guid>
      <pubDate>Sat, 21 Mar 2026 00:00:00 GMT</pubDate>
      <category>engineering</category>
      <category>career</category>
      <category>leadership</category>
      <category>growth</category>
      <category>webdev</category>
      <category>programming</category>
    </item>
    <item>
      <title><![CDATA[Just Move Into Management]]></title>
      <description><![CDATA[Every time an engineer says 'I want to grow beyond coding,' someone suggests management like it's the default next step. Nobody asks if they're good with people. Nobody asks if they want to lead humans. Nobody mentions that most engineering managers fail in year one because they think managing is just 'not coding anymore.']]></description>
      <link>https://www.jonoherrington.com/blog/just-move-into-management</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/just-move-into-management</guid>
      <pubDate>Fri, 20 Mar 2026 00:00:00 GMT</pubDate>
      <category>engineering</category>
      <category>leadership</category>
      <category>career</category>
      <category>management</category>
      <category>growth</category>
    </item>
    <item>
      <title><![CDATA[You're Too Critical to Move Teams]]></title>
      <description><![CDATA[A strong engineer asks to try a new team. Explore a different problem. Grow into an adjacent space. Leadership says no. You're too critical. And the engineer hears 'we appreciate you.' What they should hear is 'we've decided your growth doesn't matter as much as our convenience.']]></description>
      <link>https://www.jonoherrington.com/blog/too-critical-to-move</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/too-critical-to-move</guid>
      <pubDate>Thu, 19 Mar 2026 00:00:00 GMT</pubDate>
      <category>engineering</category>
      <category>leadership</category>
      <category>career</category>
      <category>retention</category>
      <category>growth</category>
    </item>
    <item>
      <title><![CDATA[Golden Handcuffs Don't Feel Like Handcuffs]]></title>
      <description><![CDATA[Great pay. Smart coworkers. Reasonable hours. Generous PTO. You list all of that and think 'I have no right to feel this way.' But you're still staring at your laptop at 2pm unable to write a single line of code. The 'objectively good job' is the hardest burnout to escape. Because there's nothing obvious to blame.]]></description>
      <link>https://www.jonoherrington.com/blog/golden-handcuffs</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/golden-handcuffs</guid>
      <pubDate>Wed, 18 Mar 2026 00:00:00 GMT</pubDate>
      <category>engineering</category>
      <category>leadership</category>
      <category>career</category>
      <category>burnout</category>
      <category>growth</category>
    </item>
    <item>
      <title><![CDATA[Velocity Should Stabilize. Not Grow Forever.]]></title>
      <description><![CDATA[90 points becomes 120. 120 becomes 150. By Q4 you'd need 500 points a sprint to stay on track. Nobody questions the math because nobody wants to look like the person who can't keep up. If your velocity chart looks like a hockey stick, you don't have a productive team. You have a team that learned how to survive your metrics.]]></description>
      <link>https://www.jonoherrington.com/blog/velocity-should-stabilize</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/velocity-should-stabilize</guid>
      <pubDate>Tue, 17 Mar 2026 00:00:00 GMT</pubDate>
      <category>engineering</category>
      <category>leadership</category>
      <category>agile</category>
      <category>productivity</category>
      <category>management</category>
    </item>
    <item>
      <title><![CDATA[Your Jira Board Is Lying to Leadership]]></title>
      <description><![CDATA[120 points completed. Leadership sees progress. Meanwhile every engineer in the room is staring at the same screen thinking the same thing. That number is fiction. Not because anyone lied. Because the system was never designed to tell the truth about what engineering actually does.]]></description>
      <link>https://www.jonoherrington.com/blog/jira-board-lying</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/jira-board-lying</guid>
      <pubDate>Mon, 16 Mar 2026 00:00:00 GMT</pubDate>
      <category>engineering</category>
      <category>leadership</category>
      <category>agile</category>
      <category>productivity</category>
      <category>management</category>
    </item>
    <item>
      <title><![CDATA[Most Technical Debt Isn't Technical Debt]]></title>
      <description><![CDATA[The term has been inflated to mean anything an engineer doesn't like about the codebase. Real debt has interest. It slows delivery, raises defect rates, and creates operational drag the business can feel. If none of that is happening, you're looking at preference with better branding.]]></description>
      <link>https://www.jonoherrington.com/blog/blog-technical-debt-vs-preference</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/blog-technical-debt-vs-preference</guid>
      <pubDate>Fri, 13 Mar 2026 00:00:00 GMT</pubDate>
      <category>engineering</category>
      <category>leadership</category>
      <category>technical-debt</category>
      <category>architecture</category>
      <category>team-management</category>
    </item>
    <item>
      <title><![CDATA[Engineering Leaders Mentor Engineers. They Forget to Mentor People.]]></title>
      <description><![CDATA[We teach technical design. Code architecture. System thinking. All of it assumes the person wants to be a better engineer. What if they don't? The moment you ask someone where they actually want to be in 10 years, everything about how you lead them changes.]]></description>
      <link>https://www.jonoherrington.com/blog/blog-mentor-people-not-engineers</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/blog-mentor-people-not-engineers</guid>
      <pubDate>Fri, 06 Mar 2026 00:00:00 GMT</pubDate>
      <category>leadership</category>
      <category>engineering</category>
      <category>mentoring</category>
      <category>career-growth</category>
      <category>management</category>
    </item>
    <item>
      <title><![CDATA[I Analyzed 74 LinkedIn Posts and Found One Thing That Predicts Performance]]></title>
      <description><![CDATA[Every post above 5,000 impressions shared one trait. Every post below 3,000 didn't have it. The topic didn't matter. The format didn't matter. The time of day didn't matter. The only thing that mattered was whether the reader saw something about themselves they didn't want to see.]]></description>
      <link>https://www.jonoherrington.com/blog/blog-mirror-principle</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/blog-mirror-principle</guid>
      <pubDate>Sat, 28 Feb 2026 00:00:00 GMT</pubDate>
      <category>linkedin</category>
      <category>content</category>
      <category>engineering</category>
      <category>leadership</category>
    </item>
    <item>
      <title><![CDATA[Shopify Lost the Enterprise War]]></title>
      <description><![CDATA[I’ve built on Salesforce Commerce Cloud since 2014. I’ve publicly questioned whether Shopify could compete at enterprise scale. Then they changed the game.]]></description>
      <link>https://www.jonoherrington.com/blog/shopify-lost-enterprise</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/shopify-lost-enterprise</guid>
      <pubDate>Wed, 25 Feb 2026 00:00:00 GMT</pubDate>
      <category>commerce</category>
      <category>shopify</category>
      <category>salesforce</category>
      <category>agentic-commerce</category>
      <category>strategy</category>
      <category>AI</category>
    </item>
    <item>
      <title><![CDATA[Stop Pretending You're Still Technical]]></title>
      <description><![CDATA[Every leadership book tells you to let go, delegate, step back. That's terrible advice. 15 years of building engineering teams taught me the moment you stop understanding how your systems break, you lose the ability to make good decisions about them.]]></description>
      <link>https://www.jonoherrington.com/blog/stop-pretending-youre-technical</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/stop-pretending-youre-technical</guid>
      <pubDate>Wed, 18 Feb 2026 00:00:00 GMT</pubDate>
      <category>engineering</category>
      <category>leadership</category>
      <category>career</category>
    </item>
    <item>
      <title><![CDATA[Most Engineering Culture Is Performance Art]]></title>
      <description><![CDATA[15 years of building engineering teams taught me that culture isn’t what you put on a slide. It’s what happens when the deadline moves up and nobody’s watching.]]></description>
      <link>https://www.jonoherrington.com/blog/engineering-culture-performance-art</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/engineering-culture-performance-art</guid>
      <pubDate>Thu, 12 Feb 2026 00:00:00 GMT</pubDate>
      <category>engineering</category>
      <category>leadership</category>
      <category>culture</category>
    </item>
    <item>
      <title><![CDATA[Your Commerce Platform Isn't Ready for AI Agents]]></title>
      <description><![CDATA[Agentic commerce isn't a 2030 problem. It's a 2026 problem with a 2015 backend. I've spent over a decade building commerce platforms. Here's what actually breaks when an autonomous agent tries to shop yours.]]></description>
      <link>https://www.jonoherrington.com/blog/commerce-not-ready-for-ai-agents</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/commerce-not-ready-for-ai-agents</guid>
      <pubDate>Thu, 05 Feb 2026 00:00:00 GMT</pubDate>
      <category>agentic-commerce</category>
      <category>engineering</category>
      <category>commerce</category>
      <category>AI</category>
      <category>SFCC</category>
    </item>
    <item>
      <title><![CDATA[Your Best Engineer Is Your Biggest Risk]]></title>
      <description><![CDATA[You call them your best engineer. I call them your single load-bearing wall. Every engineering org has one. And the day they leave, you find out everything you didn’t document, didn’t distribute, and didn’t want to admit was fragile.]]></description>
      <link>https://www.jonoherrington.com/blog/best-engineer-biggest-risk</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/best-engineer-biggest-risk</guid>
      <pubDate>Thu, 29 Jan 2026 00:00:00 GMT</pubDate>
      <category>engineering</category>
      <category>leadership</category>
      <category>teams</category>
      <category>risk</category>
    </item>
    <item>
      <title><![CDATA[The Metric Nobody’s Tracking]]></title>
      <description><![CDATA[Your team shipped 10 features this week instead of 2. Everyone’s celebrating. Nobody’s asking why regression tests are catching more issues, why the pipeline is slower, and why five engineers solved the same problem five different ways.]]></description>
      <link>https://www.jonoherrington.com/blog/ai-productivity-mirage</link>
      <guid isPermaLink="true">https://www.jonoherrington.com/blog/ai-productivity-mirage</guid>
      <pubDate>Thu, 22 Jan 2026 00:00:00 GMT</pubDate>
      <category>AI</category>
      <category>engineering</category>
      <category>productivity</category>
      <category>leadership</category>
      <category>developer-tools</category>
    </item>
  </channel>
</rss>