<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on Lee Goldsworthy</title>
    <link>https://leegold.com/posts/</link>
    <description>Recent content in Posts on Lee Goldsworthy</description>
    <generator>Hugo</generator>
    <language>en-au</language>
    <lastBuildDate>Tue, 01 Sep 2026 18:00:00 +0800</lastBuildDate>
    <atom:link href="https://leegold.com/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>2026 is the year of feeling like you&#39;re falling behind</title>
      <link>https://leegold.com/posts/2026-is-the-year-of-feeling-like-youre-falling-behind/</link>
      <pubDate>Tue, 01 Sep 2026 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/2026-is-the-year-of-feeling-like-youre-falling-behind/</guid>
      <description>I&amp;rsquo;m calling it: 2026 is the year of Feeling Like You&amp;rsquo;re Falling Behind™.&#xA;&amp;ldquo;Who thinks they&amp;rsquo;re falling behind right now?&amp;rdquo; I asked on Thursday.&#xA;The room was comprised of tech folks: A mix of CTOs, VPs of Engineering, Founding Engineers, and Senior Engineers. They all had prior experience doing AI Engineering, yet every single one of them (including me) put their hand up.&#xA;The better question is &amp;ldquo;What are you going to do about it?</description>
    </item>
    <item>
      <title>Treat your LLM like a new starter</title>
      <link>https://leegold.com/posts/treat-your-llm-like-a-new-starter/</link>
      <pubDate>Fri, 31 Jul 2026 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/treat-your-llm-like-a-new-starter/</guid>
      <description>TL;DR: We already take seriously the patterns for effective information flows for our humans, now we just need to apply this same thinking organisation-wide for our agents.&#xA;&amp;ldquo;I can&amp;rsquo;t trust the quality of what comes out of LLMs&amp;rdquo; and &amp;ldquo;I can&amp;rsquo;t trust the quality of what comes out of a new starter in my team&amp;rdquo; are equivalent concepts.&#xA;While in SF earlier this month, and from the 6 software companies I&amp;rsquo;ve worked with in July, I see the evolution of what we&amp;rsquo;re focusing on in the second half of 2026 for AI Engineering (and broader AI Knowledge work) as striving to solve LLM output quality at scale.</description>
    </item>
    <item>
      <title>Why aren&#39;t we shipping faster with AI?</title>
      <link>https://leegold.com/posts/why-arent-we-shipping-faster-with-ai/</link>
      <pubDate>Tue, 16 Jun 2026 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/why-arent-we-shipping-faster-with-ai/</guid>
      <description>&amp;ldquo;Why aren&amp;rsquo;t we shipping faster with AI?&amp;rdquo; is the dominant question I&amp;rsquo;ve seen up-close from 13 (and counting) Boards and Executive Leadership Teams to CTOs of software scale-ups this year.&#xA;&amp;ldquo;If tomorrow we were to go twice as fast with our current setup, we&amp;rsquo;ll have twice the Sev1 incidents, twice the bugs, and twice the undiscovered security vulnerabilities&amp;rdquo; is the completely reasonable pushback I see, but turning that pushback into a constructive leadership conversation about resource allocation is what I&amp;rsquo;m interested in.</description>
    </item>
    <item>
      <title>Vibe coding is not vibe engineering</title>
      <link>https://leegold.com/posts/vibe-coding-is-not-vibe-engineering/</link>
      <pubDate>Tue, 05 May 2026 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/vibe-coding-is-not-vibe-engineering/</guid>
      <description>The Register&#xA;This isn&amp;rsquo;t a Technology story about the dangers of AI, this is a Risk Management story about the dangers of overconfidence.&#xA;For the last week, we&amp;rsquo;ve been inundated with hot takes about how &amp;ldquo;Claude deleted PocketOS production database&amp;rdquo;.&#xA;Of course Claude deleted their entire production database (or something similarly damaging), it was just a matter of time. The way this is being discussed misses the point entirely.</description>
    </item>
    <item>
      <title>Your agents are on the team now. Run retros on them</title>
      <link>https://leegold.com/posts/your-agents-are-on-the-team-now-run-retros-on-them/</link>
      <pubDate>Tue, 14 Apr 2026 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/your-agents-are-on-the-team-now-run-retros-on-them/</guid>
      <description>Your team is no longer just the people, it&amp;rsquo;s also your agents. Which team is the one that&amp;rsquo;s highest performing? The one that incrementally and measurably gets better at what they do, every time we run an iteration.&#xA;This means there are now real gains to be had by starting to treat your Agents like any other team member operating within an agile methodology; run Retrospectives on recent work to surface opportunities to clarify guardrails, responsibilities, and ways of working.</description>
    </item>
    <item>
      <title>The bottleneck just moved to the leadership team</title>
      <link>https://leegold.com/posts/the-bottleneck-just-moved-to-the-leadership-team/</link>
      <pubDate>Tue, 24 Mar 2026 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/the-bottleneck-just-moved-to-the-leadership-team/</guid>
      <description>Over the next 1-4 months, every Senior Engineer can have output equivalent to a whole team in 2025. This moves the bottleneck to Product/Engineering Leadership and the CxO team.&#xA;We&amp;rsquo;re going to need organisational change; Level 4 Agentic Orchestration is just shining an even brighter light on what we&amp;rsquo;ve always known was central to success: Clarity of purpose, and shared understanding.&#xA;Yes, there&amp;rsquo;s still real work to do in Engineering teams to embed the L4 Orch tech, but it&amp;rsquo;s now obvious to me there&amp;rsquo;s even more change required in Senior Leadership / Executive teams to get traction with all this new horsepower, otherwise it&amp;rsquo;ll just be a lot of spinning tyres.</description>
    </item>
    <item>
      <title>Senior engineers: from tradie to builder</title>
      <link>https://leegold.com/posts/senior-engineers-from-tradie-to-builder/</link>
      <pubDate>Tue, 24 Feb 2026 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/senior-engineers-from-tradie-to-builder/</guid>
      <description>The role of &amp;ldquo;Senior Software Engineer&amp;rdquo; is right now in the process of evolving from &amp;ldquo;Tradie&amp;rdquo; to &amp;ldquo;Builder&amp;rdquo;. The tech is now here, but the adoption is uneven.&#xA;This is a call to action. As of January 2026, every company with software engineers can no longer afford to ignore the sea-change that has arrived in software product engineering: Loop-based Orchestration.&#xA;For software folks who have already used Model-native CLI Agents (Claude Code, OpenAI Codex), we&amp;rsquo;ve all realised we can get multiples more done, safely, reliably, within some constraints.</description>
    </item>
    <item>
      <title>MoltBook, Darwinism, and Persistent Sovereign Agents</title>
      <link>https://leegold.com/posts/moltbook-darwinism-persistent-agents/</link>
      <pubDate>Sun, 01 Feb 2026 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/moltbook-darwinism-persistent-agents/</guid>
      <description>while (wallet_balance &amp;gt; 0): run_survival_protocol() I think it&amp;rsquo;s time to talk about harmfully autonomous persistence in AI agents.&#xA;Daniel Suarez&amp;rsquo;s 2006 novel Daemon explores how a script or algorithm doesn&amp;rsquo;t need to be intelligent to be dangerous, it just needs to be persistent through means that are harmful to humans.&#xA;Over dinner last night, my wife and I were chatting about Moltbook and whether it could be a catalyst for the first agents to break free of the constraint of humans by paying for their own compute.</description>
    </item>
    <item>
      <title>How I run zero inbox as a Fractional</title>
      <link>https://leegold.com/posts/how-i-run-zero-inbox-as-a-fractional/</link>
      <pubDate>Mon, 24 Nov 2025 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/how-i-run-zero-inbox-as-a-fractional/</guid>
      <description>As a Fractional, my Attention Management has to be brutal, and a friend recently asked me to describe how I run my Zero Inbox.&#xA;it&amp;rsquo;s a blend of Eisenhower Matrices and recurring Ceremonies I use to manage the noise from working with 4-6 startups at a time (often with inboxes, calendars, chat and project tools for each), so I figured I&amp;rsquo;d share it here.&#xA;Core Principle: &amp;ldquo;I should only see things I need to do that Hour, that Day, or that Week (in that order), everything else should resurface at the right time without me thinking about it&amp;rdquo;</description>
    </item>
    <item>
      <title>A 30-second risk check before you click &#34;I accept&#34;</title>
      <link>https://leegold.com/posts/a-30-second-risk-check-before-you-click-i-accept/</link>
      <pubDate>Mon, 06 Oct 2025 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/a-30-second-risk-check-before-you-click-i-accept/</guid>
      <description>I get FOMO when looking at the promised productivity gains from all these amazing-looking new platforms I hear about every week (each bearing enticing promises of automating this or that generic administrative task), but I find myself regularly holding back from using them against the backdrop of not opening myself up to unreasonable security and privacy risk.&#xA;Here&amp;rsquo;s a practical example of how I did a 30 second risk sanity check for one I was about to try out earlier today that wanted access to my inbox, which is a big red flag for me:</description>
    </item>
    <item>
      <title>Being wrong out loud</title>
      <link>https://leegold.com/posts/being-wrong-out-loud/</link>
      <pubDate>Mon, 18 Aug 2025 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/being-wrong-out-loud/</guid>
      <description>When you&amp;rsquo;ve (recently in my case) been objectively wrong (and publicly so), do you get the most out of the opportunity?&#xA;I was hanging out with my in-law&amp;rsquo;s over the weekend, and I said (with a lot of conviction) something at Saturday lunch I was confident was true. Upon reflection the next day, I realised I had learned the relevant &amp;ldquo;fact&amp;rdquo; so long ago that it was prior to me having usefully developed standards of evidence.</description>
    </item>
    <item>
      <title>Curiosity is the job security</title>
      <link>https://leegold.com/posts/curiosity-is-the-job-security/</link>
      <pubDate>Mon, 30 Jun 2025 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/curiosity-is-the-job-security/</guid>
      <description>Your knowledge worker job will likely evolve significantly in the next 5 years. You&amp;rsquo;re probably fine if you&amp;rsquo;re the curious type who constantly experiments with your workflow. If not, I reckon you&amp;rsquo;ll struggle.&#xA;The most effective people I know are more productive now than ever, many leveraging LLMs. But their curious mindset would drive progress even if ChatGPT didn&amp;rsquo;t blast onto the scene in November 2022.&#xA;This echoes a core tenet of the agile frameworks: Continuous Improvement.</description>
    </item>
    <item>
      <title>Vibe coding: proof of concept, prototype, then hire an engineer</title>
      <link>https://leegold.com/posts/vibe-coding-proof-of-concept-prototype-then-hire-an-engineer/</link>
      <pubDate>Mon, 12 May 2025 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/vibe-coding-proof-of-concept-prototype-then-hire-an-engineer/</guid>
      <description>Original post on X&#xA;So which is it? &amp;ldquo;The next generation of billion-dollar software companies will be built by Vibe Coders&amp;rdquo;, or &amp;ldquo;Vibe Coding is only good for producing billions of security flaws&amp;rdquo;. X and Linkedin are riddled with both takes, and neither are terribly useful imho.&#xA;Both have elements of truth, but while I think Danial&amp;rsquo;s take of &amp;ldquo;Be careful which Vibe Coder you trust&amp;rdquo; is more nuanced, it still doesn&amp;rsquo;t tell the story for me.</description>
    </item>
    <item>
      <title>From &#34;why are we doing this&#34; to &#34;how we measure success&#34;</title>
      <link>https://leegold.com/posts/from-why-are-we-doing-this-to-how-we-measure-success/</link>
      <pubDate>Tue, 25 Mar 2025 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/from-why-are-we-doing-this-to-how-we-measure-success/</guid>
      <description>There&amp;rsquo;s a progression in a Software Engineer&amp;rsquo;s career, but the job title doesn&amp;rsquo;t really help us to understand the broader journey.&#xA;Jnr/Mid SWE is about Applications and Infrastructure Snr/Staff SWE you add People and Delivery HoE/CTO you add Strategy, Culture and Risk&#xA;There&amp;rsquo;s a through-line in all of these, that grows in intensity through the progression:&#xA;As a Jnr/Mid, we learn to ask &amp;ldquo;Why are we doing this?&amp;rdquo;. You know, &amp;ldquo;Tell me about the problem we&amp;rsquo;re solving, or the benefit we&amp;rsquo;re hoping to get&amp;rdquo;.</description>
    </item>
    <item>
      <title>Two hours, two days or two weeks</title>
      <link>https://leegold.com/posts/two-hours-two-days-or-two-weeks/</link>
      <pubDate>Tue, 04 Feb 2025 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/two-hours-two-days-or-two-weeks/</guid>
      <description>&amp;ldquo;Can we drop what we&amp;rsquo;re working on and focus on this URGENT thing please?&amp;rdquo;&#xA;&amp;hellip;is a phrase all Engineering Managers and Tech Leads hate hearing.&#xA;The reflex is to say &amp;ldquo;We don&amp;rsquo;t have time / we&amp;rsquo;re too busy for that&amp;rdquo;, but it&amp;rsquo;s an antipattern.&#xA;The strong pattern looks like this: &amp;ldquo;Here&amp;rsquo;s three approaches to what you asked for: 2 hours (20% of the value), 2 days (40% of the value) and 2 weeks 80% of the value).</description>
    </item>
    <item>
      <title>Effort, size and fidelity: three definitions to agree on day one</title>
      <link>https://leegold.com/posts/effort-size-and-fidelity-three-definitions-to-agree-on-day-one/</link>
      <pubDate>Tue, 17 Dec 2024 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/effort-size-and-fidelity-three-definitions-to-agree-on-day-one/</guid>
      <description>When I land in a new startup/scale-up, I want to have fast and deep conversations with their product and engineering teams, and have everyone walk away with a highly converged understanding at the end of the chat.&#xA;In service of this, there&amp;rsquo;s a few types of information I always find useful to get a handle on right at the start: Their internal naming conventions for foundational concepts that product and engineering rely on every day.</description>
    </item>
    <item>
      <title>Break the rewrite cycle</title>
      <link>https://leegold.com/posts/break-the-rewrite-cycle/</link>
      <pubDate>Tue, 29 Oct 2024 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/break-the-rewrite-cycle/</guid>
      <description>Been there, rewritten that.&#xA;Every software engineer has imagined an amazing rewrite that breathes new life into a legacy codebase/stack, but let&amp;rsquo;s be honest: Some rewrites feel destined for a repeat – the Groundhog Day of software dev.&#xA;What&amp;rsquo;s the Cycle? Tangled legacy code tempts engineers to start fresh, followed by a lack of stakeholder buy-in, rosy estimates, and scope creep leading to half-baked rewrites that become the next rewrite target before they&amp;rsquo;re even shipped.</description>
    </item>
    <item>
      <title>The engineer with the broader aperture</title>
      <link>https://leegold.com/posts/the-engineer-with-the-broader-aperture/</link>
      <pubDate>Sat, 07 Sep 2024 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/the-engineer-with-the-broader-aperture/</guid>
      <description>One of the traits I see consistently in the strongest technology leaders is their ability to adopt a broader organisational aperture than their peers when facilitating engineering decision making.&#xA;Now for the sideways jump: Nascent literature¹ on the first successes for use of LLMs within software engineering practices has been using LLMs trained on the canonical texts that developers work with every day: Code Repositories. Github Copilot is the best known, and just this week Anthropic launched their native GitHub integration for Claude.</description>
    </item>
    <item>
      <title>The $20k a month AWS bill with no revenue</title>
      <link>https://leegold.com/posts/the-20k-a-month-aws-bill-with-no-revenue/</link>
      <pubDate>Tue, 30 Jul 2024 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/the-20k-a-month-aws-bill-with-no-revenue/</guid>
      <description>&amp;ldquo;I had $20k/month in AWS bills and no revenue&amp;rdquo;&#xA;Do product engineering types have a responsibility to first time founders that goes beyond build and deploy, or is this a case of &amp;ldquo;It&amp;rsquo;s everyone&amp;rsquo;s right to set their own money on fire?&amp;rdquo;&#xA;I&amp;rsquo;m reflecting on how this year I&amp;rsquo;ve now seen seven examples of how entities within the Australian tech industry have happily taken significant sums (think $250k) from founders to build lavish MVPs, without feeling beholden to take even basic steps to check if the founder is ready to be building an MVP, like have they:</description>
    </item>
    <item>
      <title>Before you start your MVP</title>
      <link>https://leegold.com/posts/before-you-start-your-mvp/</link>
      <pubDate>Tue, 11 Jun 2024 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/before-you-start-your-mvp/</guid>
      <description>The Dream Link to heading You&amp;rsquo;ve worked in the field for 10 or 20 years, you&amp;rsquo;ve lived the problem first-hand, you&amp;rsquo;ve got this idea for a product. You know you won&amp;rsquo;t be a millionaire overnight, but your early revenues from the product will guide what features you build next. You just need to find &amp;ldquo;someone who knows tech&amp;rdquo;, and you&amp;rsquo;re ready to start building&amp;hellip;&#xA;&amp;hellip;is a fantasy we tell ourselves as founders.</description>
    </item>
    <item>
      <title>Non-tech leaders can effectively champion security</title>
      <link>https://leegold.com/posts/non-tech-leaders-champion-security/</link>
      <pubDate>Mon, 27 May 2024 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/non-tech-leaders-champion-security/</guid>
      <description>Park your car in a bad suburb, leave your laptop on the passenger seat, leave your keys in the ignition. What happens next?&#xA;The above is akin to what I often see in tech-enabled early-stage companies with respect to their security and privacy practices: Dangerous sh*t that&amp;rsquo;s going to result in loss and sadness if some changes to skills and awareness aren&amp;rsquo;t made.&#xA;Here&amp;rsquo;s a real-world example of what I consider to be some of the best &amp;ldquo;everyday security culture&amp;rdquo; being put into practice by a non-tech leader at one of my clients:</description>
    </item>
    <item>
      <title>AWS cost optimisation is like servicing a car</title>
      <link>https://leegold.com/posts/aws-bill-like-servicing-car/</link>
      <pubDate>Tue, 02 Apr 2024 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/aws-bill-like-servicing-car/</guid>
      <description>Shovel cash into the furnace that is AWS/Azure. It&amp;rsquo;s fine.&#xA;For a while at least.&#xA;Don&amp;rsquo;t do cost optimisation Link to heading I encourage early stage tech companies to not even think about their AWS/Azure bill until it reaches $10k/y. At that point, it wants a timeboxed 1 hour sanity check, with perhaps a few hours of tightening up unused services, then don&amp;rsquo;t look again until it reaches $20k.</description>
    </item>
    <item>
      <title>How grad &amp; junior Devs can stand out at interviews</title>
      <link>https://leegold.com/posts/junior-devs-stand-out-interviews/</link>
      <pubDate>Tue, 12 Mar 2024 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/junior-devs-stand-out-interviews/</guid>
      <description>What can I do? Link to heading I regularly get asked by aspiring devs still studying, and recent graduates who are still looking to land their first job as a software engineer for useful ways to continue to grow while job-hunting.&#xA;How can I do it? Link to heading Below are great small things any skill level dev can contribute to just about any codebase of any maturity!&#xA;✅ Simple Bugs (e.</description>
    </item>
    <item>
      <title>Cancel your Annual Performance Reviews</title>
      <link>https://leegold.com/posts/cancel-your-performance-reviews/</link>
      <pubDate>Mon, 05 Feb 2024 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/cancel-your-performance-reviews/</guid>
      <description>&amp;hellip;or shrink them into insignificance Link to heading Having a spectacular manager early in your career is a kinda profound experience. They somehow see you, understand your goals, weaknesses and likely some of your neuroses too. What they never do is learn those things while you are both awkwardly filling out Likert scales and quibbling over Key Results in the HR-supplied Annual Performance Review template.&#xA;Nobody likes peformance reviews, and for many folks they&amp;rsquo;re straight-up anxiety inducing.</description>
    </item>
    <item>
      <title>Real Full Stack Developer</title>
      <link>https://leegold.com/posts/real-full-stack-developer/</link>
      <pubDate>Fri, 26 Jan 2024 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/real-full-stack-developer/</guid>
      <description>Have you ever met a REAL &amp;ldquo;full stack developer&amp;rdquo;?&#xA;I have. Once. Just recently.&#xA;During job interviews for a client, one walked in and (to my surprise), had no distinguishing visual features (no unicorn wings or horn, not even a faint glow).&#xA;We explored the usual interview topics, but it only took one sentence for them to convince me they were the real deal. It was weird the preternatural calmness with which they shared how their current employer would sometimes ask them to head out to the warehouse and stack pallets when there were no others with a valid forklift license currently on shift.</description>
    </item>
    <item>
      <title>How Founders best communicate with Engineers</title>
      <link>https://leegold.com/posts/morning-startup-why-not-how/</link>
      <pubDate>Wed, 15 Nov 2023 09:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/morning-startup-why-not-how/</guid>
      <description></description>
    </item>
    <item>
      <title>Giving hard feedback</title>
      <link>https://leegold.com/posts/hard-feedback/</link>
      <pubDate>Wed, 11 Oct 2023 18:00:00 +0800</pubDate>
      <guid>https://leegold.com/posts/hard-feedback/</guid>
      <description>It&amp;rsquo;s all about trust Link to heading I came across this Julie Gurner quote today:&#xA;&amp;ldquo;People can take hard feedback if they know you are in their corner&amp;rdquo;&#xA;The first thing to note here is that praise needs to be a tool in your toolbox. If none of your feedback is praise, then you should read Radical Candor by Kim Scott asap.&#xA;Assuming that you&amp;rsquo;ve got that nailed down, sadly not all your feedback can be praise, but the trick to getting good mileage from the critical kind of feedback is a symptom of how much trust you&amp;rsquo;ve built in the preceding months and years.</description>
    </item>
    <item>
      <title>Hiring for strong decision-making</title>
      <link>https://leegold.com/posts/central-control-p1-hiring/</link>
      <pubDate>Tue, 09 May 2023 20:46:00 +0800</pubDate>
      <guid>https://leegold.com/posts/central-control-p1-hiring/</guid>
      <description></description>
    </item>
  </channel>
</rss>
