Forged · Damien Murphy

Securing GitHub Actions Is a Hard Problem

Damien Murphy — Fri, 14 Aug 2026 00:00:00 GMT

The power—and hidden risk—of GitHub Actions

GitHub Actions has become one of the most attractive CI/CD platforms available.

It is integrated directly into GitHub. Workflows live beside the code they build. Automation can respond to almost every meaningful event in the software-development lifecycle, from pull requests and releases to issue comments, scheduled jobs and deployment approvals.

Developers can also draw from a vast ecosystem of reusable Actions rather than implementing every piece of automation themselves.

That combination is extraordinarily powerful.

It also creates a security problem that I believe the industry has substantially underestimated.

GitHub Actions is not simply a build service with some reusable plugins. It is an execution platform through which externally maintained code can run inside one of the most trusted parts of an organisation: its software-delivery system.

Securing it is therefore not one problem.

It is a collection of interlocking supply-chain, identity, execution, infrastructure and governance problems. Many of the boundaries between those problems are also surprisingly difficult to see.

An Action is executable code

The first important mental shift is to stop thinking of an Action as a convenient configuration component.

An Action is executable code.

When a workflow uses an Action from another repository, it grants that code the ability to execute inside the workflow's runner environment.

Depending on the job, that environment may contain:

source code;
repository credentials;
package-registry credentials;
cloud identities;
signing material;
deployment permissions;
access to internal networks;
the ability to modify the repository itself.

This makes consuming an Action fundamentally different from copying a harmless configuration fragment.

It is closer to installing a software dependency that will execute inside your production-delivery control plane.

In some cases, an Action may be even more sensitive than an ordinary application dependency.

Application code is usually constrained by the permissions of the application at runtime. CI/CD code often exists specifically to build artifacts, retrieve secrets, publish packages and deploy software.

A compromised Action does not necessarily need to exploit the application.

It may already be running in exactly the environment the attacker wants to reach.

The barrier to publishing an Action is deliberately low

Part of GitHub Actions' success comes from how easy it is to create and distribute reusable automation.

An Action can be published from a public GitHub repository and made available for other workflows to consume. GitHub's own documentation states that anyone can publish an Action in the Marketplace.

Some organisations are presented as verified creators, but the Marketplace remains an open ecosystem rather than a tightly controlled software catalogue.

That openness is valuable. It allows useful automation to spread quickly and reduces duplicated engineering effort.

But availability should never be confused with trustworthiness.

The existence of an Action in the Marketplace does not establish that:

its source has received a meaningful security review;
its maintainers use strong account-security controls;
its release process is protected;
its dependencies are continuously monitored;
its build artifacts correspond to its source;
future releases will remain trustworthy.

The Marketplace helps developers discover Actions.

It should not be treated as an enterprise trust registry.

A verified creator is not the same as verified code

The verified-creator badge is particularly easy to overinterpret.

GitHub describes Marketplace verification primarily in terms of organisational identity. The organisation must verify its domain, display a verified badge and provide a confirmed email address through which GitHub can contact it.

Those checks are useful. They make impersonation more difficult and help establish that an Action is associated with the organisation it claims to represent.

But identity verification is not the same as continuous security assurance.

It does not mean:

every release of every Action has been independently audited;
the publisher's development environment cannot be compromised;
maintainer credentials cannot be stolen;
mutable tags cannot be repointed;
dependencies cannot become vulnerable;
the release process cannot be poisoned.

The distinction became painfully concrete in March 2026.

Checkmarx, an established application-security company and verified Marketplace creator, reported that attackers gained unauthorised access to its GitHub repositories. Malicious payloads were injected into its AST and KICS GitHub Actions before the affected tags were revoked.

The lesson is not that verified creators are untrustworthy.

The lesson is that a verified identity cannot make a software supply chain infallible.

Tags look like versions, but they are references

Many workflows consume Actions using a reference such as:

- uses: some-organisation/some-action@v3

This is readable, convenient and easy to maintain.

It may also be mutable.

A Git tag or branch can be moved to point to a different commit. A workflow referencing that tag can therefore execute different code in the future without any corresponding change appearing in the consuming repository's workflow file.

GitHub recommends pinning Actions to a full-length commit SHA and states that this is currently the only way to consume an Action as an immutable release.

- uses: some-organisation/some-action@8f4b7f84864484a7bf31766abe9204da3cbe65b3

That substantially improves security.

But SHA pinning is not a complete solution.

The organisation must still determine whether the pinned commit was trustworthy in the first place. It must also review updates, identify vulnerable versions and roll forward without creating an unmanageable maintenance burden.

The Action may download additional software during execution. A pinned entry point can still invoke:

package managers;
installation scripts;
remote APIs;
container images;
binaries downloaded at runtime.

Those dependencies may not be equivalently pinned.

Immutability narrows the problem.

It does not eliminate the supply chain.

Not all Actions have the same shape

GitHub Actions can execute in several forms, each with different security implications.

JavaScript Actions

JavaScript Actions commonly commit bundled JavaScript into the repository.

The source may be written in TypeScript, but the runner executes generated files such as dist/index.js.

Reviewing the human-readable source is therefore not enough.

A consumer must either trust that the committed bundle was produced from that source or independently reproduce and compare it.

Container Actions

Docker container Actions introduce another chain of trust.

The Action may build a container from a Dockerfile in the repository, or it may reference an existing image.

The job is then relying not only on the Action repository, but also on:

the container registry;
the image tag or digest;
the container build process;
the base image;
operating-system packages;
packaged tools and dependencies.

The apparent dependency:

organisation/action@version

may therefore conceal a wider graph:

Action repository
    ↓
Dockerfile or image reference
    ↓
Container registry
    ↓
Base image
    ↓
Operating-system packages
    ↓
Downloaded tools and dependencies

What looks like one approved component may actually represent several independently mutable supply chains.

Workflows can execute automatically

The risk is amplified by GitHub Actions' event-driven model.

Once a workflow file reaches the default branch, it can run automatically in response to configured events.

These may include:

a push;
a pull request;
a release;
an issue or comment;
another workflow completing;
a schedule;
a manually initiated dispatch.

Some of the data associated with those events may be influenced by an attacker.

Pull-request titles, branch names, issue bodies and comments can cross from GitHub event data into shell scripts or automation logic.

The workflow is therefore not only a static pipeline definition.

It is an event-processing program operating across trust boundaries.

A workflow can be secure for one trigger and dangerous for another.

A job that is harmless when initiated by a trusted maintainer may expose credentials when executed for a pull request from a fork.

Small changes to any of the following can substantially alter the security model:

the trigger;
the actor;
token permissions;
expression handling;
repository state;
runner environment;
access to secrets.

Those changes may not look dramatic during code review.

This is one reason GitHub Actions security is full of edge cases. The outcome depends on the interaction between several controls rather than one obviously dangerous line of YAML.

The runner is part of the attack surface

Even a perfectly reviewed Action still executes somewhere.

That runner environment forms part of the security boundary.

A runner may contain preinstalled tools, language runtimes, package managers and system libraries. It may have network access to internal services. It may retain files from earlier jobs. It may expose the host's container runtime or execute jobs with elevated privileges.

With self-hosted runners, the organisation also owns questions such as:

Is the runner ephemeral?
Can one repository affect another?
What remains on disk after a job?
What internal systems can the runner reach?
How is the runner image built and patched?
Can workflow code escape into the host?
What happens if a job is deliberately hostile?

These are not secondary infrastructure concerns.

They determine the blast radius of a compromised workflow.

A workflow cannot be secured solely by examining its YAML. The environment in which it runs determines what the workflow can actually reach, steal or change.

CI/CD permissions are unusually valuable

GitHub Actions workflows frequently exist to perform privileged operations.

They may:

publish artifacts;
create releases;
push container images;
update repositories;
authenticate to cloud platforms;
sign software;
deploy applications.

This means CI/CD credentials are not ordinary application secrets.

They are capabilities to alter the software-delivery process itself.

A compromised workflow may steal those capabilities directly. It may also:

modify an artifact without stealing a credential;
poison a build cache;
alter a release;
inject code into a package;
create a persistence path that survives after the workflow completes.

The right security question is therefore not:

Can we guarantee that every Action we use will remain secure?

We cannot.

A more useful question is:

If one of our Actions becomes malicious, what can it reach, steal or change?

That changes the objective from perfect prevention to controlled failure.

Controls such as SHA pinning, least-privilege tokens, short-lived cloud identities, isolated runners, restricted network paths and protected environments then become layers in a system designed to limit compromise.

Enterprise controls introduce another hard problem

The obvious reaction is to prohibit external Actions.

That can reduce risk.

It can also remove much of the value that made GitHub Actions attractive.

Teams may be forced to reimplement common capabilities. Central platform groups can become approval bottlenecks. Security updates may take longer because internal forks fall behind upstream releases.

Developers may also copy scripts directly into repositories, making usage harder to discover and govern.

An unrestricted ecosystem is dangerous.

A completely closed ecosystem can become stagnant and expensive.

The real enterprise challenge is to find a defensible point between them:

enough restriction to control the supply chain;
enough standardisation to make secure choices easy;
enough automation to keep approved dependencies current;
enough flexibility that teams do not route around the platform.

This is not merely a policy-setting exercise.

It is a platform-design problem.

The secure path must also be the easiest path.

Frontier models raise the stakes

Many GitHub Actions weaknesses are not new.

Mutable references, excessive token permissions, unsafe triggers and injection through untrusted input have existed for years.

What is changing is the cost of discovering and exploiting them.

Frontier models can help attackers:

inspect large numbers of public workflows;
reason about event paths;
identify dangerous permission combinations;
generate targeted payloads;
adapt attacks to specific repositories and workflow structures.

They also create an entirely new workflow category: Actions in which models or agents consume untrusted repository content and then use tools capable of modifying code or executing commands.

AI does not create the underlying trust-boundary failures.

It makes finding and operationalising them cheaper.

The defensive implication is important.

Security approaches that rely on obscurity, manual inspection or attackers overlooking subtle workflow behaviour will become progressively less reliable.

There is no single GitHub Actions security control

It is tempting to reduce this problem to one rule:

pin every Action;
allow only verified creators;
use self-hosted runners;
block third-party Actions;
scan every workflow;
mandate least privilege.

Each of those controls can be useful.

None is sufficient.

GitHub Actions security spans at least six connected layers.

1. Publisher trust

Who controls the Action and its release process?

2. Dependency integrity

What exact code, container and transitive components will execute?

3. Workflow design

Which events and untrusted inputs can reach privileged operations?

4. Identity and permissions

What credentials and capabilities are available to the job?

5. Runner security

Where does the job execute, and what can that environment reach?

6. Enterprise governance

How are usage, exceptions, upgrades and incidents managed at scale?

A weakness in any one layer can undermine controls in another.

That is why securing GitHub Actions is hard.

The platform combines open-source reuse, event-driven automation and privileged execution. Each is powerful independently. Together, they create a system in which trust can enter through many routes and propagate farther than expected.

The answer is not to abandon GitHub Actions.

It is to treat it as critical software-supply-chain infrastructure rather than convenient repository automation.

Over the rest of this series, I will examine the individual parts of that problem:

how third-party Actions should be evaluated;
why immutable references matter;
how triggers and permissions create hidden trust boundaries;
how runners affect blast radius;
how enterprises can govern the ecosystem without destroying the developer experience that made it valuable in the first place.

Engineering for outsized impact with small teams

Damien Murphy — Fri, 07 Aug 2026 00:00:00 GMT

Small teams force better platform decisions

Platforms promise leverage.

A relatively small group of engineers can build capabilities that improve the work of hundreds of developers. Shared infrastructure can be operated once rather than repeatedly rebuilt. Security controls can be embedded into common delivery paths. Difficult operational problems can be solved centrally, then exposed through a simple interface.

That leverage is real, but it is not automatic.

For much of the past five years, I have built and operated internal platforms with teams of three or four engineers.

Later, I became responsible for several platforms with a team of six or seven, but the effective team behind any individual platform usually remained no larger than three people.

These were not experimental services with forgiving reliability expectations. They supported critical development workflows, carried high availability requirements, and were expected to set the standard for reliability and usability across the organisation.

A small team did not reduce what we could achieve.

It changed what we could afford.

When capacity is constrained, architecture cannot be judged only by whether a system can be built. It must also be judged by whether that system can be operated, maintained, upgraded, supported, secured, and evolved by the same small group of people over several years.

That constraint shaped nearly every important decision we made.

The real limit is operational load

Small teams are often treated mainly as a delivery constraint.

The assumption is that fewer engineers means fewer features, slower development, or a smaller platform. That is sometimes true, but it misses the more important limit.

The real limit is recurring operational load.

A small team can build a surprisingly sophisticated service. The danger is building one that creates more ongoing work than the team can sustainably absorb.

Every manual provisioning step, fragile integration, noisy alert, bespoke user configuration, difficult upgrade, or ambiguous support process creates a continuing claim on the team’s attention.

Individually, each task may look manageable. Together, they consume the capacity needed to improve the platform.

This is how platforms become trapped.

The team spends so much time operating what already exists that it can no longer meaningfully evolve it. Reliability begins to decline. Upgrades are postponed. Documentation becomes stale. User requests accumulate.

Engineers start compensating through personal effort instead of improving the system.

For a small platform team, maintenance is not something to consider after the architecture is complete. It is one of the primary architectural concerns.

A design that requires frequent human intervention is not merely inconvenient.

It is structurally incompatible with the team expected to operate it.

Self-service is a capacity-control mechanism

Self-service is often presented as a user-experience feature.

It is certainly valuable to developers. They can access a capability when they need it, without waiting for another team to process a ticket or perform a manual configuration.

For a small platform team, however, self-service is also a survival mechanism.

If every new user requires direct intervention, adoption creates operational work in proportion to success. The more useful the platform becomes, the more pressure it places on the team behind it.

That is the opposite of leverage.

A platform should absorb growth without requiring equivalent growth in its operating team.

This means common actions must be exposed through stable, documented interfaces that users can operate themselves. Onboarding, configuration, credentials, access requests, routine changes, and common troubleshooting steps should not depend on a platform engineer being available.

Where configuration is required, it should usually be expressed declaratively and reviewed through familiar engineering workflows.

For our platforms, templated configuration and pull-request-based changes became particularly valuable. Users could start from a known-good structure, propose a change, and receive feedback through a controlled review process.

This reduced repetitive communication. It made changes visible and auditable. It allowed policy to be enforced automatically. It created a shared history of why a configuration changed.

It also moved interaction away from private messages and one-off instructions into a reusable system.

The important principle was not that every interaction had to be fully automated.

It was that the team should not repeatedly solve the same problem by hand.

Choose technology by total operational cost

Technology choices look different when the people choosing a system are also responsible for operating it.

A technology may be powerful, flexible, and technically impressive while still being the wrong choice for a small team.

Every component introduces more than its immediate functionality. It also introduces upgrades, security patches, failure modes, observability requirements, specialist knowledge, and integration work.

The relevant question is not simply:

Can this technology solve the problem?

It is:

What permanent operational responsibility are we accepting by adopting it?

For Kubernetes-based services, managed EKS became the obvious foundation for us.

We still retained responsibility for workloads, configurations, integrations, security controls, upgrades, and the surrounding operating model. But we avoided taking responsibility for operating the Kubernetes control plane itself.

That boundary mattered.

Managed services are not free of operational complexity, nor do they remove the need for deep technical knowledge. They reduce the number of system layers for which the team holds direct responsibility.

With a small team, that is often the correct optimisation.

Owning fewer layers allows engineers to spend more attention on the parts of the system that create distinctive value: the platform interface, reliability, security model, developer experience, and integration into the organisation.

The same logic applies beyond cloud services.

Prefer established technologies where their behaviour is well understood. Minimise unnecessary variation between platforms. Standardise deployment, monitoring, access, configuration, and incident response where possible.

Novelty spends operational capacity.

It should be reserved for problems where it creates a meaningful advantage.

Safe upgrades must be designed in

Upgrades are one of the clearest examples of hidden platform cost.

Installing software is usually easy. Keeping it current without disrupting users is considerably harder.

When a service is heavily relied upon, every upgrade carries risk. A change may affect stored data, integrations, authentication, performance, configuration, or behaviour that users have unknowingly come to depend on.

A small team cannot afford for each upgrade to become a high-stakes production event.

For several of our services, blue-green deployment patterns became effectively mandatory.

Rather than modifying the active environment in place, we could deploy and validate a new environment while the existing service continued operating.

This changed the nature of an upgrade.

Problems could be investigated before users were moved onto the new version. Integrations could be tested against the candidate environment. Rollback could be achieved by redirecting traffic rather than reconstructing the previous state under pressure.

Blue-green deployment introduces its own complexity, particularly for stateful services. But it transforms many upgrade failures from incidents into pre-production engineering work.

That distinction is enormously valuable.

A small team has limited capacity for emergency recovery. It is almost always better to invest that capacity in reversible change than to repeatedly rely on engineers recovering quickly when an irreversible change fails.

Reliability creates adoption capacity

Internal platforms depend on trust.

Developers choose whether to build critical workflows on top of them. Even where a platform is the recommended organisational standard, reluctant users can delay adoption, create parallel solutions, or treat the service as an unreliable external dependency.

Once trust is lost, recovering it is expensive.

Every new adopter must be persuaded that previous problems have been resolved. Engineers may need to provide extra assurances, support migrations more closely, or explain why the platform should now be considered dependable.

A small team rarely has the capacity for that rehabilitation work.

Reliability therefore does more than prevent downtime.

It reduces the organisational energy required to sustain adoption.

Our managed runner platform has supported more than 150 development teams while maintaining close to 100 percent infrastructure availability.

Our managed SonarQube service has similarly delivered close to 100 percent service availability while supporting more than 30 teams.

The numbers matter, but the more important outcome is behavioural.

Developers generally do not need to think about whether these services will be available. They use them as dependable parts of their delivery systems.

The platform team is not repeatedly asked to justify the platform, defend its reliability, or help teams build fallback mechanisms around it.

That trust creates capacity for both sides.

Developers can focus on their products. The platform team can focus on improving the service rather than continually re-establishing confidence in it.

Reliability is not merely an operational metric.

It is one of the mechanisms through which a small team preserves its leverage.

Observability must reduce uncertainty

Observability is essential for any production service, but a small team cannot afford observability that demands constant attention.

A monitoring system that produces frequent low-value alerts is not making the platform safer. It is continuously taxing the attention of the people responsible for it.

The goal is not to collect the largest possible volume of telemetry.

It is to reduce uncertainty when something important changes.

Useful monitoring should help answer a small number of operational questions:

Is the service available?
Are users experiencing failures?
Is capacity approaching a meaningful limit?
Has system behaviour changed?
Is a dependency degrading?
Does someone need to act now?

Alerts should be tied to actionable conditions. Dashboards should make abnormal behaviour visible without requiring extensive interpretation.

Logs and traces should support diagnosis when an incident occurs, but the normal operation of the platform should not require engineers to continuously inspect them.

High signal and low noise are not cosmetic preferences.

They determine whether a small team can maintain situational awareness across several services without becoming permanently reactive.

Every incident should reduce future work

Incidents expose the difference between how a system was expected to behave and how it actually behaves under pressure.

For a small team, that information is too valuable to waste.

Each significant failure should lead to more than an immediate repair. It should reveal an assumption, missing guardrail, weak dependency, unclear ownership boundary, inadequate alert, unsafe deployment process, or recovery path that was never properly tested.

The incident is not fully resolved when the service is restored.

It is resolved when the system has been changed so the same class of failure becomes less likely, less damaging, easier to detect, or easier to recover from.

That does not mean every incident requires an elaborate retrospective or a large programme of corrective work. The response should remain proportional.

But there should usually be a durable result:

a new automated check
a safer default
a clearer runbook
a better alert
a removed manual step
a tested recovery procedure
a redesigned component
a documented dependency or ownership boundary

The objective is to convert operational pain into future capacity.

A team that repeatedly resolves incidents through individual heroics remains fragile.

A team that turns incidents into system improvements becomes progressively harder to disrupt.

Vendor release cadence is part of your architecture

Not all operational cost originates inside the platform.

One growing source of pressure for us has been the release cadence of upstream software vendors. Many providers have shifted towards scheduled monthly releases.

At first glance, frequent releases appear beneficial. Updates arrive quickly, vulnerabilities can be addressed sooner, and users receive a steady stream of improvements.

The cost is transferred to operating teams.

Each release must be reviewed. Changes need to be understood. Compatibility and security implications must be assessed. A decision must be made about whether to upgrade, defer, or skip the version.

Where an upgrade is justified, the team must execute and validate another deployment cycle.

Semantic versioning once provided a useful prioritisation signal. Major and minor releases offered an initial indication of the likely significance of a change.

Teams could then examine the change set and decide whether the value justified the operational effort.

Calendar-based releases weaken that signal.

A monthly version may contain major behavioural changes, minor enhancements, security fixes, or little that matters to the platform operator. The release number itself communicates less about urgency or risk.

For a team managing several platforms, the cumulative assessment burden becomes substantial.

This is a reminder that dependency selection is also capacity planning.

When evaluating software, teams should consider not only its features and architecture, but the operational contract implied by its release policy:

How frequently will the team be expected to assess changes?
How long are versions supported?
Can upgrades be skipped?
Are security fixes separated from feature releases?
Is rollback supported?
Are release notes dependable?

A vendor’s delivery model becomes part of your platform’s operating model, whether or not you consciously design for it.

Standardise the platform behind the platforms

When one team owns several services, some of the greatest leverage comes from standardising how the platforms themselves are operated.

Each platform will have its own domain and technical characteristics, but many operational concerns are shared:

infrastructure provisioning
deployment workflows
identity and access
secrets management
observability
backup and recovery
vulnerability management
change approval
incident response
service documentation

Solving each of these independently for every platform creates unnecessary variation and multiplies maintenance.

Shared patterns reduce that cost.

A common deployment model means engineers can understand a new service more quickly. Standard dashboards and alerts reduce cognitive switching. Reusable infrastructure modules make improvements portable.

Common runbook structures make operational knowledge easier to find. Similar blue-green deployment mechanisms allow lessons from one platform to strengthen another.

This does not require forcing every service into an identical architecture.

Standardisation should concentrate on recurring operational problems where variation adds little value.

The objective is not uniformity for its own sake. It is to ensure that the team’s knowledge, automation, and improvements compound across the portfolio.

The platform team should itself have a platform.

Use constraints as design guidance

Small teams have genuine limitations.

They cannot support unlimited customisation. They cannot manually onboard every user. They cannot own every layer of the stack. They cannot treat maintenance as work that will somehow be handled later.

They cannot absorb an unlimited number of alerts, upgrades, incidents, integrations, and special cases.

These constraints can be frustrating, but they are also clarifying.

They force questions that larger teams can sometimes postpone:

What work will this design create every month?
What happens when the original engineer leaves?
Can users complete this action without us?
Can this change be safely reversed?
Will adoption increase or decrease our workload?
What are we choosing to own permanently?
Can one operational improvement benefit several platforms?

These questions usually produce better systems.

A small team can build and manage platforms with extremely high reliability and broad organisational impact. But it cannot achieve that through effort alone.

The team must design for leverage at every layer.

Self-service prevents adoption from becoming support work. Managed services reduce the number of layers the team must operate. Automation removes recurring manual effort. Reversible deployments constrain upgrade risk.

High-signal observability protects attention. Standardisation allows improvements to compound. Incidents are converted into permanent system improvements. Reliability protects the trust on which adoption depends.

Small teams do not need smaller ambitions.

They need architectures that respect the value of their attention.

I Never Meant to Build a Personal Cloud

Damien Murphy — Fri, 31 Jul 2026 00:00:00 GMT

It Started With Local AI

I never set out to build a personal cloud.

I bought a Mac mini because I wanted to experiment with local AI models. It was powerful enough to run useful models through Ollama, and it gave me the freedom to explore without watching API costs, worrying about usage limits, or depending entirely on services controlled by someone else.

At first, the goal was simple: run models locally and use them from the machine sitting on my desk.

That lasted about five minutes.

The models were useful, but their usefulness was constrained by where they were running. I did not want access to them only when I was sitting in front of the Mac mini.

I wanted to use them from my laptop, my iPad, my phone, and potentially from software I built elsewhere.

The moment I asked how to make that possible, the project stopped being about installing Ollama.

It became a platform problem.

The Mac mini was only the spark

A powerful machine sitting at home changes the kinds of questions you start asking:

Could it run local AI models? Certainly.
Could it also host a private interface for interacting with them?
Could I reach that interface securely when away from home?
Could the machine run CI/CD agents, internal developer tools, or software supply-chain services?
Could it become dependable enough to support other projects rather than remaining an experimental box under my desk?

Once personally owned compute becomes powerful, quiet, energy-efficient, and permanently connected, the economics of local infrastructure begin to change.

A home computer is no longer necessarily just a client used to access somebody else’s cloud. It can become a meaningful part of your own computing environment.

Local AI made that especially visible.

Running inference workloads locally provided an immediate reason to own capable hardware, but the same machine could support far more than inference.

The AI lab was only the first workload.

From application to platform

My first instinct was to expose the models to other devices.

That immediately raised questions about networking, identity, access control, service discovery, certificates, domains, and remote administration.

Then came the operational questions:

How would I know whether the service was available?
How would I update it?
What happened when the machine restarted?
Where would configuration live?
How would I recover it after a failure?
How would I stop an experimental service from becoming an unmaintainable dependency?

These were no longer questions about one application.

They were questions about the environment in which applications would run.

The scope widened naturally:

Local AI model
    ↓
Remote access
    ↓
Identity and security
    ↓
Service hosting
    ↓
Monitoring and recovery
    ↓
A reusable platform

What started as a lab for exploring specific applications gradually became the foundation of a personal cloud.

The distinction matters.

A lab is somewhere you run experiments.

A platform provides reusable capabilities that make future experiments and services easier to build, operate, secure, and retire.

I wanted both.

Why build it myself?

I have worked across much of the software delivery lifecycle.

I began in systems analysis, moved through software development and quality engineering, and eventually into cloud platforms, DevOps, DevSecOps, and operations.

That has given me deep experience in individual parts of the lifecycle, but professional systems are usually divided across teams.

One group designs the network. Another manages identity. Another operates the Kubernetes platform.

Application teams own their services. Security teams define controls. Operations teams respond when something breaks.

That separation is necessary at organisational scale, but it can make the whole system difficult to see.

Building a personal cloud creates a rare opportunity to own the complete lifecycle.

I get to define the requirements, choose the architecture, provision the infrastructure, configure the services, design the security model, establish observability, operate the platform, respond to failures, document decisions, and decide when something should be removed.

There is nowhere for ambiguity to hide.

Every trade-off eventually becomes my problem.

That is precisely what makes the project valuable.

It is a small enough environment for one person to understand, but complex enough to expose the same fundamental problems found in much larger platforms.

Not everything belongs at home

Building a personal cloud does not mean attempting to replace every external service.

Some workloads are cheaper, safer, or more reliable when operated by somebody else.

Some services are not worth the maintenance burden. Others require availability, bandwidth, or operational maturity that would be unreasonable to reproduce at home.

Self-hosting can easily become an ideology: if something can be hosted locally, it therefore should be.

I do not find that particularly useful.

The better question is:

Which capabilities are strategically valuable for me to own?

Local AI inference made sense because it supported experimentation and removed usage constraints.

Private development tools made sense because they could support future software projects.

A personal ebook service made sense because it gave me control over my own library.

Monitoring made sense because once services became useful, I needed to know whether they were working.

Each service needed to justify the operational responsibility it introduced.

The objective was never maximum self-hosting.

It was deliberate ownership.

A cornerstone for other projects

The most important change in my thinking was recognising that the personal cloud was not merely another project.

It was infrastructure for projects I had not built yet.

A private AI interface could support writing, research, and software development.

CI/CD runners could support repositories and automation.

Storage services could support documents, books, media, and backups.

Monitoring could be reused by every future service.

Identity and access controls could provide a consistent security boundary.

Once those capabilities existed, each new project would no longer need to begin from zero.

That is the leverage of a platform.

The value does not come only from the services currently running on it.

It comes from reducing the cost of everything that might be built on top of it.

Learning from platforms that succeed — and fail

Earlier in my career, I knew engineers who ran highly available Kubernetes clusters in their homes.

I admired the ambition, although I was never convinced that reproducing enterprise complexity was automatically a good use of personal time.

A three-node cluster can teach you a lot.

It can also create a part-time operations job that exists mainly to keep the cluster itself alive.

Professional platform work has shown me that technical sophistication and platform success are not the same thing.

Successful platforms tend to be understandable, secure by default, observable, recoverable, and easy to operate.

Failed platforms often accumulate technologies without developing coherent operating principles.

They optimise for what is interesting to build rather than what is valuable to maintain.

Eventually, the platform becomes more demanding than the workloads it exists to support.

I wanted to bring those lessons into this project from the beginning.

That meant resisting the temptation to start with Kubernetes simply because I could.

It meant treating identity as a primary boundary.

It meant documenting architectural decisions rather than relying on memory.

It meant designing for recovery, not just initial deployment.

And it meant accepting that boring infrastructure is often good infrastructure.

Why call it a personal cloud?

The term homelab would be accurate, but incomplete.

A homelab is often understood as an environment for experimentation. My system certainly serves that purpose, but I also intend it to run services I use regularly and capabilities that other projects can depend upon.

Nor is it a private data centre in any meaningful sense.

It is small, heterogeneous, and deliberately constrained.

I use personal cloud because it describes the role I want the system to play.

It is a personally owned computing platform, accessible across devices and locations, providing reusable services under my control.

Some components run inside my home.

Some supporting services remain external.

The important boundary is not physical location.

It is architectural intent and ownership.

The project that emerged

The initial platform is modest.

A Mac mini provides the primary compute capacity.

A Linux ThinkPad acts as a management and infrastructure node.

Services run using conventional container tooling. Remote administration is handled over a private network. Browser-facing applications sit behind identity-aware access controls.

Monitoring runs independently enough to detect when the main compute node disappears.

None of this is particularly revolutionary.

That is part of the point.

I am not trying to build the most sophisticated personal infrastructure possible.

I am trying to build a system that is useful, understandable, secure, recoverable, and capable of evolving over time.

The interesting work lies not in any individual technology, but in how the pieces fit together.

Building from first principles

This series will document that process.

It will cover the decisions behind the platform rather than presenting a pile of configuration files as though they appeared fully formed.

I will explore what the platform is for, what belongs on it, and how different devices and workloads should be separated.

I will look at the access and identity model, the choice to favour deliberately simple infrastructure, and the role of observability and recovery.

I will also cover the less glamorous parts: documenting services, creating operational procedures, and deciding when the platform should grow — and when it should not.

The personal cloud began with a local AI model and a simple desire to access it from another device.

But that small request exposed a much larger opportunity.

Instead of building isolated services one at a time, I could build the underlying capabilities that made all of them easier.

I never intended to build my own cloud.

I simply followed the problem until that was what the problem required.

The runner was easy. The platform was the real engineering

Damien Murphy — Sun, 26 Jul 2026 00:00:00 GMT

Simplicity can be deceptive

GitHub Actions made CI/CD feel unusually accessible.

A workflow lived beside the code it operated on. It could respond directly to repository events. Reusable actions could be published and consumed with relatively little ceremony. Developers did not need to leave GitHub or learn an entirely separate system before they could automate a build, test, or deployment.

Adoption moved quickly because the interface was compelling. But every GitHub Actions workflow eventually has to run somewhere.

For organisations able to use GitHub-hosted runners, much of that infrastructure could remain invisible. For organisations using GitHub Enterprise Server at the time, that was not an option. Teams that wanted to adopt Actions had to provide their own compute and operate their own runners.

On the surface, this looked easy. Download the runner agent, execute it on a machine, register it with GitHub, and give it a label. It is now ready to accept work.

That is enough to create a runner. It is nowhere near enough to create a runner platform.

Local solutions appear before organisational ones

The earliest adopters across our organisation built their own solutions.

Some installed the runner agent on persistent virtual machines. Others created automated systems that provisioned ephemeral runners for individual jobs. Some implementations were basic, while others were sophisticated and thoughtfully engineered.

Each team was responding rationally to an immediate need. They wanted to use GitHub Actions, no central service existed, and operating their own runner was the shortest path forward.

The result was predictable. The organisation gradually accumulated a fragmented estate of critical CI/CD infrastructure.

Different teams used different operating systems, images, patching strategies, scaling approaches, credential mechanisms, network configurations, and security controls. Some runners were long-lived. Some were recreated between jobs. Some were closely maintained. Others quietly became part of the organisational furniture.

The workflows were visible in GitHub. The infrastructure executing them was much harder to see.

This is a common platform-engineering pattern. A capability is easy enough for individual teams to create locally, so local implementations spread before the organisation recognises the need for a shared solution.

By the time the need becomes obvious, the problem is no longer simply technical. It is also organisational.

Someone must decide what should be centralised, what should remain under team ownership, what guarantees the shared service will provide, and who will carry the operational burden.

Capable teams wanted the platform too

It would have been easy to assume that a central runner service was mainly for teams that lacked the skills to operate their own infrastructure.

That was not what happened.

Even teams with sophisticated runner implementations were keen to move to a centrally managed service. Their existing systems were often good. The engineers responsible for them understood autoscaling, ephemeral compute, image management, security, and cloud infrastructure. They could continue operating those systems if they needed to.

They simply did not want to.

Running CI infrastructure was necessary, but it was rarely where those teams created distinctive value. Every hour spent patching runner hosts, updating images, debugging capacity problems, or responding to agent changes was an hour not spent on their own products.

That is one of the clearest signals that something belongs in a platform.

The demand does not only come from teams unable to build the capability themselves. It also comes from capable teams that understand exactly how much ownership costs.

A good internal platform is not a rescue service for weak engineering teams. It is a way to prevent many strong engineering teams from repeatedly solving the same undifferentiated problem.

The runner was the smallest part of the problem

GitHub recommended Actions Runner Controller, commonly known as ARC, as the basis for our shared service.

ARC used Kubernetes to create and manage GitHub Actions runners. It offered an attractive foundation for ephemeral workloads and automated scaling. Rather than keeping fleets of persistent runner machines alive, runners could be created in response to demand and removed after completing their work.

This addressed part of the problem. It did not answer most of the questions we actually had.

How would teams onboard to the service? Which repositories and organisations would be allowed to use it? What runner environments would we support? How would workloads be isolated from one another? How would a workflow securely authenticate to a cloud account?

What happened when the runner platform was hosted in a different environment from the system a workflow needed to deploy into? How much customisation could users request? How would Windows workloads fit into a system primarily designed around Kubernetes and Linux containers? How would we detect capacity problems, stuck jobs, controller failures, or breaking changes?

And perhaps most importantly, how would three or four engineers operate the service while also owning several other platforms?

None of these questions were solved by installing a controller.

ARC was an important component, but components do not become platforms merely because they are centrally deployed.

Multi-tenancy is a question of trust

The moment unrelated teams begin executing arbitrary workflow code on shared infrastructure, multi-tenancy becomes one of the defining concerns.

It is tempting to think of multi-tenancy as a scheduling problem: several workloads share a cluster, and Kubernetes decides where they run. The deeper issue is trust.

A CI job can execute code from a repository, install dependencies from the internet, access credentials, interact with internal networks, build deployable artifacts, and modify external environments. That makes a runner a particularly sensitive boundary.

A compromised workflow might attempt to access another workload, inspect the host, query the Kubernetes control plane, reach internal services, steal credentials, poison build outputs, or move laterally into environments reachable from the runner.

Ephemeral runners helped reduce some risks. A clean runner could be created for a job and destroyed afterwards, limiting the amount of state that survived between workloads.

But ephemerality was not the same as isolation.

A disposable workload can still cause significant damage during the period in which it exists. It can still access anything made available to it. It can still exploit excessive permissions, weak network boundaries, vulnerable dependencies, or an incorrectly configured cluster.

The question was therefore not merely whether runners were short-lived. It was what each runner was trusted to access, what could access the runner, and how far a compromise could spread.

Those questions affected cluster design, namespace boundaries, Kubernetes permissions, network policy, node configuration, image hardening, secrets management, and the degree to which different classes of workload could safely share infrastructure.

The technical architecture was really an expression of the trust model.

Identity was more important than connectivity

Many workflows needed to interact with cloud environments.

The simplest approach would have been to place long-lived cloud credentials on the runners or store them as repository secrets. It would also have created a large and persistent attack surface.

A central runner service made that trade-off even less acceptable. When many organisations and repositories share a platform, static credentials become difficult to control, rotate, attribute, and contain. A compromised runner or workflow may gain access far beyond the job it was meant to perform.

The better model was based on short-lived, workload-specific identity.

A workflow should receive only the permissions it needs, for only as long as it needs them, based on a trust relationship tied back to the organisation, repository, branch, environment, or workflow invoking it.

This changed the problem from distributing secrets to designing identity.

That was a significant improvement, but it also made the platform boundary larger. Cloud IAM configuration, trust policies, GitHub identity claims, environment ownership, and onboarding processes all became part of the runner service.

Networking created a similar challenge.

The runner platform was centralised, while the environments workflows needed to reach were distributed across different networks and cloud accounts. It would have been easy to solve each requirement with another peering connection, firewall exception, proxy rule, or private endpoint.

Taken one at a time, each request could appear reasonable. Taken together, they could turn the runner platform into a highly connected bridge across the organisation.

That would make the platform convenient, but it would also increase the blast radius of a compromise and create an ever-growing operational dependency on the platform team.

The better question was not simply, “How can the runner reach this environment?”

It was, “What is the safest boundary at which this interaction should occur?”

Sometimes the answer was network connectivity. Sometimes it was workload identity. Sometimes it was a different deployment pattern entirely.

A platform team adds value partly by resisting the temptation to treat every user request as an infrastructure request.

Self-service required deliberate constraints

A shared service could not depend on engineers manually configuring every new repository.

The organisation was adopting GitHub Actions too quickly, and the platform team was too small. Manual onboarding would have made the team a permanent bottleneck.

We needed self-service, but self-service does not mean allowing every user to configure every aspect of the underlying system.

In practice, sustainable self-service required us to decide which choices the platform would expose and which it would deliberately remove.

Users generally did not need to understand the Kubernetes controller, runner pods, autoscaling configuration, node pools, cluster permissions, or upgrade process.

They needed to know which runner environments were available, what guarantees those environments offered, how to request access, how to authenticate to their target systems, and what to do when they needed a capability outside the supported path.

The useful abstraction was not “here is access to our ARC installation.”

It was closer to “here are the supported execution environments your workflows can depend on.”

That distinction mattered.

Exposing the underlying machinery would have transferred complexity rather than removing it. Hiding everything without defining clear behaviour would have created a black box that users could not reason about.

The platform needed a stable contract. That contract included supported runner types, expected tooling, resource limits, security boundaries, authentication patterns, maintenance responsibilities, and the line between platform problems and workflow problems.

Good platform abstractions do not eliminate complexity. They decide where complexity should live.

Supporting everything would have meant supporting nothing well

Once a shared runner service existed, requests for variation naturally followed.

A team needed a particular tool installed. Another needed a larger machine. Another wanted a persistent cache. Another needed access to an internal network. Another had a Windows workload. Another wanted its own customised runner image.

Every request could be justified in isolation. The problem was cumulative.

Each runner variation created another image to patch, test, secure, document, monitor, and support. Each network path created another dependency. Each exception weakened the consistency of the service. Each bespoke environment increased the amount of knowledge the platform team needed to retain.

This was especially important because the team operating the platform consisted of only three or four engineers, all of whom worked on other services too.

The architecture therefore had to account not only for technical scale, but also for team scale.

A design that could theoretically support every use case was not useful if it required a dedicated operations team to keep it alive.

We had to standardise aggressively. That meant a limited number of supported runner environments, automated image construction, consistent security tooling, reusable onboarding patterns, common observability, and clear criteria for when a request should become a platform capability rather than an exception.

Constraints were not a failure of the platform. They were part of the product.

Without constraints, the shared service would have become a collection of centrally owned bespoke solutions. The infrastructure would have been centralised, but the operational model would still have resembled the fragmented state we were trying to replace.

Open-source software gave us a foundation, not an operating model

The early road with ARC was rough.

The project could demonstrate how to create runners, but the documentation available at the time did not cover many of the concerns that mattered at enterprise scale.

We needed to understand high availability, scaling behaviour, controller upgrades, runner registration, GitHub job assignment, private networking, image management, observability, and failure recovery.

Much of that understanding came through experimentation.

Some configurations were technically valid but operationally poor. Some behaviours were not documented clearly. Some expectations based on other CI/CD systems did not hold. Some changes to the GitHub runner agent introduced effects that reached all the way into users’ workflows.

Windows support introduced further complexity. It was not on the same supported path as Linux-based runners, and examples for operating it through ARC were limited. We had to bridge the gap between what the project provided and what our users required.

This is another recurring platform-engineering pattern.

An open-source component may solve the central technical mechanism without solving the organisational capability.

A controller can reconcile resources. A scheduler can place workloads. An identity provider can issue credentials. A workflow engine can execute jobs.

The platform team still has to turn those mechanisms into a dependable service. That requires architecture, operating procedures, support boundaries, upgrade strategies, security controls, documentation, observability, and judgement.

The gap between “the software works” and “the organisation can depend on this” is where much of platform engineering happens.

Maturity elsewhere could still break us

The runner platform did not operate in isolation.

It depended on Kubernetes, GitHub Actions, the runner agent, ARC, cloud infrastructure, container images, authentication systems, security tooling, and users’ workflows.

Each of those systems evolved independently.

GitHub Actions itself was still maturing. Some behaviours were poorly documented or inconsistent with what users expected. Runner-agent updates occasionally introduced breaking changes that required workflows to be modified. Controller changes altered deployment and scaling models. Kubernetes upgrades affected the underlying platform. Security requirements changed as new risks were discovered.

This meant the service could be operationally healthy while still causing user-visible failures.

The cluster might be running. The controllers might be available. The runners might be registering successfully.

But a change in the runner agent, an action dependency, a permission model, or GitHub’s scheduling behaviour could still break workflows across the organisation.

That forced us to think beyond infrastructure monitoring.

We needed to understand the full service path from a workflow being triggered to a job being scheduled, a runner being created, credentials being issued, dependencies being downloaded, and the workflow reaching its target environment.

A platform is only as reliable as the user journey it enables.

Monitoring individual components is necessary, but it is not enough. The system must also be observed from the perspective of the capability users are trying to consume.

The interface was simple because the system was not

From the user’s perspective, the final interaction could be remarkably small.

A workflow referenced a runner label.

Behind that label sat Kubernetes controllers, autoscaling, hardened images, cloud identity, network design, secrets handling, policy enforcement, logging, metrics, upgrades, vulnerability management, support processes, and operational ownership.

That asymmetry was the point.

The platform absorbed complexity so that every application team did not have to rebuild and operate the same machinery.

But hidden complexity still has to be owned somewhere.

It must be made observable. It must be documented. It must have boundaries. It must be designed so that a small team can maintain it when individual engineers are unavailable, priorities shift, dependencies change, and incidents occur.

The simplicity of the user interface was not evidence that the problem was simple. It was evidence that the complexity had been deliberately moved.

Centralised infrastructure is not automatically a platform

It is possible to centralise runners without creating a platform.

A team could deploy ARC, operate a shared Kubernetes cluster, publish a few runner labels, and declare the problem solved.

That would produce shared infrastructure.

A platform requires more.

It needs a coherent user experience, self-service onboarding, secure defaults, supported patterns for identity and connectivity, a deliberate multi-tenancy model, clear ownership boundaries, observability based on user outcomes, and an operating model that fits the team responsible for it.

Most importantly, it needs to reduce the total burden placed on the organisation rather than merely transferring that burden to a central team.

That is why self-hosted GitHub Actions runners are such a useful platform-engineering case study.

The core technical mechanism is easy to understand. A runner accepts a job and executes a workflow.

Everything that makes that capability safe, scalable, dependable, and usable is where the real engineering begins.

The runner was easy.

The platform was the real work.

How judgement, not technical skill, defines a senior engineer

Damien Murphy — Mon, 20 Jul 2026 00:00:00 GMT

Seniority begins where certainty ends

I have worked with technically accomplished engineers whom I would not trust to make a critical production change. They could understand the system, write the code, and navigate difficult technical problems. Some had senior titles and longer careers than most of the engineers around them.

But when a change was difficult to reverse, when several teams depended on the outcome, or when the requirements were incomplete, I did not trust the decisions they were likely to make. The problem was not whether they could deliver a solution. It was whether they would identify the right problem, choose a proportionate solution, recognise the important risks, and understand the wider consequences of the work.

That distinction is central to engineering seniority.

Technical skill determines what an engineer is capable of building. Judgement determines what they decide should be built, how it should be introduced, and whether the result will remain valuable after the implementation is complete.

At junior levels, technical ability is usually the dominant constraint. Engineers need to learn how systems work, how to write maintainable software, how to debug failures, and how to use the tools of the profession. As an engineer becomes more senior, however, the nature of the constraint changes.

The difficult question is no longer simply:

Can you implement this?

It becomes:

What is the right thing to do here?

That question contains many others. What problem are we actually solving? Which risks deserve attention? What can safely be deferred? How much complexity is justified? Who will operate the result? How easily can the decision be reversed? What are we making easier, and what are we making harder?

These are not questions separate from technical engineering. They are what technical engineering becomes when the scope and consequences increase.

Technical skill creates the decision space

Sound engineering judgement depends on technical competence. An engineer cannot properly evaluate trade-offs they do not understand. They cannot distinguish a safe shortcut from a reckless one without understanding the system underneath it, and they cannot anticipate failure modes if they lack a sufficiently accurate model of how the technology behaves.

Technical depth creates the decision space. It gives an engineer more possible approaches, a better understanding of their consequences, and a greater ability to detect when an apparently simple solution hides significant risk.

But having more options does not guarantee a better choice. A highly capable engineer can still over-engineer a straightforward problem, introduce an unnecessary technology, construct an elegant abstraction nobody needs, or optimise a system whose real constraint lies elsewhere. The implementation may be sophisticated while the decision remains poor.

Technical skill answers:

What could we build?

Judgement answers:

Which option best serves the system, the organisation, and the people who will inherit it?

As an engineer’s scope grows, the second question becomes increasingly important.

Experience does not automatically become judgement

Judgement is usually built through experience. Engineers encounter failures, migrations, ambiguous requirements, operational constraints, difficult stakeholders, production incidents, and decisions that looked reasonable but produced unexpected consequences. These experiences can compound into better instincts, but only if someone learns from them.

Ten years in engineering is not necessarily ten years of development. It can be one narrow year repeated ten times.

Two engineers can pass through the same incident and extract entirely different value from it. One remembers the immediate cause and the eventual fix. The other asks why the failure was possible, which assumptions proved false, what signals were ignored, why the safeguards did not work, and whether the same weakness exists elsewhere.

The second engineer is doing more than accumulating experience. They are converting specific events into reusable models.

That is why seniority is not a linear function of tenure. Some engineers progress faster because they extract more from each experience. They reflect, compare situations, update their assumptions, and recognise recurring patterns across different systems. Others accumulate time without significantly changing how they reason.

The important variable is not simply how much an engineer has seen, but how effectively they convert what they have seen into better future decisions.

Judgement can transfer, but technical depth still has to be earned

I entered software engineering after working in another professional field. When I began as an intern and junior engineer, I had substantial technical ground to cover. I needed to build the depth required to understand systems properly, produce strong implementations, diagnose failures, and make decisions grounded in engineering reality.

That technical development was essential to my progression. But I was not starting from zero in every dimension.

I already had experience dealing with ambiguity, separating stated requirements from underlying needs, prioritising competing work, communicating across organisational boundaries, and recognising that technically correct work can still fail when it ignores context. Those capabilities did not substitute for technical competence; they helped me acquire and apply it more effectively.

This is one reason some career switchers progress quickly once their technical ability catches up. Judgement developed in another field is not perfectly transferable, but parts of it often are. The ability to assess incomplete information, understand incentives, anticipate second-order effects, communicate uncertainty, and recognise when confidence exceeds evidence remains useful across domains.

A mature career switcher may begin with less technical knowledge than a graduate who has spent years programming. They may still be better prepared to learn from consequences, recognise patterns, and understand how engineering work interacts with the wider organisation.

They cannot bypass the technical apprenticeship, but they may be able to extract more from it.

Poor judgement often looks like misplaced attention

Poor engineering judgement is not always dramatic. It often appears as an inability to distinguish what matters from what merely exists.

I once worked with an engineer who was more senior than several others both in organisational level and in years of experience. Their technical proposals frequently contained substantial detail, but the attention was often directed toward marginal concerns while larger risks, dependencies, and operational consequences remained underexplored.

The problem was not an inability to analyse. It was an inability to weight the analysis appropriately.

This is a common failure mode in engineering: majoring in the minors. A proposal may spend pages on an implementation detail while saying little about ownership. A review may identify dozens of theoretical risks without distinguishing the probable from the merely possible. A technically elegant design may ignore migration cost, support burden, or the reality that another team must operate it.

Weak judgement often shows itself through disproportion. The solution is larger than the problem. The certainty is stronger than the evidence. The attention given to an issue is disconnected from its likely consequence.

Other signals include proposing solutions before understanding the problem, optimising for theoretical purity while ignoring operational reality, treating all risks as equally important, and repeatedly choosing technically interesting work over valuable work.

Skill without judgement tends to produce sophisticated but immature solutions. The work may demonstrate what the engineer knows, but not necessarily that they understand what the situation requires.

The trust test

A practical way to think about seniority is through trust.

Who would you trust to lead a consequential change when the requirements are incomplete, the deadline is real, several teams have conflicting interests, and there is no obviously correct answer?

The person you choose may not be the deepest specialist in every technology involved. But they will usually have sufficient technical depth to understand the important parts of the system and enough judgement to know where their understanding ends.

They will identify the consequential unknowns rather than pretending uncertainty does not exist. They will seek input without surrendering ownership, make risks visible, keep the solution proportional to the problem, and preserve reversibility where possible. They will also know when the technically strongest local solution creates a worse overall system.

That is engineering judgement in practice. It is why the people trusted with the most consequential work are not always those with the longest CVs, the loudest opinions, or the greatest command of technical vocabulary.

Trust emerges from repeated evidence that someone will make sound decisions under imperfect conditions.

Seniority is visible in how scope is handled

I was promoted into a team and technical lead position ahead of engineers who had longer technical tenures and, on paper, more experience. Technical capability was not incidental to that decision. The role required enough depth to understand complex systems, challenge implementation choices, diagnose difficult problems, and guide the technical work of others.

The differentiator was how that capability was applied across a wider scope.

The work was no longer only about producing strong technical solutions. It involved determining which problems mattered, sequencing work, balancing delivery with operational risk, understanding organisational constraints, creating clarity where the direction was incomplete, and making decisions that other engineers and teams could safely build upon.

This is the broader pattern behind engineering progression. A junior engineer is often asked to implement a defined change. A senior engineer is increasingly expected to shape the change: to clarify the problem, identify the constraints, compare approaches, and ensure that the implementation will hold up in practice.

At staff or principal scope, the question broadens further. Is the organisation solving the right problem? Are several teams independently compensating for the same missing capability? Does the proposed solution improve the wider system, or merely move complexity across a boundary?

At each stage, technical competence remains necessary. What changes is the radius over which that competence must produce good decisions.

Judgement is also visible in what does not get built

Technical output is visible. Good judgement is often less visible.

The unnecessary migration that never happened, the platform that was not introduced, the outage avoided through a cautious rollout, and the maintenance burden prevented by choosing a simpler design rarely attract much attention. Yet these may be among the most valuable decisions a senior engineer makes.

Senior engineers create value partly through subtraction. They reduce unnecessary scope, resist premature abstractions, challenge false urgency, avoid creating accidental platforms, simplify ownership, and sequence work so that important uncertainty is resolved before the organisation commits heavily.

They also recognise when boring technology is the more sophisticated decision.

A junior engineer often demonstrates value through what they can build. A senior engineer increasingly demonstrates value through knowing what does not need to be built, what should not be built yet, and what must be understood before anyone starts building.

Judgement without humility becomes dogma

Experience can improve judgement, but it can also harden into ego.

An experienced engineer may begin to mistake pattern recognition for certainty. They have seen similar situations before, so they assume they already understand the current one. Past experience then stops being evidence and becomes authority.

Good judgement requires the ability to use experience without becoming trapped by it. A strong engineer should be able to say:

I have seen this pattern before, but I may be wrong about whether it applies here.

That does not mean becoming indecisive or retreating into performative uncertainty. It means developing calibrated confidence: being decisive when the evidence is strong, cautious when it is weak, and willing to update when reality disagrees.

Without confidence, an engineer may avoid making necessary decisions. Without humility, they may stop noticing when their decisions are wrong.

Experience should make an engineer less naïve, but not less curious.

How engineers can develop better judgement

Judgement develops faster when experience is examined rather than merely endured.

After an important decision, do not review only whether the outcome was good or bad. Examine the quality of the reasoning that produced it. What assumptions were made? Which proved correct? Which were wrong? What evidence was available at the time? What was overlooked? Did the decision succeed because the reasoning was sound, or because the team was fortunate?

Good outcomes can come from poor decisions, and good decisions can occasionally produce bad outcomes. Learning requires separating the two.

Engineers should also seek exposure to consequences, not only implementation. Building a service teaches one set of lessons. Operating it teaches another. Supporting its users reveals costs that are invisible during design. Participating in incidents exposes the difference between how a system was expected to behave and how it behaves under pressure.

The wider the feedback loop, the better the raw material for judgement.

It is also useful to study engineers whose decisions you trust. Do not simply copy their conclusions. Observe how they frame problems, identify important unknowns, compare trade-offs, distinguish reversible from irreversible decisions, and communicate uncertainty.

The transferable skill lies in the reasoning process, not in memorising what someone decided in a particular situation.

Finally, resist the urge to demonstrate seniority through complexity. The desire to prove technical sophistication is one of the easiest ways to produce immature engineering decisions.

Strong engineers rarely need every solution to display the full extent of their abilities. Their sophistication is visible in the appropriateness of the result.

How mentors can teach judgement

Mentoring judgement requires more than reviewing code or supplying better answers. A mentor who always gives the answer may improve the immediate outcome while slowing the development of the engineer.

A better approach is to make the reasoning visible. Ask what problem the engineer believes they are solving. Ask which constraints matter most, what alternatives they considered, what could fail, who inherits the operational cost, and what evidence would cause them to change direction.

The goal is not to force the engineer toward the mentor’s preferred answer. It is to improve the structure of the decision.

Mentors can also expose engineers to the parts of work that are often hidden from implementation roles: planning, incident response, stakeholder conversations, operational reviews, trade-off discussions, and the consequences of previous architectural decisions.

Judgement develops when engineers see the whole system around the code.

A useful mentoring question is:

What would have to be true for this to be the right decision?

That question forces assumptions into the open.

Another is:

Which part of this decision will be most expensive to reverse?

That shifts attention from immediate implementation toward longer-term consequence.

How organisations can recognise judgement

Organisations often claim to value judgement while promoting people using easier-to-measure proxies. Years of experience, qualifications, visible technical output, architectural complexity, and performance during interviews are all easier to assess than decision quality, but they are incomplete signals.

One organisation I worked in placed significant weight on experience and formal qualifications. This made it easier for people to appear senior on paper without consistently demonstrating senior-level judgement.

Another organisation was much better at identifying technical strength and experience with hard problems, but gave insufficient weight to how engineers affected the people and systems around them. As a result, some personally toxic engineers progressed further than they should have.

This is not merely a failure to value “soft skills.” An engineer who hoards information, damages collaboration, dismisses operational concerns, creates unnecessary dependency on themselves, or reduces the effectiveness of the surrounding team is exercising poor engineering judgement.

At senior levels, the unit of evaluation cannot remain the individual’s technical output. Organisations should examine the quality of the decisions an engineer enables.

Do their solutions reduce or increase long-term complexity? Do they improve the decisions of others? Do they identify risks early? Do they create clarity under ambiguity? Do the systems they influence become easier to operate, change, and understand?

Promotion evidence should include decisions, not only deliverables. What was the context? What alternatives existed? What trade-offs were made? What consequences followed? What did the engineer learn when reality differed from the plan?

The purpose is not to reward people for always being correct. It is to recognise those who consistently improve the quality of consequential decisions.

Practical questions for consequential engineering decisions

No checklist can replace judgement, but a small set of questions can improve it.

Before committing to a significant technical direction, ask:

What problem are we actually solving? Separate the underlying need from the first requested implementation.
What happens if we do nothing yet? Not every problem requires immediate intervention.
Which constraints genuinely matter? Distinguish hard constraints from preferences, habits, and assumptions.
What is the smallest responsible solution? Avoid both reckless shortcuts and unjustified complexity.
What are the likely failure modes? Focus first on probable and consequential risks.
Who will own and operate the result? Delivery is only the beginning of the system’s life.
What are we making harder elsewhere? Local simplification often exports complexity across a boundary.
How reversible is the decision? Move quickly on reversible choices and more carefully on irreversible ones.
What evidence would change our direction? Define the conditions under which the current reasoning should be revisited.
What will this decision teach us? Prefer approaches that reduce important uncertainty early.

The value of these questions is not that they produce a single correct answer. They widen the frame before the organisation commits to one.

Seniority is the quality of the decisions you can be trusted to make

Technical skill matters enormously. Without it, judgement becomes detached from engineering reality. An engineer cannot make consistently sound technical decisions without understanding the systems involved.

But technical skill is the foundation of seniority, not its final form.

As engineers progress, their contribution shifts from executing known solutions toward navigating uncertainty, making trade-offs, managing consequences, and improving the decisions of the people around them.

That is why tenure is not enough. Technical brilliance is not enough. Confidence is not enough.

A senior engineer is someone who can be trusted to exercise sound technical judgement when the answer is unclear and the consequences matter.

Their ceiling is determined not merely by what they know how to build, but by the quality of the decisions they make about what should be built, how it should be introduced, and what the organisation should deliberately leave undone.

Designing a personal learning platform

Damien Murphy — Wed, 15 Jul 2026 00:00:00 GMT

Reframing learning

For years, I approached learning the same way most engineers do.

I’d identify a topic, buy a book, watch conference talks, read the documentation, build something, and then move on to the next challenge. It worked reasonably well, but something always bothered me.

Each learning effort felt largely independent. I was accumulating knowledge, but I wasn’t deliberately designing a system that made me better at learning itself.

Eventually I realised something.

As platform engineers, we spend our careers building platforms that make other engineers more effective. We reduce friction, standardise common capabilities, automate repetitive work, and create systems that compound in value over time.

Why wasn’t I doing the same thing for myself?

That question fundamentally changed how I think about learning.

From projects to platforms

Imagine two organisations.

The first solves every problem independently. Every new team builds its own CI/CD pipeline, monitoring solution, authentication system and deployment process. The same problems are solved over and over again.

The second organisation invests in an internal developer platform. Authentication, observability, deployment, documentation, security and engineering standards become shared capabilities. Every new project starts from a much stronger foundation because it inherits everything the platform already provides.

The platform compounds.

Learning isn’t very different.

Many of us treat every new subject as an isolated project. We learn Kubernetes, then architecture, then leadership, then AI as though each exists in its own world.

I think that’s a mistake.

Instead, I’ve started thinking about building a personal learning platform. Not something that teaches me Kubernetes or cloud computing, but something that makes me better at learning anything.

Every capability follows the same lifecycle

Whether I’m learning platform engineering, writing, architecture, AI or leadership, I’ve found the process is remarkably similar.

Orient ↓ Build mental models ↓ Deliberate practice ↓ Build something ↓ Reflect ↓ Capture knowledge ↓ Teach ↓ Repeat

The domain changes.

The lifecycle doesn’t.

Recognising that was surprisingly important. Once I stopped designing separate learning processes for every subject, I could start improving the learning system itself.

Orientation comes before information

The first question isn’t:

“What should I read?”

It’s:

“What problem am I actually trying to solve?”

Before diving into documentation or tutorials, I try to understand why the capability matters, where it fits into the broader landscape, what assumptions I’m bringing with me, and what success actually looks like.

I’ve found that good orientation dramatically reduces wasted effort. It’s far easier to decide what deserves your attention once you understand the landscape you’re operating in.

Mental models over memorisation

Technology changes too quickly to optimise for memorisation.

Instead, I try to identify the underlying abstractions, constraints, trade-offs, invariants and failure modes. Those ideas survive changing tools.

A good mental model of distributed systems remains valuable whether I’m using Kubernetes today, something completely different tomorrow, or explaining a design to another engineer five years from now.

Tools evolve.

Good mental models tend not to.

Deliberate practice

This is where I think many learning systems fall apart.

Reading isn’t practice. Watching conference talks isn’t practice. Neither is collecting bookmarks, courses or videos you’ll “get around to” someday.

Capability develops when you repeatedly operate just beyond your current level and receive meaningful feedback.

That usually means choosing projects that expose your weaknesses rather than reinforce your strengths. It’s often less comfortable, but it’s where the most valuable learning happens.

Build something real

Eventually every capability has to leave your head.

Infrastructure gets deployed. Software gets written. Articles get published. Ideas become architecture. That’s when reality begins to push back.

Building exposes misunderstandings that reading rarely reveals. Systems behave differently under load. Assumptions turn out to be wrong. Constraints appear that no tutorial mentioned.

Reality is an excellent teacher.

Reflection is where experience becomes judgement

One of the biggest changes I’ve made is treating reflection as part of learning rather than something optional.

After finishing a project, I ask questions like:

What surprised me?
What assumptions changed?
What mistakes would I avoid next time?
What patterns appeared?
What principle emerged?

Without reflection, experience often remains isolated.

Reflection is what turns experience into judgement.

Capture reusable knowledge

Every learning cycle should leave something behind.

Sometimes that’s a note. Sometimes it’s a runbook, an Architecture Decision Record, a checklist or a blog post. The specific artifact matters less than the habit of creating one.

If future me has to rediscover the same insight, I probably failed to capture it properly.

The goal isn’t to document everything.

It’s to preserve the lessons that are likely to make future work easier.

Teaching closes the loop

I’ve found that writing is one of the best tests of understanding.

Trying to explain an idea exposes fuzzy thinking remarkably quickly. If I can’t explain something clearly, I probably don’t understand it as well as I thought.

Teaching isn’t simply about helping other people.

It’s one of the most effective ways of improving your own thinking.

Where AI fits

Interestingly, AI isn’t the platform.

It’s one of the platform’s services.

Sometimes it’s a teacher. Sometimes it’s a reviewer, a coach or a thinking partner. Increasingly, I find it most valuable as a curriculum designer, helping me identify what I should learn next rather than simply explaining the topic I’ve already chosen.

Its value isn’t replacing learning.

Its value is strengthening every stage of the learning lifecycle.

Build a platform, not a syllabus

The biggest lesson for me has been this.

Individual technologies come and go. Today’s learning goals will eventually be replaced by new ones.

A well-designed learning platform, however, continues to improve regardless of what you’re learning next.

The return isn’t measured by how quickly you finish a book or complete a course.

It’s measured by whether the next capability becomes easier to acquire than the last.

Because in the long run, I don’t think the greatest advantage comes from knowing more.

I think it comes from becoming better at becoming better.

The dashboard is not the work

Damien Murphy — Wed, 08 Jul 2026 00:00:00 GMT

Observing developer productivity

There is a growing temptation in software organisations to make developer productivity more visible. On the surface, this sounds reasonable. Software is expensive, engineering teams are hard to understand from the outside, and leaders want to know whether investment is turning into progress. Developer experience matters. Friction matters. Delivery health matters.

Measurement is not the problem.

The problem begins when organisations measure what is easy to count, then quietly start pretending those numbers represent engineering performance. Pull requests created. Lines of code added. Lines of code deleted. Tickets closed. AI suggestions accepted. AI-generated code volume. Tool usage. Activity. Throughput. Motion. These things are visible, but visibility is not the same as value.

Visibility is not performance

Developer metrics often optimise for visibility, not performance. They make work legible to people who are not close enough to understand the work. That can be useful when the metrics expose genuine friction in the system. It becomes dangerous when those same metrics are used to shape developer behaviour without understanding what good engineering actually looks like.

A developer can create many pull requests and still make the system worse. A developer can add thousands of lines of code and still be solving the wrong problem. A developer can delete very little code and still be doing deep, valuable work. A developer can spend a day debugging something subtle, prevent a future incident, and produce almost no visible output.

A developer can stop a bad idea from becoming a six-month mistake. They can improve a design in a conversation. They can unblock five other people without committing anything. They can understand a fragile legacy system well enough to avoid breaking it. Where does that appear on the dashboard? Usually nowhere.

That is the problem. The most visible work is not always the most valuable work. Sometimes the most valuable engineering work is the work that prevents unnecessary work from existing at all.

Metrics become incentives

The real danger is not that metrics are incomplete. All metrics are incomplete. All models simplify reality. The danger is when incomplete metrics become incentives.

Once teams know they are being measured by pull request volume, lines changed, tickets closed, or AI usage, behaviour will shift. Not always dramatically. Not always consciously. But it will shift. More small pull requests. More visible activity. More performative updates. More generated code. More movement that looks good from far away and smells strange up close.

An organisation may believe it is improving productivity, when it has actually created a theatre for productivity-shaped behaviour. People become incentivised to look good rather than be good. That is not engineering improvement. That is dashboard appeasement.

AI makes this worse

AI makes bad developer metrics even more dangerous. If we measure lines of code, AI can create more lines. If we measure pull requests, AI can help create more pull requests. If we measure suggestions accepted, AI can increase suggestion acceptance. If we measure usage, people can use AI more.

None of that proves better engineering. AI usage metrics are not a measure of AI savviness. They measure how much is coming through the pipe, not the quality of what comes out the other end.

A poor engineer with AI can generate more poor code faster. A strong engineer with AI may use it sparingly, precisely, and with judgement. One might look more “AI-enabled” on a dashboard. The other might actually be better.

This is the absurdity of measuring tool usage instead of engineering outcomes. It is like measuring a carpenter by how many times they touched the hammer.

Good engineering is often qualitative

The best developer qualities are difficult to quantify. Good engineers reduce ambiguity, simplify systems, ask better questions, understand failure modes, spot hidden coupling, avoid unnecessary complexity, and improve the judgement of people around them. They know when not to build. They know when the problem is not technical. They debug with patience. They understand context. They make systems more operable. They leave behind fewer traps. They create leverage.

Much of this is visible only to people close enough to the work. That is why strong engineers can often recognise other strong engineers through conversation. Not through a productivity dashboard, but through how they reason. Through what they notice. Through what they ignore. Through the trade-offs they make instinctively. Through the scars in their judgement.

A dashboard can show activity. It cannot show taste. It cannot show restraint. It cannot show whether someone made the codebase easier to live with. It cannot show whether a decision avoided future pain. It cannot show whether someone protected the system from unnecessary cleverness. And in software, those things matter. A lot.

Developer experience should measure friction

This does not mean metrics are useless. The better use of developer metrics is not to measure developers as output units. It is to measure the environment developers are forced to work inside.

How long does it take to get a local environment working? How painful is onboarding? How long do builds take? How flaky are tests? How often do deployments fail? How long do pull requests wait for review? How many approvals are ceremonial? How much work is blocked by unclear ownership? How hard is it to find documentation? How often does delivery depend on tribal knowledge? How much cognitive load is caused by the organisation itself? How much time is lost to platform friction?

These are useful signals. They are not individual productivity scores. They are system health indicators. That distinction matters.

A healthy engineering organisation does not ask only, “How do we make developers produce more visible output?” It asks, “What friction is preventing good engineers from doing good work?”

That is a very different question. One leads to surveillance. The other leads to better systems.

The management smell

There is a particular smell that appears when engineering metrics are introduced without enough proximity to the work. The dashboards become more important than the conversations. Developer feedback becomes decorative rather than directional. The organisation starts treating visible activity as a proxy for valuable engineering.

The people closest to the work can sense the model is wrong, but the model is legible, polished, and convenient. So the model wins.

That is dangerous. The dashboard will never understand the codebase. It will never feel the drag of bad architecture. It will never notice that a “small change” is only small because someone spent years making the system coherent. It will never know which engineer quietly prevented a bad decision. It will never understand why a good engineer deleted an idea before it became code.

Metrics can support judgement. They cannot replace it. When metrics become a substitute for technical leadership, the organisation has started outsourcing its judgement to a chart.

The interview parallel

This reminds me of the nonsense that often happens in technical interviews. Companies want to measure technical skill, so they invent artificial exercises that are easy to score. But the things that are easy to score are often not the things that matter most in real engineering work.

The result is a proxy game. Candidates learn to perform well against the measurement system. The company learns surprisingly little about how they will behave inside a real codebase, with real constraints, real ambiguity, and real humans.

Developer metrics can make the same mistake inside the organisation. They create a proxy for productivity, then slowly forget it is only a proxy.

Measure the system, not the smoke

The useful version of developer metrics is not “who produced the most activity?” It is “where is the system making good work harder than it needs to be?”

That means measuring friction, flow, reliability, waiting time, cognitive load, feedback loops, and operational pain. It means using metrics as a starting point for better questions, not as a scoreboard. It means listening to developers when they say the numbers are missing the point. It means treating developer experience as an engineering problem, not a surveillance programme with friendlier branding.

Metrics should help us see the system more clearly. They should expose bottlenecks, waste, fragility, and pain. They should help good engineers do better work.

But when metrics are used to score developers through visible activity, they become corrosive. They reward output over judgement. They reward motion over progress. They reward theatre over substance. And with AI, the theatre can now scale beautifully.

A software organisation should not be trying to measure who produces the most smoke. It should be asking where the fire is, why it started, and what kind of system keeps making people reach for matches.

The dashboard is not the work.

The work is the work.

Don't steal people's failure

Damien Murphy — Wed, 01 Jul 2026 00:00:00 GMT

Managing failure for growth

There is a kind of help that looks generous in the moment but quietly weakens people over time.

You see someone heading toward a mistake. You know how the story ends. You can already feel the awkward conversation, the broken plan, the rework, the avoidable mess. So you step in. You correct the path. You save the outcome.

Sometimes that is exactly the right thing to do. Some failures are too expensive, too harmful, or too pointless to allow. Letting someone walk into a wood chipper for the sake of “learning” is not wisdom. It is negligence with a beard.

But not every failure is a wood chipper. Some failures are small, survivable, and deeply useful. When we prevent all of them, we may protect short-term performance, but we also steal the feedback loops people need to build judgement.

Advice is not experience

People rarely learn deeply from advice alone. Advice can help, of course. It can prepare someone, warn them, give them a map, or make the lesson easier to recognise later. But advice often remains theoretical until reality lands the punch. There are things people only understand once they have felt the consequence themselves.

You can explain a trade-off ten times. You can describe why an approach is fragile. You can warn that a plan depends on too many assumptions. But until the thing bends, cracks, or becomes awkward in their own hands, the lesson often stays abstract.

This is frustrating when you can see the mistake coming. It is especially frustrating when you have already paid for the same lesson yourself and would quite like to save someone else the bill. But saving someone from every bill is not the same as helping them become competent. Sometimes it only teaches them that someone else will catch the falling plate.

Intervention has a cost

Intervention improves immediate performance, but it can damage long-term performance.

A senior engineer who constantly steps in may keep the work moving, but they may also prevent someone else from building judgement. The task gets done, the delivery risk drops, the meeting goes more smoothly, and everyone feels like the right decision was made. Maybe it was. But there is still a trade-off.

The person who was rescued did not get to experience the consequence of their decision. They did not have to debug the assumption. They did not have to recover the situation. They did not have to sit with the gap between what they thought would happen and what actually happened.

That gap is where judgement forms.

If we close that gap too quickly, we create dependence. People learn to wait for correction, approval, or rescue. They become good at operating inside someone else’s judgement instead of developing their own. This is one of the quieter costs of micromanagement. It does not only waste the manager’s time or frustrate the person being managed. It interrupts the learning loop.

The goal is not abandonment

None of this means we should let people fail blindly. There is a lazy version of “let people learn” that is really just neglect wearing a philosophical hat. That is not the point.

The job of a senior person is not to disappear. It is to design the conditions where people can encounter reality without being destroyed by it. That means setting context, clarifying constraints, making risks visible, and managing the blast radius.

Let the small things break so the big things do not.

That might mean letting someone own a technical decision, but keeping the scope small. It might mean allowing an awkward design review, but not allowing a production incident. It might mean letting someone present an imperfect proposal, but making sure the room is safe enough for them to learn rather than be humiliated.

The distinction matters. Preventing every mistake creates fragility. Allowing unlimited damage creates chaos. The useful path is deliberate exposure to recoverable failure.

Failure should be visible

There is another reason to let some failures play out: other people learn from them too.

In healthy engineering cultures, failure is not hidden away like a family curse. It is examined. Not theatrically. Not with blame. But openly enough that the team can learn from what happened.

This is especially important for senior engineers. Senior people set the tone for what is allowed to be visible. If they hide every mistake, every bad assumption, and every moment of uncertainty, they teach everyone else to perform competence instead of build it.

That performance is toxic.

Junior engineers start believing that strong engineers are always certain. Less technical managers start judging people against an unrealistic image of effortless expertise. Teams stop asking questions because nobody wants to look like the only confused person in the room.

But real competence is not clean. It involves wrong turns, bad assumptions, incomplete context, debugging, recovery, revision, and occasionally staring at a terminal with the hollow expression of someone reconsidering several life choices. People need to see that. They need to see strong engineers misunderstand something, correct themselves, ask for help, change their mind, and recover.

Not because failure is glamorous. Because it is normal. Hiding it creates a fantasy model of competence, and fantasy models are terrible operating systems.

Cultures that hide failure become brittle

An organisation where people hide failure is as unhealthy as an organisation where people hoard knowledge. Both create the same underlying problem: learning gets trapped.

When knowledge is hoarded, people cannot build on what others know. When failure is hidden, people cannot build on what others learned. In both cases, the organisation becomes dumber than the sum of its people.

Failure that is never discussed becomes private tuition. The individual pays the price, maybe learns something, and the wider system gains nothing. That is waste.

A team should not need every person to step on the same rake independently. The first person to take the handle to the face should be able to make the rake visible for everyone else.

This requires psychological safety, but psychological safety is often misunderstood. It does not mean low standards. It does not mean everyone gets wrapped in emotional bubble wrap. It means people can expose uncertainty, mistakes, and incomplete thinking without being punished for the act of learning in public.

High standards and visible failure are not opposites. In serious engineering cultures, they depend on each other.

Some people still will not learn

There is an uncomfortable edge to all of this: failure only teaches people who are willing and able to reflect.

Some people do not learn from advice. Some do not learn from failure either. They repeat the same pattern, pay the same price, blame the same external forces, and somehow emerge with the same conclusion they started with. At that point, failure is no longer a feedback loop. It is just a recurring subscription.

This matters because “let people fail” is not a magic growth strategy. Exposure alone is not enough. The learning comes from reflection, ownership, and adjustment.

If someone repeatedly fails in the same way and refuses to engage with the lesson, the answer is not infinite patience disguised as empowerment. The answer may be clearer boundaries, different responsibilities, direct feedback, or removal from a context where their failure damages others.

Recoverable failure is useful. Repeated unexamined failure is a signal.

Support is better than rescue

The better alternative to over-intervention is not passivity. It is support.

Rescue says, “I will prevent this from going wrong.”

Support says, “I will help you understand the terrain, make the risk visible, and stay close enough that the failure remains useful.”

Rescue takes ownership away. Support leaves ownership in place while improving the conditions around it. That is the difference between micromanagement and leadership. Micromanagement tries to control the outcome by controlling the person. Leadership improves the environment so the person can grow into better judgement.

A useful senior person knows when to intervene, when to warn, when to ask a question, when to let the decision stand, and when to quietly reduce the blast radius. That is harder than simply stepping in. It requires patience, trust, and tolerance for some mess in the system, because all capability is built through contact with reality.

The job is to manage the blast radius

The job of a senior person is not to prevent every mistake. It is to know which mistakes are survivable, which ones are dangerous, and which ones are necessary.

Do not let people walk into the wood chipper. Do not let avoidable damage hit customers, patients, production systems, security boundaries, or people’s dignity just because you enjoy the rugged aesthetic of “learning by doing.”

But do not wrap every sharp edge in foam either.

Let the small things break. Let people feel reality. Let the team see recovery in public. Let people build scar tissue while the stakes are still low enough for scar tissue to be useful rather than catastrophic.

That is how judgement forms. That is how engineering cultures mature. That is how people become strong enough to not need rescuing.

Hidden costs of ownership

Damien Murphy — Mon, 22 Jun 2026 00:00:00 GMT

Initial cost != total cost

The price of acquiring something is rarely its true cost. The purchase price is merely the most visible part: a number that appears on a receipt, an invoice, or a budget request. It is concrete, immediate, and easy to compare. The rest of the cost is distributed across the future, where it becomes much harder to see.

Anything we own must be stored, maintained, understood, secured, upgraded, worked around, or eventually disposed of. It occupies physical space, mental space, organisational space, or some combination of all three. Even something that is free can be expensive to own.

I understand this instinctively in my professional life. When assessing a tool or platform, I rarely consider only what it costs to acquire. I think about operational burden, maintenance, support, security, integration, migration, documentation, and the long-term consequences of introducing it into an organisation.

I am much less consistent about applying the same thinking to my personal life.

Acquisition Is an Event. Ownership Is a System.

Buying something happens once. Owning it continues.

That distinction matters because the initial transaction is usually the easiest part of the relationship. The deeper costs emerge later, often in small and seemingly insignificant increments.

A physical object needs somewhere to live. It may need cleaning, repairing, charging, insuring, organising, or replacing. A piece of software needs updating, configuring, learning, backing up, and occasionally migrating away from. A service needs monitoring and someone who knows what to do when it stops working.

None of these costs may be particularly large in isolation. The problem is accumulation.

A single object rarely creates intolerable clutter. One application rarely destroys a workflow. One additional platform rarely overwhelms an engineering team. But ownership scales poorly when every new thing introduces another set of obligations, decisions, dependencies, and failure modes.

The dangerous cost is not always money. More often, it is the gradual fragmentation of attention.

The Maintenance Tax

Maintenance is the most obvious hidden cost of ownership, but even this is usually underestimated.

We tend to imagine maintenance as occasional repair: something breaks, we fix it, and the object returns to normal. In reality, maintenance includes all the effort required to keep something useful. It includes remembering where accessories are stored, finding replacement parts, learning how something works, installing updates, managing subscriptions, keeping documentation current, and retaining enough knowledge to troubleshoot problems months later.

In software engineering, we understand this as operational ownership. A service does not stop costing us once it reaches production. It requires monitoring, incident response, dependency upgrades, security patches, capacity planning, support, and eventually decommissioning.

The same principle applies outside work. A cheap appliance that breaks frequently may cost more than an expensive reliable one. A bargain piece of furniture that is awkward to move may extract its price every time the room is rearranged. A self-hosted service might be free in monetary terms while consuming hours of attention every month.

Maintenance is not merely what happens when something breaks. It is the ongoing tax required to prevent it from becoming useless.

The Cost of “Good Enough”

I recently bought a desk that is good enough. It is sturdy, looks fine, and performs its primary function, but it is missing one feature that increasingly matters to me: built-in cable management.

That omission seemed minor when I bought it. Cable management is not the primary purpose of a desk, and it felt unreasonable to reject an otherwise suitable option because of it. The problem is that small design omissions become recurring friction.

The lack of cable management means additional trays, clips, ties, and improvised solutions. It makes the desk harder to keep tidy and more annoying to reconfigure. Every new device introduces another small negotiation with the physical constraints of the desk.

None of these problems justify replacing it, and that is precisely why the decision has such persistence.

A terrible desk would be easy to replace. A perfect desk would not need replacing. A desk that is good enough but consistently irritating occupies the awkward territory between the two. It does not fail severely enough to force action, but it creates enough friction to be noticed repeatedly.

This is one of the least obvious costs of ownership: the power of an adequate existing solution to prevent the adoption of a substantially better one.

Once we own something, the comparison is no longer between two products. It is between the full cost of the new product and the perceived cost of continuing with the existing one. The existing thing feels free because we have already paid for it, but continuing to own it is not free. Its future friction remains unpaid.

Ownership Creates Opportunity Cost

Every choice closes other choices.

Money spent on one thing cannot be spent elsewhere, but the opportunity cost of ownership goes beyond the original purchase. Once we possess something that is broadly sufficient, we are less likely to consider alternatives.

We do not buy the better chair because we already have a chair. We do not redesign the workflow because the current process technically works. We do not replace the platform because migrating would be disruptive. We continue to pay for yesterday’s decision because the cost is spread thinly enough to remain tolerable.

This is path dependence: previous decisions constrain the decisions available to us now.

The effect can be particularly strong when the existing system carries accumulated investment. We have learned how to use it, configured it, integrated it with other systems, built habits around it, and perhaps convinced other people to adopt it. Replacing it means accepting that some of that investment will not be recovered.

This is where ownership interacts with the sunk-cost fallacy. We treat past expenditure as a reason to preserve the current arrangement, even though the better decision should be based entirely on future costs and benefits.

Sometimes, the highest impact move is to replace the thing that still works—not because it is broken, but because its continued existence prevents a disproportionately better system from taking its place.

Clutter Is Not Passive

Physical clutter is often discussed as an aesthetic problem, but its deeper cost is cognitive.

Every visible object is a small piece of unresolved information. It may represent something to organise, repair, use, sell, store, or decide upon. Even when we are not actively thinking about it, the object contributes to the environment our attention must process.

The same is true of digital clutter. Unused applications, abandoned repositories, stale documents, unread newsletters, dormant subscriptions, and half-configured services do not merely sit there. They expand the surface area of our lives.

They create more places to search, more systems to remember, more notifications to interpret, more credentials to protect, and more uncertainty about where the current version of something lives.

We often underestimate this because the cost of any individual item is nearly zero. The psychological cost emerges from the total number of unresolved objects and systems competing for a small amount of attention.

Things we own become a source of low-level friction. That friction is rarely dramatic enough to identify as a problem, but it can shape how calm, focused, and capable we feel. An environment does not need to be visibly chaotic to be operationally expensive.

Names Also Have a Cost of Ownership

Not everything we own is physical. Organisations also own concepts, interfaces, terminology, and names.

One of the services I own at work is called Code Scan. It is our managed SonarQube service.

The name is understandable. It describes, in broad terms, something the service does. It is also so generic that it creates problems.

“Code scanning” could mean static analysis, dependency scanning, secret scanning, container scanning, infrastructure-as-code scanning, or several other security activities. As the organisation’s capabilities grow, the name becomes increasingly ambiguous.

The service still works, and the name has not technically failed. Yet every conversation now carries a small translation cost.

People must learn that Code Scan refers specifically to our SonarQube service rather than the wider category of code-scanning tools. Documentation must compensate for the ambiguity. New services must be named around terminology that has already been claimed. The organisation’s mental model becomes slightly harder to understand.

Changing the name now would also have a cost. Documentation would need updating. Integrations might contain references to the old name. People would continue using the previous terminology. For some period, both names would coexist, increasing confusion before eventually reducing it.

This is the cost of ownership applied to language.

Names create interfaces between people and systems. Once adopted, they accumulate dependencies just as software does. A weak name is not merely a branding problem; it is a form of conceptual technical debt. The initial naming decision may take minutes, but the organisation may live with its consequences for years.

Switching Costs Protect Weak Systems

The longer we own something, the more tightly it becomes connected to everything around it.

A desk determines the position of monitors, cables, drawers, and lighting. A software tool accumulates integrations, documentation, permissions, and trained users. A name becomes embedded in meetings, dashboards, repositories, and organisational vocabulary.

These connections increase the cost of change.

That can be useful. Stability has value, and constant replacement is its own form of waste. Switching tools every time something shinier appears produces fragmentation, migration fatigue, and shallow expertise.

But switching costs also protect mediocre systems from competition. An existing solution does not need to remain the best option; it merely needs to be less painful than changing it.

This creates a dangerous asymmetry. The costs of migration are visible and concentrated, while the costs of staying are dispersed and normalised. One appears as a project requiring time, money, and approval. The other appears as another year of small frustrations.

As a result, we often demand overwhelming evidence before replacing something, even though we required far less evidence before adopting it.

The better question is not simply, “Does the current thing still work?” It is, “Knowing what we know now, would we choose this again?”

If the answer is no, continued ownership deserves scrutiny.

Own Fewer Things, but Own Them Deliberately

The obvious conclusion might be that we should own as little as possible. There is some truth in that. Every reduction in possessions, tools, services, and systems reduces the surface area we must maintain. Simplicity creates capacity.

But ownership itself is not the problem. Poorly considered ownership is.

Some things repay their costs many times over. A well-designed tool can eliminate recurring friction. A reliable system can reduce uncertainty. A carefully chosen object can make an activity easier or more enjoyable for years.

The goal is not minimalism for its own sake. It is to maintain a higher standard for what we allow to create ongoing claims on our time and attention.

Before acquiring something, it is worth asking what maintenance it will require, what space it will occupy, and what decisions it will create. We should consider what other options it might discourage us from considering, how difficult it will be to replace or remove, and what dependencies will form around it.

Perhaps the most useful question is this: would I still want to own this if the purchase price were zero, but all the ongoing obligations remained?

These questions are useful for furniture, software, subscriptions, services, processes, and platforms. They apply to almost anything that persists beyond the moment of adoption.

The Cost Continues Until the Thing Is Gone

The true cost of ownership is the sum of all the future attention a thing demands. That includes maintenance, storage, learning, administration, opportunity cost, switching cost, and the subtle friction created by living with something that is almost—but not quite—right.

The initial price is merely the admission fee.

Once we recognise this, a cheaper purchase may no longer look cheaper, and a free tool may no longer look free. Keeping an existing system may no longer appear to be the conservative option.

Sometimes the highest-leverage decision is to buy the better thing from the beginning. Sometimes it is to replace something before it fails, or to rename a system while the change is still manageable. And sometimes it is simply to remove something that has quietly been charging rent in our lives for years.

Design the conditions

Damien Murphy — Sat, 13 Jun 2026 00:00:00 GMT

Environment - an underappreciated lever

We tend to think of our behaviour as the product of deliberate choices. We decide to focus, exercise, write, rest, or become more organised, and then judge ourselves according to whether we follow through.

But much of our behaviour is shaped before we make any conscious decision at all. It is influenced by what is visible, what is nearby, what is easy, what is noisy, what is uncomfortable, and what requires even a small amount of effort. Our physical surroundings, digital tools, defaults, workflows, and social expectations constantly suggest what we should do next.

The environment is rarely neutral. It is always applying pressure in one direction or another.

I have come to believe that consciously designing and managing our environments is one of the highest-leverage activities available to us. Its impact is easy to underestimate because it rarely feels dramatic. A better desk layout, a different default, an improved lighting arrangement, or one fewer step in a workflow does not look like a major intervention.

But its effects are repeated every day.

The Environment Is Already Designing Our Behaviour

Whether we design it intentionally or not, our environment shapes us.

A phone left beside us invites checking. An untidy desk creates a low-level demand for attention. A tool that takes several minutes to configure discourages occasional use. A document buried in a folder hierarchy is less likely to be opened. A room dominated by a television encourages a different set of behaviours from one organised around a desk, books, or exercise equipment.

None of these things forces a particular action. They simply make some actions more likely than others.

That distinction matters because we often look for large explanations for our behaviour when the cause may be a sequence of tiny environmental influences. Each one is too small to seem decisive, but together they create a strong directional pull.

The cumulative effect is similar to the way systems and processes shape organisations. People usually adapt to the incentives, constraints, and defaults around them. If a process makes the right action difficult and the wrong action easy, repeatedly reminding people to make better choices will have limited effect.

The same is true in our personal lives. We adapt to the systems around us, even when we are the ones who created them.

The Path of Least Resistance Usually Wins

Motivation is unreliable. Willpower is finite. Energy and attention vary throughout the day.

A system that only works when we are highly motivated is not a particularly robust system. This is why the path of least resistance matters so much. When we are tired, distracted, or under pressure, we tend to choose the behaviour that requires the least cognitive and physical effort. The environment often determines which behaviour that is.

If writing requires finding a notebook, clearing a table, locating an idea, deciding where to begin, and reconstructing the context of an unfinished piece, the resistance may be enough to prevent it. If a writing application opens directly into an organised list of ideas and active drafts, starting becomes much easier.

If exercise equipment is hidden away, training must first overcome the friction of retrieving and assembling it. If the equipment is visible and ready to use, the threshold is lower. If healthy food requires preparation while a less useful alternative can be eaten immediately, convenience is likely to win.

The lesson is not that people are lazy. It is that friction has a disproportionate effect on repeated behaviour.

The important question is therefore not simply, “How do I become more disciplined?” A better question is, “How do I make the desired behaviour easier to begin and the undesired behaviour slightly less convenient?”

Friction Is a Design Variable

We often treat friction as an unavoidable property of a task. In reality, much of it is designed into our environments, tools, and processes.

Sometimes that design is deliberate. More often, it is accidental.

A login process with several unnecessary steps adds friction. An unclear filing system adds friction. Too many choices add friction. A badly positioned cable adds friction. A cluttered workspace adds friction. A frequently used command that must be reconstructed from memory adds friction.

No individual inconvenience seems important enough to fix. But when it occurs repeatedly, its cost compounds.

This makes friction reduction one of the highest-return and most underestimated forms of improvement. Removing ten seconds from a task performed once is irrelevant. Removing ten seconds, one decision, and one point of irritation from something performed several times a day can meaningfully change whether it happens at all.

The same principle can be used in reverse. Friction can be deliberately added to behaviours we want to discourage. Logging out of a distracting service, moving an application off the home screen, keeping the phone outside the room, or requiring an additional step before making an unnecessary purchase will not make the behaviour impossible. It creates a moment in which an automatic action can become a conscious decision.

Good environmental design does not depend on perfect self-control. It uses small amounts of friction to redirect behaviour.

Environments Communicate Intent

One of the more interesting things I have discovered through experimenting with my own workspace is that an environment can communicate intent without words.

Lighting has been particularly powerful. Different lighting arrangements can make the same room feel oriented towards focused work, reading, conversation, or rest. A bright, directed light near the workstation creates a different psychological signal from softer ambient lighting elsewhere in the room.

The effect is not merely aesthetic. The change helps trigger a different mode.

When I want to focus deeply, I now lean into the environment that supports it. I may change the lighting, reduce what is visible on the desk, close unrelated applications, alter the screen layout, or adjust the physical arrangement around me. The goal is not to manufacture motivation. It is to make the desired mode feel like the natural response to the surroundings.

Over time, these cues become associations. A particular lighting arrangement, application layout, or physical configuration begins to communicate what kind of activity should happen next.

The environment starts doing some of the work of transition.

Designing for Operating Modes

This has helped me understand that I do not simply perform different tasks. I operate in different modes.

My work typically spans design, architecture, delivery, documentation, collaboration, operations, and strategy. These activities may all take place at the same workstation, sometimes within the same hour, but each requires a different posture, pace, level of attention, and tolerance for interruption.

Design work is exploratory. Architecture requires systems thinking and sustained attention across multiple levels of abstraction. Delivery is more concrete and execution-oriented. Documentation requires clarity and empathy for a future reader. Collaboration depends on responsiveness and communication. Operational work may demand urgency, diagnosis, and precision. Strategic work requires stepping back from immediate tasks to examine direction, constraints, and second-order effects.

Moving between these modes has a cost. It is not only the time spent changing applications or opening different documents. There is also a cognitive transition cost: releasing one mental model, loading another, and adapting to a different type of thinking.

When the environment remains unchanged, the mind receives little indication that the operating mode has shifted. The same screen, lighting, browser tabs, notifications, and physical posture continue to signal the previous activity.

Small environmental changes can make that transition easier. A different lighting arrangement, screen layout, application set, physical position, or level of ambient stimulation can act as a deliberate boundary. The environment becomes a kind of interface for switching mental context, helping the mind recognise what kind of work is now expected.

For someone whose work crosses many domains, this is not cosmetic. Reducing the friction between operating modes can materially improve focus, clarity, and effectiveness.

Many Productivity Problems Are Transition Problems

We often assume that a failure to focus is a failure of discipline. Sometimes the deeper problem is that we have not completed the transition from one mode to another.

We know what we intend to do, but the environment continues signalling the previous activity. The browser remains full of unrelated tabs. Communication tools remain open. The desk contains reminders of several competing responsibilities. The lighting and physical posture remain unchanged. The mind receives no clear signal that the context has shifted.

This is particularly difficult when the previous mode was highly stimulating or reactive. Moving directly from an operational incident, a sequence of meetings, or a stream of messages into deep architectural thinking is not a simple task switch. It is a transition between fundamentally different cognitive states.

A deliberate environmental transition can act as a boundary. Closing applications, changing lighting, clearing the desk, moving to another position, taking a short walk, or opening a specific workspace configuration can help terminate one mode before beginning another.

The value is not in any individual ritual. It is in creating a repeatable signal that one context has ended and another has begun.

Physical and Digital Environments Are the Same System

It is tempting to think of environment design primarily as interior design: furniture, lighting, storage, and room layout.

Those things matter, but our digital environment now shapes just as much of our behaviour as the physical one. Our home screens, folder structures, notification settings, browser tabs, default applications, templates, shortcuts, and automation rules all influence what we notice and what we do next.

A digital workspace can be cluttered in exactly the same way as a physical desk. It can present too many competing signals, hide important work, create repeated micro-decisions, and keep us tethered to an operating mode we are trying to leave.

The most useful digital systems tend to make the correct next action obvious. They reduce the number of places where something might be stored. They preserve context. They automate routine transitions. They expose important information at the moment it becomes useful and hide it when it does not.

A good environment does not merely contain the tools required for a task. It helps carry the user into the task.

This also means that physical and digital environments should not be designed independently. The workstation, lighting, applications, notification state, file organisation, and automation all form a single behavioural system. Improving one part while ignoring the others can leave much of the friction intact.

Design for the Version of You That Actually Appears

Environmental design becomes especially valuable when it accounts for reality rather than aspiration.

It is easy to design systems for the ideal version of ourselves: fully rested, highly motivated, patient, and attentive. That version of us may use a complicated workflow correctly, maintain a perfectly organised environment, and make the optimal decision every time.

But the environment matters most on the days when that version does not appear.

A durable system should work when energy is low, attention is fragmented, and motivation is absent. It should minimise the number of decisions required to begin and make recovery easy when the system has not been maintained perfectly.

This is similar to designing reliable software. We do not build only for the happy path. We consider failure modes, degraded conditions, limited capacity, and the behaviour of the system under pressure.

Our personal environments deserve the same level of realism.

The question is not whether a system works when everything is going well. The question is what behaviour it encourages when we are tired, distracted, interrupted, or overwhelmed.

The Goal Is Not Perfect Optimisation

There is a risk of turning environmental design into another endless optimisation project.

The purpose is not to create a perfectly controlled space where every object, light, and application has been engineered to produce a measurable behaviour. Nor is it to avoid ever relying on discipline or conscious choice.

The purpose is to create a reliable bias.

A well-designed environment gently increases the likelihood of useful actions and decreases the likelihood of unhelpful ones. It does not eliminate agency. It supports it.

The highest-value changes are often surprisingly mundane: placing something where it will be used, removing an unnecessary decision, improving the lighting, creating a template, keeping a tool ready, silencing an interruption, preserving context, or making the next step visible.

These changes rarely transform a life overnight. They shape hundreds of small decisions that accumulate into something much larger.

The most effective environmental design is also likely to remain flexible. Our work changes, our priorities change, and the modes we need to support change. The aim should not be to create one permanent, perfectly optimised configuration, but an environment that can be adapted deliberately as our needs evolve.

Design the Conditions, Not Just the Goal

We often begin with the outcome we want.

We want to write more, train consistently, think clearly, sleep better, produce higher-quality work, or spend less time distracted. We define the goal and then try to push ourselves towards it.

But goals describe the destination. They do not create the conditions that make movement likely.

A more useful approach is to examine the environment surrounding the behaviour. What is currently easiest? What is visible? What repeatedly interrupts? Where does the process stall? Which decisions must be made every time? What atmosphere supports the desired mode? What friction could be removed, and where could friction be added?

For work that spans several domains, we can also ask a more specific set of questions. What signals that I am entering design mode rather than delivery mode? How do I close an operational context before beginning strategic work? Which parts of my environment help me think clearly, and which keep me reactive? What configuration supports the type of person I need to be for the work in front of me?

The answers are usually less inspiring than a new goal, but they are often more consequential.

We are shaped by the environments we repeatedly inhabit. Leaving that process entirely to chance means accepting whatever behaviours those environments happen to produce.

Designing them deliberately gives us a quiet but persistent form of leverage. Instead of constantly forcing ourselves to behave differently, we can build surroundings that make different behaviour feel more natural.

Personal systems are production systems

Damien Murphy — Sat, 06 Jun 2026 00:00:00 GMT

Treat Personal Systems Like Production

One of the unexpected things I've learned from software engineering is that the best personal systems often look remarkably similar to production systems. Not because life should become over-engineered, but because good systems solve the same kinds of problems regardless of the domain. They reduce friction, make progress visible, remove unnecessary decisions, and make consistent execution easier than relying on motivation alone.

I recently rebuilt the way I write. Not by searching for another note-taking application or the latest AI tool, but by asking a different question:

If this were a production system, how would I design it?

The answer wasn't a folder full of Markdown files. It was a pipeline.

Every Piece of Work Has a State

In software engineering, work moves through well-defined states. A feature begins as an idea, becomes a design, turns into code, passes review, reaches production, and is eventually retired. At any point, everyone involved knows exactly where it is and what needs to happen next.

Writing isn't fundamentally different.

Ideas don't become published articles in one leap. They evolve through recognisable stages, each requiring a different kind of thinking. My own workflow now looks like this:

Seed Tray
    ↓
0-Seeds
    ↓
1-Growing
    ↓
2-Drafts
    ↓
3-Published

Each stage has a single purpose. The Seed Tray captures ideas before they're forgotten. Seeds test whether an idea is worth developing. Growing articles collect research, stories and supporting arguments. Drafts become complete pieces, and Published contains only work that is ready for the world.

Nothing is ambiguous because every article has exactly one home.

Separate Thinking From Editing

For years I made the same mistake every time I sat down to write. I'd begin drafting, immediately rewrite the opening paragraph, stop to research a supporting point, rethink the title, question whether the idea was any good, and eventually close the document feeling like I'd accomplished very little.

The problem wasn't a lack of discipline. The problem was trying to perform completely different kinds of thinking at the same time.

Software teams don't design, implement, test and deploy simultaneously. Each phase demands a different mindset, and trying to combine them usually creates unnecessary friction. Writing follows the same pattern. Capturing ideas requires speed. Developing arguments requires curiosity. Editing requires criticism. Publishing requires confidence.

Those modes don't complement one another—they compete. Separating them makes each one easier.

Every Stage Has One Job

One lesson I've come to appreciate is that the best systems become almost mundane. Once they're established, they fade into the background. You stop thinking about the system itself because it quietly guides the work without demanding your attention.

Each stage in my writing pipeline has exactly one responsibility. The Seed Tray captures. Seeds clarify. Growing expands. Drafts refine. Published ships.

There are no grey areas and no "almost finished" folders full of forgotten work.

That means when I sit down to write, I don't spend time deciding what to do next. I simply look at the pipeline, see where each piece of work currently lives, and choose something appropriate for the time and energy I have available.

The system doesn't make the work easier. Writing is still hard. Thinking is still hard. What it does is remove unnecessary friction. The next step becomes obvious, leaving more attention available for the work itself.

The best systems rarely demand recognition. Like good infrastructure, they're quiet, dependable and almost invisible until the moment they're missing.

Automate the Routine

Production systems automate routine work because we cannot rely on consistent execution of tasks when they are performed manually. We automate deployments, backups and testing not because they're difficult, but because they shouldn't depend on someone remembering to perform them or perform them correctly.

Publishing shouldn't be any different.

When an article reaches my 3-Published directory and I push the repository, a GitHub Actions workflow takes over. It synchronises the published articles into my blog repository, commits any changes, pushes them, and triggers the site deployment automatically.

The writing repository manages content. The blog repository manages presentation and deployment.

Each system has a single responsibility. That's exactly how I'd design a software platform, so it made sense to design my writing workflow the same way.

Build Systems That Reduce Decisions

The biggest benefit hasn't actually been automation. It's the reduction in cognitive load.

I no longer decide where a file belongs. I don't wonder whether an article is finished. I don't need to remember how publishing works. The workflow answers those questions for me before I even have to think about them.

Every unnecessary decision removed is attention I can spend on the work itself. That's what good engineering has always been about—not replacing human judgement, but protecting it for the places where it creates the most value.

The more decisions a system can make consistently on my behalf, the more of my attention remains available for the decisions that actually matter.

The Pattern Is Much Bigger Than Writing

The more I've thought about it, the more I've realised this isn't really a post about writing at all.

The same pattern appears everywhere. Fitness becomes easier when training follows a progression rather than daily inspiration. Learning improves when ideas move through stages of capture, understanding and application. Projects become more manageable when work has explicit states instead of living inside one enormous to-do list.

Even personal goals become easier to pursue when they're supported by systems rather than dependent on motivation.

Production systems aren't successful because they're sophisticated. They're successful because they make the right thing the easy thing. They reduce uncertainty, make progress visible, remove unnecessary decisions, and allow people to focus on the work that requires human judgement.

Our personal systems deserve the same treatment. Not because every hobby needs to become an engineering project, but because thoughtfully designed systems create more space for the work that only we can do.

The irony is that the better these systems become, the less we notice them. They quietly disappear into the background, leaving us with fewer decisions, less friction and more opportunity to do meaningful work.

To me, that's what treating your personal systems like production systems is really about.

Engineer for Durability

Damien Murphy — Thu, 28 May 2026 00:00:00 GMT

Designing for sustained success

Every system has a breaking point.

Software fails. Teams fail. Companies fail. Bodies fail. People fail.

Given enough pressure—or simply the wrong combination of pressures at the wrong time—everything eventually reaches its limit.

As engineers, we accept this instinctively. We design around failure rather than pretending it will never happen. We replicate critical data, monitor constrained resources, remove single points of failure, and plan for recovery.

Yet when it comes to our careers, our health, or our personal lives, we often behave as though success depends on avoiding failure altogether.

I’ve come to believe the opposite.

The objective is not to become unbreakable. No system is. The objective is to become difficult to break, capable of operating under imperfect conditions, and able to recover when failure does occur.

Long-term success depends less on permanent peak performance than on durability.

Peak performance is a poor long-term strategy

We celebrate exceptional performances because they are memorable.

The engineer who rescues a production outage at three in the morning. The athlete who produces a moment of genius in the dying minutes of a final. The startup that appears to grow overnight.

These stories are compelling precisely because they are unusual.

But they are poor models for sustained success.

Over decades, few careers are defined by isolated moments of brilliance. They are shaped by the accumulation of thousands of ordinary days on which good work was delivered reliably.

One remarkable week may create an opportunity. Ten years of dependable execution changes which opportunities become available.

Brilliance gets attention. Consistency earns trust.

Consistency is an emergent property

We often talk about consistency as though it is a personality trait.

Some people are disciplined. Some are motivated. Some simply possess the willpower to keep going.

I don’t think that explains very much.

Consistency is what durability looks like from the outside.

When someone performs reliably over a long period, what we are usually seeing is not extraordinary willpower. We are seeing a collection of systems that do not fail easily.

Their environment supports good decisions. Their routines absorb disruption. Their workload contains margin. Their habits are simple enough to survive stressful weeks instead of collapsing at the first sign of pressure.

They have engineered reliability into their lives in much the same way we would engineer reliability into a production service.

Consistency is rarely created at the moment action is required. It is created earlier, through the design of the system.

Know your capacity

Every system has constraints.

A database saturates. A queue backs up. Memory fills. A CPU reaches one hundred percent utilisation.

These limits are not failures in themselves. They are simply characteristics of the system.

The real failure is often discovering them for the first time under production load.

People are no different.

We all have cognitive, emotional, physical, and social limits. We each have conditions under which our judgement deteriorates, our patience disappears, or our discipline becomes unreliable.

The problem is not that these limits exist. The problem is pretending they do not.

A system operating near capacity becomes fragile. Minor interruptions have disproportionate consequences. Work begins to queue. Recovery slows. Eventually, something that would have been manageable under normal conditions becomes enough to cause failure.

The same pattern appears in people.

When sleep is poor, workload is excessive, finances are strained, relationships are neglected, and every hour is already committed, even a small disruption can become overwhelming.

Without margin, everything becomes a critical dependency.

Understanding your own capacity is therefore not an admission of weakness. It is basic operational awareness.

If you do not identify your bottlenecks, life will eventually benchmark them for you.

Durability must be designed

Good engineering rarely depends on optimism.

We do not assume disks will never fail, so we replicate data. We do not hope services remain healthy, so we monitor them. We do not rely on a single machine remaining available forever, so we design for graceful degradation and recovery.

Durability begins with acknowledging reality.

The same principle applies outside software.

Sleep is recovery capacity. Financial savings are redundancy. Strong relationships provide resilience during periods of stress. Good documentation protects against imperfect memory. Simple routines reduce the number of decisions required when mental bandwidth is already limited.

None of these things are especially glamorous.

Neither is wearing a seatbelt.

Their value becomes obvious on the day they are needed.

Durability is not about tolerating unlimited pressure. A durable system does not simply endure whatever load is placed upon it.

It detects strain. It sheds unnecessary work. It degrades gracefully. It protects critical functions and creates space for recovery.

The goal is not to withstand everything.

It is to prevent temporary pressure from becoming permanent damage.

Compounding rewards those who remain

Compounding is one of the most powerful forces we know, yet we often discuss it only in financial terms.

Experience compounds. Trust compounds. Knowledge compounds. Relationships compound. Reputation compounds.

But compounding has one uncompromising prerequisite:

You have to stay in the game.

Burnout interrupts compounding. Injury interrupts compounding. Chronic stress interrupts compounding. Repeatedly rebuilding after preventable collapse interrupts compounding.

Over a long enough period, sustainable output has an enormous advantage over cycles of brilliance and exhaustion.

The person who can continue producing good work year after year remains available for the next project, the next relationship, the next idea, and the next opportunity.

Their advantage is not merely that they worked for longer. It is that everything they built previously remained intact and continued to accumulate.

Durability protects compounding.

Be standing when the moment arrives

Sport keeps teaching the same lesson.

Some of the most gifted teams I have followed produced breathtaking moments of skill. They dominated possession, created spectacular passages of play, and looked capable of beating anyone on their day.

Too often, they still lost.

Not always to more talented opponents, but to teams that remained organised, absorbed pressure, and continued executing their fundamentals for the full eighty or ninety minutes.

They did not need to produce brilliance continuously. They needed to remain in the contest long enough for an opportunity to appear.

The spectacular moment is often not the cause of victory. It is the reward for everything that allowed the team to still be standing when the moment arrived.

Engineer for durability

Perhaps we ask ourselves the wrong question.

Instead of asking:

How can I perform at my absolute best?

We might ask:

What repeatedly causes me to break?

That is an engineering problem.

It means identifying failure modes, understanding capacity limits, removing single points of failure, reducing unnecessary complexity, building in margin, and creating recovery paths.

It means designing for imperfect days rather than depending on perfect ones.

The aim is not to eliminate failure. It is to contain it, recover from it, and prevent it from ending the process of compounding.

Because over the long run, the greatest advantage may not belong to the person capable of the highest peak.

It may belong to the one who can keep going.