michaelheap.com

It just has to work

2026-04-29T09:01:50Z

We've been trained all of our work life to "do things the right way".

The right process. The right level of detail. The right amount of alignment.

You know what happens next. Six months later, nothing has shipped.

The Hidden Cost of "Doing It Right"

When you're a scrappy startup, everything is allowed. Quick hacks, half-baked ideas, and sometimes editing things live in production. But as a company grows, it starts to establish processes to prevent failure. A "best practice" here, or an "executive review" there.

Some of that is necessary. Every process is someone's scar. They've lived through outages, security incidents, compliance failures, and broken trust.

The problem is what happens over time. Last-resort safeguards quietly become prerequisites for action. Teams wait for a complete understanding of the problem. It rarely happens. When you treat perfection as a risk-avoidance strategy, nothing ever ships.

Momentum Beats Consensus

One product manager I worked with hit this problem. They were struggling to get stakeholder time to talk about the requirements for a new capability. Everyone had opinions, and they wanted to make sure that they were captured.

I asked them to write a one-page, opinionated spec and share it. Within a day, stakeholders were commenting in the doc with their opinions.

A one-page spec can trigger in a day what weeks of scheduling can’t: informed disagreement.

The first version is almost always wrong, but it surfaces the right disagreements fast.

It doesn't need to be a spec. Sometimes it’s a clickable prototype. Sometimes it’s a command-line script, a mocked API, a Loom walkthrough. Just make something that people can react to.

It doesn’t need to be complete. "Working" means:

Usable by a real person today
A measurable metric moves
You can tell that it worked within hours or days
It fits within your guardrails

Incremental progress is how you get to the right answer faster. It requires clear success criteria and fast feedback loops. More importantly, it requires a willingness to delete work. Ship, learn, iterate, then ship again.

Some work has tight constraints - safety, legal, ethical, security - but the need to learn doesn't go away.

The Real Questions

Action creates something people can react to. Once something "good enough" is unblocking real users, the questions change. Instead of asking "Is this ready?" or "Will this scale?", ask questions that inform the future.

“What will we learn if this works?”
“How quickly will we know if it doesn’t?”
“What gets better the moment this exists?”

Most teams fail not because they move too fast, but because they wait for certainty that never arrives. Teams that wait for perfect don't have better outcomes. They just have fewer of them. Progress starts when there’s something real to push against.

Treating every decision as permanent is how you end up six months in with nothing shipped.

Disable VSCode embedded browser

2026-04-27T20:05:28Z

VSCode recently started opening my blog previews as an editor tab rather than in my normal browser. It turns out that this is a new Integrated Browser feature inside VSCode Insiders.

To disable it, add the following to settings.json:

json
"workbench.browser.openLocalhostLinks": false

Or you can search for workbench.browser.openLocalhostLinks in the settings panel and uncheck the box.

Then restart VSCode, or reload the window with Command Palette → Developer: Reload Window.

When AI beats procrastination

2026-04-20T13:09:18Z

I have a list. I’m sure you have a list too. A list of all the things that could be, if only you had more time. Time to explore the idea. Time to build a prototype. Time to invest in something new.

And if you’re anything like me, time is an excuse. Once I get started on a project, it becomes all-consuming. I find the time - 10 minutes here, 10 minutes there.

If I'm being honest, the list isn’t full of hard problems. It’s full of things that never felt important enough to start.

Human vs AI

A year ago, I thought AI was pretty terrible. It was too slow. Too unpredictable. Too willing to confidently invent nonsense.

I’d look at its output, think “I could do this better,” then walk off, adding the idea to the growing pile of things I was technically capable of doing but never motivated enough to begin.

The mistake I was making was simple: I was comparing AI to a human.

I was asking, “Is this as good as if I did it myself?” and the answer was usually “no.”

But I was asking the wrong question. What I should have been asking was “would I ever do this at all?”

The breakthrough

I’ve been meaning to build a CLI that wraps listentotaxman.com so that I can compare two salaries for years. With a full-time job, a family, and other interests, it never quite made it to the top of the list.

So one Saturday evening, I took 10 minutes to write down what I wanted:

the commands
what each should do
a couple of example outputs

Then I walked away and made dinner.

When I came back, I had something that mostly worked. It wasn’t perfect. It’s definitely not something I’d ship to a customer. But for infrequent, personal use? It was perfect. Far better than the “this would be nice to build someday” alternative.

This was the breakthrough for me. It’s not “AI vs. Michael.” It’s “AI doing the work I never make time for.”

Getting started is the hard part

Realising this changed how I approach my backlog.

I try more things, because failure is cheap.
I finish more things, because “good enough” is easy to reach.
I revisit old ideas, because they’re no longer competing with everything else for my time.

I used to have more ideas than time. I had to choose between spending an evening at my desk or with my family. That's no longer the case.

In two months, I built six tools I’d been putting off for years:

listentotaxman-cli - Compare multiple salaries using listentotaxman.com
gh-saved-issues - Configure github.com/issues from a config file
agent-en-place - Sandbox agents using dynamically built environments with mise and docker
google-contacts-backup - Back up and restore your Google contacts to JSON
Automatic AUR updates with GitHub Actions
trace2mermaid - Render OpenTelemetry traces using mermaid

None of these are groundbreaking. And honestly, that’s the point. I couldn’t justify the time investment. But now they exist where they didn’t before.

AI is still untrustworthy

Let’s be clear: I don’t trust any of the code. It's brittle. I’m certain there are bugs I haven’t found (mostly because I haven’t looked very hard). AI has made assumptions that I haven’t validated.

AI is not how you build things you care deeply about.

It’s how you build things you want to exist.

AI doesn’t replace deep thinking and craft. It’s a shortcut around the part where nothing happens at all.

Prompt Engineering for Humans

2026-03-31T20:14:17Z

A while back, I was working on trello-cli, a CLI tool I maintain. I've been slowly adding commands as time allows, but this time I wanted to try out this new-fangled "agentic development" thing that everyone is talking about.

So I opened up my terminal, asked it to "Add support for showing card details" and let it churn away. Once it was done I reviewed the output and, honestly, I was disappointed. It added a command that showed the board title, description, and labels. It was missing the card's due date, which is the most important information of all. Checklist support was nowhere to be seen.

I went to close my laptop, safe in the knowledge that AI wasn't coming for my job any time soon. Then I realised, the agent had done what I asked. It had added support for showing card details. I didn't specify which details I wanted to see.

So I gave it another go, this time assuming it didn't know anything about my intent:

Add a card:show command that accepts --board and --list as flags. Output the card title, description, due date, any attached checklists and labels. If any of these values do not exist, skip the header for that section. If checklists have more than 10 items, add a "+ X more" entry. Add an --all-details flag to show all of the information.

This time the output was fantastic. It was a command I could use immediately. What would have easily taken me an hour was finished in minutes. Nothing about the model changed. The only thing that changed was the context.

The fastest way to get bad output from an AI system is to give it a vague prompt. It turns out the same is true for humans, too.

Management = Context

This is exactly what good managers do. Or at least what they’re supposed to do. Good managers, it turns out, spend a lot of time doing prompt engineering for humans.

Vague prompts produce vague results. From AI. From teams. From organisations.

Management isn't about assigning work. It’s about designing context: goals, constraints, expectations, and validation. When those things are clear, teams move quickly and independently. When they aren’t, people guess.

The one-sentence management problem

Managers often give direction the same way people write bad AI prompts: short, clear, and wildly underspecified.

Here's something that I said in a documentation project at work:

“All the information needed to achieve a task must be on a single page.”

To me this was a precise requirement. Users must be able to achieve their goal by reading the content on a single page. What I didn't realise is that I had a set of assumptions about what that meant.

Bad prompts to AI fail fast; bad prompts to humans fail expensively.

Reverse-engineering intent from an underspecified prompt takes a lot of time, and it's usually missing nuance.

The rewrite

In this case the team built something that met the requirements, but didn't match my expectations. I could figure out how to achieve a use case from the page, but it was a painful experience copying arcane configs into various files. If I didn't read closely I'd paste the wrong thing into the wrong file, and none of it would work.

After some deliberation, I rephrased the requirements:

Users must be able to copy and paste down a page from top to bottom and be successful with their task. They must also have a way to validate that it's working.

The goal didn’t change. The context did.

Now we understand how the user behaves. We know what success looks like. We know how the user verifies the outcome.

Why constraints create autonomy

Managers sometimes hesitate to define constraints. They worry that too many rules will limit creativity. In practice, the opposite happens. Constraints remove ambiguity.

When teams understand the boundaries - what matters, what doesn’t, and how success will be measured - they stop waiting for clarification and start making decisions.

When projects struggle, the instinct is often to blame execution. The team misunderstood the task. The engineer built the wrong thing. The feature didn’t meet expectations.

Sometimes that’s true. But more often the real problem is simpler: the context wasn’t clear.

The context checklist

Before assigning work, ask yourself whether the prompt you’re giving your team includes five things:

The goal
What outcome are we trying to achieve?

The context
Why does this matter?

The constraints
What boundaries exist around time, scope, or resources?

The success criteria
What does good look like?

The validation mechanism
How will we know it works?

When these pieces are clear, the team doesn’t need constant clarification or supervision.

Specify, don't guess

AI didn’t introduce a new problem. It exposed an old one.

We’ve always relied on people to interpret vague instructions, fill in gaps, and guess at intent. Sometimes that works when you're a small team. At scale, it breaks.

Prompt engineering is just a new name for something managers have always been responsible for: making sure the work is understandable before it begins.

The difference now is that there’s no illusion. Machines don’t guess what you meant. They reflect exactly what you said and you have to deal with the consequences.

In the spotlight

2026-02-26T14:58:41Z

I've spent most of my career on the periphery. Building the tools, documentation and platforms that make it possible to build the product that customers pay for. I remember fighting tooth and nail for headcount. Lobbying to get some time on the company all-hands to make sure people know that we exist. Being worried that when cuts inevitably come, the teams I work with would be first on the chopping block.

Now, I'm in the spotlight. I'm the product leader for the product that makes the majority of our revenue. I fought so long to be in the spotlight, and now that I'm here I'm struggling to bear its weight.

The weight of the spotlight

Working on a revenue-generating product is often treated as a privilege. The work is visible. Impact is easier to point to. Success maps cleanly to business outcomes.

But that visibility comes with scrutiny.

Every decision is observed, evaluated, and challenged - by leadership, sales, marketing, finance, customer success, and often customers themselves. The closer your work is to revenue, the more people feel entitled to an opinion about it.

I thought I'd spend my time adding new capabilities to the product, but I've learned that in the spotlight you don't ship features. You defend them.

Revenue = Restrictions

The closer your work is to the revenue, the less freedom you have on your own destiny. With so many people's careers relying on your product (internally, and within your customers) you're subject to a large list of constraints:

Features promised to sign a deal
Existing customer expectations
Revenue targets from the business

As you try to deliver all of these, you also need to maintain stability for your existing customers. You can't break anything, ever. Experimentation becomes expensive. Reversibility matters more than elegance.

You're walking down a narrow corridor under a bright light, stepping carefully do you don't touch the wall on either side. As you walk, people are shouting their opinions on pricing, roadmap priorities and market positioning.

And you can't ignore those opinions. Each statement is framed as risk. If we don't ship feature X, customer Y will churn. If we charge $10,000, we'll lose the deal. We need to shift messaging to CIOs to capture that budget.

System breakdown

Over time, everything grinds to a halt.

People ship the safe thing, not the impactful thing
Timelines are extended so that we can "underpromise and overdeliver"
People optimize for defensibility rather than learning

This isn't your team doing the wrong things. They're reacting to the risk in the system with a rational response. No-one wants to be associated with a loss of revenue due to a bet they made. So we keep doing the safe things.

The trade-off

When I think back to my time on auxiliary teams, there was no spotlight. We'd occasionally get feedback from a customer, but overall our destiny was our own. We could make the big bets, but when they were successful no-one really understood just how impactful the work was.

For auxiliary teams, success looks like nothing breaking, and no-one complaining. They keep the lights on all while longing for the spotlight themselves, not realising that there's a cost to pay.

Revenue teams trade autonomy for visibility.
Auxiliary teams trade visibility for autonomy.

Neither is easier. They just fail in different directions.

Learning to carry the light

I don't think the answer is to work in the shadows. Revenue work is what pays the bills, and the scrutiny exists for real reasons. It's rational for people to protect it.

But the cost of that protection is often invisible: slower learning, narrower ambition, and teams that mistake defensibility for good judgment. When everything is framed as existential risk, we stop asking what’s worth building and start asking what’s hardest to argue against.

The work, I’m learning, isn’t just product strategy. It’s systems design. Creating space where teams can make bets without being crushed by hindsight. Separating real risk from imagined risk. Absorbing pressure so it doesn’t flatten everyone else.

That's the role of a leader. To make space. To bring clarity. To be the filter that brings signal to the noise.

The spotlight isn’t going away. But maybe it doesn’t have to blind us.

Choose your losses

2026-02-18T17:13:44Z

Strategy is choosing what you’ll be bad at.

I’ve been revisiting Michael Porter’s work on strategy, and the point that's stuck with me is this: trying to be “the best” is usually a trap. “Best” often means you’re competing on the same dimensions as everyone else. The same benchmarks, same dashboards, same playbook. You can lead for a while, but the moment everyone copies what works, yesterday’s advantage becomes today’s expectation.

If you want to avoid the race to the bottom, don't try and compete on doing the same things as everyone else, but better. Do the things that you're uniquely positioned to do that are hard to copy for your competitors.

Stop Confusing “Better” With “Different”

Companies often confuse differentiation with excellence. Maybe you have more features, or higher quality, or better customer support. Those are differentiators, but guess what:

Your competitors are building those features right now
You're only one bad bug away from reputational damage
Your best support staff will leave (potentially for your competitors)

The things that we say make us different are mostly operational effectiveness rather than strategic differentiation.

Strategic differentiation is the thing that's hard to copy. It's a set of choices that reinforce each other to build an advantage. Copying a single choice that you've made doesn't help the copier. They'd have to copy the whole system (and accept the trade-offs that you've made along the way).

This is how you differentiate yourself from the market.

The uncomfortable part is you have to name what you’re not going to optimize.

If you can’t say what you choose to be bad at, you don’t have a strategy, you have ambition.

Choose Your Customer

Let's build a sample use case to really drive the point home. There has been a proliferation of observability tools over the last couple of years. Thanks to open standards (thanks, OpenTelemetry!) it feels like a new competitor has popped up every other week and the cost of switching is lower than it's ever been. Competing on better pricing or a nicer UI is a dead end.

Many of the tools out there position real-time data processing as a benefit. The event happens, and less than 5 seconds later you can see it in your dashboard. Your system can do it in 3 seconds, so you're the market leader for those looking for speed.

Eventually though, someone else will do it in 2.5 seconds. Then 2, then 1. Suddenly your advantage is gone.

Instead of competing on the same metric that everyone uses, what if you explored other use cases:

These tools have 30-day retention -> We'll provide 365-day retention at the same granularity (targeting compliance) -> Storage and retrieval of the data takes up to 10 minutes
Sending so much data across the internet is expensive -> Our product can't show realtime, fine-grained data, but we have an agent that runs daily and reduces data egress costs by 90% (targeting FinOps teams) -> Additional deployment complexity for customers
We pride ourselves on performance -> We're slightly slower to ingest, but we guarantee exactly once ingestion (targeting regulated industries) -> Our sales team finds it hard to demo

Each of these use cases forces architecture, pricing and go-to market decisions. They are hard to imitate, and hard to undo. If sales asks for realtime dashboards, the strategy answer isn’t ‘maybe later.’ It’s ‘no’ unless we’re willing to unwind the system that makes our advantage.

If you're successful, your competitors will try to copy you without having the correct foundations. They built an architecture around ingestion speed and are trying to pivot to long-term retention with the wrong technologies, and the wrong team.

It's important to emphasize that these are trade-offs. If the market values speed over retention, you don’t get to “pivot” to instant ingestion without undoing the choices that made you different. You can't do everything and be differentiated.

Build a Stack, Not a Skill

Most career advice is generic. "Be a great communicator". "Always deliver on time". When I'm reviewing applications as a hiring manager, I've seen all of the generic traits by the fifth or sixth application.

Instead of saying the same as everyone else, build a specific combination of traits that sets you apart.

To build your stack of traits, choose one item from each of these categories:

Domain / context (where you have unusual understanding)
Examples: platforms, regulated industries, developer workflows, migrations, pricing, enterprise buying, support realities.
Craft (how you work)
Examples: writing, systems thinking, facilitation, debugging, prototyping, negotiation, research.
Leverage (how it spreads)
Examples: internal enablement, templates, docs, workshops, tooling, a repeatable process, a network.

Your uniqueness usually lives in the combination, not a single skill.

Example: “Deep platform context + crisp writing + enablement templates”
becomes: someone who makes complex platform decisions simple and repeatable across teams.

As mentioned earlier, there are trade-offs each time you make a decision. Name the trade-off you're willing to make consistently:

I'll lose five small deals to save one large deal
I care more about getting to what’s true than about everyone agreeing
I prioritise iteration speed over upfront certainty
We optimise for consistency, not autonomy
I aim to understand 25% of Product, Engineering and Marketing rather than 80% of Product

Personally, I am the person you call when something is on fire, because I can rapidly gain context from both a technical and business perspective. To enable this, I will happily be mediocre at long-horizon planning and stakeholder consensus-building.

The Pattern Shows Up Everywhere

Being unique is a strategy that works in every industry.

IKEA optimise for low prices and immediate availability, at the expense of service through flat-pack, self-assembly, and “good enough” furniture.

FedEx optimise for reliable, on-time delivery rather than aiming to be the cheapest option.

Nespresso optimise for convenient premium-at-home coffee, at the expense of a closed pod ecosystem and a higher cost per cup.

That's how you build an advantage, not by competing in a race where the prize is eventually becoming everyone’s baseline. Strategy is choosing what you’ll refuse to be great at - and then living with that refusal long enough that it becomes your advantage.

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.