<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Engineering Leadership on Lee Goldsworthy</title>
    <link>https://leegold.com/categories/engineering-leadership/</link>
    <description>Recent content in Engineering Leadership on Lee Goldsworthy</description>
    <generator>Hugo</generator>
    <language>en-au</language>
    <lastBuildDate>Tue, 24 Mar 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://leegold.com/categories/engineering-leadership/index.xml" rel="self" type="application/rss+xml" />
    <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>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>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>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>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>
  </channel>
</rss>
