Layer Notes

Two Operating Modes

Wed, 02 Sep 2026 00:00:00 GMT

I did not set out to run a company. I set out to build software, and then the software needed a company around it, and then the company needed someone to run it, and the room was empty.

Nobody warns you that these are two different modes of thinking, and that you will be expected to switch between them several times a day.

Mode one: the engineer

The engineer’s instinct is to find the correct answer.

Not a good answer. The correct one. There is a right data model, a right boundary, a right failure mode. Ambiguity is a bug in the requirements, and the fix is more information.

This instinct is excellent. It is why systems stay up. It is also why an engineer, handed a business question, will try to gather enough information to make the answer obvious — and will keep gathering, because the answer is never going to become obvious.

Mode two: the operator

Business problems do not have correct answers. They have decisions with different failure modes.

Should we take this customer? Should we hold this much inventory? Should we hire now or in three months? There is no test suite. You will not find out whether you were right for a year, and by then six other variables will have moved, so you will never be able to attribute it cleanly anyway.

The engineer’s response to this is to want more data. The operator’s response is to ask a different question: if this is wrong, how bad is it, and can we find out cheaply?

That reframing was the single most useful thing I learned. It is the business version of “make it observable.”

What actually transfers

The good news is that most engineering instincts survive the switch, if you translate them.

Systems thinking transfers completely. A company is a system with queues, bottlenecks, and feedback loops. If you have debugged a distributed system, you already have the right intuitions for why a team is slow. The bottleneck is rarely where people are complaining.

Interfaces transfer. A badly defined responsibility between two teams behaves exactly like a badly defined API between two services: everything looks fine until load arrives, and then nobody owns the failure.

Observability transfers. “We think sales are fine” is console.log debugging for a business.

Reversibility transfers. Engineers already sort changes into “easy to roll back” and “not”. That is the most valuable prioritisation tool in business and almost nobody outside engineering frames it that way.

What does not transfer

Determinism. The same input does not produce the same output, because the input includes people.

Refactoring. You cannot pause a company to clean up its architecture. Every restructure ships to production while it is running, with no staging environment and no rollback.

Edge cases. In a codebase, edge cases are finite and you can enumerate them. In a company they are generated continuously by reality, and reality is not going to stop to let you handle them. Companies have considerably more edge cases than codebases.

Switching

The honest part: I do not switch modes cleanly.

I have caught myself in a supplier negotiation thinking about retry semantics, and in an architecture review thinking about unit economics. Sometimes that cross-wiring is exactly the useful thing. Sometimes it means I have spent forty minutes optimising something that does not matter.

Mode switching is automatic and occasionally unstable. I have stopped trying to fix that and started treating it as the actual job.

Explore → Understand → Build

Tue, 01 Sep 2026 00:00:00 GMT

Every interesting thing I have built started the same way: I saw something, did not understand it, and refused to leave it alone.

That is the whole method. Three steps, run in order, repeatedly.

Explore

Go where the information actually is.

For software, that is documentation, source code, and the issue tracker where somebody has already hit your problem and given up. For hardware and physical products, it is showrooms, exhibitions, factories, and people who make things for a living. For a market, it is customers who are currently solving the problem badly with a spreadsheet.

What matters is that exploration has to be physical often enough to stay honest. Catalogues and landing pages describe products the way they were meant to be. The interesting details — what breaks, what is actually in stock, what the real minimum order is, what everyone quietly works around — do not make it into the PDF.

Understand

This is the step everybody skips, and it is the one that pays.

Understanding is not “I read the spec sheet.” It is being able to explain why a thing is built the way it is, what it costs, what it cannot do, and what would have to change for that to be different.

A worked example, without naming anyone: two products can look identical in a listing and differ by 4x in price. The gap is never mysterious. It is a component, a tolerance, a certification, a volume commitment, or somebody’s margin. If you cannot name which one, you do not understand the product yet — and you are about to make a purchasing decision on vibes.

The uncomfortable version of this rule: if you cannot explain why the cheap one is cheap, you are the reason it sells.

Build

Only now.

Building before understanding produces something that works in the demo and dies on contact with a real user, a real warehouse, or a real supplier lead time. I have shipped that thing. More than once.

Building after understanding is boring in the best way. You already know where the hard parts are, because you went and looked.

Where the value hides: arbitrage

Here is the pattern worth naming.

Technology has wildly different value depending on where it lands. A component that is unremarkable in one market — mature, commoditised, boring, competing on price — can be genuinely useful somewhere it has not arrived yet. Not because anyone is behind, but because the problem it solves has not been connected to the thing that solves it.

That gap is technology arbitrage: finding useful technology somewhere and figuring out where it actually creates value somewhere else.

It is not clever. It requires no invention. It requires being in two places, understanding both, and noticing.

The catch is that it only works after the middle step. Arbitrage without understanding is just importing things and hoping. Plenty of people are doing that, and their warehouses are full.

The loop

Explore → Understand → Build → and then, because building always exposes what you missed, Explore again.

That is it. It is not a strategy. It is closer to a personality trait that I have decided to be organised about.

Most of what appears on this site will be some point in that loop, written down before I forget the details.

Build things. Explore ideas. Chase snow. Repeat.

Mon, 31 Aug 2026 00:00:00 GMT

I have been meaning to write things down for about a decade. This is the part where I finally start.

Not because the internet needs another founder blog. Mostly because I keep learning things, telling three people about them, and then forgetting the details six months later. Writing is the cheapest storage I have found for that.

What this is

A workshop, not a résumé.

My CV lives on LinkedIn and it is fine. It says I was an engineer, then a senior engineer, then a lead, and then somehow a CEO. All true, all deeply boring as a description of what I actually do on a Tuesday.

What I actually do on a Tuesday is closer to this: read something, get suspicious about how it works, take it apart, find out it is more complicated than advertised, and then wonder whether the complicated part is a business.

The four modes

Looking back at how I spend time, it sorts into four buckets. Not a framework. Just an honest description.

BUILD. Products, software, companies, experiments. The default. Most weeks live here.

THINK. Technology, product strategy, business models, systems. The part where I work out whether the thing I want to build should exist.

EXPLORE. Factories, suppliers, trade shows, new technology, rabbit holes. The input side. Nothing worth building comes out of a room with no windows.

LIVE. Snowboarding, Japan, travel, food, the parts of life that have no roadmap. Also the part that keeps the other three from eating everything.

They are not phases. They run concurrently and interrupt each other constantly, usually at inconvenient times.

What I will write about

Things I actually investigated. Which means:

Notes from building software and running companies, including the parts that did not work
Technology I took apart — AI, RFID, computer vision, IoT, hardware, automation
What happens when a software person discovers warehouses, suppliers and shipping
Field notes from travelling, which for me is usually half business and half snow

I am not going to pretend to be an expert on any country, industry or technology. These are field notes. The value is in the specifics, not the conclusions.

What I will not write about

Growth hacks. Morning routines. Ten lessons from my journey.

If you are here for that, I am afraid this is going to be disappointing.

More soon. Some of it will be about snow.