michaelheap.com

Never leave on a no

2026-02-13T03:52:05Z

One of the biggest mistakes I see new managers make is how they manage disagreement with their boss.

They do one of two things:

They nod along, but disagree quietly and disengage
They keep arguing until they run out of time and the meeting ends awkwardly, with no real decision

Both options leave their boss frustrated.

Something that's worked well for me is that I never leave a conversation on a no.

It doesn't mean we always agree. It means that we're aligned on what the next steps are.

Disagreeing behind closed doors

I believe that it's everyone's responsibility to challenge bad ideas. You should challenge ideas when:

You have information that the person you're talking to doesn't
You're accountable for the outcome
You believe a decision will materially harm your team, customers or business

How you challenge is important. Shouting in a meeting room with 15 other people won't get you anywhere. Instead, argue with your boss in private where there is space to listen and to be heard.

Know when to stop

There's a difference between advocacy and infinite debate. Knowing when to stop pushing and start aligning is a skill.

Early in a discussion you can push hard:

Ask clarifying questions
Share concrete risks
Offer alternatives, not just objections

But at some point, you'll feel a shift in the conversation. You start getting repeated answers. The trade-offs have been heard. The decision has been made.

The most senior person in the room decides when the argument is over. Your job is to notice.

Missing that moment once is forgivable. Missing it repeatedly gets you labeled “difficult,” regardless of the quality of your ideas.

Disagreement is a tool for improving decisions, and once the decision is made your job changes.

What “never leave on a no” actually means

Before the meeting ends, alignment has to be explicit.

You should be able to say one of these - and mean it:

“I disagree, but I understand the decision and I’ll execute it.”
“I still have concerns, but given the trade-offs, this is the direction we’re taking.”
“Let’s try this for X weeks and revisit with data.”

A clean disagreement that ends in commitment builds trust. A fuzzy disagreement that lingers destroys it.

From your boss’s perspective, there are few things more dangerous than a manager who:

Appears aligned in the meeting
Signals doubt afterward
Executes half-heartedly

If you can’t commit, say so in the room. Don’t carry a private veto.

It's easy to paint leadership as the bad guys.

"This wasn't my call"
"I don't agree, but..."
"Leadership wants us to..."

It feels like solidarity, but it teaches your team that alignment is optional.

Your team works for you, not leadership, and they need to know what they need to do be successful in your business.

What was the decision?
Why did we decide this?
What does success look like?

You don't have to say that you're fully behind the idea, but you do need to communicate that this is the direction.

“There were other options, and we discussed them. This is the direction we’re taking, and here’s how we’ll make it successful.”

If you can't stand behind the decision at all, you need to get back in a room with your boss and talk until you can.

Your real job

Your job isn’t to win arguments.
It’s to reduce uncertainty.

Argue fiercely when it matters.
Notice when the argument is over.
And never walk out of the room without a clear answer to one question:

“What are we doing next?”

Update the AUR from GitHub Actions

2026-02-05T13:45:31Z

I maintain trello-cli, which is also published to the Arch User Repository (AUR).

Each time the package is published, I needed to update the PKGBUILD with a new version and sha512sum. I'm no longer an Arch user (I miss it, but MacOS works so much better for my current role) and so I don't have makepkg readily available.

I had an idea that updating the PKGBUILD could be done with GitHub Actions:

Updating an AUR package for a node based tool could be automated using GitHub Actions.
Each time a release is tagged, the pkgver and sha512sums fields in the PKGBUILD need updating, and the repo needs pushing to the https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD
The sha512sum needs to be calculated from the published NPM package, so we'd need to wait until the version is available, download it from the registry and then calculate the checksum.

Here's how I did it:

Generate an SSH keypair:

bash
ssh-keygen -t ed25519 -f ~/.ssh/aur -C "GH AUR - your-email@example.com"

Add the public key to your AUR account:
- Go to https://aur.archlinux.org → My Account → SSH Public Keys
- Paste contents of ~/.ssh/aur.pub
Add the private key as a GitHub secret:
- Go to your repo → Settings → Secrets and variables → Actions
- Create secret named AUR_SSH_PRIVATE_KEY
- Paste contents of ~/.ssh/aur

Then create a GitHub Actions workflow that you can run. You can't add it to your npm release workflow as there is a delay between publishing and it appearing in the API.

There's some tricky runuser logic required when updating .SRCINFO as you can't run makepkg as root:

yaml
name: Update AUR Package
on:
  workflow_dispatch:
  schedule:
    - cron: "0 0 * * 0" # Weekly on Sunday at midnight UTC
jobs:
  update-aur:
    runs-on: ubuntu-latest
    container:
      image: archlinux:base-devel
    steps:
      - name: Install dependencies
        run: pacman -Sy --noconfirm jq openssh git
      - name: Get latest npm version
        id: npm
        run: |
          VERSION=$(curl -s https://registry.npmjs.org/trello-cli/latest | jq -r '.version')
          echo "version=$VERSION" >> $GITHUB_OUTPUT
      - name: Download tarball and get sha512sum
        id: checksum
        run: |
          curl -sLO "https://registry.npmjs.org/trello-cli/-/trello-cli-$.tgz"
          SHA512=$(sha512sum trello-cli-$.tgz | cut -d' ' -f1)
          echo "sha512=$SHA512" >> $GITHUB_OUTPUT
      - name: Setup SSH for AUR
        run: |
          mkdir -p ~/.ssh
          echo "$" > ~/.ssh/aur
          chmod 600 ~/.ssh/aur
      - name: Clone AUR repo
        env:
          GIT_SSH_COMMAND: "ssh -i ~/.ssh/aur -o IdentitiesOnly=yes -o StrictHostKeyChecking=no"
        run: git clone ssh://aur@aur.archlinux.org/trello-cli.git aur-repo
      - name: Check if update needed
        id: check
        working-directory: aur-repo
        run: |
          CURRENT=$(grep '^pkgver=' PKGBUILD | cut -d= -f2)
          if [ "$CURRENT" = "$" ]; then
            echo "Already up-to-date (version $CURRENT)"
            echo "skip=true" >> $GITHUB_OUTPUT
          else
            echo "Update available: $CURRENT -> $"
            echo "skip=false" >> $GITHUB_OUTPUT
          fi
      - name: Update PKGBUILD
        if: steps.check.outputs.skip != 'true'
        working-directory: aur-repo
        run: |
          sed -i "s/^pkgver=.*/pkgver=${{ steps.npm.outputs.version }}/" PKGBUILD
          sed -i "s/^pkgrel=.*/pkgrel=1/" PKGBUILD
          sed -i "s/^sha512sums=.*/sha512sums=('${{ steps.checksum.outputs.sha512 }}')/" PKGBUILD
      - name: Update .SRCINFO
        if: steps.check.outputs.skip != 'true'
        working-directory: aur-repo
        run: |
          useradd -m builder
          mkdir -p /home/builder/build
          cp -a . /home/builder/build
          chown -R builder:builder /home/builder/build
          runuser -u builder -- bash -lc 'cd /home/builder/build && makepkg --printsrcinfo > .SRCINFO'
          cp /home/builder/build/.SRCINFO ./.SRCINFO
      - name: Commit and push
        if: steps.check.outputs.skip != 'true'
        working-directory: aur-repo
        env:
          GIT_SSH_COMMAND: "ssh -i ~/.ssh/aur -o IdentitiesOnly=yes -o StrictHostKeyChecking=no"
        run: |
          git config user.name "Michael Heap"
          git config user.email "m@michaelheap.com"
          git add PKGBUILD .SRCINFO
          git commit -m "Update to version $"
          git push

Now you have a workflow that will update your PKGBUILD automatically once per week, or whenever you trigger the action manually.

Yes, if…

2026-02-04T20:25:58Z

People love hearing “yes.”

In a meeting, it sounds like momentum. In Slack, it reads as alignment. On a roadmap, it feels like progress.

It's also the first step towards disappointment. "Yes" is a contract - a commitment to deliver something. If you say "yes" to everything, you start paying for it with late nights, dropped balls and a creeping resentment that's hard to admit because you chose to say yes.

Every “yes” goes on an invisible ledger. Time, attention, credibility. All quietly debited, rarely reconciled. Eventually you will go bankrupt and disappoint someone. The only question is whether you disappoint them when they ask, or later when your lack of delivery has a much higher cost.

The two types of "yes"

We say “yes” for many reasons. In personal relationships, it can strengthen bonds and make others feel valued. In professional settings, saying “yes” can signal teamwork, ambition, and a commitment to shared goals. However, saying “yes” can also be driven by fear. A fear of disappointing others, a fear of missing out, or a fear of conflict.

No matter why we say yes, the expectation to be agreeable leads to us committing to way more than we can ever hope to achieve. You say yes to avoid disappointing someone, only to disappoint them at the worst possible time: after you've agreed, they've told other people about their idea and half of the org is excited.

So, how do you keep the momentum that "yes" brings without overcommitting yourself? By using "Yes, if."

"Yes, If" is a trade

“Yes” pretends there is no conversation. It hides the cost and defers the pain.

“No” without context shuts the conversation down before anything useful is learned.

“Yes, if” is the conversation.

“Yes, if” makes the cost visible. It takes the invisible tax you were about to pay and puts it on the table where everyone can see it. Not as a complaint. Not as drama. As accounting.

“Yes, if you can wait until Thursday after the report goes out.”
“Yes, if we agree this replaces the other thing I’m doing.”
“Yes, if you do the first draft and I’ll review.”
“Yes, if we can fund the work and assign an owner.”

Most frustration at work doesn’t come from disagreement. It comes from ambiguity.

Applying this in real life

A good “Yes, if” is just good bookkeeping. It names which account you’re drawing from.

Time: “Yes, if it can wait until Thursday.”
Priority: “Yes, if Bob agrees this outranks the report.”
Ownership: “Yes, if you draft it and I’ll review.”
Scope: “Yes, if we do a 1-page version, not a full report.”
Resourcing: “Yes, if we fund it / staff it.”

Most org pain comes from pretending those currencies are infinite. By explicitly naming them and negotiating with the requester you can be collaborative without overcommitting.

Price the work

“Yes, if” is about maintaining balance. It’s about making sure the work you agree to aligns with your time, energy, and priorities.

Next time someone asks you for something, name the trade-offs. Make the constraint explicit. Price the work. See if they still want it.

If that trade kills the request, it wasn’t a priority. It was just an idea looking for someone else to carry the cost.

“Yes, if” is about maintaining balance. It's about making sure that projects align with your time, energy, and priorities. It fosters collaboration without compromising your well-being. Next time you’re faced with a request, remember: you don’t have to say “yes” to everything, but with the right conditions in place, you might just find a way to make it work for everyone.

Delivery and Dopamine

2026-01-28T20:08:57Z

I've built my career around being the person that delivers. Throw me into a messy problem and I'll figure it out and make progress.

My performance reviews praised output. Peers trusted me as the person who “got things done”. The system rewarded shipping, and for a long time I used that as my definition of “doing my job well”. I confused visibility with value, and if I’m being totally honest, I was addicted to being the person that everyone pinged.

Then one day, my career stalled. I just couldn't justify another promotion on output alone. Shipping things feels good in a way that designing systems doesn't. Shipping provided that immediate dopamine hit, but system design doesn't work like that. Feedback is delayed and ambiguous, and honestly, things usually get worse before they get better.

You can justify being a player-coach as a manager, senior manager and in some places, even a director. But at some point you need to accept that the best use of your time is to act as a multiplier for the team that you're supporting.

That's where I failed.

Dopamine vs. Leverage

Execution gives you fast feedback. System design demands patience.

When I say “designing systems,” I don’t mean architecture diagrams. I mean the interfaces that shape how the business operates: who makes decisions, how work gets planned and what happens when things break.

Discipline means letting the system converge on an idea and make decisions without you "helping". It means allowing systems to fail without heroics, enabling the organization to understand the flaws in the system. It means trading that dopamine hit for organizational leverage.

It also means being comfortable with feeling like a failure. Letting projects fail felt irresponsible. Not being hands on felt lazy. And if I'm honest, not getting that dopamine hit felt like withdrawal.

The Relapse

When leaders step back, things slow down. Metrics wobble. People complain.

That's the system revealing itself. Heroics are praised, and organizations choose short-term relief over long-term leverage. So when things got messy, I didn’t choose execution, I relapsed into it. It was the easy choice. The safe choice. It was also the wrong choice.

I fell back into being an IC multiple times. Each time the dopamine hit was even bigger. "Things were really going downhill and you turned it around!" Each time, it was even harder to crawl back out of the routine of shipping and start thinking about the overall system.

In one example, there was a last minute tooling update required for a key customer. So I dove in, made the changes, got the relevant approval and shipped a fix within 24 hours. The customer was happy, the account team was happy, the engineering team appreciated not being interrupted... then less than a week later the exact same thing happened again. Everyone's first instinct was to message me. My save the previous week didn’t fix the problem; it taught the organization the workaround.

The "helping" trap

I told myself I was "just helping".

But “helping” was a trap. It kept me focused on solving the immediate problem instead of asking why this problem kept showing up. It made me the bottleneck instead of fixing the decision boundary. It let me feel needed, and in the process I stole learning from the organization. The team didn’t get stronger; the system didn’t improve; I just became the workaround.

I'm not entirely at fault, though. While I was chasing the next hit I was also operating in an environment that was easy to understand. Do good work, get rewarded. Designing systems is filled with ambiguity and risk. System design is political, cross-functional and uncertain. It's also invisible to your stakeholders (until it fails). Execution is visible, measurable and safe.

Build a System That Ships Without You

Building a sustainable system is thankless work. The feedback loop is slow, and the wins are quiet. You don’t measure it by what you shipped - you measure it by what happens when you’re not there.

A system is getting healthier when:

Recurring fires disappear because you removed root causes instead of treating symptoms.
Decisions happen without you (and they’re good enough. Not perfect. Good enough).
Approval paths are explicit: who decides, what “good” looks like, and how long each step should take.
Leading indicators show up early, so problems surface while they’re still cheap to fix.

If you're looking for a concrete example, we moved approvals from an ad-hoc Slack-based approach with emoji reactions to a weekly forum with named decision owners and SLAs. It felt like more process, but the overall time investment was much lower.

To understand if the system is working, ask yourself "if I take a month off, does the team still make good decisions, ship on time and recover from setbacks?".

(Fun fact! This is one of the reasons I quit my last job. I took 3 months off when my baby was born and when I got back to work it was as though I'd been there the whole time. They no longer needed me, and it was time to go and build systems somewhere else.)

The organization trained me

The org rewarded heroics, and I cashed the checks. Repeatedly.

In many cases a leader is doing what the organization expects of them. It's not that they can't let go of execution, it's that no-one tells them that they should. So we keep delivering, getting that dopamine hit and feeling effective.

Until organizations realize that leadership is about designing systems that enable the work, rather than doing it, they'll keep celebrating productivity and wondering why nothing scales.

We have to fix the incentives. Evaluate leaders based on team throughput and decision quality, not individual output. Celebrate recurring fires that no longer happen. Put “eliminated dependencies” and “decisions made without me” into performance reviews. Heroic saves should result in a postmortem and a system fix, not a medal.

If heroics are the path to praise, leaders will keep relapsing (even when they know better). If you keep rewarding people for being the system rather than building the system you won’t get leaders.

You’ll get bottlenecks with better titles.

Fix the inputs, not the outputs

2026-01-21T09:58:37Z

A friend of mine is a design leader at a company with a couple of thousand people. We were recently chatting about the amount of time she was spending reviewing her team's work. It wasn't because the work was bad, but because she had no idea if the design met the needs of the project. She was spending hours trying to reverse-engineer the requirements from the final design.

The reviews didn't feel good for the individual designers either. Their manager was coming in at the end of a project and scrutinizing every little decision without the full context of what the requirements were. As it turned out, the designers also didn't have the full context - they knew how it started, but not how the requirements evolved over time. That information lived somewhere between the manager, the designers, and the project lead, with no clear source of truth.

My friend works in a design team, but I've seen this play out in a variety of settings. Engineers without clear product requirements. DevRel teams without clear metrics. Salespeople without a solid ideal customer profile. Anytime someone's required to fill in the blanks themselves, there's a high chance that it will lead to frustration for everyone involved.

Garbage In, Garbage Out

Every output is an echo of its inputs. If the team doesn't know what "good" looks like from the start, they have to make decisions that they're not informed enough to make. Sometimes it works out, but more often than not it results in conflict.

The person reviewing the output feels that something is "off", while the team is blindsided by feedback that could have been provided as a requirement early, before the work was done.

Good requirements aren't about more documentation - they're about building a shared understanding of what you're trying to achieve.

What problem are we solving?
What does success look like?
What constraints do we have?

By aligning on the answer to these questions early, you make it easy to evaluate the work objectively. Did it solve the problem within the constraints expressed? Yes? Excellent work! Let's ship it.

A Stitch in Time

"But we don't have time to do such rigorous alignment work! They need this delivered yesterday!" I hear you, I understand, and respectfully, I disagree.

You're already spending this time, and more, at the end of the project "catching problems" with the implementation. It feels productive to catch the issues, but doing it after the work is complete is both expensive and demoralizing for the team.

Aligning on the inputs takes time, but it takes less time than trying to reconstruct requirements from an output. It takes less time than redoing the work because someone made a decision they didn't have enough context to make. Investing the time up front pays off in the long run. A stitch in time saves nine.

In order to improve for good, you need to solve problems at the systems level. Fix the inputs and the outputs will fix themselves. - James Clear, Atomic Habits

How to Fix the Inputs

Fixing the inputs isn't hard, but it does take some concerted effort. At your next project kickoff, try asking the initial framing questions:

What problem are we solving?
What does success look like?
What constraints do we have?

Take the answers provided and write them down in a location that can be linked to from the work you do. This provides the base for your requirements doc.

Over time, you'll build up a list of additional questions that are specific to your org, for example:

Is this intended for new users or for experienced users?
Are they likely to interact on a small screen, or will they always be on a laptop-sized screen?
There's a lot of data being processed here. Are users expecting a result within a second, a minute or an hour?

Of course, not every requirement can be known in advance. Discovery happens through iteration and exploration. You learn what users really need, what's technically feasible, and what trade-offs actually matter by trying things out.

That's normal. The problem isn't that requirements evolve, it's that the written requirements are rarely updated as the real world requirements change. The initial assumptions are treated as the "requirements" even as reality shifts. This is even worse than having no requirements at all, as the final output is then evaluated against incorrect assumptions.

When requirements change, don't delete the old requirements. Instead, append to the document and make a note of the date. Then add a "current requirements" section to the top that is a synthesis of everything you know from the initial definition and the updated requirements. This is your evaluation criteria once the project is ready for review.

The Real Definition of "Done"

Everyone has a different definition of "done" depending on their context and point of view. When teams say a project is "done", they mean that the solution is ready for review. In reality, the work is only done when everyone is aligned that this is the best possible outcome given the constraints.

Before calling something complete, review everyone's understanding of the problem and the proposed solution. Ask "Do we still agree on what good looks like? Are the inputs still valid?"

When inputs are solid, reviews become easier. Feedback stops becoming a surprise attack and becomes a shared evaluation against a known goal. Teams spend less time justifying their decisions and more time improving the product. "Done" stops meaning "I hope this is what you wanted" and starts meaning "we all understand why this is the best solution given the trade-offs".

So the next time you're tempted to try and reverse engineer what was required from the final output (and inevitably provide misguided feedback), pause and think about what led you to this point.

Don't fix the output.

Fix the input.

When Asking is Easy (and Answering Isn't)

2026-01-14T08:34:05Z

It's 4pm on a Thursday, and I'm patting myself on the back that I've managed to align multiple teams on a tricky project. The requirements document has been reviewed and approved by everyone involved, and I'm excited to see what's been scoped come to life.

I'm about to sign off for the day when someone from our SaaS team pinged me: "Hey, quick question. What would it take to make this multi-tenant?". It's as though the walls come crashing down around me. It's not a quick question at all - it's one that takes deep technical, historical, and organizational knowledge to unpack.

I sigh as I make another cup of tea and settle in to write an essay of a response, trying to balance the need for details without it appearing as though I'm trying to overwhelm them with complex explanations.

Questions like this aren't malicious. They're often great questions, asked in good faith. But they reveal something important about effort - it's much easier to ask questions than to answer them.

Asymmetric Questions

An asymmetric question is one where the effort to ask is trivial compared to the effort to answer.

This asymmetry isn't inherently bad. I'd choose to work with a curious team over a disinterested team every time given a choice. But when left unchecked, these questions can lead to a high emotional load for those receiving them.

I've been the person receiving the questions, and my responses have ranged from "Why are they asking questions that they definitely won't understand the answer to?" (which was an unkind categorization on my behalf) to "This sucks. Weeks of alignment undone by a single question. Maybe I can pretend I didn't see it?" to "This is a good question. I should have covered this in the first place. It's going to take time, but it's worthwhile".

Lack of knowledge is often the driver of asymmetric questions. The person asking is often missing the context required to realize how much effort it will take to answer what appears to be a simple question.

In general, the more senior or cross-functional your audience, the higher the likelihood is of one of them asking an asymmetric question. This isn't malicious - their curiosity spans domains that they're not totally familiar with.

Asymmetric questions can be valuable, but they can also be distracting. If the system that the asker is operating in rewards visibility, you're going to get spontaneous questions that don't add much. They don't care as much about the answer as they do about being seen to contribute. Over time, this erodes focus and encourages reactive rather than strategic work.

Managing the Imbalance

Asymmetric questions aren't malicious. They're born from curiosity, but left unchecked they can command a lot of time. It takes 30 seconds to ask a question, and 30 minutes to answer it.

My rule of thumb for asymmetric questions is to spend twice as long answering a question as it took to ask it. If they spent a minute asking a question, I'll give it two minutes of thought then respond (usually to ask clarifying questions of my own). The asker's response might take 5 minutes to write, and so I'll take 10 minutes to respond.

If a question takes one minute to write and will take twenty minutes to respond to, schedule a call. That's a good sign that there's something missing from either the asker's knowledge, or from your proposal itself.

The goal isn't to stop people asking questions. It's to right-size your response.

Navigating Asymmetric Questions

The first step to navigating asymmetric questions successfully is to get past the resentment stage as quickly as possible. Even being aware of the knowledge asymmetry, I still have an initial burst of resentment every time someone asks "why don't we do X?".

The impact that their question has on the project, and on me as an individual, is huge. But I need to separate intent from impact. People don't generally ask asymmetric questions without a reason.

Once you're past the initial resentment, you can engage with the asker in good faith. Many people see a question and feel like they have to answer it immediately, and in depth. This usually isn't the case.

Exploring or Deciding

Questions on proposals are either exploring or deciding.

If someone is exploring an idea e.g. "Did we consider internationalizing the docs?" then you can respond with a similar level of depth. You could say "We did, but the return on investment for both time and cost wasn't there. I'm happy to dig in more if you like."

If the same question is phrased slightly differently, they're looking for a decision: "Why aren't we internationalizing the docs?". My personal instinct here is to write a 10 paragraph response in the comments section of a Google doc, but that's the wrong approach. Instead, propose a follow-up with the correct audience: "That's a good question. A full answer will take some time to put together. Can we chat next week with a few others that were involved in the decision?"

Clarify and Redirect

If the question is open-ended, don't try to answer every potential question. Here's one question that I had recently:

Why don't we provide a hosted version of {Dependency X}?

Instead of diving in, I asked a clarifying question to narrow the scope: "There a couple of reasons. Are you asking about technical, cost or market reasons?". The author came back with "market" and I explained that a hosted version would be well received by the market, but the technical implications (single tenant dependency) meant that the cost of providing a service (COGS) was too high for it to be a viable option for us.

Asking questions turns what sounds like a demand into a conversation. Either the asker wants to really dig in and you can have a fruitful conversation, or (as I've experienced many times) they just don't respond at all and you can forget about the question entirely.

Answer with Intention

Asymmetric questions are inevitable in collaborative work, especially as scope and seniority increases. By clarifying the questions and matching your effort to their intent you can keep projects moving without letting "one quick question" derail weeks of progress.

Visibility is Velocity

2026-01-07T11:29:57Z

Once upon a time, I worked with a Product Manager, Bob. Bob's team worked with incoming data pipelines, and transformed and augmented a variety of disparate data sources in to a consistent data model. It was a tough job, as you didn't actually know what data you were going to receive from our providers until it arrived.

Bob’s team also had a reputation for being slow. On average, onboarding a new data source took about three months. When the work shipped, though, it was excellent: reliable, well-instrumented, and easy to maintain.

But when they shipped, they didn't get any accolades. The team heard "Finally! Why did it take so long?". Worse, they heard "I wish you'd have warned us - we haven't implemented the new data source in the billing system". So not only did the project feel late, the business couldn’t even use what had been delivered.

A few months later, Bob was no longer with the company. The feedback was that he “wasn’t compatible with how the business needed to operate.” We hired Alice as his replacement.

The perceived change was immediate. Alice shipped something in her first two weeks. People were impressed. It didn’t even seem plausible that Bob’s team could ship anything in two weeks, let alone within two weeks of a new PM starting.

But Alice didn’t actually make the team faster. New data sources still took three months to fully integrate. The work was the same. The complexity was the same. What changed was that progress became visible.

And suddenly, everyone believed the team had become fast.

The Dangers of Silence

Humans hate ambiguity. When there’s no signal, people invent their own story.

Bob's lack of updates created its own narrative: the work had stalled, or it wasn’t a priority. The project lost momentum. Other teams postponed their related work. Leaders delayed decisions tied to the project. Everyone just kind of "forgot" about the ongoing work.

The lack of communication usually comes from a good place:

“I didn’t want to distract people until I had something solid.”

But updates aren't a distraction. Surprises are. And surprises are expensive for everyone.

Each and every time I've found myself surprising an executive, I've ended up on calls where they're trying to figure out what's going on. Those calls take a lot of time.

We need to re-establish context for those that aren't deep in the project, then explain what's happening and why. The conversation inevitably turns to re-litigation of a decision that was already made.

Before you know it, the engineering team is frustrated that we're revisiting old decisions and the execs are frustrated that things are taking even longer. Surprises don't serve anyone.

The Power of Updates

Sending regular updates doesn't make you go any faster - in fact, it slows you down slightly as writing the updates takes time. You don't want them to be a torrent of useless information ("We added 14 new tests and added support for the FlubJam"). Instead, focus on what's useful ("We added tests to ensure that URL mapping works consistently, and integrated FlubJam so that the billing team can get started with their work").

These small, regular updates build trust and predictability for your audience. They know what's happening, and that the project is still on track. And if there is something that isn't quite right, these regular updates allows people to raise concerns, build alignment and course correct while the cost of doing so is cheap.

How to Ship Incrementally

Let's go back to Bob and Alice. Alice didn’t deliver results any faster. She just made progress visible.

Instead of waiting for everything to be solid, she shared updates like these:

Week 2: Great news! We've connected to the third party system. Here's a video of us ingesting a piece of data (no mapping, no augmentation)
Week 4: We've figured out what data is available. Here's a link to our proposed data mapping, and a demo video with the mapping added
Week 6: The pipeline is running well, and we've managed to add some augmentations. Here's a video of URL extraction from text working. Look how it augments the data with the page title from the URL
Week 8: Slow progress this week. We realised that the data isn't guaranteed to arrive in order, so it turns out that we were missing some data. We're reworking our pipeline to use the deduplication service so that we don't have to rely on timestamps. I'm still optimistic that we'll be done next month
Week 10: All solved! I've shared the data size/volume information with the billing team so that they can load it into the rate card system. We're working on additional test cases to give us confidence that we haven't missed anything.
Week 12: Tada! The project is done. Here's a list of sample configurations and test cases that we run. Thank you for all the feedback along the way.

We still couldn't ship the new data source to customers until week 12, but all of the stakeholders were clear what was happening every step of the way.

Compare that to Bob's updates:

Week 12: The integration is complete. Here’s the final implementation - let me know if you have feedback.

The engineering team did the same work on the same timeline, but the leadership team had a very different perception.

Alice wasn’t seen as faster because she did more. She was seen as faster because progress showed up continuously. Risks were surfaced early, course corrections happened when needed, and no one was surprised at the end.

Your updates don’t need to be long. Fifteen minutes to produce. Two minutes to consume. That's all it takes.

Bulk unsubscribe in Gmail

2026-01-06T10:23:42Z

Back in 2021 I added an idea to /ideas that would scan my email inbox and provide a single page containing unsubscribe links that have been scraped from emails. Here was the proposal:

A UI that reads all emails in a folder and shows all emails with an unsubscribe link.
Provide a way to group by sender / subject / unsubscribe URL
I'd like to be able to choose which folder this runs in (minimum Inbox + Trash, but ideally any folder/label)

Today I learned that Google have built this themselves. In your inbox, click on More in the sidebar and then choose Manage subscriptions. You'll see a screen that shows you email volume from each sender and allows you to unsubscribe with a single click.

Now, I need to go and unsubscribe from all of these Kickstarter platform emails that I always delete without reading...

Building `listentotaxman-cli` with OpenCode + Claude Sonnet 4.5

2026-01-05T16:01:31Z

If you've ever needed to calculate tax in the UK, you've probably landed on https://listentotaxman.com/. My main use case is comparing two sets of numbers - sometimes it's base salary, sometimes it's to see what happens if I change a pension contribution %.

The website is ok, but I wanted something I could script. So this morning, I wrapped their API in a CLI. Or rather, I asked Copilot / Claude Sonnet 4.5 to wrap their API while I did some other work.

This idea has been on my /ideas page since September 2021, and I've never taken the time to build it out. Occasionally I'll use the website and remember that I wanted to build a CLI but then I solve my immediate problem and move on.

Today, I decided that this was a nice, bounded problem that I could use to test out OpenCode, which was recommended to me over the weekend as a vendor neutral Claude Code replacement.

Building with OpenCode + Copilot

Here's the transcript of the conversation I had with OpenCode. I've skipped over some of the clarifying questions that were inconsequential (e.g. when it asked if responses should be cached, which ASCII table library I prefer etc). I've added a clarification section when it asked good questions, and insight for when I was pleasantly surprised when the LLM reminded me about actions that I needed to take.

As with when I was building gh-saved-issues I did some initial exploration so that I could provide curl commands to get the project started:

📝 Prompt

You are building a Cobra based Golang CLI for https://listentotaxman.com/. A sample curl request for calling the API is:

bash
curl 'https://listentotaxman.com/ws/tax/index.js.php' \
  --data-raw '{"response":"json","year":"2025","taxregion":"uk","age":"0","pension":"3%","time":"1","grosswage":100000}'

Build a CLI that can be invoked as:

bash
listentotaxman check --year 2025 --region uk --age 0 --pension 3% --grosswage 100000 --student-loan postgraduate --extra 999 --tax-code K12

The --tax-code flag should be passed as "taxcode" in the API request
The --student-loan flag should be passed as "plan" in the API request
The --region flag should be passed as "taxregion" in the API request

Year should default to the current year (e.g. 2026) if today's date is after the fifth of april. Otherwise it should default to the previous year.

--tax-region should default to "uk"

The LLM one-shot this pretty well. I could run listentotaxman check and see the output:

╔══════════════════════════════════════════════╗
║ Tax Calculation for 2025 (UK) - Yearly       ║
╠══════════════════════════════════════════════╣
║ Gross Salary                     £100,000.00 ║
║ Taxable Pay                       £97,129.00 ║
║ Tax Paid                          £31,311.60 ║
║ National Insurance                 £4,010.60 ║
║ Student Loan                       £4,740.00 ║
║ Pension (You)                      £3,000.00 ║
║ Net Pay                           £56,937.80 ║
╠══════════════════════════════════════════════╣
║ Employer's NI                     £14,250.00 ║
║ Pension (HMRC)                     £2,000.00 ║
║ Total Cost                       £116,250.00 ║
╚══════════════════════════════════════════════╝

One of the things I liked about the website is the ability to see these figures for a specific time period:

📝 Prompt

Add a --period flag that defaults to "yearly". Other possible options are "monthly" "weekly" "daily" "hourly". Take the "yearly" values and divide by the 12 (monthly), 52 (weekly) or 365 (daily) or 2920 (hourly)

Did you spot my mistake? The LLM did:

❓ Clarification

Question: Is 2920 correct for hourly? This assumes 8-hour workdays. Some alternatives:

2080 hours (40 hours/week × 52 weeks) - standard US calculation
1820 hours (typical UK full-time: 37.5 hours/week × 52 weeks - 5 weeks holiday)
2920 hours (365 × 8 hours) - your specified value

I opted to use 2080 hours, assuming that I get paid for my lunchtime too.

At this point the CLI was working well, but there were some formatting issues due to the recent changes:

📝 Prompt

Alignment is off in the header:

══════════════════════════════════════════════╗
║ Tax Calculation for 2025 (UK) - Monthly║
╠══════════════════════════════════════════════╣

With the basic usage working, it was time to add the compare command that the UI doesn't provide. The trickiest thing to figure out here was how to accept groups of information.

I ended up accepting the pattern --option <NAME> --flags go --here, where any flags provided after one --option value, but before another are treated as one set of configuration:

📝 Prompt

Now add a new listentotaxman compare command. Accept all flags from listentotaxman check

Each flag can be provided multiple times. Each group of inputs should be preceeded by an --option flag e.g.:

bash
listentotaxman compare --option job1 --pension 3% --grosswage 10 --option job2 --grosswage 1000 --pension 10%

Once the command was built, I ran listentotaxman compare --help to see how to use it, but the help screen was useless:

📝 Prompt

Improve the --help output. The following is not useful:

bash
Error: no options specified (use --option to define each scenario)
Usage:
listentotaxman compare
Flags:
-h, --help help for compare
Error: no options specified (use --option to define each scenario)

The LLM updated the --help command with many useful examples:

bash
listentotaxman compare \
  --option "Current Job" --income 100000 --pension 3% \
  --option "New Offer" --income 120000 --pension 5%

The CLI did everything I needed at this point. Everything that I did next was just polishing the experience:

📝 Prompt

Format numbers using the correct locale e.g. 100,000 rather than 100000

I realsied that I only provided sample API calls, and we should support everything the UI does. I've removed the HTML from the following prompt, but assume that I pasted in the whole HTML form from the UI:

📝 Prompt

Here is the HTML definition for the inputs available on the website. Which CLI flags are we missing?

...snip...

It was interesting for me to see the LLM match the UI properties to the form:

👀 Insight

Implemented ✅
--year - Tax year
--region - Tax region (uk, scotland, wales, ni)
--grosswage - Salary amount
--pension - Pension contribution (£ or %)
--student-loan (maps to plan) - Student loan plan
--age - Age selection
--tax-code (maps to code) - Tax code
--extra (maps to add) - Additional allowances/deductions
Missing Flags 🔴
Based on the HTML form, we're missing these inputs:

--married (checkbox: married)

Boolean flag for married status
Affects marriage allowance calculations
--blind (checkbox: blind)

Boolean flag for blind person's allowance
Additional tax-free allowance for registered blind persons
--no-ni or --exempt-ni** (checkbox: exNI)

Boolean flag for "I pay no NI"
For people exempt from National Insurance
--partner-wage (input: partnerGrossWage)

Partner's gross wage for marriage allowance calculations
Only relevant when married flag is set
Affects transferable marriage allowance
--time - Input frequency selector

Currently we only accept yearly amounts
Website supports: year, month, 4 weeks, 2 weeks, week, day, hour
Note: This is an INPUT multiplier, different from our --period OUTPUT divisor
Additional Observations
Student Loan Plans
We support:

✅ plan1
✅ plan2
✅ postgraduate
We're missing:

🔴 plan4 - Plan 4 (for students from Scotland)
🔴 scottish - Scottish student loan
Age Values
Current implementation uses string values like "0", "1", "2", "3"

Website uses:

0 - under 65 ✅
3 - female 60-65 (historical, likely for older tax years) 🔴
1 - 65-74 ✅
2 - over 75 ✅
We're mostly correct but missing the "female 60-65" option.

Region Values
Our values match except:

We use: uk, scotland, wales, ni ✅
Website uses: uk, scotland, eng, wales, ni
Minor difference: We don't have eng (England) as distinct from uk 🟡

I had the LLM implement all of the above flags and options (and add them to --help), then continued to polish the experience:

📝 Prompt

Rename --grosswage to --income

Finally, it was time to release. I knew I wanted to use GitHub Actions and goreleaser:

📝 Prompt

I want to build and release this tool with github actions and goreleaser. Build a plan to add this CI/CD setup

The LLM wanted to do so much more! It suggested enabling CodeQL, dependabot, Homebrew support and Docker builds.

❓ Clarification

Please answer the questions above, and I'll create:

Minimal setup (if you want quick start):

.goreleaser.yml with basic config
.github/workflows/release.yml for releases
.github/workflows/ci.yml for testing

Full-featured setup (if you want everything):

All workflows (release, CI, CodeQL, dependabot)
Homebrew tap support
Docker image builds
Comprehensive documentation
Security scanning

Which approach do you prefer? And please let me know your answers to the questions above!

I chose an option that it didn't give me: the minimal setup, but with Homebrew/Docker support too.

📝 Prompt

Option 3: Minimal setup, but with Homebrew / Docker support

This is when the LLM surprised me. In addition to generating all of the workflows, it succinctly explained which secrets I needed to add to my repository, and how to find those values:

👀 Insight

🔧 Manual Setup Steps Checklist
Before you can release, complete these manual steps:

✅ Step 1: Create Docker Hub Access Token
Go to https://hub.docker.com/settings/security
Click "New Access Token"
Description: "GoReleaser CI/CD"
Access permissions: "Read, Write, Delete"
Generate and COPY the token (shown only once)

✅ Step 2: Create GitHub Personal Access Token
Go to https://github.com/settings/tokens
Click "Generate new token (classic)"
Name: "GoReleaser Homebrew Tap"
Expiration: No expiration (or as preferred)
Scopes: Check repo (all sub-scopes)
Generate and COPY the token

✅ Step 3: Add Secrets to GitHub Repository
Navigate to: https://github.com/mheap/listentotaxman-cli/settings/secrets/actions

Click "New repository secret" for each:

Secret 1: GH_PAT

Name: GH_PAT
Value: (GitHub PAT from Step 2)
Secret 2: DOCKERHUB_USERNAME

Name: DOCKERHUB_USERNAME
Value: mheap
Secret 3: DOCKERHUB_TOKEN

Name: DOCKERHUB_TOKEN
Value: (Docker Hub token from Step 1)

✅ Step 4: Configure GitHub Actions Permissions
Go to: https://github.com/mheap/listentotaxman-cli/settings/actions
Under "Workflow permissions":
Select "Read and write permissions"
Check "Allow GitHub Actions to create and approve pull requests"
Click "Save"

✅ Step 5: Verify Homebrew Tap Repository
Confirm https://github.com/mheap/homebrew-tap exists and is:

Public
Empty (or has minimal content - GoReleaser will manage it)

I didn't like that I had to provide permissions via settings. I want them declared in the workflow instead:

📝 Prompt

Update the GitHub Actions workflows to set permissions explicitly

And finally, it wouldn't be a GitHub Actions implementation unless the first build failed. The LLM somehow generated a version 2 configuration file for goreleaser while using version 1 in CI. I pasted the error in and it fixed it with no intervention from me:

📝 Prompt

only configurations files on version: 1 are supported, yours is version: 2, please update your configuration
Error: The process '/opt/hostedtoolcache/goreleaser-action/1.26.2/x64/goreleaser' failed with exit code 1

I pushed these changes to the repo, tagged a new release and watched as the listentotaxman CLI came alive! I ran brew install mheap/tap/listentotaxman on my local machine and now I can compare tax implications as much as I want 😁.

Electron Node module version

2025-12-27T17:11:26Z

I've been building an Electron app for the first time. It was all going well until I tried to use a dependency that involved native components. When I tried to run the app, I got an error that [...] was compiled against a different Node.js version:

bash
Error occurred in handler for 'tasks:fetch': Error: The module '/private/tmp/electron-demo/node_modules/better-sqlite3/build/Release/better_sqlite3.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 137. This version of Node.js requires
NODE_MODULE_VERSION 140. Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`).

It turns out that the node.js and Electron ABIs are not compatible (see the compatibility matrix), and any native code needs to be compiled specifically for Electron.

To solve the issue above, you have to rebuild native modules for Electron using @electron/rebuild:

bash
npm install --save-dev @electron/rebuild
./node_modules/.bin/electron-rebuild

Then npm start and everything works.

⚠️ You'll need to re-run electron-rebuild after every npm install.

Reproduction case

If you're looking for a simple reproduction case:

bash
git clone https://github.com/mheap/electron-build-sample
cd electron-build-sample
npm install
npm start # You'll get an error here

Rebuild the native modules and try again:

bash
./node_modules/.bin/electron-rebuild
npm start

You'll see a task that says "Do the thing".

michaelheap.com

Never leave on a no

Disagreeing behind closed doors

Know when to stop

What “never leave on a no” actually means

Sharing with your team

Your real job

Update the AUR from GitHub Actions

Yes, if…

The two types of "yes"

"Yes, If" is a trade

Applying this in real life

Price the work

Delivery and Dopamine

Dopamine vs. Leverage

The Relapse

The "helping" trap

Build a System That Ships Without You

The organization trained me

Fix the inputs, not the outputs

Garbage In, Garbage Out

A Stitch in Time

How to Fix the Inputs

The Real Definition of "Done"

When Asking is Easy (and Answering Isn't)

Asymmetric Questions

Managing the Imbalance

Navigating Asymmetric Questions

Exploring or Deciding

Clarify and Redirect

Answer with Intention

Visibility is Velocity

The Dangers of Silence

The Power of Updates

How to Ship Incrementally

Bulk unsubscribe in Gmail

Building `listentotaxman-cli` with OpenCode + Claude Sonnet 4.5

Building with OpenCode + Copilot

Electron Node module version

Reproduction case