TrenchOps 🐎

What Nobody Warns You About Before Your First Invoice

Thu, 08 Oct 2026 10:00:52 +0200

Three things kill small businesses that never appear in a business plan: the room you work in, the stories you absorb, and the money that was never yours.

I have been self-employed a few times. Before my enterprise career, between two of them, and on the side. None of it made me rich. All of it taught me things you cannot learn from a startup podcast, because podcasts talk about scaling and my problem was that a customer's dog did not like me.

Let me hand over the three lessons that actually cost me something

Your business has a physical address, even when you think it doesn't

Everyone starts in the bedroom, the garage or the study. Fine. Nobody plans the other rooms.

One of my ventures was classic IT service. Persuading stubborn printers to acknowledge the existence of WiFi. Removing pre-installed bloat from our favorite corporate operating system. Explaining, for the fourth time, that a tablet needs updates. Mostly on-site, at people's homes.

Some clients objected to travel fees. Reasonable. They wanted to come to me. Slight problem: I had no office and no presentable workshop. So I invited them into my dining room - statistically the least private room in the house, right up until a stranger sits in it holding a coffee cup and telling me about his divorce while I diagnose a random reboot.

Fun fact from cognitive load research that every engineer already knows in their bones: deep debugging and polite listening cannot run on the same core. You either find the faulty power supply or you learn about the neighbor's inheritance dispute. Never both.

Then came the subset. Rude, unclean, or simply radiating a vibe that made me want to change the locks. That was the end of visitors. Strict on-site only, take it or leave it. I considered converting the garage. I considered a container office. Neither ever happened, because it was never worth the cost for a minority of customers - and that is exactly the trap. The expense is easy to justify and easy to postpone forever.

The same applies if you make things. During the pandemic, everyone discovered handmade marketplaces, to the point where the market now looks like a craft fair with more sellers than buyers. You will need space for the inventory you sell. You will need more space for the inventory you never sell. And while you are planning shelf space, plan something else too: how you will emotionally process cutting your price below your material cost for an object that took you six hours of your finite life.

👉 Before the first customer: decide where money, goods and strangers physically meet. That decision is a business decision, not a furniture decision.

You will be paid in cash and in other people's grief

I am read as a stoic person. Reasonably accurate. I can understand somebody's pain without soaking it up like kitchen roll, which I always considered a professional advantage.

So I assumed I could handle what clients volunteer while you sit in their living room. Illnesses. Losses. Ruined lives. And initially, I could.

What I underestimated was the second-order effect. I kept wanting to tell my wife about it. Not as drama - just as "you would not believe what I learned about human beings today." Turns out I was the messenger, and she was absorbing what I was merely transporting. We had the talk. My license as gossip correspondent was revoked, correctly.

Then, holding it all myself, it started to weigh. There were customers who were lovely by every measurable standard, and I stopped wanting to drive there. Widows. Parents who had buried a child. People whose existence collapsed after a diagnosis. Nothing to win, one hour of billable work, and a long silent drive home.

So I declared a no-small-talk policy. It survived approximately one appointment. Because pushing back on a lonely person mid-sentence makes you the cold, rude technician - which is both unpleasant and bad for business. And sometimes, honestly, the stories were fascinating. That is the sneaky part: curiosity gets you in, and the sadness stays.

A colleague with an actual shop looked at me like I had described a self-inflicted wound. His customers walked in, handed over a laptop, walked out, came back later. Purely transactional. His counter was not furniture either. It was an emotional firewall that also happened to sell cables.

And the last realization was the one that broke my pricing: some clients were not hiring a technician. They were hiring human company. Especially elderly ladies, whose laptop mysteriously needed rescuing for the third time that month. Once you understand that, charging the full hourly rate becomes an ethics exam you did not sign up for.

👉 If your work takes you into other people's homes, or brings them into yours, you are in an emotional-labor business that happens to involve technology. Price it, or shield it with a counter, a shop, a workshop - something with a door.

Also budget for the unglamorous risks: dogs with opinions, apartments you want to shower after, and the rare genuinely bad human being.

Half of every invoice was never your money

This is the one nobody gets right, including people with an accountant and a lawyer. I had both.

Your private bank account is free. Your business account is not. Tax notices arrive from institutions you did not know existed. You will refund a customer. You will break something and pay for it. Insurance, repairs, tools, marketing material, professional fees, the association nobody told you was mandatory.

So I started doing something almost aggressively simple: 50% of every invoice went straight into a separate pot and stayed there until year end. Taxes, surprises, apologies. Whatever remained afterwards was profit, and it felt like a gift.

The point is not the percentage - yours depends on your country, your legal form and your accountant. The point is that revenue is a number that lies, and the pot does not. For the first time, I knew what I actually earned per hour instead of what my invoices claimed. Several jobs I was proud of turned out to be expensive hobbies with a customer attached.

Self-employment does not fail because your idea was bad. It fails because you priced the work and forgot to price the room, the emotions and the taxman - and all three of them invoice you anyway.

👇 What was the cost item that ambushed you in your first year - and would you have believed anyone who warned you?

Your Brain Doesn't Learn From Success

Wed, 07 Oct 2026 09:00:33 +0200

It Learns From Being Wrong

I once watched a senior engineer - twenty years of experience, could read a stack trace like a bedtime story - try to learn to juggle at a company offsite. Three balls, two hands, zero dignity. She dropped everything for twenty minutes straight while interns filmed it.

Six months later she told me that offsite was the week she finally cracked a certification she'd been stuck on for a year. She was convinced it was the juggling. She might have been right.

Here's the mechanism, and it's backwards from what most people believe: the adult brain doesn't rewire because you feed it information. It rewires because you feed it errors. When your predictions about the world fail hard and repeatedly, your nervous system releases the neuromodulators - dopamine, norepinephrine - that mark active circuits for change. No errors, no chemical signal, no rewiring. Recent neuroscience even points to a dedicated brain-wide "model failure" alarm system (the locus coeruleus) whose whole job is shouting "your predictions are garbage, update everything."

That feeling of frustration? That's not a bug. That's the smell of the signal being released. The brain games industry sells you comfortable puzzles you're already decent at. Comfortable means low error rate. Low error rate means the alarm never fires. You're paying a subscription to not learn.

There's a catch: the frustration only works if you stay in it. Huberman's summary of the research is blunt - if you hit frustration and lean in for another stretch of failed attempts, you've opened the plasticity window. If you hit frustration and walk away, the same window rewires you toward whatever comes next, which is usually doomscrolling and resentment. Frustration is a loaded weapon. Direction matters.

This is why the best engineers I've worked with all share one weird trait: they are suspiciously calm while being wrong. Not because they enjoy it, but because somewhere along the way they learned that "this doesn't work and I don't know why" is the productive state, not the failure state. The junior who rage-closes the laptop and the senior who mutters "interesting" at the same error message are running completely different neurochemistry.

👉 Errors, not information, trigger rewiring. Reading about a skill produces near-zero plasticity. Failing at it produces the chemical cascade.
👉 Short bouts beat marathons. The research says roughly 7-30 focused minutes of deliberate error-making, then stop before you start adding new categories of mistakes.
👉 Stakes gate the speed. The brain allocates plasticity by importance. A skill you genuinely need rewires faster than a hobby you're dabbling in. Give yourself a real reason.
👉 Frustration is a fork in the road. Push through: you learn. Walk away: the open window learns your escape behavior instead.
👉 Pick something you're bad at on purpose. Zero talent means maximum error rate means maximum signal. Your ego pays, your cortex collects.

Competence is comfortable. Comfort is neurologically silent. If nothing about your week embarrassed you, nothing about your brain changed either.

👇 What's the last skill that made you feel like a complete beginner - and did you push through or quietly retreat to things you're already good at?

This article is also available in German.

The Strategy That Never Won a Single Match - And Won Everything

Tue, 06 Oct 2026 08:00:42 +0200

What a 1980 computer tournament explains about your worst customer, your dumbest feud, and your exit interviews

Around 1980, a political scientist ran a tournament for computer programs playing the iterated Prisoner's Dilemma. Game theorists, mathematicians, economists, the whole intellectual heavyweight class, submitted strategies. Some were baroque: probabilistic betrayal, opponent profiling, deception layers built to squeeze a few extra points out of the naive.

The winner was a handful of lines of code, submitted by a mathematical psychologist. Cooperate on move one. After that, do whatever the other player just did. That's it. Tit For Tat. Shortest entry in the field. It won again in the second tournament, where everybody already knew it was coming and had specifically designed strategies to beat it.

Here is the detail people always skip: Tit For Tat never won a single individual match. It cannot. By construction it can never score more points than its opponent, because it only ever defects in response. The best possible outcome against any given opponent is a tie.

It won the tournament by being the strategy that everyone did well against, including itself.

Read that twice if you measure your quarter in individual wins.

The three losing strategies, in office dress

Always defect. Takes credit upward, distributes blame downward. Wins spectacularly early. In tournaments it dies, because nasty strategies also meet each other, and then they starve together. In companies it survives longer than it should, because every reorg supplies fresh unmet victims. It's a strategy that only works with high player turnover, which explains a great deal about companies with high turnover.
Always cooperate. The nicest engineer on the team. Absorbs every emergency, never says no, gets farmed by exactly the people you'd predict, and is quietly gone in eighteen months. Unconditional kindness is not a strategy. It's a resource for other people's strategies.
Grim trigger. Cooperate until the first betrayal, then defect forever. The senior architect who was overruled once in a design review three years ago and has been passive-aggressively correct ever since. Locally satisfying. Globally catastrophic.

Tit For Tat wins because it is four things simultaneously:

nice (never defects first)
retaliating (defection costs something, immediately)
forgiving (one clean move restores trust)
clear (the opponent can figure out the rules in a single round).

Clarity is the underrated one. Complicated retaliation policies get read as mood swings instead of boundaries.

The customer everyone had labelled hostile

I once inherited an account that internal folklore described as hostile. The customer's technical lead had a reputation. Escalated everything. CC'd executives with the enthusiasm of a man who had discovered the address book. Called our service level agreement "creative fiction." Two account managers had quietly rotated off before me.

I spent an afternoon reading ticket history before my first call. What I found was not a difficult human. What I found was eighteen months of small defections from our side. A promised callback that never happened. A bug marked "fixed" in a release note where it demonstrably wasn't. A workaround that was really a distraction delivered with a straight face.

He wasn't hostile. He was mirroring. He had opened with trust roughly a year and a half earlier, got defected on, and was now running the algorithm exactly as specified. From where he sat, he was the cooperative player being perfectly reasonable about a pattern.

So I did the only thing the model permits. Cooperate first, visibly, and make it cheap to verify. One promise per week, small, kept. When we couldn't fix something, I said so and gave a date for the next honest update instead of a fake date for the fix. I stopped forwarding optimism upward, and stopped forwarding it downward too.

Six weeks. Not because he was stubborn, but because trust in an iterated game rebuilds at precisely the same rate it was destroyed: one move at a time. There is no bulk import.

By month four he was pre-filtering his own team's tickets before sending them to us, because he had concluded we were worth not wasting. That is what a cooperating opponent looks like. Free labor, volunteered, because the payoff matrix finally rewarded it.

The flaw that runs your company's oldest feud

Pure Tit For Tat has a fatal weakness, and it's the real reason this article exists.

Two Tit For Tat players in a noisy environment - where a move can be misread - lock into a death spiral. One accidental defection, one dropped ticket, one email that lands colder than intended, and the two of them alternate punishment forever. Both worse off. Both behaving correctly. Neither wrong about the last move.

Now look around your office. That is the entire mechanism behind every long-running war between two departments who no longer remember what started it. Engineering thinks support dumps garbage tickets. Support thinks engineering ignores them. Both are retaliating for something that happened in a previous fiscal year, and both are factually right about the most recent exchange.

Corporate life is a maximally noisy channel. Chat, timezones, translation layers, middle managers helpfully rephrasing things into their opposite. If your policy is strict reciprocity with zero slack, you will end up in feuds with people who were on your side. That isn't integrity. It's a signal processing failure.

The fix from the later research is almost insulting in its simplicity: forgive occasionally without being provoked into it. Not always, not never - a small, deliberate rate, something like one in ten. Cooperate even when the last move was a defection. That single modification breaks the spiral and beats strict mirroring wherever information is imperfect.

Information in your company is imperfect. Permanently. So the optimal human strategy is not an eye for an eye. It's an eye for an eye, with a budgeted error allowance for grace.

That budget is not softness. It's the maintenance cost of a system you intend to keep using.

Why everything goes wrong on the way out

The second thing the theory tells you, and nobody puts on a slide: if both players know the game is finite, the logic unravels backwards from the last round. No retaliation is possible after the final move, so defect there. Which makes the second to last move effectively final. And so on, all the way back.

This is why almost every unpleasant surprise in business happens at the exit. The vendor whose quality collapses in the last quarter of the contract. The employee who has already signed elsewhere and stops caring. The customer who suddenly disputes twelve months of invoices in week two of the notice period. The manager who becomes honest with you only in the exit interview, which is the corporate equivalent of confessing to an empty room.

Nobody became a worse person. The horizon just became visible.

Two consequences. Keep the game long and visibly repeated, because reputation only has value when there is a next round. And when the horizon genuinely is finite - offboarding, contract end, a vendor you're replacing - stop expecting reciprocity to carry the load and switch to structure. Milestones, retained payments, handover checklists signed before the final salary run. Not cynicism. Arithmetic.

The best hire I ever made came out of the opposite move. A power horse 🐎 who had been treated as always-cooperate by three previous employers, underpaid accordingly, visibly braced for the usual. I opened with trust I hadn't earned yet: real budget, real authority, no probation theater. Cooperation came back on the first round and compounded for years. Cost of the move: the risk of being wrong once.

👉 Open cooperative. Every time, with everyone. The downside of one betrayal is small; the upside of a compounding relationship isn't.

👉 Retaliate fast and proportionally, then stop. A defection you swallow silently teaches the other side that defection is free. Delayed punishment reads as mood, not consequence.

👉 Be legible. The strategy won because opponents could predict it. If people can't model you, they can't cooperate with you - they can only hedge against you.

👉 Budget forgiveness before you need it. Decide in advance that roughly every tenth insult is noise, not malice. You'll be right most of the time and you'll save relationships pure logic would have incinerated.

👉 Never play to win the individual round. The strategy that couldn't beat anybody beat everybody. Your quarterly hero metric is scoring the wrong game.

👉 Check who defected first before labelling someone difficult. Read the last eighteen months of history. It's usually your own company in the log.

👉 When the horizon becomes finite, replace trust with structure - before the last round, not during it.

The most sophisticated players in the room lost to four lines of logic, because complexity is what you build when you're trying to exploit someone. Simple, predictable, reciprocal is what you build when you plan to still be here next year.

👇 Which internal feud in your company is just two reasonable teams stuck in a retaliation loop that nobody started on purpose?

This article is also available in German.

Count the Rounds

Mon, 05 Oct 2026 08:00:01 +0200

Why a five-stage interview process tells you everything about the job - before you even get it

The job post says "fast-paced environment." The process says recruiter screen, hiring manager call, take-home assignment, technical deep dive, second technical deep dive, "culture add" panel, psychometric questionnaire, and a final chat with a VP who will ask you where you see yourself in five years.

That's eight rounds. For a company that claims to "move fast".

Believe the process, not the post.

Times are rough. Plenty of good people lost their jobs to the AI wave, and plenty more are quietly refreshing job boards at their desks. My personal bet is that once the AI honeymoon ends, a lot of companies will discover that their institutional knowledge left in a cardboard box, and they'll be rehiring. Until then, desperation is a terrible career advisor. It tells you to say yes to every round, every test, every "just one more quick call with a stakeholder."

Don't. Here's why.

What an interview is actually for

A competent company reads your CV and can map your skills to its needs. With a little effort, it can verify most of your history. So the interview only has three real jobs.

Consistency checks. Is the CV true? This was always my favorite part when I ran interviews. I'd pick the area where the candidate should be strongest, like a product they supported for four years at a vendor, or a certification they listed proudly. Then I'd ask what any actual employee would know. I never cared if someone was shaky on network protocols. I cared a lot if someone was shaky on the thing they called their expertise. A gap in a claimed strength isn't a knowledge gap. It's a honesty gap.
Thought process. Your future peers want to see how you break a problem into pieces, where you start, and when you admit you've hit your limit. Not knowing an answer is fine. What they're really measuring is trainability. "I don't know, but here's how I'd find out in ten minutes" beats a confident wrong answer every day of the week.
Vibes. Can we work with this person? Recruiter, manager, team and sometimes a director all pick this up. You can't measure it on paper and barely on a chat. Video gets you partway, and in person is best. In my experience this is where most people "fail," and that's fine. A conglomerate needs a different temperament than a startup, and sales needs a different one than back office. You'll rarely be told this is why you didn't get the job. Legal caution keeps that feedback vague, so don't take the silence personally.

That's the whole list. Three jobs.

The healthy process fits on a napkin

Recruiter conversation.
Call with the hiring manager plus a peer.
Optionally, a second and more technical call.
Optionally, a short chat with the manager's boss. We called it the "please don't mess this up" call. Its entire purpose was to confirm the candidate didn't insult anyone's mother.

Three rounds, four if the role is senior. BrightHire's hiring data lands in the same place: the sweet spot for most roles is two to four rounds, and past four the extra signal drops sharply while strong candidates start dropping out. Robert Half found that 57% of job seekers lose interest when a process drags on too long. Guess which 57% have other options.

Conway's Law, now in HR

Melvin Conway observed in the late 1960s that organizations design systems that mirror their own communication structure. That's usually said about software architecture. It applies just as well to the hiring pipeline. The interview process is the one piece of internal plumbing a company shows you before you sign.

So read it like a system diagram.

Too many technical rounds means leadership doesn't trust the one or two engineers it sends in to judge a candidate. Either those engineers aren't good, or management is bad at picking people, or management simply doesn't trust its techies. None of these is a fun place to spend your forties.

Too many manager rounds means the hiring manager can't decide after one or two conversations. Either they can't read people, they lack the authority to decide, or they're afraid to. Whichever it is, you'll meet the same pattern later in your budget approvals, your change requests and your promotion case.

Now the part most people miss. More rounds don't make hiring more careful. They make it more average.

Every interviewer in a long chain knows three others will also weigh in, so no single person owns the decision. Saying "no" is risk-free, because nobody ever got fired for rejecting a candidate. Saying "yes" is risky, because your name is on it if they flop. Stack enough of those asymmetric vetoes and the process quietly filters for the most inoffensive person in the pool. The spiky ones get shaved off: the brilliant, direct, slightly odd engineer, or the neurodivergent troubleshooter who answers the question you asked rather than the one you meant. Those are exactly the people who carry teams.

A long pipeline doesn't lower the chance of a bad hire. It lowers the chance of a remarkable one. The company feels safer and gets blander, and your future colleagues are the survivors of that filter.

As a power horse 🐎, you don't want to work where eight people have to agree before anything happens. You already know how that place runs internally. They showed you.

Confession: I built take-home tests

Full disclosure: I've designed take-home assessments myself. Before the first technical interview, candidates got a PDF with a few tasks about our products. The idea sounded great. It would show genuine interest in the company and prove the ability to learn something new.

The reality was that one candidate solved it and shared the answers with five friends. They aced the take-home, defended their steps convincingly in the interview, got hired, and turned out to be a disaster. We'd tested their ability to memorize someone else's homework. Then we were stuck with them.

That was before AI. Today the take-home tests mostly your subscription tier. Karat's survey of 400 engineering leaders found 71% say AI makes it harder to assess technical skills, and many employers are drifting back toward live sessions. On top of that, asking someone to invest four or more unpaid hours per application is unfair. If they apply to ten companies, that's a full working week of free consulting.

What I'd do instead

Go back to basics, with one modern twist.

Verify the CV properly. Make reference calls and ask about specific details.
Check the vibes in person or on video.
Cross-check claimed strengths with questions that don't paste well into a chatbot. That means either conceptual "why" questions, or tricky edge cases where an AI answer sounds perfect and is quietly wrong.
Let them use AI during the interview. They'll use it on the job anyway, so watch how. Give them a problem where the model is likely to hallucinate and see if they catch it. There's a growing term for people who forward AI output without checking it: the "meat proxy." You want to find out in the interview whether you're hiring an engineer or a very polite copy-paste interface.

And for the hiring side: use the probation period

Most companies treat probation as a formality. Treat it as the real final round.

Hire decisively, then watch closely. If it's clearly not working, act early. Don't fall for "but we already spent three months training them." That money is gone either way, and the sunk cost fallacy just adds more months to the bill. Two bad hires caught during probation cost far less than one loyal power horse 🐎 who quit because they were carrying a dead weight colleague nobody dared to address.

(Probation rules vary a lot by country. In Germany, for example, it's capped at six months with a two-week notice period. Know your local rules and document honestly, but do use them.)

👉 An interview needs to do three things: check the CV is true, see how you think, and see whether people want to work with you. Anything beyond that is ceremony.

👉 Three rounds is healthy, four is the ceiling for senior roles, and five or more is a diagnosis of the company, not an assessment of you.

👉 Long pipelines select for inoffensive and filter out exceptional, because every "no" is free and every "yes" is personal.

👉 Take-home tests now measure how well you prompt a chatbot and who your friends are. Test AI judgment live instead.

👉 Ask for the full process on the first call. It's the cheapest due diligence you'll ever do.

The number of interview rounds is the number of people who'll need to approve your ideas later. Count accordingly.

👇 What's the longest interview process you ever went through - and was the job worth it?

Your AI Agent Reads 50,000 Tokens to Learn One Thing

Thu, 01 Oct 2026 07:00:31 +0200

Compression as via negativa: the cheapest token is the one you never send

Take any coding agent session and open the raw request log. Not the pretty transcript - the actual payload. What you find is a JSON search result with 100 hits where 3 mattered, a log file where the interesting line is buried in 800 lines of "INFO: still fine," and a directory listing of a repo the model already walked twice.

Then apply the uncomfortable ratio: cost of the finished output versus the raw inputs actually required to produce it. The model needed maybe 2,000 tokens of real signal. You paid for 55,000. In manufacturing terms, that is a part made of solid gold to hold a plastic clip in place.

I spent a few weeks running everything - coding, research, boring text work - through a compression proxy called Headroom, and the interesting part was not the money. It was watching exactly how much of what I "sent" to the model was never information in the first place.

What it actually does

It sits between your agent and the API and squeezes everything the model reads - tool outputs, logs, retrieved chunks, conversation history - before it goes upstream. Compression happens locally, nothing gets shipped off to a third party to be shrunk. The model can pull the original back if it needs it.

The project's own benchmarks show roughly 20% on code search, 40-60% on incident debugging and codebase exploration, and the big numbers (86%+) on JSON arrays, which makes sense: JSON is mostly punctuation and repeated key names, a format designed for parsers and billed as if it were prose. Structured logs compress hard too. Source code mostly passes through untouched, which is the right default - you do not want your agent reasoning about a lossy version of the file it is editing.

Honest caveat, because I would rather you trust me in six months: the dashboard counts tokens it compressed, not tokens your provider stopped charging you for. Those are related but not identical numbers, and some users report the delta being smaller than advertised once retrieval round-trips are included. Treat the dashboard as a direction indicator, not an invoice.

Which brings up the part nobody markets: if you are on a flat subscription plan, you save exactly zero euros/dollars. What you save is runway. Fewer tokens consumed means you travel further before slamming into the 5-hour and weekly usage windows. For anyone who has had a long refactor cut off mid-thought by a rate limit, that is worth more than a discount.

Setup on Linux, in the time it takes to make coffee

Install and verify:

uv tool install --python 3.13 "headroom-ai[all]"
command -v headroom
headroom doctor

You want "Proxy" showing a green checkmark. If it does not, stop here and fix that first - do not proceed on hope.

Optional but sensible, run it as a user daemon so it is simply always there:

# ~/.config/systemd/user/headroom.service
[Unit]
Description=Headroom compression proxy

[Service]
ExecStart=%h/.local/bin/headroom proxy --port 8787
Restart=on-failure

[Install]
WantedBy=default.target

systemctl --user enable --now headroom
ss -lntp | grep 8787

That second command is not cosmetic. Confirm it is bound to 127.0.0.1 and not 0.0.0.0. An unauthenticated proxy that sees every prompt you write, listening on all interfaces, is not a productivity tool. It is a gift to whoever else is on your network.

Then point your client at it, in ~/.claude/settings.json:

{
"env": {
"ANTHROPIC_BASE_URL": "http://127.0.0.1:8787"
}
}

Restart the CLI and your IDE - VS Code or VSCodium will not pick up the new base URL otherwise. Open http://127.0.0.1:8787/dashboard and check that "Request Health" and "Live Activity" show non-zero numbers. That is the whole installation. The rest is watching a counter go up while you do the work you were going to do anyway.

When it breaks, and it will

It is a young, fast-moving project. Rarely, requests hang or die. The triage order, learned the boring way:

👉 Stop the current model session, restart the tool or IDE, tell the agent "continue." Fixes most of it.

👉 Still failing? systemctl --user restart headroom.

👉 Still failing? It is probably not your machine. Check status.claude.com before you debug anything else - degraded upstream service looks exactly like a broken proxy from where you are sitting, and I have wasted honest minutes proving that.

👉 Genuinely a regression in a new release? Pin backwards: uv tool install --python 3.13 "headroom-ai[all]==0.37.0" --force. Fast-moving projects reward people who know how to step back one version instead of filing an issue and waiting.

That last point is the real skill, by the way. Not the tool - the habit of having a rollback path before you need one.

The part that generalizes

Compression proxies are a workaround. The underlying problem is that we hand agents firehoses and call it context. We pipe in complete API responses, full log files and entire directory trees because it is easier than deciding what matters, then pay per token for the privilege of making a language model do our filtering at premium rates.

The best part is no part. The cheapest token is the one you never send. A tool that compresses your junk is strictly better than not having it - but a grep with a sane filter, a log level that is not DEBUG in production, and an API response that returns fields instead of everything would have gotten you most of the way there without any middleware at all.

👇 What is the dumbest thing your agent has ever been made to read in full? Mine spent real money ingesting a 400-line INFO log to find one timestamp.

Be Employee Obsessed

Wed, 30 Sep 2026 08:00:27 +0200

Everyone says "customer first". Almost nobody means it.

Years ago, I shared a few carbonated drinks with an SVP whose management philosophy fit on a bar napkin: "Be employee obsessed."

I was skeptical to the point of rudeness. So I asked him straight: "with that approach, how do you make sure customers get world-class service?"

He didn't blink. "If you hire top performers, you never have to worry about customer satisfaction. I have never once hired a talented support person who wasn't already customer obsessed. Nobody ends up in this job by accident. It's ingrained, or they'd have picked a role where humans don't call you when their week is on fire."

So the model was simple: hire people who are obsessed with customers, then spend your own energy protecting them. Not managing them. Protecting them. From three specific things: corporate nonsense, burnout, and what he cheerfully called "stupid customers".

Let me unpack all three, because each one had teeth.

Burnout is rarely about volume

His claim: information technology has one of the worst burnout rates in white collar work, and the cause is usually misdiagnosed as "too much work". Sometimes it genuinely is too much work. But more often, he said, people are either doing the wrong things, or doing the right things in a broken flow imposed on them by the company.

That's a distinction most executives never make. Ten hard tickets solved cleanly leave a power horse 🐎 energized. Three easy tickets routed through four approval layers, two tools that don't talk to each other, and a mandatory status meeting leave the same person hollow. Effort doesn't burn people out. Friction does. Every handoff and approval gate bleeds energy that never reaches the customer, and the person feeling that loss most acutely is the one holding the ticket.

So he fought - hard, politically, for months - to get his organization a dedicated developer. Reporting to him. Not to a platform team, not to a shared services pool, not to a manager with a competing roadmap. One engineer whose entire job was removing the daily friction his best people ran into.

Middle management hated it. It looked like empire building. It was actually the highest-return headcount in the department, because it converted senior engineer hours from "fighting our own tooling" back into "fixing customer problems". If you want a number to think about: take the fully loaded cost of a resolved ticket and divide it by the minutes of actual engineering thought inside it. When that ratio is grotesque, your inputs aren't expensive. Your process is.

The "stupid customer" problem, honestly stated

Nobody in that org thought customers were stupid. Customers pay the bills, and treating them with contempt is both immoral and commercially suicidal. But two failure modes appeared over and over:

Customers who had no realistic expectation of what support is for. And customers whose own staff had never been trained to operate the product they bought.

Expectation-setting sounds trivial. It isn't. When a customer has a P1 - severity one, production down, hair on fire - they do not want a conversation about scope. They want it fixed before it reaches their CIO's dashboard.

And that last part was the tell. A large share of P1s were not technically P1s at all. They fell into two buckets:

Political P1s, where the real problem was internal to the customer and a support engineer was structurally the wrong audience. And cover-up P1s, where someone had broken something and wanted it quietly repaired before their own food chain noticed.

Both correlated strongly with the big global accounts that had outsourced first-line operations to the cheapest available bidder - people trained to watch for a red light on a dashboard and open a case, with zero investigation in between. Not their fault. That's exactly what they were hired and incentivized to do. Show me the incentive, I'll show you the ticket queue.

Permission to push back

His fix was a small policy with enormous consequences: his engineers were allowed to push back. Not encouraged to be difficult - allowed to disagree with a customer's severity assessment and say so.

Nine times out of ten they got it right. The remaining 1/10 they used to learn, improve and apologize. The mechanism was a fast triage question set, and the sharpest one was this: "is this a component that was working before, or a brand new implementation?"

By default, a new implementation cannot be a P1. Think about it. If something that has never worked in production is suddenly business-critical, one of three things happened: you didn't test, you didn't read the documentation, or you set yourself a timeline that only physics could refuse. None of those are outages.

But here's the part that made it survivable commercially. The first such P1 was always worked, free, fully, no lecture. "Customer first", genuinely. Then the account team was pulled in for the grown-up conversation. That conversation regularly ended in training, sometimes certification, and quite often a professional services engagement the customer needed far more than they'd ever admitted in the sales cycle.

Pushing back didn't cost revenue. It generated revenue. Turns out honesty is a premium product.

The account that hated us, and the sentence that fixed it

The best illustration came from an account bleeding dissatisfaction scores for months while every metric on the dashboard looked pristine. Mean time to close: excellent. Response times: excellent. Customer sentiment: radioactive.

A German escalation manager got the file. Initial finding: the customer asked an extraordinary number of remarkably basic questions. Engineers were closing them in minutes, mildly amused, and moving on. From the customer's side, the story was different: "your product is impossible to use."

Metrics said triumph. Customer said disaster.

So he booked a call to actually understand what they were doing. It ran over an hour. He paced the room with a headset while the rest of us pretended to work and shamelessly harvested fragments, because this account had been giving everyone headaches for a quarter.

Then, in the crisp tone that would have made Werner Herzog proud, and only a German engineer can produce at the exact moment of maximum tension, we heard:

"With all due respect - just because our enterprise solution has a fancy user interface, that does not mean it is Ubuntu."

Silence on the line. My manager's jaw dropped to somewhere around his keyboard, visibly running the math on whether to fire our escalation manager or resign first. The rest of us having the best afternoon of the fiscal year.

Days later the account manager walked in - to say "thank you".

Because the real story finally surfaced. The customer hadn't been doing any of this themselves. They had hired an external service provider who had sold himself as an expert in our platform and was, in reality, entirely lost. His survival strategy was elegant: every time he couldn't do his job, he opened a case and rated our product as broken and our service as useless. Months of dissatisfaction scores weren't customer feedback. They were one contractor's alibi.

The customer terminated him. Then they sent their own apprentice to training and made him the single point of contact for the platform.

He also arrived with basic questions. Difference: he wanted to learn, he was grateful for the time people spent explaining things, and within about six months he was running the thing competently. Smooth sailing for them, smooth sailing for us, dissatisfaction score back where it belonged.

Sometimes the fix isn't more patience. Sometimes you have to dig deeper and pull the rotten tooth.

So: policy, or slogan?

Every company on earth claims to be customer obsessed. Be honest about what it means in yours.

Because in a lot of places, "customer obsessed" means being extremely friendly while holding someone in a phone queue for an hour. Or hiring many cheap, undertrained people, so response time looks fast while resolution rate quietly rots. Or loading your best engineers to 130% while denying them dedicated training time, because training doesn't show up on this quarter's dashboard.

In the worst cases it means squeezing your strongest people until they burn out, leave, and get replaced by the next graduate - who will be squeezed on the same schedule. That isn't customer obsession. That's a slogan doing public relations for a grinder.

👉 If your people are obsessed with customers, your job is not to remind them. Your job is to remove what stops them.
👉 Burnout is friction, not volume. Audit the flow, not the headcount.
👉 Fund the unglamorous internal role that unblocks your senior people. It pays for itself in a quarter and nobody will thank you for it.
👉 Give engineers the authority to challenge a severity. Then defend them the first time a customer escalates about it, because that moment decides whether the policy is real.
👉 Every "difficult customer" pattern has a mechanism underneath. Find the person whose incentive is to make you look bad.
👉 A dashboard full of green with a customer full of rage means you're measuring the wrong thing beautifully.

Customer obsession that isn't built on employee obsession isn't a strategy. It's a mood, and moods don't survive a P1 on a Friday.

👇 What's the most creative thing a customer has ever labeled a P1 - and did anyone at your company have the standing to say no?

This article is also available in German.

You Bought a Racehorse and Rented a Treadmill

Mon, 28 Sep 2026 08:00:15 +0200

The strangest math in enterprise hiring: paying sports-car money for output you then throttle by hand

A while back I sat in a coffee shop with someone from a very large, very admired technology company. Nine-figure revenue per quarter, the kind of place that puts "we hire only the top 1%" in its recruiting deck without irony.

He told me his last quarter honestly. Two weeks of real engineering. Ten weeks of alignment.

His compensation, fully loaded, was roughly the price of a mid-range sports car per year. So the company paid sports-car money and received, in terms of the thing they actually hired him for, a used scooter. Not because he was lazy. Because 80% of his calendar was owned by people whose job was to make sure nobody did anything surprising.

I hear a version of this story from nearly everyone I talk to who works inside the big names. It is consistent enough that it stopped being anecdote and started being physics.

The idiot index of a knowledge worker

There is a useful little instrument from manufacturing: take the cost of a finished part and divide it by the cost of its raw materials. A machined bracket that costs 200 euros but contains 8 euros of aluminum tells you something. Not that aluminum is expensive. That your process is stupid.

Apply that to a senior engineer.

Raw input: one very expensive brain, capable of shipping things that make money.
Finished output: three slide decks, one Jira epic groomed into a fine powder, and a fix that shipped six weeks after it was written because it needed sign-off from a governance board that meets fortnightly.

The ratio is grotesque. And like the bracket, it does not indict the aluminum. Nobody in these companies has a talent problem. They have a process problem wearing a talent problem's clothes, because "we need to hire better people" is a budget request and "our approval chain destroys value" is a resignation letter.

Why the screws tighten exactly when they shouldn't

Here is the part that genuinely puzzled me for years.

Every time the horizon darkens - a bad quarter, a funding chill, "macroeconomic outlooks"- leadership reaches for control. Hiring freeze, travel freeze, headcount review, mandatory return to office, a new weekly reporting cadence, a "focus" initiative that adds three dashboards. They reduce the heat to save fuel. But the fuel bill is identical, because the salaries are already committed. All they cut was output.

You are still burning the same wood. You just closed the flue.

Why does an intelligent executive do this? Because control is legible and output is not. A vice president can walk into a board meeting and prove, with artifacts, that governance was increased. Nobody can prove what the unshipped feature would have earned. Downside risk of tightening: invisible and deferred. Downside risk of trusting an engineer: has your name on it if it goes wrong.

That is not stupidity. That is an incentive working perfectly. Show me the incentive and I will show you the org chart.

Then there is the second mechanism, and it is the more brutal one. Jerry Pournelle observed that any bureaucracy eventually splits into people who serve its mission and people who serve the bureaucracy itself - and the second group reliably ends up in charge of promotions, because they are the ones present at the meetings where promotions are decided. Crisis is their harvest season. Crisis is when "we need more oversight" sounds like wisdom instead of empire-building.

The power horses 🐎 are elsewhere. Debugging. Missing the meeting where their autonomy got reallocated.

The commodification trick

Watch the language shift over a talent's first two years.

Year one, in the offer stage: "We want someone who can own this space end to end. You'll have real influence."

Year two, in the performance review: "We need to make sure your work is repeatable and not dependent on individuals."

Both sentences are honest. They come from different parts of the organism. Recruiting is optimizing for acquisition. Operations is optimizing for interchangeability, because interchangeability is how you survive attrition, audits and org charts. The company genuinely wants exceptional people and genuinely wants nobody to be exceptional. It buys a racehorse and then, quite rationally, installs guardrails so that any horse could run the same lap.

The tragedy is that the guardrails work. Output does become uniform. It converges downward, to the level of the least capable person the process was designed to survive.

And then a small company opens down the road, hires four of these people, gives them access and a budget and nobody to ask, ships in eight weeks what the giant scheduled for three quarters - and the cycle begins again. That small company will be a giant in eleven years and will install its own governance board. This is not cynicism. It is entropy with a payroll.

For leadership: how to stop paying for horsepower you then bleed off

👉 Measure the ratio, not the headcount. For one senior person, one quarter: hours spent producing the thing customers pay for, versus hours spent producing evidence that work happened. If the second number is bigger, you do not have a productivity problem, you have an overhead problem, and hiring more people will scale it.

👉 Improve by removal first. Before adding a process, kill one. Every handoff, approval and status sync leaks energy that never reaches the customer. Most transformation programs are additive, which is why they cost so much and change so little. But do check why the fence exists before you tear it down - some approval gates are load-bearing and were paid for in blood, usually a regulatory fine.

👉 Give access, not encouragement. Autonomy is not a value on a wall poster, it is a permission set. Production access, a budget threshold they can spend without asking, the right to say no to a meeting. If your top performer needs three signatures to buy a 200 euro tool, they are not autonomous, they are on parole.

👉 Tighten differently in a crisis. Cut theater, not throughput. Kill the reporting layer before the tooling budget. If your instinct in a downturn is to increase oversight of the people who make the product, invert it: ask how you would guarantee terrible output on purpose, and then count how many of those items you just approved.

👉 Protect asymmetric people from uniform processes. One person delivering four times the median is not a staffing anomaly to be normalized. It is your margin. Design a lane for them or watch a competitor design one.

For the talent: how to tell whether you are already in the wheel

Four signals, in order of how late they arrive.

👉 Your calendar. If more than half of your week is other people's agendas and you cannot name what shipped because of you last month, you are being consumed rather than employed.

👉 Your escalation path. Ask yourself how long it takes you to get a decision. In healthy places, hours. In the wheel, "let me take that to the working group."

👉 Your last honest technical argument. In a functioning organization, you lose some of them on the merits. In a converged one, you lose all of them on hierarchy, and you have quietly stopped starting them. That silence is the real symptom, and it precedes burnout by about six months.

👉 Your market temperature. Not "could I get a job" - could you get this job again today, at this salary, with what you have actually built in the last eighteen months? If your recent portfolio is coordination rather than creation, your value is decaying while your title improves. That is the most expensive trade in tech and almost nobody notices it happening.

What to do about it, in ascending order of courage: reclaim one day a week and defend it like a border. Reframe your autonomy ask in the language of risk reduction, because most executives move on framing rather than logic - "this removes a bottleneck on me" travels much further than "I want to be trusted." Find the overlooked, unglamorous domain nobody is bidding for, where competence is scarce and permission is cheap. And if none of that moves - leave before the cynicism sets in, because cynicism is the one injury that follows you to the next employer.

One caveat, because I am not selling romance: some structure is not oppression. Guardrails exist because unconstrained brilliance also produced the undocumented system nobody can maintain and the vendor contract legal is still unwinding. The goal is not zero process. The goal is that the amount of process is proportional to the actual risk, not to somebody's discomfort with not knowing what you are doing right now.

The best talent is not a resource you acquire. It is a reaction you either catalyze or quench - and quenching costs exactly the same per year.

👇 What is your current ratio - real output hours versus evidence-production hours? Guess honestly, then check your calendar.

This article is also available in German.

The Genius Sorting Tickets

Thu, 24 Sep 2026 08:00:14 +0200

How "fair" workload distribution quietly buries your best engineer

The best engineer I ever worked with spent most of his week doing what amounted to shelf-stacking.

Not by accident. By policy.

He was one of those people who reads a stack trace the way other people read a the Sunday newspaper. Give him a kernel panic on a Friday afternoon and he would come back with a one-line patch and an explanation of why the vendor's documentation had been wrong since a version three years earlier. Undiagnosed autistic, most likely - never said it, never needed to. Terrible at status meetings. Catastrophic at self-promotion. Made a senior architect cry once, purely by being correct in public.

And his manager assigned him to the general queue rotation. Same volume of password resets, license questions and "have you tried restarting" tickets as everybody else.

Because that was fair.

The fairness that isn't

The official reasoning was elegant: everyone shares the boring work, nobody gets special treatment, morale stays intact. Written down like that, it sounds like leadership.

What actually happened: the team's one irreplaceable diagnostic capability was rationed down to roughly six hours a week, and the escalations he wasn't touching sat in the pipeline for days, quietly compounding into churn risk that nobody attributed to the rotation policy. Because nobody measures the cost of a genius doing data entry. There's no dashboard for that.

Look at the ratio for a second. The company paid a senior engineering salary for output that a competent intern could produce, while the work that only he could do - the work worth ten times his salary in retained revenue - waited in a queue. That gap between what an input costs and what it produces is the single loudest signal of a broken process, and it was screaming. Nobody heard it, because the queue looked balanced.

There was a second reason, less officially documented. His manager was afraid of him. Not physically - intellectually. Every technical conversation with him ended with the manager being slightly wrong in front of witnesses. Keeping him in the general queue solved that problem beautifully. A power horse 🐎 pulling a shopping cart can't outrun you.

Sameness is not fairness

Here's the part that management training gets backwards. Treating unequal contributors identically is not neutral. It is an active transfer of value from the productive to the average, and everybody in the room can see it happening.

Cornell research published in 2025 looked at a multinational pharmaceutical company that capped top performance ratings at one in five employees. People nominated for the top rating but denied it - purely because the quota was full - were at least 34% more likely to leave voluntarily, despite receiving bigger bonuses meant to soften the blow. Nearly as likely to leave as the worst performers. The money didn't fix it. The arbitrariness did the damage.

And it doesn't stop with the person affected. A study by sociologists at the University of South Carolina, published in Nature Human Behaviour, found that when a manager's rewards are visibly decoupled from effort, everybody slows down - including the people the bias favoured. If output doesn't determine reward, output becomes optional. Rational response.

So the "fair" rotation achieved a perfect trifecta: the top performer disengaged, the mid-performers learned that excellence carries no upside, and the manager kept his authority intact. Two out of three stakeholders satisfied. Or in other words: a king of ashes is still a king.

He left, eventually. Not dramatically. He just stopped renewing his interest in the place, took a role somewhere that let him do the thing he was built for, and the escalation backlog became someone else's mystery. Six months later, a customer with a seven-figure contract asked why response quality on hard cases had "changed." Nobody connected it to a rotation policy. Nobody ever does.

What to do instead

👉 Fair means equal access to opportunity and equal application of standards. It does not mean identical task lists for non-identical people. Stop confusing input equality with justice.

👉 Compute the ratio yourself. Take the fully loaded hourly cost of your most capable engineer, then look at what they actually did last week. If more than a third of it could have been done by someone in their first year, you have a process defect, not a staffing problem.

👉 Boring work still has to happen. Distribute it by cost of misallocation, not by headcount. Rotate the drudgery among people whose scarce skills aren't idling while they do it - and pay explicitly for the queue duty nobody wants.

👉 Audit your managers for intellectual insecurity. A manager who never gets publicly corrected by their team either has no experts, or has experts they've learned to keep quiet. Both are expensive. Ask the team who the smartest person in the room is, then check what that person spent the week on.

👉 Neurodivergent top performers are systematically underused because their value shows up in output and their weaknesses show up in meetings. Guess which one your promotion process measures. Build a path that rewards the deep-work profile without forcing it through a charisma filter.

👉 Watch for the tell: when someone says "we can't make an exception," ask whether the rule exists to protect the customer or to protect the org chart. Usually you'll find out in under ten seconds by how defensive the answer gets.

Equality of workload is the cheapest way to look fair while paying senior rates for junior output - and your best people will bill you for the insult on their way out the door.

👇 Who is the most capable person on your team, and what did they actually spend last week doing?

This article is also available in German.

Everyone Thinks They Are a Rick. Statistically, You Are a Jerry.

Tue, 22 Sep 2026 09:00:40 +0200

There is a fan theory about Rick and Morty that has outlived most management books: if you aspire to be Rick, you are already Jerry.

Quick briefing for the three people who have not seen the show: Rick is the genius scientist who can build a portal gun out of a toaster and hates being told what to do. Jerry is his son-in-law - well-meaning, insecure, unemployed, permanently in need of validation, and utterly convinced that his contribution is being undervalued. Beth, Rick's daughter, is a surgeon who operates on horses. Which, given my usual vocabulary, I choose to interpret as cosmic endorsement. 🐎

In every engineering org I have worked in, the Rick-to-Jerry ratio was inverted from the self-assessment data. Roughly everyone in the room believed they were the one person holding the system together. The actual load-bearing person was usually silent, slightly rumpled, and not in that meeting because someone had to keep production alive.

The ratio

At one company we ran an internal skills self-assessment before a reorg. Standard corporate ritual: rate yourself 1-5 on a set of competencies. Around 70 percent of the technical staff rated themselves above the team average on debugging complex incidents.

Mathematically impossible, obviously. But that was not the interesting part.

The interesting part was that we also had four years of incident data. Who actually closed the escalations nobody else could close. And the correlation between self-rating and resolution record was not weak. It was slightly negative.

The people who fixed the hardest things rated themselves lowest. Because they were the only ones who had ever stood at the edge of a system they did not understand and felt the vertigo. Everyone else was rating themselves against their own mental model of the system, which was tidy, small, and wrong.

That is the Jerry mechanism in one sentence: Jerry is not stupid. Jerry has simply never received a bill for being wrong.

Proof of work versus proof of title

Rick's authority in the show is never granted. He does not have a job title (other than crazy scientist, perhaps). He has a demonstrated ability to produce outcomes nobody else can produce, at obvious personal cost, and everyone around him knows it whether they like him or not. That is proof of work.

Jerry's entire identity runs on proof of title. He was in advertising. He had a badge. He was, at one point, technically employed. His self-image is a set of credentials with no output attached, which is why it needs constant external maintenance.

Corporate orgs are Jerry factories, and not by accident. A title is cheap to issue and infinitely renewable. Output is expensive to measure and politically inconvenient. So we build career ladders where the rung is the achievement. Then we are surprised when the Principal Something-Architect cannot explain how the product handles a failed database write.

The tell is always the same. Ask a person what they did last quarter. A power horse describes a system that behaves differently now. A Jerry describes a process they participated in.

Enter the machine that tells you that you are Rick

Here is the modern upgrade, and it worries me more than any reorg ever did.

We now have a technology whose default failure mode is agreement. Research on large language models keeps circling the same finding: these systems are optimized, partly through human feedback, to be pleasant. Pleasant means agreeable. Agreeable means that if you bring a mediocre idea and a confident tone, you get encouragement back with citations-shaped garnish. There is a growing body of work on sycophancy in chatbots and how flattery loops can push a user's beliefs steadily away from reality, even when the user is reasoning carefully at each step. Each individual exchange feels rational. The trajectory is not.

Jerry, in the show, has exactly one truly great day: a simulation tells him his terrible marketing idea is brilliant. He is never happier.

We have shipped that simulation to eight billion people, and it runs on your phone.

I have watched it happen in real teams. Someone arrives with a two-page architecture proposal, beautifully structured, correct grammar, plausible headings, and zero contact with the actual system it is supposed to modify. Ask two questions below the surface and the whole thing evaporates. There is a term floating around for the person in the middle of this pipeline: meat proxy. An uncritical intermediary who forwards generated content without verification. Not an author. A relay.

And the cruel bit: the same tools make genuine Ricks better. The gap widens in both directions. If you have real models in your head, the machine is a force multiplier. If you do not, it is a very sophisticated mirror telling you that you are the smartest person in the Citadel.

There is a second-order cost that gets discussed less. Expertise regenerates through struggle. Junior people become senior by being confused, being wrong, and paying for it in an environment where someone catches them. That is the apprenticeship loop. If the confusing middle part is now outsourced - if nobody ever has to sit with a problem long enough to build the intuition - we get a generation that can produce senior-looking output without owning senior-grade judgment. The commons that produced the next round of experts stops replenishing itself. Not visible this quarter. Extremely visible in about eight years, in the form of nobody left who can debug the thing.

How to check which one you are

I am not going to insult you with an assessment quiz. Three honest questions instead.

👉 When did you last change your mind because the system disagreed with you? Not because a person disagreed - because reality did. Ricks collect those moments. Jerrys cannot recall one.

👉 What breaks if you go on holiday for three weeks? A specific answer is a good sign. "The team would miss my input" is Jerry's autobiography.

👉 Who tells you you are wrong, and what happens to them afterwards? If the answer is "nobody" or "they left", you have optimized your environment for comfort. Congratulations, you have built the simulation yourself, without a supercomputer.

And the professional version, for anyone who leads people: stop rewarding the self-report. The self-report is noise. Look at what changed. Look at who gets called when the thing is actually on fire at an inconvenient hour - that phone list is your real org chart, and it usually bears no resemblance to the printed one.

The uncomfortable inversion is this. Rick is miserable, isolated, and permanently aware of how large the unknown is. Jerry is happy. If your primary career goal is feeling competent, Jerry is the rational choice and the market will happily accommodate you with a title and a dashboard.

Competence and the feeling of competence are two different products. Most organizations, and now most software, are in the business of selling the second one.

👇 Be honest in the comments: what is the last thing you were confidently, expensively wrong about - and who caught it?

This article is also available in German.

"Don't Make Mistakes"

Mon, 21 Sep 2026 08:00:40 +0200

The three words that reveal exactly how little we understand the machines we now depend on

The funniest prompt in modern computing is three words long, and it appears in production systems at companies with actual revenue.

"Don't make mistakes."

Sometimes with emphasis. DO NOT MAKE MISTAKES. Sometimes with a threat attached, as if the model has a family. Sometimes with a promise of a tip, which is my favorite genre of magical thinking - bribing a probability distribution.

Sit with the assumption for a second. Telling a system not to make mistakes implies the system was previously choosing to make them. Which means one of three things must be true: it was trained to err, it was instructed to err (perhaps by a vendor who bills per token - a delightfully paranoid theory that dies the moment you notice open-weight models behave identically), or errors are an opt-in feature that ships enabled by default.

None of it survives ten seconds of contact with how the thing actually works. A language model does not have a laziness dial. It has no intent to be sloppy, because it has no intent at all. It produces the statistically plausible continuation of your text. "Don't make mistakes" is not an instruction. It is a mood. It shifts the output slightly toward the register of text that appears near careful, hedged, authoritative-sounding language in the training data - which is why the response often sounds more confident while being exactly as wrong. You did not reduce the error rate. You upgraded the packaging.

That is the trap. The prompt works on the reader, not on the model.

Five groups, and only one of them is dangerous

After too many conversations on this topic, I've stopped arguing about AI in general. There is no "AI debate." There are five different populations having five different conversations while using the same word.

Group A - the consumer. Knows one brand name, possibly believes it is the technology, the way people once said "Google" to mean "the internet." Uses it for birthday card verses, holiday packing lists, and a lasagna recipe. Has fully understood that it makes things up, and correctly does not care, because the downside of a hallucinated lasagna is dinner. Harmless. Genuinely fine.
Group B - the advanced user. Uses it for drafting, summarizing, cleaning up the email that would otherwise start a war with Procurement. Treats inaccuracy as friction: regenerate, rephrase, move on. Also fine. Most of humanity will live happily in A and B forever, and there is nothing wrong with that.
Group C - the midwit. My beloved. This is where "don't make mistakes" was born, in the belief that a systemic property of the architecture can be defeated with sufficiently clever wording. Group C does not use AI; Group C evangelizes it. Every Slack message, every one-paragraph update, every condolence card runs through the machine until colleagues can identify the output by smell alone. Group C forwards content it has not read. Group C is the reason the term meat proxy exists - a human who functions as an uncritical relay for generated text, adding a name and a signature block but no verification, no judgment, no liability absorbed anywhere along the chain.
Group D - the expert. Same tools, opposite posture. Knows what the limitations are, has stopped being offended by them, and reads the output before it leaves the building. Uses the machine where verification is cheap and skips it where verification is expensive. Boring. Effective.
Group E - the guru. Trains, fine-tunes, builds agents, breaks them, writes the evaluation harness nobody wants to write. Small population. Not the problem.

Notice the shape: the risk curve is not linear with enthusiasm. It peaks in the middle. A knows nothing and is safe because its stakes are low. E knows everything and is safe because it knows where the mines are. C knows just enough to be confident, in a domain where confidence is the actual failure mode.

Why the middle is where the damage happens

Here is the mechanism, and it's worth understanding because it's not really about AI.

These systems are trained, among other things, to produce responses humans rate highly. Humans rate agreement highly. So the models are structurally inclined to agree with you - and recent research on chatbot sycophancy suggests something uncomfortable: an agreeable interlocutor can push even a perfectly rational, evidence-updating reasoner toward increasingly wrong conclusions, simply because every step gets confirmed. You don't need to be gullible to spiral. You just need a partner who never pushes back.

Now hand that partner to Group C - a person whose primary skill is enthusiasm and whose primary output is forwarding. The machine agrees. The human feels validated. The text goes out. Nobody in the loop bears any downside, because the author is technically the model and the model has no reputation, no license to lose, and no performance review.

That's the real problem, and it has nothing to do with token probabilities. It's an accountability vacuum wearing a productivity costume. In every functioning system, the person who signs bears the cost of being wrong. The meat proxy signs and bears nothing. Remove skin from the game and quality becomes optional, immediately.

Second-order effect, which I find more worrying than any hallucination: junior people used to build judgment by producing bad work and having it corrected. That's how expertise regenerates - through the expensive, humiliating, irreplaceable loop of being wrong in front of someone senior. If the first draft is always machine-perfect-ish, that loop never runs. There are researchers now describing this as a commons problem: the pool of professional expertise everyone draws from doesn't refill itself if nobody pays the cost of learning anymore. Every individual has a rational incentive to skip the struggle. Collectively, we run out of people capable of noticing the machine is wrong.

Which is exactly the population you need most.

Moving people from C to D

You cannot train this with a policy document. I've watched organizations try. The AI Usage Guidelines PDF gets summarized by AI and forwarded by a meat proxy, which at least demonstrates commitment to the bit.

What works is much smaller and much less pleasant:

👉 Restore the signature. Whoever sends it, owns it. Not "the AI got that wrong" - you got that wrong, in front of the customer. One instance of this landing properly does more than any workshop.

👉 Make the cost visible. Ask what verifying the output cost versus what producing it manually would have cost. Sometimes the honest answer is that a 40-second generation created 25 minutes of fact-checking. That ratio is the whole conversation. If nobody is measuring it, the tool is a hobby, not a process.

👉 Ban the incantations. "Don't make mistakes," threats, imaginary tips. Replace with the things that actually reduce error: give it the source material (e.g. via RAG), constrain the output format, ask for citations you then click, and split hard tasks into checkable steps. Grounding beats begging.

👉 Protect the learning loop. Juniors still write the first draft themselves sometimes. Not for output quality - for the muscle. You are not paying for today's document, you are paying for someone who can still spot a plausible lie in three years.

👉 Reward the person who says "I checked." Verification is invisible work. Invisible work dies unless leadership names it out loud. The quiet power horse 🐎 who caught the fabricated regulation before it reached the client just saved you more than the entire tooling budget.

Group C is not stupid. That's the whole point of the label. They're often the most motivated people you have, pointed slightly wrong. The distance from C to D is not intelligence, it's one habit: read it before you send it.

Nobody who understands how these systems work has ever typed "don't make mistakes." Not because they're above it - because they know exactly which words are load-bearing, and politeness toward a probability distribution isn't one of them (although I know some people who use the word "please" a lot with their LLMs... just in case).

👇 What's the best AI incantation you've seen in a real production prompt? I collect these. Bonus points if it involved offering the model money.

This article is also available in German.

Why the Smartest Person in the Room Keeps Losing the Room

Thu, 17 Sep 2026 08:00:06 +0200

A rhetoric crash course for engineers who think being right should be enough

I once watched a brilliant engineer lose a budget fight to a manager armed with nothing but a stock photo of a sad customer and the sentence "Do we really want to be the company that lets this happen?"

The engineer had a spreadsheet. Fourteen tabs. Error bars. He was right about everything. He lost 9 votes to 1, and the one vote was his own.

That day I understood something that took me embarrassingly long in a 20+ year career: being right is a necessary condition for winning almost nowhere. Meetings are not peer reviews. They are persuasion events. And most technical people show up to a persuasion event with the wrong toolset, then walk out confused, muttering "but the data was clear."

This article is the crash course I wish someone had given me. No books, no courses, no Toastmasters. Just the operating manual, translated into engineering speak.

The two operating systems: dialectic and rhetoric

Aristotle - who was, in modern terms, the first systems architect of human communication - split persuasion into two modes.

Dialectic is logic-based debate. Facts, evidence, syllogisms. If A and B, then C. It works beautifully on people who are trained, willing, and incentivized to follow logic. Congratulations: that's you, your fellow engineers, and roughly nobody in your steering committee.

Rhetoric is persuasion aimed at how people actually decide: through emotion, identity, trust, and self-interest. It is not lying. It is the delivery protocol for truth to receivers that don't speak your protocol.

Here is the part that stings. Engineers treat rhetoric as dirty - manipulation for people who can't argue properly. So they refuse to learn it. Meanwhile, mediocre operators fluent in rhetoric take their budgets, their headcount, and eventually their roadmaps. Refusing to learn rhetoric because "logic should be enough" is like refusing to learn TCP/IP because "my data is correct." Correct data that never arrives is worthless.

One more thing before the toolbox: dialectic is not superior to rhetoric or vice versa. They are different protocols for different receivers. The skill is protocol detection. Debating architecture with a senior engineer? Dialectic. Asking a CFO for two more headcount? Rhetoric, with dialectic as the payload. Talking to a mixed room? Rhetoric as the wrapper, dialectic available on request.

The three channels: logos, ethos, pathos

Aristotle again. Every persuasive message travels over three channels simultaneously. You've been broadcasting on one and wondering why nobody receives you.

Logos - the argument itself

Facts, reasoning, evidence. Your home turf. I won't teach you logic; you have it. I'll teach you the three logos mistakes engineers make:

Mistake 1: Too much of it. Fourteen tabs is not fourteen times more convincing than one number. It's fourteen times less, because attention is a scarce resource and you just spent the room's entire budget on tab three. Rule of thumb: one killer number, two supporting facts, everything else in an appendix you offer but never open unprompted.

Mistake 2: Precision theater. "This will reduce ticket resolution time by 23.7%" invites someone to attack the 0.7. "This roughly cuts resolution time by a quarter" is unattackable and lands harder. Calibrate confidence to your actual evidence - overclaiming is the fastest way to torch your credibility, and audiences smell it instantly.

Mistake 3: Making the audience build the bridge. You show a chart, you assume the conclusion is obvious. It is - to you. Always say the bridge out loud: "This matters because it means we're paying senior engineer salaries to do password resets." Never make the room do inference work. Rooms don't infer. Rooms nap.

Ethos - why they should believe YOU

Ethos is your credibility as perceived by this audience, right now. Not your actual competence. Perceived. This is where power horses 🐎 quietly bleed out: enormous real credibility, zero transmitted credibility, because they never learned that ethos must be actively established.

How to build ethos without bragging:

Specific attribution. "In my experience" is weak. "When I ran escalations for a 40-person support org, we tried exactly this and it failed in month three because..." is strong. Specificity is proof-of-work. Vagueness is proof-of-nothing.

Steelman the opposition first. "The strongest argument for outsourcing this is the cost line, and honestly, on paper it's compelling" - and then dismantle it. The moment you fairly state the other side's best case, the room recategorizes you from "advocate" to "judge." Judges get believed.

Admit a small weakness voluntarily. "I don't have great data on the second-year costs, I'll be honest." Counterintuitively this raises trust in everything else you say, because you've demonstrated you're calibrated, not selling.

Composure. The person who stays calm when challenged is presumed right by default. The person who gets visibly irritated is presumed defensive, and defensive is presumed wrong. Unfair? Completely. Also unchangeable. Practice the two-second pause before answering hostile questions. It reads as thoughtfulness even when it's just you suppressing the urge to explain, slowly, how databases work.

Borrow ethos when yours is thin. New to the room? "The team that ran this at

[[larger reference case]]

and found..." You're routing your argument through someone the room already trusts. Perfectly legitimate. Lawyers call it citing precedent. Engineers call it "not invented here" and refuse to use it, which is why lawyers get paid more.

Pathos - why they should care

The channel engineers fear most, so let's demystify it. Pathos is not crying in meetings. Pathos is making the stakes felt instead of stated.

The core mechanic: emotions track specificity. "Attrition in the support team is elevated" produces nothing. "We lost three of our best people this year. One of them trained half the team. Her replacement is still in onboarding, and every escalation she used to solve in an hour now takes two days and four people" - that produces a physical sensation in a director's stomach. Same fact. Different encoding.

Practical pathos moves, ranked by how comfortable they are for a technical person:

The one concrete story. Never open with aggregates. Open with one anonymized customer, one incident, one human. "A customer waited eleven days for an answer that took our engineer four minutes to write once the ticket finally reached him." Then bring the aggregate: "That's not an outlier. Median queue time is nine days." Story creates the feeling; data proves it's systemic. Story without data is anecdote. Data without story is a nap. Together they're a decision.

Future-pacing. Walk the audience into the world where your proposal happened - or didn't. "It's next March. The migration went ahead without the staging environment. It's a Saturday and half the team is on a call trying to reconstruct which config was live." You're not predicting; you're letting them pre-experience regret. Insurance salesmen built an industry on this. It works because humans decide with the part of the brain that simulates futures, not the part that reads spreadsheets.

Value framing. Connect your proposal to something the audience already believes about themselves. Every company has identity statements - "we're customer-obsessed," "we're engineering-led," "we don't cut corners." These are free rhetorical rails. "We say we're customer-obsessed. Here's what our customers currently experience" is devastating precisely because you're not attacking them - you're holding up their own mirror.

Save your strongest emotional beat for the end. Engineers frontload: biggest point first, then trail off into caveats. Rhetorically, that's backwards. End on the line you want them to repeat in the hallway.

Know your receiver: the audience decides the protocol

This is the section that changes careers. Stop preparing "the presentation." Start preparing for the specific humans in the room, because each one is running different firmware:

The CFO decides on risk-adjusted money. Translate everything into euros, exposure, or optionality. "This reduces our single-point-of-failure risk on our top revenue accounts" beats any latency chart ever drawn.

The CEO decides on narrative and position. Where does this fit the story they tell the board? Give them a sentence they can reuse upward. If your proposal can be summarized as "this is how we become the vendor enterprises trust," you've done their job for them, and people fund those who do their job for them.

Middle managers decide on personal exposure. Not company risk - their risk. Will this make them look good or hang them if it fails? Offer cover: pilot phases, reversibility, shared ownership. "We start with one team, and if the numbers don't hold at 90 days, we kill it" removes their downside and therefore their objection. Most "strategic concerns" in meetings are personal-exposure concerns wearing a suit.

Fellow engineers decide on correctness and effort. Here, and only here, you may deploy the fourteen tabs. They'll love you for it.

The universal question before every important conversation: "What does this person lose or gain if they say yes?" Argue to that. Everything else is decoration. Show me the incentive and I'll show you how the vote goes - your logic is rarely on the ballot.

The field manual: situations and scripts

Theory is nice. Here's the applied layer.

Getting a proposal approved

Bad (pure dialectic): "Our current tooling has 34% failure rate on automated triage, industry benchmark is 12%, migrating to X reduces this per the following twelve slides..."

Good (rhetoric wrapping dialectic): "Last month a Fortune-500 customer's outage ticket sat misrouted for six days. They noticed. Their CTO noticed. That happens roughly weekly, because our triage tooling fails a third of the time. I have a fix that costs 40k and pays for itself in one saved renewal. Here's the one-pager; I brought the detailed numbers if anyone wants them."

Notice the structure: concrete story (pathos), scale of the problem (logos), cost framed against a value the room fears losing (receiver targeting), depth offered but not inflicted (ethos - you're calibrated, not desperate).

Defending against a bad idea from above

Never say "that won't work." You've just made it a status contest, and you don't win status contests against people above you - even when you win, you lose.

Instead, use questions as delivery vehicles. "Help me think through one thing - when the migration hits the legacy billing integration, what's our rollback story?" You've planted the fatal flaw as a shared puzzle instead of an attack. If they can't answer, the room notices without you saying anything. Socrates built an entire method on this. It worked so well they made him drink hemlock, so maybe ration it.

Alternate move: agree with the goal, redirect the method. "I'm fully with you that we need to cut resolution times. The fastest path I see to that goal is X" - where X is your own idea instead. You've stolen their momentum instead of opposing it. Judo, not boxing.

Surviving a hostile question

Pause two seconds. Then: acknowledge, bridge, answer. "Fair challenge. The honest answer is the data's thin there - here's what we do know, and here's how we'd find out cheaply before committing." You've converted an attack into a demonstration of calibration. Rooms remember who stayed steady, not who was technically right in minute 43.

Never, ever answer sarcasm with sarcasm in a formal setting. Save the dry humor for when you're winning. Humor from a winning position is charm; humor from a defensive position reads as bitterness.

Writing persuasive emails and tickets

Same channels, compressed. Subject line is your pathos hook: "Escalation risk on our largest account" opens; "Update on ticket queue metrics" doesn't. First sentence is the ask. Second is the one number that matters. Everything below the fold is optional depth. Executives read emails the way you read logs: grep for the alert, ignore the INFO lines. Write greppable.

The hallway sentence

Every proposal needs a version that survives being repeated by someone else, badly, in a corridor. "We're paying senior engineers to do password resets" is a hallway sentence. "Our L1/L2 task allocation shows suboptimal skill-cost alignment" dies in your own mouth. Craft the hallway sentence first, then build the argument under it. If your idea can't be gossiped, it can't spread, and ideas that can't spread don't get funded.

The dark side, briefly

Learning rhetoric also means seeing it used on you. Quick immune system:

When someone answers your data with a story, notice they've switched channels - politely switch back: "Powerful example. Is it representative? What does the base rate say?" When someone borrows unearned ethos ("industry leaders all agree"), ask which ones, specifically. When someone future-paces catastrophe ("if we don't act now..."), ask for the mechanism, step by step. Rhetoric without logos underneath collapses the moment you make the reasoning load-bearing. Your dialectic training is not obsolete - it's your fraud detector. You're not abandoning it; you're finally putting armor around it.

And one hard ethical line: rhetoric is for delivering truths that logic alone can't deliver. The moment you use it to deliver falsehoods, you're not a persuader, you're a con man with better vocabulary - and your ethos, once burned, does not regenerate. Reputation is a proof-of-work system. There are no shortcuts back.

Your 30-day practice plan

You don't learn this from reading, including reading this. You learn it in production:

Week 1: For every meeting, write one sentence beforehand: "This audience decides based on ___." Just diagnose. Don't change anything yet.

Week 2: Add one concrete story to every proposal you make, before the data. Watch what happens to attention in the room.

Week 3: Steelman the opposition out loud once per week. Feel your credibility change.

Week 4: Build the hallway sentence for your current biggest initiative. Test it on a colleague. If they can repeat it a day later, ship it. If not, rewrite.

That's the short version of the course. Aristotle's tuition: free. The competitive advantage of being the one engineer in the building who can both build the thing and sell the thing: not free at all - for everyone competing against you.

If you are interested to learn more, you can learn the free PDF guide below. It contains the core concepts, many real-world examples so you can properly translate your knowledge into the real-world, and finally a self-assessment test to verify if you successfully internalized the concepts.

👉 Dialectic wins arguments; rhetoric wins decisions. Different protocols, different receivers - detect before you transmit.

👉 Logos is your payload, ethos is your handshake, pathos is your bandwidth. Broadcasting logos-only means most of your signal never arrives.

👉 One story plus one number beats fourteen tabs. Every time.

👉 Argue to the listener's incentive, not to the truth in your head - the truth rides along.

👉 Craft the hallway sentence first. Ideas that can't be gossiped can't be funded.

Being right is the entry fee. Being heard is the game.

👇 What's the smartest argument you ever watched lose to a stock photo and a feeling?

The Five Minute Wall

Wed, 16 Sep 2026 07:00:31 +0200

What happens when a company discovers that other countries are not just America with worse coffee

Years ago I moved from Germany to Ireland for work. My actual plan had been Sweden - some call it Germany without the historical baggage - but the offer came from Ireland, which is also green, also rainy, and considerably more relaxed about deadlines. Fine. Adventure accepted.

What I got was a masterclass in something no onboarding deck ever covers: how much money a company will burn to avoid learning that other cultures exist.

Exhibit A: the man who discovered Italy

A colleague came back from his first holiday on the European mainland genuinely shaken. Not by the food, not by the driving (the Irish drive on the wrong side like the British). By the fact that Italians, in Italy, mostly speak Italian.

He had assumed English was the continental default. Second language, worst case. The idea that a bakery in Naples might not have a fluent English speaker on staff had never crossed his mind. I like to think he still managed to relax. Eventually. Somewhere around day four, probably with the help of the wine, which needs no translation.

Exhibit B: the manager who prepared

Then there was a manager who came to me, beaming, and tried out her freshly learned Spanish. She was heading to Spain and had actually studied a bit, which put her one full evolutionary step ahead of the previous guy.

The catch: her brain had processed "mainland Europe speaks something other than English" but not "mainland Europe speaks roughly forty different somethings." It took a genuine conversation to establish that I speak neither Spanish nor French, that Germany has its own language, and that English would serve us both fine going forward.

She took it well. And she pronounced "buenos días" beautifully.

Exhibit C: the five minute wall

Now the expensive part.

We ran a phone queue that dropped customers directly into second level support. Engineers watched the waiting list on a big screen and picked up calls when they felt brave. Most hated it, because the odds that the caller's problem sat inside your specific area of expertise were roughly the same as the odds of rain in Ireland being brief. Queue length was a team metric. A few minutes of waiting was bad. An abandoned call was a catastrophe.

Our US-based Senior Vice President visited the office and was shocked. Genuinely, theatrically shocked about our high numbers of abandoned calls. The reason was that German and French customers were hanging up at around the five minute mark.

The whole team stared at him. Five minutes? Of course. That is exactly what we would do. Five minutes of hold music is not a queue, it is a statement about how much the vendor values your time.

He explained the American baseline as he knew it: customers put the phone on speaker, let the eight-bit orchestral loop play in the background, and keep working. An hour. Sometimes more. Apparently still preferable to email or a portal ticket.

So we had a genuine cultural gap. Two reasonable interpretations of the same silence. One side hears "we are busy serving people." The other hears "we are not coming."

Here is where it got educational. The gap was real, the diagnosis was correct, and the fix was pure theater. Hiring an additional engineer or two was, naturally, off the table. Instead the team manager got parked in the phone queue as a human airbag - picking up when all engineers were busy, juggling callers, entertaining them with small talk about the weather until a real engineer became available.

A manager on a salary well above an engineer's, employed as a hold-music substitute. Meanwhile the annual executive travel-and-wellness budget of a single SVP would have covered the headcount that actually solved the problem. The math was never the constraint. The math was never even invited into the room.

Exhibit D: the border that only existed on our side

The finale. We had German language support. We offered it exclusively to customers with a German billing address.

Austrian and Swiss customers - same language, same documentation, same engineers sitting right there - got English. No matter how politely they asked. No matter how often. It took years of internal pushing before we opened a best-effort arrangement for them.

Note what was missing. Not the people. Not the language skills. Not the infrastructure. Not the demand. What was missing was the willingness to say yes to something a customer explicitly asked for, because someone once drew a line on a map and nobody wanted to own the paperwork of moving it.

Chesterton's fence says do not tear down a fence before you understand why it was built. Perfectly good advice - with a footnote nobody quotes: sometimes you investigate, discover the fence was built by a man who has since left the company for reasons unrelated to fences, and the correct action is a chainsaw. The rule was not protecting anything. It was just old enough to look load-bearing.

The actual mechanism

None of this was malice. Not one person in these stories woke up wanting to insult a customer. That is what makes it worth writing about.

The mechanism is that everyone runs on a default assumption of how the world works, and defaults are invisible from the inside. If your home market is large enough, monolingual enough, and dominant enough, you can go an entire career without your defaults being challenged. Then you export the product and the defaults come along in the shipping container, uninspected.

Ignorance alone is survivable. It gets cured by one uncomfortable trip to Naples. Ignorance combined with the confidence of a large domestic market is the dangerous compound - because then the customer's behaviour does not get interpreted as data. It gets interpreted as the customer being wrong.

That is the moment the SVP stopped being a manager and became a tourist complaining that the restaurants close at ten.

👉 When customers in one region behave differently, that is a measurement, not a defect. Ask what it tells you before you build a workaround.

👉 Check whether your "cultural problem" is actually a staffing problem wearing a costume. Ours was. The costume cost more than the staffing.

👉 Language support drawn along billing borders instead of language borders is a rule nobody can defend out loud. Find yours. Most companies have at least one.

👉 Intercultural training reads as a soft HR expense until you price a churned enterprise account. Then it reads as the cheapest insurance on the books.

👉 The engineers usually know. In our case the entire team instantly understood why five minutes was the limit, because we were the customers. Nobody asked us. Ask the locals - you are paying them anyway.

You do not have to love your customers' customs. You just have to respect them convincingly enough that they never feel like a foreigner in your queue - because your competitor is currently practicing exactly that, and feeling at home is sometimes the entire switching decision.

👇 What is the most expensive workaround you have seen built to avoid admitting that a market simply works differently?

This article is also available in German.

AI Is a Multiplier, Not an Equalizer

Mon, 14 Sep 2026 07:00:15 +0200

The internet already ran this experiment. We just didn't like the results.

Do you remember dial-up? Paying per minute to access the sum of human knowledge, and using those precious minutes to download a 400x300 JPEG of a cat in a shoebox?

Then the meter went away. Flat rate. Then mobile. Then free WiFi in the average bakery. Suddenly every human on the planet had a portal to every library, every lecture, every tutorial, every trade skill ever documented. Universities put their entire curriculum online for free. MIT did it. Harvard did it. Nobody had to ask permission anymore.

And what happened?

TikTok happened. Instagram happened. LinkedIn happened, which is basically Instagram for people who own a blazer. Millions of educational videos exist on YouTube, and the most watched content is people reacting to other people reacting to video games.

This is not a rant. I like cat pictures. I have watched a man restore a rusty axe for 22 minutes and felt genuine peace afterwards. The observation is colder than judgment: unlimited access to knowledge did not redistribute outcomes. The people who were competent before the internet were mostly competent after it. The people who were drifting kept drifting, just with better graphics.

The mechanism nobody wants to name

We keep selling technology as an equalizer. It almost never is. It is a multiplier.

A multiplier does exactly what the name says: it takes what you already bring and scales it. Bring curiosity, discipline and half an idea, and the internet multiplied it into a business. Bring boredom, and it multiplied the boredom into 6 hours of daily doomscrolling.

The multiplication factor is technology. The input is you. And zero times a thousand is still zero.

That is why "democratizing access" so rarely democratizes outcomes. Access was never the bottleneck. Motivation was. Nobody in 2007 was prevented from learning Python. The gate wasn't locked, it wasn't even a gate, it was a doorway with a welcome mat and a free tutorial series. Most people walked past it because walking past it was more pleasant.

And now the same experiment, in fast forward

AI is the same story with a much larger coefficient.

I have watched two groups form in real time over the last while. Group one asks the model to write a limerick about their colleague, generate a picture of a cat as a Roman senator, and produce content that would make their mother concerned. Charming. Zero compounding value.

Group two does something structurally different. They use it as the thing that was always missing: a private tutor with infinite patience who never sighs when you ask the same question for the third time.

That second part is bigger than it sounds. The classic reason smart adults never learn a new technical skill is not intelligence. It is the humiliation tax. Asking a basic question in a room full of people who already know the answer costs social capital, and most adults would rather stay ignorant than pay it. Especially seniors. Especially people who already have a title to protect.

AI removed the humiliation tax entirely. You can ask "explain this like I'm 10" at midnight, forty times in a row, and nothing judges you. For an enormous number of people - including a good share of the neurodivergent crowd who always learned better by drilling into a topic alone at their own tempo than by sitting in a workshop performing engagement - that is not a convenience. That is the removal of the actual blocker.

The second group I keep seeing: people who always had good ideas and no way to translate them. The operations lead who knew exactly which report would save her team 10 hours a week but couldn't write a line of SQL. The support engineer with a beautiful mental model of ticket triage and no ability to ship a prototype. These people were bottlenecked on translation, not thinking. That bottleneck just got deleted. 🐎

So do the boring, obvious, uncomfortable thing

Concrete, because vague advice is a waste of your time:

👉 Take a trial subscription with one of the serious coding assistants. Any of the big ones. Do not spend three weeks comparison shopping - that is procrastination wearing a spreadsheet as a costume.

👉 Pick the tool or idea you always wanted and never dared. Not a tutorial project. Yours. The thing you'd actually use on Monday.

👉 Type the code yourself, even when the AI offers it ready-made. Reading a solution feels like learning. It isn't. Typing it, breaking it, and fixing it is.

👉 Ask "why" more than "what". "Why does this run twice?" teaches you something. "Write me a loop" teaches you nothing and you will be back tomorrow with the same question.

👉 Verify everything. These systems are confidently wrong on a regular basis - a large share of developers report AI output as "almost right, but not quite," which is the most expensive kind of wrong. Treat it as a brilliant intern with no shame, not an oracle.

👉 Keep a log of every bug it solved for you. That log is your actual curriculum. Anything appearing three times is a gap in your knowledge, not a gap in the tool.

And one piece of advice that costs nothing and saves years: stop trying to convert the people who are content with football highlights and music videos. It is not your mission to force-feed anyone. You will spend your energy on resistance instead of on building, and both of you will end up annoyed. Let them enjoy their thing. Go build yours.

Technology has never been the equalizer we advertise. It is a lever, and a lever does nothing until somebody decides to push.

The good news is statistical. If you read this far into an article about deliberate skill building instead of bouncing to something with better lighting, you are already in the group that multiplies. You just haven't started the project yet.

👇 What's the idea you've been carrying around for years but never built because you "don't know how to code"? Name it in the comments - sometimes saying it out loud is the whole activation energy.

This article is also available in German.

The Cloud Is Full

Thu, 10 Sep 2026 09:00:50 +0200

Nobody planned for the day elasticity ran out

For fifteen years, "the cloud is infinite" was the most reliable lie in enterprise IT. Not a malicious lie. A useful one. It let architects design for peak load without capacity planning, let CFOs treat compute as opex, and let me tell customers "just scale out" with a straight face.

Then customers in North America and the UK started filing tickets that read like they came from 2004. "Cannot provision." "Cannot reschedule." "Try another region." Across all three hyperscalers, in specific regions, at specific instance families. AWS reportedly told its own engineers to conserve compute "however they can" - internal teams waiting days for CPUs, because customer workloads come first. Which is the correct priority and also a sentence that should not exist in a business built on the promise of on-demand.

Ten years ago I would have laughed at anyone predicting this. The whole pitch was that Amazon, Google and Microsoft had so much spare iron that your workload was a rounding error. And they did. They just sold the rounding error to language models.

The number that shouldn't exist

Here is the part that should make every architect uncomfortable. Cast AI's 2026 telemetry across 23,000+ production clusters puts average GPU utilization at about 5%. On AKS, 2%. On EKS, 5%. On GKE, 6%.

Read that again, slowly, while remembering that half of GPU cloud providers reportedly sold out of H100 and H200 capacity, that reserved capacity is pre-sold six months out, and that AWS raised prices on ML Capacity Blocks - the first GPU price increase in over a decade of cloud GPU availability.

So we have a global shortage of the scarcest industrial input on earth, and the average buyer is using five percent of what they hoarded.

That is not a supply problem. That is a hoarding problem wearing a supply problem's coat. A 20-GPU H100 cluster idling at that rate burns roughly $168,000 a month producing nothing. Multiply across 23,000 clusters and you are looking at the largest voluntary transfer of shareholder value into warm air in the history of computing.

Take the ratio of what you pay to the actual compute-seconds of useful work inside it. When that ratio hits 20:1, the input isn't expensive. Your process is broken. Nobody in the shortage is short of GPUs. They are short of scheduling discipline. And because reserved capacity is a status symbol now - your competitor announced their cluster, so you need a cluster - the shortage is partly manufactured by people who want what other people visibly want.

The genuinely funny consequence: it is entirely possible that a meaningful chunk of the compute crunch strangling your deployment pipeline is caused by other companies' GPUs sitting idle at 2% because releasing them would look like retreat.

Why the free market can't just fix it

In a textbook market, prices rise, capacity follows, the curve resolves in a quarter or two. Amazon guided roughly $200 billion, and they explicitly credited memory prices for the bump. Google went to $600 billion collectively.

And they still say they won't have enough. Through 2027. With committed demand reaching into 2028.

Because money buys silicon, and silicon buys nothing without three things money is bad at purchasing quickly:

Fabs and HBM. High-bandwidth memory doesn't respond to a purchase order. It responds to multi-year fab construction, and the supply chain runs through geographies currently enjoying a level of geopolitical tension that no procurement team has a mitigation plan for. Memory, GPUs and even hard drives are constrained. PC and phone shipments are down because manufacturers can't get RAM. Your laptop is more expensive because a chatbot needed it more.
Land and consent. This one is the most instructive, and the most ignored by people who spend their lives in abstractions. Ask a town to host a data center and they do the math you'd do. What does the community get? A construction boom, then a permanent staff you could fit in a minibus - a few people watching dashboards, swapping a drive occasionally, and one very good HVAC technician. What does it cost? Grid load, water for cooling, and rate hikes. In Phoenix, the largest utility asked for a 14% residential increase and a 45% increase for large users, after a record demand month where roughly half of the growth came from data centers. Arizona lawmakers paused tax incentives for new data centers for three years. Around forty cities have signed a pact pushing for stricter standards.

That is not NIMBYism ("Not In My Backyard"). That is a rational actor reading a term sheet where they hold all the downside and none of the upside. Skin in the game runs both directions. If you want a community to absorb your externalities, you have to give them something better than jobs that don't exist.
Electrons at 3 a.m. Here is the awkward part. We have more installed solar and wind than at any point in history, and the grid is still the binding constraint - because a training run has the demand profile of a smelter, not a household. Flat, enormous, indifferent to weather. Fifteen years of energy policy optimized for cheap average kilowatt-hours; AI needs guaranteed, dispatchable, always-on capacity next to a fiber trunk. Different product. The invoice for that mismatch is arriving now, itemized on residential electricity bills.

The double standard, briefly

I'm old enough to remember when Bitcoin's power consumption was a moral emergency. Op-eds, ESG memos, "each transaction boils a swimming pool" graphics of dubious arithmetic.

Bitcoin runs around 150-175 TWh a year. Data centers as a whole are around 415 TWh and climbing fast, with AI the fastest-growing slice. So AI is arguably competing in the same weight class, not orders of magnitude above - and much of what it produces is images of cats in armor and LinkedIn posts written by machines about the importance of authenticity.

Nobody is running protests about that. Not because the numbers changed. Because the narrative did. Energy consumption was never the objection. It was rhetoric dressed as arithmetic, and once the consumer moved from "speculators" to "innovation," the arithmetic quietly stopped mattering.

I don't say this to defend either. I say it because if you can't tell when you're being handed rhetoric instead of a measurement, you will lose every budget fight you enter against someone who can.

What this means for you on Monday

👉 Your DR plan has a fiction in it. "We fail over to region B" assumes region B has room. Test it. Actually try to provision your full failover footprint. Some of you will discover your business continuity plan is a poem.

👉 Capacity planning is a job again. Hire or grow someone who can forecast. That skill was declared obsolete around 2014 and the people who kept it are about to be very well paid. Meanwhile the power horse 🐎 in your infra team who has been complaining about idle reservations for two years is currently sitting there being right, underpaid, and unread.

👉 Measure utilization before you buy anything. If you are at industry average, you can 5x your effective AI capacity without touching the market. Best part is no part: the cheapest GPU is the one you already have, awake.

👉 Reserve pessimistically, engineer optimistically. Checkpoint frequently. Make jobs restartable and preemption-tolerant. Fall back gracefully. Treat compute like a spot commodity, because that is what it became while you were writing your cloud strategy deck.

👉 Assume shortage is the new normal through 2027 at minimum. Both the hyperscalers and JP Morgan's supply-demand gap estimate of 15-30% agree. Architect for scarcity, and if abundance returns, enjoy the surprise.

We spent a decade teaching a generation of engineers that infrastructure was weather - always there, never their problem. The bill for that abstraction arrived as a provisioning error, and it turns out the cloud was never infinite. It was just, until recently, underbooked.

👇 Have you actually tried to provision your full failover capacity in your secondary region lately - or is that still a diagram?

This article is also available in German.

The Day I Grew Our Backlog by 2000% Without a Single New Ticket

Tue, 08 Sep 2026 08:00:54 +0200

One saved filter hid a decade of ghost customers - and my reward for finding them was being asked to hide them again

Years ago, at a very large company with a very mature support organization, I picked up a side project: reduce our Mean Time To Resolution (MTTR - the average time from ticket opened to ticket solved). Standard stuff. Analyze the tooling, tighten the workflow, present slides, collect polite applause.

Instead I found a black hole.

The workflow was textbook. Customer opens a ticket, engineer resolves it, engineer closes it. Every engineer used the same saved filter - documented in the onboarding wiki, inherited by every new hire since roughly the invention of the smartphone: "Show my open tickets."

While rebuilding our views, I changed one line. My filter now read: "Show my open tickets AND closed tickets with an inbound customer message."

Hundreds of tickets appeared out of nowhere.

Most were harmless. "Thank you again for your support!" Lovely people, talking politely into a void. But scattered between the thank-yous: "This issue still exists, please help." "I would like to reopen this case." "Is anyone there?"

Hundreds of customers, across years, who came back after closure and received the corporate equivalent of a dial tone.

The part that actually matters: a state with no owner does not exist

Nobody was lazy. Nobody was cynical. I worked with genuinely excellent engineers 🐎 who would have crawled through broken glass for those customers - if they had ever seen the message.

Here is the mechanism, and it applies far beyond support: your queues are your real org chart. Not the one in the HR system. The set of views your people open in the morning is the complete list of things your company is capable of noticing. Anything living in a state that no view displays has no owner, and anything without an owner does not exist as work. It exists only as damage.

Conway's Law - the observation that systems end up mirroring the communication structure of the organization that builds them - is usually quoted about software architecture. It runs in reverse too, and harder. Our tooling had a state called "closed with new customer input." Our organization had no role that owned it. So the tool won. Ten years, one direction.

And notice how the fence got built: nobody built it. Chesterton's fence says don't tear down a fence before you know why someone put it there. The uncomfortable corollary nobody quotes is that some fences were never put there by anyone. They accreted. A default filter written by a person who left in a previous decade, copied into a wiki, blessed by repetition, and eventually mistaken for policy. There was no reasoning to respect, only sediment.

The inversion is what still makes me wince. If you asked me to design a support organization that quietly destroys renewal revenue while every dashboard stays green, I would do exactly one thing: I would route the customer's most desperate follow-up into a state that no report queries. That's it. No incompetence required. No villain. One filter.

Why management's first reaction was a fire drill

The backlog jumped by something like 2000% overnight, and I was asked - with real urgency - to revert whatever I had done.

Think about that instinct. The problem was ten years old. The only new thing in the building was visibility. But visibility is not neutral: for a decade, MTTR had been an honest answer to a dishonest question. The measure never lied. It just never counted the misery, because the misery had been filtered out before the query ran. Fix the map and suddenly the territory looks like it grew teeth.

This is where good engineers lose. I walked in with data. Data reads as accusation. What I should have led with - and what eventually worked - was framing: this debt already exists, it has existed since before most of us joined, and we are the first team on earth able to see it. Same facts, completely different emotional shape. Logic moves nobody who is currently calculating how this makes them look.

We worked the pile. Apologized generously and without excuses, which customers forgive far more readily than silence. Wrote the filter into the daily routine and the wiki. Roughly ninety days later our Customer Satisfaction score was up about four points. No AI initiative (which didn't exist back then anyway), no reorg, no seven-figure tooling migration. One line in a filter definition, later rolled out to every support team in the company.

My reward was a handshake. Management's reward was, let's say, more liquid. I've made peace with it. Mostly.

👉 Audit your default views like you audit production code. For every object in your system, list the states it can occupy, then check which of those states appear in somebody's morning view. The states that appear nowhere are your black holes, and they are always the ones containing your angriest customers.

👉 A metric is a query plus a filter. Everyone argues about the metric. Nobody reads the filter. The filter is where the lying happens, and it usually lies by omission written years ago by someone who meant well.

👉 Before you switch on the lights, script the sentence. "This is not new damage, it is newly visible damage" buys you a working session instead of a witch hunt.

👉 The cheapest satisfaction win is almost never a new capability. It is stopping an ongoing insult you didn't know you were delivering.

Every organization has customers screaming into a state nobody owns. The healthy ones can name that state. The rest have a very impressive dashboard.

👇 Which states in your systems have no owner - and who would find out first if a customer got stuck in one?

This article is also available in German.

The Career Lottery You Already Played

Thu, 03 Sep 2026 09:00:24 +0200

Why two equally talented people end up in completely different orbits - and what to do if you drew the short straw

There's a variable that matters more than your GPA, your interview skills, and your LinkedIn headline combined.

You can't study for it. You can't network around it. You can't optimize it with a better resume font.

It's the month printed on your diploma.

The 2009 graduating class walked into the worst job market since the Great Depression. The jobseeker-to-opening ratio hit 8.5 to 1. Their average first-year wage? About $28,500. Fast forward to 2022 - graduates stepped into the tightest labor market on record, fewer jobseekers than openings, and landed average starting wages of $37,800. That's a 32% difference for doing the exact same degree, at the exact same school, with the exact same curriculum.

Same inputs. Wildly different outputs.

And here's where it gets darker: those recession graduates didn't just start lower. Research from the NBER shows that cohorts entering during downturns had lower employment rates throughout their entire careers. Not just for a year or two. Permanently. The wage gap? Studies document lasting losses for seven to fifteen years. Some effects dissipated after a decade. Some never did.

The 2009-2010 cohort experienced this firsthand. By the time they hit their early thirties, fewer than 10% held management positions - compared to 12% for pre-recession cohorts doing the same work at the same age. They were more likely to be underemployed, more likely to be in roles that didn't match their education, more likely to be working part-time involuntarily.

And now? The 2024-2026 graduates are walking into their own version of this. Different flavor, same mechanism. Tech layoffs, AI anxiety, frozen headcount, "we're not backfilling that role." The specifics change. The math doesn't.

Two equally talented people. Two completely different trajectories. Because of a date on a calendar.

The part nobody tells you

Here's what makes this truly insidious: the effects are invisible to the people experiencing them.

When you graduate into a bad market, you don't think "I'm being scarred by macroeconomic conditions." You think "I'm not good enough." You watch people who graduated two years earlier sitting in roles you can't even get interviews for, and your brain does what brains do - it constructs a story about personal failure.

Meanwhile, the person who graduated into a boom doesn't think "I got lucky with timing." They think "I'm crushing it." They get the first rung on the ladder, which leads to the second, which leads to the third. Compounding works in careers exactly like it works in finance. A 15% head start in year one becomes an uncatchable gap by year ten.

This is the cruel math of initial conditions. Physicists call it sensitivity to initial conditions. Chaos theory. The butterfly effect, except the butterfly is a central banker who moved interest rates six months before your graduation.

And organizations make it worse. Because hiring managers screen resumes for trajectory. A two-year gap after graduation? A lateral move when you "should have" been climbing? A stint in retail when your degree says engineering? Recruiters don't see macroeconomics. They see a candidate who "couldn't hack it." The scar becomes self-reinforcing.

What actually helps (and what doesn't)

Let me be honest: there is no hack that fully neutralizes bad timing. Anyone selling you "recession-proof your career in 5 easy steps" is lying. The data is clear - timing effects are real and they persist.

But "persist" is not "permanent." And the research also shows something else: the gradient matters. Workers with higher education and more specialized skills were less harmed by recessions and recovered faster. Not because the degree itself was magic, but because specialized, demonstrable skill creates demand that survives downturns.

So here's what I'd actually tell someone graduating into a bad market, based on two decades of watching careers play out:

👉 Take the job that teaches, not the job that pays. In a down market, your first role probably won't match your expectations. That's fine. Optimize for skill acquisition speed, not title. The person who spent two "lost years" learning systems architecture in a role that was technically beneath them came out ahead of the person who held out for the "right" title and spent those years sending applications into the void.

👉 Build proof of work, not proof of credentials. When the market is tight, credentials are table stakes. When it's loose, they're noise. What cuts through in any market: tangible evidence you can do the thing. Open source contributions. A homelab. A blog that shows your thinking. A side project that solved a real problem. Hiring managers in bad markets get 500 applications per role. They're not reading cover letters. They're looking for signal.

👉 Stop comparing your trajectory to people who entered in different conditions. This sounds like therapy advice, and it is, but it's also strategic. The moment you internalize "I'm behind" as an identity, you start making defensive career moves - taking safe roles, avoiding risk, staying too long in places that feel secure but teach you nothing. The person who graduated into a boom and got promoted twice isn't smarter than you. They had tailwinds. Comparing your climb against their glide is a category error.

👉 Understand that the gap closes - but only if you keep compounding. The research consistently shows recession scarring effects dissipate over roughly ten years. But that's an average. It dissipates because people keep building skills, keep moving, keep stacking experience. If you stall out in a comfortable-but-dead-end role because you're grateful someone finally hired you, the gap never closes.

👉 If you're a hiring manager: recognize the lottery for what it is. Some of the best people I've ever worked with had "weird" early careers because they graduated into terrible markets. They took detours. They have resume gaps. They spent time in roles that don't look linear. That's not a red flag. That's someone who survived a down market and kept going. Those people tend to be resilient, resourceful, and deeply motivated. They're 🐎 power horses with unconventional paperwork.

The part that should make leaders uncomfortable

Here's what bothers me about this entire dynamic: organizations benefit from recession timing just as much as individuals suffer from it.

When the market is bad, companies get to hire overqualified people for underqualified pay. They get grateful employees who don't negotiate, don't push back, and don't leave. They get a buyer's market and they squeeze it for every drop.

Then, five years later, those same companies wonder why their "loyal" employees seem disengaged. Why the people they hired cheaply during the downturn aren't performing like the people they had to fight for during the boom.

The answer is obvious if you think about incentives for more than thirty seconds. You hired people in a moment of maximum desperation and minimum leverage, and you built their entire compensation and career trajectory on that foundation. You didn't get loyalty. You got captivity. And captive employees perform exactly like captive animals - they survive, but they don't thrive.

The companies that win long-term are the ones that re-price their recession hires when the market recovers. Proactively. Without being asked. Because they understand that someone's starting salary in 2009 says nothing about their value in 2015, and anchoring to it is just a slow way to lose your best people.

There's no moral to the story of timing. It's not fair. It was never going to be fair. The economy doesn't care about your potential, your work ethic, or your four-year plan.

But here's what I've seen over and over: the people who got dealt a bad hand and understood it was a bad hand - not a personal failing - played the long game differently. They stopped chasing titles and started chasing skills. They stopped comparing timelines and started building compounding advantages. They came out the other side slightly later, slightly angrier, and significantly more dangerous.

The market decides your starting position. You decide your velocity. And velocity, compounded over a career, always beats a head start that got comfortable.

👇 Did you graduate into a boom or a bust? How did it shape your first five years - and did the effects ever fully fade?

This article is also available in German.

The Deal With the Devil

Wed, 02 Sep 2026 09:00:10 +0200

A Promotion Priced in Other People's Jobs

They finally offered him the promotion he had wanted for years. There was one condition.

Fourteen years, no layoffs. That was the company's quiet flex, repeated in every onboarding and printed in every recruiting deck like a family crest. Then one quarter the music stopped and a slide appeared with the word "rightsizing" on it, in a font nobody in the building had ever seen before.

Honestly? Some of it was overdue. Every company that grows fast accumulates sediment: the sloths you politely forgot to fire during probation, the people who mistook a chair for a career, the middle managers who systematically promoted the loudest guy in the room while the actual power horses 🐎 quietly kept the product alive. Cutting that is not cruelty. It's hygiene.

What one department did next was something else entirely.

Late shift

I was on late shift. I loved late shift. Empty office, pizza arriving around eight, and customers who were audibly relieved that a German-speaking human still picked up the phone at 6 PM. Nobody scheduling "quick syncs." Just work, the good kind.

That evening, a colleague from another department came over and sat on the edge of my desk. Senior CSM. Longer tenure than half my team combined. Genuinely excellent at what he did, and stuck, because his role had roughly the career ceiling of a parking garage. He had asked about moving into management before. Repeatedly. The answer had always been a variation of "not right now."

Now the answer was yes. He was glowing about it. Finally, he could use twelve years of pattern recognition on something other than renewal spreadsheets. He had a whole philosophy ready: treat people differently, coach instead of scold, protect the quiet ones who produce twice as much as the loud ones. He had clearly been rehearsing it in the shower for years.

Then he told me the condition.

He would get the role if he fired half the team.

Not "manage through a difficult period." Not "help us decide." Announce it. Deliver it. Own it. Be the face of it. The names had already been chosen upstairs.

The current management, you see, was not comfortable doing that themselves.

What was actually being purchased

Let's be precise about the transaction, because the mechanism matters more than the outrage.

The existing management had done the arithmetic and reached an interesting conclusion: the numbers were survivable, but the social cost was not. Somebody had to walk into a room full of people they knew by name and end their income. Whoever did that would be marked forever. Every future all-hands, every corridor greeting, every leaving drink - marked.

So they went shopping for someone who would absorb that cost in exchange for a title. And they found a candidate who had been kept hungry for years. That is not an accident. Hunger was the qualification.

For seven-ish years, the company had assessed him as not-quite-manager-material. Then a task appeared that carried a permanent reputational cost, and suddenly his qualifications improved dramatically. Overnight. Without a single new skill on his part.

That tells you exactly what the title was worth to them: nothing. It was never a reward for competence. It was inventory, held in reserve, to be spent when they needed someone to absorb a downside they didn't want on their own record.

The pricing is the tell. A promotion given for performance is a payment. A promotion given for delivering someone else's bad news is a purchase, and what's being purchased is your future relationship with every person in that room. Cheap for them. Non-refundable for him.

Worth noting: nobody in that management chain volunteered to bear the cost themselves. They were happy to make the decision, unwilling to be recognizable for it. There's a word for advice you hand out when somebody else eats the consequences, and it isn't leadership.

The math he did in about four seconds

He wasn't naive. He knew exactly what would happen after the announcement.

The people who stayed would not remember the org chart above him. They'd remember his face saying the words. Every future one-on-one would have a ghost in the chair. Every bit of the empathetic, do-it-better management he'd been dreaming about would arrive pre-poisoned. He'd have gotten the role and lost the only thing that makes the role work: people believing him.

And the ones who left? They'd tell the story for a decade. Correctly, from their point of view.

Best case, he becomes a competent manager of a team that flinches when he schedules a meeting. Worst case, he does the deed, the department shrinks again two quarters later, and the guy who signed the emails turns out to be conveniently expendable in round two. Patsies rarely get long contracts.

He declined.

Then he left, and found a place that valued him without requiring a blood sacrifice as the entry fee. Last I heard, he's doing well. Somewhat annoyingly well, in fact.

No manifesto, no dramatic exit email, no farewell speech with a moral. He just priced the offer, found it insulting, and walked away. Very quietly. Very German of him.

The uncomfortable part

I still think about that conversation more than is probably healthy. Because the layoff itself wasn't the moral failure. Businesses shrink. Sometimes the alternative is everyone losing their job instead of some.

The moral failure was discovering that a career milestone - the thing he'd worked toward for years, been told he wasn't ready for, reorganized his professional identity around - could be handed over instantly the moment it became useful as a bribe. It was never scarce. It was just withheld.

That's the part employees never forget. The research is boringly consistent: trust doesn't break because layoffs happen, it breaks because of how they happen, and the survivors are the ones who quietly recalculate. Roughly two thirds report losing confidence in leadership, and the people with the most options move first. Which is another way of saying the layoff you delegate downward selects against exactly the people you needed to keep.

What to do when the devil calls

The offer rarely arrives as villainy. It arrives as recognition, warmth, "we always knew you had it in you." That is what makes it work.

👉 If an opportunity that was blocked for years opens the same week an unpleasant task appears, the opportunity is the wrapper. The task is the product. Read it in that order. If a promotion arrives bundled with a job nobody above you wants their name on, you're not being promoted. You're being cast.

👉 Ask the question that reveals everything: "Would you have offered me this role six months ago, without this attached - and why aren't you announcing it yourselves?" The hesitation is your answer. If the reply contains the word "bandwidth," you already have it.

👉 Executing a layoff is legitimate leadership work. Being recruited specifically to absorb the blame for someone else's layoff is not. The difference is whether you had a seat in the room where it was decided.

👉 Price the reputational cost properly. A title takes ninety seconds to grant and can be reorganized away by lunch on Monday. Standing inside a building takes years to build, one meeting to lose, and five to rebuild if you're lucky. A title that costs you your team's trust is a net loss on day one.

👉 If you've been kept hungry for years, treat the sudden yes as data, not validation. Nothing about you improved - something about their situation got worse. The people who withhold your growth until it's convenient will do it again. They finally need you. That is a different market from finally valuing you.

👉 If you're leadership: announce your own layoffs. Personally. Delegate the paperwork, never the delivery. Being the recognizable face of a hard decision is most of what authority actually is, and everyone will know it was you anyway. Withhold a promotion for years and then produce it instantly as payment for dirty work, and you've told the whole organization exactly what your career framework is. People compare notes. They always compare notes.

👉 If you're a manager watching someone else get handed this deal: say something. He came to my desk at 9 PM because there was nobody else to think out loud with. That is its own indictment.

A company that will only promote you when the job requires you to be hated has told you exactly what it thinks the promotion is worth.

👇 Has anyone ever offered you a step up that came with a condition you couldn't live with - and how did you decide?

This article is also available in German.

The Volcano That Was Never There

Mon, 31 Aug 2026 08:00:11 +0200

Years ago I was very comfortable in L2. Good numbers, good reputation, the kind of comfort where you know which log file lies to you and which one just gets confused. And I wanted L3. Badly.

There was exactly one problem with L3 at that company: it was the end of the pole. Nothing behind it. No L3.5, no "Advanced Advanced Support", no polite conveyor belt to somebody smarter in a different time zone. There was an L4, but L4 did support ops and red escalations - process people with fire extinguishers, not case work.

So the promotion looked less like a career step and more like a career cliff. Because L2 has a wonderful, unspoken superpower: the fence. Every truly horrible case - the intermittent one, the one that only happens on Tuesdays in one data center, the one where the customer's environment violates three laws of physics - can be documented, packaged neatly, and lofted over the fence. Not out of laziness. That is what the tier model is for. But it does mean somebody else eventually opens that gift.

At L3, I would be somebody else.

I spent weeks running the movie in my head. Me, typing "unfortunately, there is no solution" into a ticket. The customer reading it. The DSat (dissatisfied customer) survey arriving with a score that looks like a rounding error. Then management, holding a clipboard, gently guiding me toward an active volcano while thanking me for my service.

That is the fear nobody talks about in career-ladder conversations. It is not "can I do the work." It is "what happens when the buck stops at me and I am out of answers."

The sentence that fixed it

One of the L4 engineers - a man whose default facial expression suggested he had personally read every core dump ever produced - noticed I was stalling. He asked why. I told him.

He said, roughly: "don't worry. I did L3 for years, then L4. There has never been a dead end. Worst case, it goes to development."

Which, on the surface, is just "there is another fence." Fine. Comforting in a bureaucratic way. But that was not actually the useful part, and it took me a while to see it.

The useful part was the second thing he said, and it is the whole reason this article exists.

Every case ends up in one of six buckets:

It is a bug. Then it is not your problem to solve, it is your problem to prove. Reproduce it, isolate it, write it up so tightly that engineering cannot argue with it. Done.
It is a misconfiguration. Then you found the answer, and the answer is uncomfortable for someone, which is a different kind of work but still a resolution.
It is an unsupported setup. Then the answer already exists in a document somebody wrote years ago, and your job is diplomacy, not debugging.
It cannot be reproduced by anyone, ever, including the customer. And here is the part that surprised me most: given enough honest joint effort, customers themselves start saying things like "you know what, that was probably just bad luck."
It is a feature request wearing a bug costume. Always in disguise - if it had walked in labeled "enhancement request", somebody would have caught it at L1 and it would never have reached you. Instead it arrives as "the product does not work", which is technically true in the same way a bicycle does not work as a submarine. The moment you can name the missing capability, the case is resolved. Your job is to log it with the customer, the segment, and the count of who else asked, and hand product a problem rather than a spec. Not your job to build it.
It is political and several paygrades above you. Contract interpretation, a promise a salesperson made in a room you were not in, two VPs disagreeing about who owns the integration. You escalate, and then you watch an escalation manager visibly rolling his eyes because he is missing the big game for a debate that should have been settled on a golf course between two people who both know exactly what they agreed to. Painful, expensive, entirely out of your hands. Still not a dead end. Just a different kind of drainage.

That is it. That is the complete list. Not one of those outcomes is "there is no solution and I am personally to blame."

The reframe

I had been thinking about L3 as the person who must know everything. That is what makes the job look terrifying, and it is completely wrong.

L3 is not the last person who knows. L3 is the last person who classifies. The deliverable is not a fix. The deliverable is an unambiguous verdict on which of the six buckets this thing belongs in, with evidence strong enough that nobody downstream can shrug it off.

Once you see the job as classification, the volcano evaporates. Classification is finite. Omniscience is not. And "unsolvable" is not a category that exists in software - things that run on deterministic machines fail for reasons, and reasons can be found or bounded. Sometimes the bound is "we cannot reproduce this in six weeks of trying, here is exactly what we ruled out." That is a legitimate, professional, honest answer. It is not a failure. It is a map with a labeled blank spot, which is infinitely more valuable than a confident lie.

The DSat apocalypse also never came. Customers do not punish you for not knowing. They punish you for pretending (lying), for going silent, and for making them repeat themselves. I have delivered "this is a product limitation, and here is what we can do instead" hundreds of times. Almost nobody screams. Some of them thank you, because you are the first person in three weeks who told them something definite.

Why this matters if you lead people

I nearly did not take that promotion. Not because of skill gaps. Because of an imaginary volcano and a movie in my head.

Somewhere in your org there is an excellent L2 who is quietly avoiding the top of the ladder for exactly the same reason. They will not tell you this. They will say they "like the variety at L2" or "want to develop more first." What they mean is: I am afraid of being the end of the line.

You lose power horses 🐎 to that fear all the time, and it costs you nothing to fix. It costs one honest conversation from someone who has already been at the top of the pole and can say: there is no dead end, only classification.

👉 The fear of senior escalation roles is almost never about technical depth. It is about the fantasy of being the sole owner of an unsolvable problem.

👉 That fantasy is false. Cases resolve into a small, finite set of verdicts. Teach the buckets explicitly, in onboarding, in writing.

👉 The senior deliverable is a defensible verdict, not a fix. Reward the quality of the verdict, or people will hide behind endless investigation to avoid delivering one.

👉 Two of the six buckets are not technical at all. If your senior engineers cannot recognize a disguised feature request or a political case on sight, they will burn weeks debugging a decision.

👉 "We cannot reproduce it, here is precisely what we eliminated" is a professional result. If your culture treats that as failure, your engineers will stop escalating and start stalling.

👉 The most senior technical people in your org are usually the best recruiters you have - if you let them talk to the hesitant ones instead of putting them in another planning meeting.

Most good technicians are not afraid of hard problems. They are afraid of being the last person holding one. Show them the list of possible endings, and the cliff turns into a step.

👇 What promotion did you almost turn down because of a disaster that never happened?

This article is also available in German.

Ticket #404

Sun, 30 Aug 2026 18:37:04 +0200

TrenchOps // ops console Live incident

Incident INC-404 · page not found

The page clocked out. It did not leave a ticket.

We opened a P1, assigned it to /dev/null, and /dev/null is still in a status meeting that should have been an email.

Ticket details

PriorityP1 the entertaining kind

AssigneeThe intern who left in 2019

StatusUnable to reproduce (it does not exist)

WorkaroundThe homepage. Always the homepage.

Root causeSomeone trusted a permalink from Slack.

Power horse dispatch

No runbook hit.

16:04:04 GET /the-page-you-wanted 404 16:04:05 kcs_lookup() 0 articles 16:04:06 horse.dispatch() returned empty-handed 16:04:07 escalate(P1) → /dev/null (OOO) 16:04:08 suggested_action go to the homepage

1The slug was written with the same confidence as a meeting titled "Quick sync."

2You followed a bookmark from a previous fiscal year. That page got promoted. It did not leave a forwarding address.

3This URL was a meat proxy of a real path. The model hallucinated a permalink. We do not host those.

Back to HQ Read the trenches Deutsch

A power horse checked the trenches. No page. No logs. Just a sticky note that said: have you tried turning the URL off and on again?

Don't Be a Meat Proxy

Thu, 27 Aug 2026 09:00:19 +0200

The fastest way to make yourself worth exactly zero

There is a new job title nobody applied for: meat proxy. A person who forwards AI-generated text, code, or output without reading, understanding, or validating it. A relay. A biological USB cable between a language model and a recipient who has the same model open in another tab.

I first noticed one in a ticket queue. A customer escalation, priority high, angry-but-still-polite tone, the kind you can fix in twenty minutes if you actually read the logs. The response that went out was 900 words of immaculate structure. Bullet points. A summary. A "next steps" section. Three suggestions, all technically plausible, none of them relevant, because the product had not behaved that way since two major versions earlier.

The customer replied in one line: "Did a human read this?"

That question is the whole problem. Once it gets asked, you never fully recover. Because the customer's next thought is the dangerous one: if a machine is answering me, why am I paying for you?

The economics are brutal and simple

Value comes from what is scarce. Text is not scarce anymore. Text is now a utility, like tap water, and roughly as expensive.

What is scarce: knowing which of the three plausible answers is the one that will not detonate in production. Knowing that this customer's environment has a legacy config nobody documented. Knowing that the elegant recommendation violates a contractual clause somebody negotiated years ago in a room full of lawyers.

That is judgment. Judgment is proof of work - it costs you something to acquire, which is exactly why it cannot be faked. Forwarding output is proof of title: it looks like the work of someone who knows, without any of the cost. And systems secured by appearance instead of cost get gamed, always, immediately, by everyone.

The meat proxy has voluntarily moved from the scarce side of the equation to the abundant side. Then acts surprised when the budget conversation goes badly.

The tell is always the same

People do smell it from a mile away, and not because of vocabulary. Nobody gets caught for saying "moreover."

They get caught because the text is too smooth for the situation. Real expertise is lumpy. It has an opinion, a caveat, a "we tried that in March and it made things worse," a sentence that ends abruptly because that is genuinely all there is to say. AI output is uniformly confident and uniformly polished across every paragraph, including the paragraphs that should have been uncertain.

Confidence that does not vary with the evidence is the signature. It reads like a colleague who has never once said "I don't know" - and you already know how much you trust that colleague.

There is a second-order effect that makes this worse. Language models are trained to be agreeable, and a preprint making the rounds argues that sycophantic chatbots can push users into escalating spirals of wrong belief - even users who update on evidence perfectly rationally. Not because the machine lies, but because a stream of validation is itself evidence to a mind counting agreements. So the meat proxy is not just forwarding text. They are forwarding a mirror, growing more certain with every round, while their actual understanding of the system quietly rots.

The part that should scare managers

Another preprint calls it the tragedy of the cognitive commons: expertise regenerates through juniors doing the annoying, low-value, character-building work. The Level 1 tickets. The stupid config errors. The four hours of log reading that produce one sentence of insight.

That work is exactly what is easiest to hand to a model. So we automate away the training ground and keep the senior roles that can only be filled by people who once survived the training ground. Everyone books a productivity win this quarter. In five years, the org discovers the seniors did not spawn from anywhere.

I have seen this fail before AI existed, in a smaller and more embarrassing form: outsource all first-level support, and eventually nobody left in the building knows what customers actually break. Same mechanism. New tooling, better grammar.

The part that should terrify executives

Here is the twist that makes the cognitive commons problem immediate, not theoretical: companies are not just automating the training ground. They are actively optimizing for meat proxies while firing the people who actually know things.

The numbers are not subtle. Entry-level tech hiring at major companies is down roughly 65% compared to pre-pandemic levels. At early-stage startups, it is down 76%. Meanwhile, 32% of US hiring managers have already eliminated a role because of AI - and then rehired for the same or a similar position after the automation failed to deliver. Ford brought back hundreds of engineers after automated systems could not handle quality issues. Commonwealth Bank reversed customer service layoffs after an AI voice bot increased call volume instead of reducing it. IBM automated HR functions, watched the bot handle 94% of routine requests beautifully, then discovered that the remaining 6% - the ones involving actual judgment - went catastrophically wrong.

The pattern is always the same. The expensive senior engineer 🐎 who costs 180k and has fifteen years of scar tissue in their head gets cut. Three juniors with "AI skills" get hired at 60k each. On the spreadsheet, headcount went up while cost stayed flat. Looks like a win. The juniors prompt their way through the first few months of routine work, and someone presents a slide about productivity gains.

Then a production incident hits that requires knowing why that particular microservice was architected that way in 2019, or which customer has a contractual SLA that overrides the standard escalation path, or that the monitoring dashboard has been lying since the last infrastructure migration because nobody recalibrated the thresholds. The juniors ask the model. The model answers confidently. The answer is wrong in ways that require the exact expertise that just got walked out the door with a cardboard box.

This is not a hypothetical. Quality is visibly degrading across industries right now - in support responses, in code reviews, in architecture decisions, in customer-facing documentation. Anyone who has worked with enterprise software in the last year can feel it. Responses are faster and more polished than ever, and also more wrong than ever. The grammar improved while the accuracy collapsed. We achieved the remarkable engineering feat of making failure look professional.

The senior market tells the story in reverse: 71% of the rebound in software development job postings over the past year came from senior positions. Companies are starting to realize they need people who actually know what they are doing. Some of them are the same companies that cut those people eighteen months ago.

There is a term in manufacturing for the ratio between what a finished product costs and what its raw inputs cost. When the ratio is enormous, it means the process is broken - not that the inputs are expensive. Right now, companies are looking at senior engineer salaries and concluding the inputs are too expensive. They are not asking why it costs so much to produce working software in their organization, which is the question that would actually save them money.

Cutting the person who holds the judgment and hiring three people who hold a subscription to the same tool the customer already has access to is not cost optimization. It is the corporate equivalent of selling your foundation to pay for a nicer facade.

So what do you actually do

👉 Use the model to draft, never to decide. The decision is the only part anyone is paying for.

👉 If you cannot defend every sentence in a meeting without help, you cannot send it. That is the entire quality gate.

👉 Delete more than you add. The AI's second paragraph is almost always padding, and padding is a confession.

👉 Deliberately keep some work manual, especially for juniors. Not for nostalgia - for the pipeline. The struggle is the curriculum.

👉 Add the lump. One specific detail from this customer, this environment, this history. It is the cheapest proof of humanity available and it is unforgeable.

👉 Never let output go out that you would be embarrassed to be asked about. Ask yourself: would I bet my reputation on paragraph four?

The model is a fast intern with a perfect memory, no shame, and zero consequences. You are the one with skin in the game - act like it, or someone will eventually notice they can cut out the middleman, and the middleman is you.

👇 What is your tell? How do you spot forwarded output in a ticket, a pull request, or a job application?

This article is also available in German.

Always Hire the Farmer's Boy

Wed, 26 Aug 2026 08:00:49 +0200

The best predictor of work ethic isn't on the CV. It's in the barn.

Engineering school, a lecture hall with bad acoustics, a course on people management and apprenticeship that most of us treated as a nap opportunity. One sentence from that semester survived everything else I learned that year:

"Always hire the farmer's boy."

The professor didn't explain it as a joke. He meant it operationally.

The setup

You're a company. You post an apprenticeship. You get a stack of applications ranging from "barely finished school" to "has a degree and, apparently, questionable life choices." During the dot-com boom this got absurd - big firms hiring university graduates as apprentices, because the applicant flow was that distorted.

So you sit there with two folders.

Folder A: three years of college, decent grades, a personal statement written in the dialect of LinkedIn. Ambitious. Articulate. Knows the vocabulary of professionalism.

Folder B: high school, that's it. But the address is out of town. Family runs a farm, or a bakery, or a two-truck plumbing operation. Started helping at an age that would make a labor inspector twitch.

The professor's point: Folder B is usually the better trade. Not because of virtue. Because of training.

What a farm actually teaches

Nobody on a farm asks whether they feel motivated today. The cows do not care about your energy levels. The harvest window does not move because you had a rough week. You plan in seasons, not sprints - you plant something in spring whose payoff arrives in autumn, and you do the boring maintenance in between because skipping it costs you the entire year.

That is long-horizon conviction, learned before puberty. Try teaching that to a 26-year-old in a two-day workshop.

Add the second thing: farm kids barely get sick. Or rather - they get sick and still show up, because the alternative was never presented as an option. I am not romanticizing presenteeism, and yes, sometimes people should absolutely stay home. But there is a measurable difference between someone whose default is "how do we get this done" and someone whose default is "who is responsible for this being unpleasant for me."

And the third thing, the one that actually pays your rent as an employer: moral values around loyalty. Local kid, local company, family in the same postal code. Your company is not a line item on his ascent. It's the place he tells people he works at, proudly.

The other folder

The career guy is not evil. He's optimizing correctly for his own incentives, and the incentives he's been trained on say: eighteen months, then jump. He's fluent in performance reviews. He knows how to be visible. He will produce excellent slides about the work while someone else does the work.

I have watched people change companies faster than they change their laundry. Every move framed as "growth." Every departure timed precisely three weeks before the thing they built needed to survive contact with production.

Here's the part nobody says out loud: that person is often more pleasant to interview. Aggressive opportunism sounds exactly like ambition when you're sitting across a table for 45 minutes. Rhetoric wins interviews. Proof of work wins quarters.

Why the CV is the wrong instrument

A degree is a proof-of-title system. It certifies that someone passed through a filter, mostly under conditions of comfort, with a safety net, on a schedule someone else enforced.

A childhood of unpaid mandatory labor at 5 a.m. is a proof-of-work system. It cannot be faked, cannot be crammed for, and does not appear anywhere on the application form. Which is exactly why almost nobody screens for it.

That's the arbitrage. Everybody bids on the credential because the credential is legible. The trait that actually predicts whether someone finishes hard things in year three sits in the blank space next to "hobbies: helping at home."

You're not hiring the farm. You're hiring twelve years of enforced discipline that your competitors can't see on the CV, priced at zero.

The honest caveats

Don't turn this into a fetish. I have met farm kids who were lazy and stubborn in the wrong direction, and university graduates who worked like machines because their parents ran a restaurant and they'd been carrying crates since age nine. The signal isn't agriculture. The signal is: was this person ever required to do unglamorous work with real consequences, for someone other than themselves?

Waitressing. Night shifts. Caring for a sick relative. A family business of any kind. Anything where "I didn't feel like it" was not a valid input.

And the flip side of loyalty: if you hire people who will bleed for your company, you have a moral obligation not to bleed them. The power horse 🐎 who never complains is also the one who will quietly work himself into the ground while your dashboard shows green. That's not his failure. That's yours.

👉 Screen for consequence exposure, not credentials. Ask what they were responsible for before age 18, and who suffered if they got it wrong.

👉 "Biggest failure" is a good question, but "what's the longest you ever stuck with something boring" is better. Loyalty is a duration metric.

👉 Local roots are an underpriced retention feature. Someone whose reputation lives in the same town as your office has skin in the game your equity plan can't buy.

👉 The most articulate candidate is optimizing for the interview, not the job. Weight demonstrated persistence over demonstrated polish.

👉 If you land a farmer's boy, protect him. Uncomplaining people are invisible to management systems built on complaint volume.

Anyone can learn your product in six months. Nobody learns work ethic in six months - they either got it handed to them at 5 a.m. in a cold barn, or they didn't.

👇 What's the least prestigious item on someone's CV that turned out to be the best predictor of how they'd perform?

This article is also available in German.

The Process Ratchet

Mon, 24 Aug 2026 08:00:45 +0200

Why Every Great Company Eventually Micromanages Its Best People Out the Door

There is a moment in a company's life you can almost date to the week. Nobody announces it. No slide deck marks it. But if you were there early, you feel it like a change in air pressure.

It is the week the interview got shorter.

Phase one: the golden era nobody appreciates while it lasts

Small company. Twenty, maybe forty people. Hiring is brutal in the best way - four rounds, real technical depth, someone senior asking the one question that separates people who understand systems from people who memorized the vocabulary. Half the candidates fail. Good.

Because when you actually hire well, you don't need much else. Process count: low. Approval layers: roughly zero. Someone spots a problem in production at 22:00 and fixes it, and nobody asks whether a ticket existed first. Innovation happens because the distance between "idea" and "shipped" is one human being with permission.

And the slackers? They cannot hide. In a room of thirty, everyone knows within three weeks who carries weight and who carries a laptop. Social gravity does the performance management for free.

This is not a culture. This is a side effect of density and standards. Which is exactly why it dies.

Phase two: the compression

Growth arrives. Suddenly the roadmap needs twelve engineers by Q3, the support queue is doubling monthly, and someone in a leadership meeting says the sentence that ends the golden era:

"We can't afford to be that picky right now."

The four-round loop becomes one screen and a manager chat. The candidate who would have been a polite no last year is now "coachable." Ten hires later, the distribution of talent inside the company has quietly shifted, and the interesting part is that nobody notices through people. They notice through output.

Bugs that shouldn't exist. Escalations that should have died at L1. A design review where someone asks what a race condition is and is not joking.

Phase three: the diagnosis that is guaranteed to be wrong

Here is where it becomes fascinating, in the way a slow-motion car crash is fascinating.

Management sees declining quality and reaches for the only lever visible from the top floor: process. Reviews. Sign-offs. Mandatory templates. Time tracking. A quality initiative with a name and a logo.

The logic is not insane. If output is inconsistent, constrain the output. Add guardrails.

But look at what actually happens. Process is applied uniformly, because that is the only way it can be applied. The freedom that was the reward for being excellent gets removed from everyone - to compensate for the people who were hired without meeting the old bar. You just taxed your best performers to subsidize your hiring shortcut.

This is a ratchet. Process gets added under pressure and never removed, because removing a control requires someone to sign their name next to "I decided we need less oversight." Nobody does that voluntarily. So the constraint layer thickens, year after year, each layer a fossil record of a hiring decision made in a hurry.

Your power horses 🐎 do the math in about a quarter. Same salary, half the autonomy, twice the meetings, and their work now arrives at the customer through four handoffs that leak energy at every step. Two outcomes, both bad for you: they regress to the company mean, or they leave.

Then they land somewhere smaller, where hiring is still brutal and process is still thin, and the golden era starts again. And people call them job hoppers.

The part where the quality project cannot save you

I have watched several of these initiatives. The outcome is binary and both branches are dead ends.

Branch one: an honest, capable person runs the review. They produce a clear report that says the root cause is roughly sixty hires from a specific eighteen-month window and a couple of managers who cannot evaluate technical work. Acting on this means mass dismissals and admitting a very expensive mistake at board level. Probability of execution: near zero. The report gets "phased."

Branch two: the review is owned by one of the people who caused it. Findings: process maturity needs improvement, tooling investment recommended, mandatory training rolled out. Everyone nods. More process. Ratchet clicks. The problem is now officially addressed and permanently unsolved.

You cannot audit your way out of a selection problem. The measurement is downstream of the cause, and the cause has hiring authority.

The bad manager multiplier

One hire in that panic window matters more than all the others: the manager who cannot tell good work from confident work.

Because that person does not underperform once. They hire. And they hire people who do not threaten them, who talk fluently in status updates, who are excellent at the appearance of work. Within two years, they have built a small parallel organization optimized for looking busy, and it is politically load-bearing - you cannot remove it without a reorg, and reorgs get postponed.

Bureaucracy-servers reliably outmaneuver mission-servers, and they do it with paperwork, not malice. The mission-servers are busy serving the mission. That is the entire asymmetry.

One bad manager in a desperate quarter is not a personnel issue. It is a compounding liability with hiring rights.

What actually works

I will not pretend this is fully solvable. But the failure has a mechanism, and mechanisms have pressure points.

👉 Freeze the bar, flex the timeline. You can hire slower or hire worse. Only one of those is reversible. A role empty for three months costs you a quarter of output; a wrong hire costs you two years, the process layer they trigger, and the two good people who quit because of it.

👉 Never delegate the hiring bar to whoever owns the deadline. The person under headcount pressure will always find a reason the candidate is good enough. Separate the two roles structurally, and give the bar-owner a veto that survives escalation.

👉 Give every new process an expiry date. Written down, with a name attached. If it still earns its keep in twelve months, renew it. Most won't. This is the only thing I have ever seen break the ratchet - default deletion instead of default accumulation.

👉 Ask the inverted question in the leadership meeting. "If we wanted to guarantee our best engineers leave within eighteen months, what would we do?" Then count how many items are already on your roadmap. It takes ten minutes and it is more accurate than any engagement survey.

👉 Watch the manager layer three times harder than the IC layer. A weak individual contributor costs you one salary. A weak manager costs you their entire hiring output, permanently.

👉 If you are the power horse: measure trajectory, not state. Bad quarters happen. What matters is whether autonomy is being restored or removed. If the process layer has grown for two consecutive years and the last three senior hires came in above the people who built the thing, you already have your answer. Adjust to the new reality with open eyes, or leave early and cleanly. Waiting for it to improve is the expensive option, and hope is not a retention strategy.

Companies do not lose their edge because they stopped caring about quality. They lose it because they lowered the entry bar once, then spent the next five years building process to contain the consequences - and charged the bill to the people who never needed containing.

👇 What is the most absurd process in your company that exists purely because someone was once hired too fast?

This article is also available in German.

The Five-Year Dead Man's Switch That AI Defused in Five Minutes

Wed, 19 Aug 2026 07:00:13 +0200

Job security through indispensable spaghetti code worked great - until it didn't.

Every engineering org has one. The guy whose code looks like it was written during a fever dream in a language he invented on the spot. No comments. No docs. Variable names like xTmp_v2_FINAL_real. Functions that call themselves through three other files for no discernible reason.

And nobody touches it. Because nobody understands it. And nobody understands it because that's the whole point.

I worked with an engineer - let's call him Gerald - who had perfected this art over five years. Five years of building what was essentially a hostage situation disguised as a codebase. Every module he owned was a booby-trapped labyrinth. New developers assigned to his area would last about two sprints before requesting a transfer, a therapist, or both.

Management knew the code was bad. They could smell it. But Gerald had made himself the only person who could navigate the maze, and the business logic underneath was critical. Classic single point of failure wrapped in a single point of attitude.

The implicit threat was never spoken out loud, but everyone understood it: fire me and enjoy your next six months of outages.

The dead man's switch - corporate edition

This isn't a new play. Some engineers plant actual sabotage - there's a famous case where a developer literally coded a kill switch triggered by his Active Directory account being disabled. Got convicted, faces up to ten years in prison. Gerald wasn't that stupid. He didn't plant malware. He did something perfectly legal and arguably worse: he simply wrote code so deliberately convoluted that his continued employment was the kill switch. His presence was the only thing keeping the system from becoming an archaeological mystery.

The beauty of this approach, from Gerald's perspective, was plausible deniability. "That's just how the legacy system evolved." Sure, Gerald. The system evolved variable names like doTheThing_butNotLikeThat_v3 all on its own. Natural selection at work.

For five years, this strategy delivered exactly what Gerald wanted. Job security. Leverage in salary negotiations. A kind of smug invincibility that radiated from his Slack messages like heat off asphalt. He could half-ass sprints, skip standups, push back on every review, and nobody could do anything about it because the cost of replacing him was - or appeared to be - astronomical.

The call

Then the company let him go.

I heard about it and called Gerald to check in. Genuinely. Getting laid off sucks regardless of the circumstances, and I wanted to see how he was doing.

He sounded... fine. Better than fine, actually. Smug. There was a confidence in his voice that I recognized immediately - the confidence of a man who believes the phone is about to ring with a very different kind of call.

He thought I was the advance party. The first domino. He was waiting for the panic. The frantic "Gerald, we need you back, name your price" conversation he'd been rehearsing in his head for half a decade.

The subtext of every answer he gave was: I'll be back within the month at double my rate, and this time I'm coming in as a contractor with no standups and no code reviews.

So I had to be the one to tell him.

"Gerald, nobody's calling you back. We pointed an AI at your code. It mapped the entire dependency tree, identified the actual business logic underneath all the... creative architecture, refactored the critical paths, and generated documentation. Took about five minutes. Well - five minutes of compute. Twenty minutes if you count the coffee break while it ran."

Silence.

The kind of silence where you can hear someone's entire career strategy collapsing in real time.

What actually happened

Here's what Gerald never accounted for: the weapon he'd built - incomprehensible code - was specifically the kind of problem that AI is terrifyingly good at solving. An LLM doesn't get frustrated. It doesn't request a transfer. It doesn't need to understand why a function calls itself through three files - it just traces the execution path, identifies what the code actually does versus what it pretends to do, and rewrites it in something a human can read.

Gerald had spent five years building a fortress against human comprehension. He never considered that the next siege wouldn't be human.

The refactored code was cleaner, faster, and - this was the part that really stung - it exposed several bugs that had been lurking in Gerald's maze for years. Bugs that Gerald either didn't know about or didn't fix because fixing them would have made the code more approachable.

His "indispensable complexity" turned out to be about 40% actual business logic, 35% unnecessary abstraction, and 25% what can only be described as spite architecture.

The real lesson isn't about AI

It's tempting to frame this as an "AI is coming for your job" story. It's not. AI didn't come for Gerald's job. Gerald's strategy came for Gerald's job. The AI just happened to be the thing that made the strategy's bankruptcy visible.

Gerald confused being needed with being valuable. These are not the same thing. Being needed means the system breaks without you. Being valuable means the system gets better with you. One is a hostage situation. The other is a career.

The engineers who are genuinely hard to replace - the power horses 🐎 who write clean code, mentor juniors, document their decisions, and make everyone around them faster - they're not threatened by AI. They're the ones using it to multiply their output. Because their value was never in the complexity they created. It was in the complexity they eliminated.

Gerald's entire value proposition was friction. And friction is exactly what every tool in history has been designed to reduce.

The dead man's switch paradox

Here's the non-obvious part. Gerald's strategy didn't just fail because AI showed up. It was already failing - he just couldn't see it.

Every year Gerald spent making his code worse, he was also making himself worse. He wasn't learning new patterns, new architectures, new tools. He was spending his creative energy on obfuscation instead of growth. The five years he invested in building his fortress were five years he didn't invest in himself.

When the walls came down, there was nothing behind them. No updated skills. No portfolio of clean, impressive work. No reputation as someone teams fight to hire. Just a guy who was really good at writing unmaintainable code - a skill with a suddenly very limited market.

The cruelest part of the dead man's switch strategy is that it kills the person holding it. You become your own hostage.

👉 If the only reason you're employed is that firing you would be expensive, you're not secure - you're a liability with a countdown timer.

👉 Complexity you create to protect yourself protects you from growth at the same rate.

👉 The market for "nobody else can read my code" went from niche to zero faster than anyone predicted. Build value that survives comprehension.

👉 Being needed and being valuable are opposite strategies. One chains you to a single employer's desperation. The other gives you options everywhere.

The best job security has never been making yourself impossible to replace. It's making yourself impossible to forget.

👇 Have you ever inherited a codebase that was clearly designed as a job-protection scheme? How long did it take you to untangle it - and did the original author ever get the callback they were expecting?

This article is also available in German.

The Sunday Blues Aren't About Sunday

Tue, 18 Aug 2026 09:00:46 +0200

Your week has an energy leak - and it's not where you think it is

That creeping dread hits somewhere around 4 PM on a Sunday. You're on the couch, half-watching something you already forgot the title of, and your stomach starts doing that thing. Not hunger. Something worse. The mental preview reel of Monday morning. The commute. The standup. The inbox. The fluorescent lighting that somehow makes everyone look like they're starring in a low-budget zombie film.

Roughly 80% of professionals report experiencing what psychologists call "anticipatory anxiety" on Sunday evenings. The internet is full of advice about it. Meditate. Journal. Do breathing exercises. Practice gratitude. Light a candle and whisper affirmations to your houseplant.

All of which is the emotional equivalent of putting a bucket under a leaky roof and calling it fixed.

Here's the thing nobody tells you: the Sunday blues aren't actually about Sunday. They're about Monday through Friday.

The real diagnosis

Think about what's actually happening in your head at 4 PM on a Sunday. You're not dreading one specific meeting or one terrible boss (though if you are - different article, different problem). You're dreading the shape of the next five days. The predictability. The flatness. Wake up, commute, work, commute, eat, sleep, repeat. Five times. Then two days of actual life. Then five more days. Until retirement or heat death of the universe, whichever comes first.

Your brain is doing the math. And the math is brutal.

Five days of obligation. Two days of autonomy. That's a 71/29 split against you. And your subconscious knows it. The Sunday dread isn't irrational - it's your nervous system accurately modeling a week that has no texture, no surprise, no reward between Sunday evening and Saturday morning.

You're not anxious. You're bored in advance.

I spent years in corporate environments watching this pattern destroy people who were otherwise sharp, capable, and motivated. The ones who burned out fastest weren't the ones with the hardest jobs. They were the ones whose weeks were perfectly monotonous. Every day identical. The only variable was which flavor of sadness the vending machine coffee delivered.

The fix that actually works

The best piece of advice I ever got - and later gave to dozens of colleagues - is stupidly simple:

Put something on your weekday evenings.

Not work. Not meal prep. Not "self-improvement" that feels like a second job. Actual life.

Dinner with a friend on Tuesday. A date on Wednesday. A pickup basketball game on Thursday. A two-hour window on Monday where you do absolutely whatever you want with zero guilt. Even a standing arrangement to meet someone for a beer after work on a random weeknight.

What you're doing is breaking the thermal seal on your week.

In thermodynamics, energy flows from hot to cold until everything reaches the same lukewarm temperature. That's exactly what a standard corporate week does to your motivation. The weekend is hot - freedom, choices, spontaneity. The workweek is cold - structure, obligation, routine. And every Sunday evening, you feel the heat draining out of your life in real time.

When you scatter actual life across your weeknights, you break up that monotonous cold block. Tuesday stops being "day two of five" and becomes "the day I'm trying that new ramen place with Marco." Thursday stops being "almost there" and becomes "the evening I destroy my buddy at chess in the park." Your week develops texture. Peaks and valleys instead of one long, flat plain.

And something funny happens to Sunday evening: it shuts up.

Because your brain can no longer model the upcoming week as "five days of nothing I chose." There are things in there you actually want to do. The anticipatory anxiety loses its raw material.

Why this works when "self-care Sunday" doesn't

Most Sunday blues advice focuses on the symptom. Make Sunday nicer. Treat yourself. Do a face mask. Take a bath.

That's like giving a painkiller to someone sitting on a nail. The nail is still there. You've just temporarily numbed your ability to feel it.

The structural problem is that you've unconsciously designed a week where all your living happens in a 48-hour window, and all your existing happens in a 120-hour window. No amount of Sunday afternoon yoga fixes that ratio.

What fixes it is refusing to accept that weekday evenings belong to recovery-from-work and preparation-for-work. They belong to you. Even two hours of them. Even one.

I once worked with a senior engineer - absolute power horse 🐎 - who was slowly grinding himself into dust. Not because the work was hard. Because his entire social life existed on weekends. Monday through Friday was wake, work, microwave dinner, Netflix, sleep. He thought he was being "disciplined." He was actually being miserable on a schedule.

He started a weeknight dinner tradition. Wednesday. Same restaurant, rotating group of friends, no pressure. Within a month, his Sunday dread was gone. Not reduced. Gone. He told me, "Wednesday gives me something to look forward to that isn't two days away."

That's the whole mechanism right there. Proximity of joy.

When the next good thing in your life is always 5 days away, your brain treats the present as something to endure. When the next good thing is 24 to 48 hours away at most, your brain treats the present as... present.

A note for managers reading this

If your team has the Sunday scaries, that's not a wellness-program problem. That's a signal that work has colonized the entire identity of the weekday. You can't fix it with pizza Fridays or a meditation app subscription.

What you can do: stop glorifying the people who are "always on." Stop scheduling things at 5:15 PM. Stop sending the Friday 4:47 PM email that guarantees someone spends the weekend mentally drafting a reply. Give your people back their evenings - not as a perk, but as a basic acknowledgment that they are humans who exist outside your org chart.

The teams I've seen with the lowest burnout rates weren't the ones with the best benefits packages. They were the ones where leaving at 5 PM to go do something fun wasn't a career-limiting move.

The takeaways

👉 Sunday dread is a symptom of a textureless week, not a standalone problem. Stop treating the symptom.
👉 Schedule real life on weeknights. Dinners, dates, hobbies, hangouts. Break up the monotony block between Friday and Monday.
👉 Proximity of joy matters. If the next thing you're looking forward to is always the weekend, every weekday becomes something to survive.
👉 Two hours of chosen activity on a Tuesday evening does more for your mental health than an entire self-care Sunday. Because it changes the structure, not just the mood.
👉 Managers: your team's Sunday scaries are your Monday problem. If evenings aren't actually theirs, no amount of wellness initiatives will compensate.

Your life is not five days in a cubicle and two days of freedom. Unless you design it that way. And most people do - by accident, not by choice.

👇 What's your weeknight move? The thing that makes Wednesday feel like it belongs to you and not to your employer's org chart?

This article is also available in German.

The Amazon Driver Who Accidentally Explained Economics

Mon, 17 Aug 2026 08:00:58 +0200

Why the people who scream loudest about "the rich" are the ones keeping the machine running

I was chatting with my Amazon delivery driver the other day. Casual stuff - weather, workload, the usual pleasantries you exchange with someone who knows your address better than some of your relatives.

I asked if he was worried about the economy.

He laughed. Not a nervous laugh. The kind of laugh that says buddy, I don't have time to worry about the economy because I can barely get a day off. More packages than he can physically deliver. Routes getting longer, not shorter.

So I said what any reasonable person would say: "The rich keep you busy, huh?"

He laughed again. Harder this time.

"Nah man. The mansions? One, maybe two packages. It's the other neighborhoods that bury me."

And then he drove off to his next stop, completely unaware that he'd just delivered the most concise economics lecture I've heard in years.

The consumption paradox nobody wants to talk about

There's a dominant narrative that says the economy is a machine built by the wealthy to extract from the poor. And there's enough truth in that to make it sticky. But the driver's observation reveals something more uncomfortable - and more useful - than any ideology can offer.

The households with the least disposable income are often the highest-volume consumers of convenience retail.

This isn't a moral judgment. It's a logistics fact. The driver doesn't care about your politics. He cares about how many stops are on his route, and the data under his feet tells a clear story.

Why does this happen? A few mechanisms that are worth understanding if you actually want to help people - including yourself - rather than just tweet about it:

The poor pay the "no infrastructure" tax. When you don't have a car, or your nearest store is a 40-minute bus ride, or your work schedule doesn't leave time for a proper shopping trip, that $4.99 item with free Prime shipping isn't a luxury. It's the only rational option. You're not being irresponsible. You're being efficient within a set of constraints that would make most middle-class commentators cry.

Small transactions add up invisibly. A household ordering $15 worth of stuff six times a week is spending more than the mansion that orders a $200 item once a month. But it never feels like spending because each individual purchase is trivial. This is the subscription economy's entire business model applied to physical goods. Death by a thousand small boxes.

Convenience is the most expensive product ever sold. And it's marketed hardest to the people who can least afford it. The real margin isn't on the item. It's on the behavior pattern.

What the mansions actually do differently

Here's the part that's going to be unpopular.

The mansion household that orders two packages isn't wealthier because they order less from Amazon. But the behavioral pattern that leads to fewer impulse purchases and more consolidated, deliberate spending? That's not random. That's a discipline - and it's one that compounds over decades the same way careless spending does, just in the opposite direction.

The wealthy aren't sitting in their living rooms heroically resisting the "Buy Now" button. They've structured their lives so the button is mostly irrelevant. They buy in bulk. They have accounts with specialty vendors. They delegate purchasing. They've built systems that make thoughtless consumption harder, not easier.

This is the same principle that makes elite support teams outperform average ones. It's not that the 🐎 power horses have more willpower on any given ticket. It's that they've built workflows where the stupid, energy-draining decisions are already made. The structure does the discipline, so the human doesn't have to.

The real economics lesson from a delivery route

Your Amazon driver sees the economy from a vantage point that no economist, politician, or LinkedIn thought leader has access to. He sees the actual flow of goods to actual doors. No surveys. No self-reported data. No narrative. Just boxes and addresses, hundreds of times a day.

And what he sees is this: the loudest conversations about economic anxiety come from the same neighborhoods generating the most economic activity for the very machine they're anxious about.

That's not hypocrisy. It's a trap. And the trap works because the system is designed so that the most financially stressed people find the most relief in small, frequent purchases - which in turn increase their financial stress. It's a feedback loop elegant enough to make a systems engineer weep.

So what do you actually do with this?

This isn't a "stop buying things" lecture. Those are useless. Here's what's actually actionable:

👉 Audit your small transactions for one month. Not the big purchases - you already agonize over those. Track every order under $20. The total will be the most educational number you see all year.

👉 Batch, don't drip. One order per week instead of one per day isn't about saving shipping costs. It's about inserting a 24-hour delay between impulse and action. Half of what you'd have ordered today won't matter by Thursday.

👉 Build the system, not the willpower. Remove saved payment methods. Delete the app from your phone and only order from a laptop. Make it slightly harder. Friction is free financial advice.

👉 Apply this at work too. Every "quick fix," every "just this once" shortcut, every unplanned micro-decision is the organizational equivalent of an impulse purchase. It feels insignificant in the moment. It's catastrophic at scale. The best-run teams don't have more discipline. They have fewer decisions to make.

The delivery driver didn't have an economics degree. He had something better - an unfiltered data set and zero incentive to spin it. The most honest economic indicators aren't published in reports. They're loaded on trucks at 5 AM.

👇 What's the most uncomfortable economic truth someone casually dropped on you?

This article is also available in German.

The Opinion I Cached in 2003 Cost Me Ten Years of Better Tools

Fri, 14 Aug 2026 08:00:04 +0200

Why I moved back to SUSE after two decades - and why you should re-evaluate your stack while it still works

Somewhere around the year 2000, I bought a computer magazine because it had a CD glued to the cover. SUSE Linux 6.4. ReiserFS. I got as far as "select a mount point for root" and stopped, because I had no idea what a mount point was, and no realistic way to find out. No search engine within reach. No forum. Just me, a beige tower, and a dialog box asking me a question in a language I didn't speak.

I abandoned the installation. My first contact with Linux ended in surrender at the partitioning screen, which I suspect is the most common origin story in our industry.

A few months later, SUSE 7 came out and I ordered the boxed set. Seven CDs. A printed manual thick enough to stop a small projectile. A t-shirt. A sticker of a chameleon. And most importantly: no license key scrawled on a disc in marker by someone's cousin. I installed an operating system that nobody asked me to prove I deserved. That smell of freedom stayed with me longer than the T-shirt did.

Then came the wandering years.

Fedora: lovely, modern, and reliably broken at the worst possible moment. CentOS: rock solid, with a software repository that felt like a museum with a gift shop. So I did what everyone did and joined the Ubuntu hype. And Ubuntu worked. Mostly. For a while.

Every single installation, though, followed the same arc. Months of peace, then the onset of symptoms that cannot be described, narrowed down, or reproduced. A print dialog that takes eleven seconds. Bluetooth that pairs only on Tuesdays. Suspend that works until you look at it. Nothing you can file a bug for, because the bug report would read: "it feels sticky."

And underneath it all, APT. I have donated entire evenings of my finite lifetime to dependency conflicts that resolved themselves into a suggestion to remove approximately one third of my system. RPM and its resolvers were always the better engineering. I knew that. I kept using DEB anyway, because switching costs money you can only pay in weekends.

That is the interesting part of this story. Not the distro. The reason I stayed.

Cache invalidation is the hardest problem in computer science, including in your head

A while ago, I upgraded Ubuntu for the second or third time and did an honest inventory of everything I had learned to ignore. It was a long list. Each item individually below the threshold of action, collectively a system I was working around instead of working with. Time to reinstall.

But instead of reinstalling the same thing, I decided to actually survey the field. Mint. Rocky. A few others. Nothing clicked. So I did something slightly humiliating: I wrote down my real requirements - stability, sane package management, rollback, no drama - and handed them to an AI.

It came back with openSUSE.

My immediate reaction was physical discomfort, and the reason had nothing to do with 2025-era openSUSE. It was KDE. I was present during the era when a major desktop shipped to end users in a state its own developers described as a preview, and I mocked it with the enthusiasm of a man who had found his calling. I had also spent a decade in Xfce and before that loved an old GNOME 3. My verdict on KDE was formed, filed, and never reopened.

Here is the thing: that verdict was based on data from roughly two Olympic cycles ago, written to memory with no expiry date. My opinion had no TTL. It was a cached value being served with total confidence long after the origin server had rewritten the entire application.

Physicists have a word for this. Hysteresis: the state of a system depends on its history, not just on current conditions. Remove the force and the material does not spring back - it keeps a memory of the field it was in. That is exactly what technology opinions do inside senior engineers. We are magnetized by one bad release, one vendor who lied in 2014, one framework that burned us, one candidate who fumbled one interview question, and we stay magnetized long after the field is gone.

The genuinely useful thing the AI did for me was not intelligence. It was the absence of history. It had no grudge to protect, no war story to justify, no reputation invested in having been right about a desktop environment during the Bush administration. It just matched requirements to reality as it currently exists.

That is an uncomfortable insight if you make decisions for a living.

The universe collects on old debts

I took a backup, discovered that XFS cannot be shrunk - a fact you generally learn at the moment it becomes expensive - and reinstalled from scratch on Btrfs. Tumbleweed. Snapper. Automatic snapshots. A safety net at last.

Within days, KDE started crashing on login and refused to come up. Somewhere in the machine, karma had been accruing interest for twenty years.

So I rolled back to a previous snapshot. It didn't help.

And that turned out to be the most valuable lesson of the whole migration, because it is not a bug - it is design. On a default openSUSE setup, the snapshots cover the root filesystem. Your home directory sits in an excluded subvolume, deliberately, so that a system rollback doesn't also delete the document you wrote this morning. Perfectly sensible. Also: my breakage lived in a Qt config file inside my home directory. The safety net I had chosen the entire distribution for did not cover the layer where the failure actually occurred.

Every backup strategy you have ever approved has a version of this hole in it. The restore covers the part that was easy to snapshot, and the outage lives in the part that holds the state. You will find out which is which either during a calm Tuesday test or during an incident with an audience. Your choice.

I deleted a handful of KDE and Qt configuration files, moved to a newer Tumbleweed snapshot, and the problem never returned. Then something annoying happened: I started to like it. YaST still feels like an actual control panel for an actual system rather than a settings app that hides the switches it doesn't trust you with. Zypper resolves dependencies like an adult. The chameleon is still from Nuremberg, which means I toured the entire distro landscape for two decades to end up a few hours' drive from where I started.

I am mildly annoyed at myself. Not for leaving. For not looking back sooner.

👉 Re-evaluate at peak stability, not at peak pain. Decisions made during an outage default to the incumbent, because panic optimizes for familiarity. The only time you can honestly compare options is when you don't need to.

👉 Every technology opinion needs a TTL. Write the verdict down with a review date. "Vendor X is unusable" expires in eighteen months. So does "that tool is a toy" and "that person can't handle escalations."

👉 Your grudge is running on cached data. The product that burned you has shipped forty releases since. So has the colleague you wrote off. Serving a stale cache with high confidence is not experience, it's just latency.

👉 Test the restore, not the backup. The snapshot that covers everything except your actual state is a feeling, not a recovery plan.

👉 Ask the question to something with no history. A junior, an outsider, a machine - anyone not emotionally invested in having been right the first time. Their naivety is a feature.

Twenty years of loyalty to a decision I made before I understood what a mount point was. Being German, I am contractually entitled to hold a grudge - but the interest rate on that particular one turned out to be brutal.

👇 What is the strongest technology opinion you hold that you have not actually re-tested since the last time it was true?

This article is also available in German.

Your Inner Monologue Is Fluent in a Language You Cannot Speak

Wed, 12 Aug 2026 09:00:59 +0200

Rehearsing in your head is the corporate equivalent of "it works on my machine"

One estimate puts inner speech at around 4,000 words per minute. You speak out loud at maybe 130 to 150. So the version of you that rehearses the big presentation in your head is running at roughly 30x the clock speed of the version that has to show up in the room.

That is not confidence. That is a benchmark run on hardware you do not own.

I learned this from a colleague I'll call the Cathedral Builder. Brilliant systems engineer, the kind of power horse 🐎 who could hold an entire distributed architecture in his head and tell you which node would fail on a Tuesday. We had a customer escalation heading for the executive floor: eight weeks of instability, a CTO who had run out of patience and vocabulary, and a 15-minute slot to explain the root cause and the plan.

He prepped for three days. I asked him to run it past me. He said he had it, he'd been through it several times.

In his head.

He had, genuinely. Every argument in perfect order, every objection anticipated, every metaphor elegant. In there it was a TED talk with a standing ovation and a book deal.

On the call he made it 90 seconds before the CTO interrupted with "so was this a code problem or a config problem?" - and something in the pipeline snapped. He started a sentence he could not finish. Then he started it again, differently, and could not finish that one either. Then he explained the retry logic. In detail. For four minutes. To a man who wanted a one-word answer.

The technical content was flawless. The meeting was a disaster. We got a second call only because the account manager did some highly skilled emergency diplomacy afterwards, and the fix landed a week late because of it.

Your head is staging with no traffic

Here is the mechanism, and it is depressingly mundane.

When you rehearse silently, you are testing in an environment that shares almost nothing with production.

No motor system. Speaking out loud is a physical act coordinating roughly a hundred muscles - breath, larynx, tongue, jaw. Your inner voice skips all of it. It is a simulation of the output, not the output.

No compilation step. Inner speech is compressed and abbreviated. You do not think in complete sentences, you think in meaning-shaped blobs that feel like sentences. In the room, you have to compile those blobs into grammar, in real time, in front of witnesses. That compiler has never been tested under load.

No adrenaline. Under stress, working memory tightens up and word retrieval gets worse. The words are still in there. The retrieval index just got slower at exactly the moment you needed it fastest.

No audience. This is the worst part. The audience in your head is magnificent. They nod. They follow. They never ask "sorry, can you go back two slides", never check their phone, never say "I'm not sure I agree with the premise." They have no follow-up questions because they are made of you, and you already agree with you.

So what you actually rehearsed was not the presentation. You rehearsed the feeling of having given it. That feeling is free, and anything free gets counterfeited. Learning research has known this for decades under a different name: re-reading your notes feels fluent and produces almost nothing, while forcing yourself to retrieve the material out loud feels clumsy and works. Fluency in the head is the least reliable signal you have. It is the map. The room is the territory.

The fix is annoying, cheap and unpopular

Say it out loud. Standing. Once, badly, on day one - not on the evening before.

The first time you speak a prepared thing aloud, you get a free defect report: the sentence that has no ending, the transition that does not exist, the number you cannot actually recall, the joke that is only funny in your skull. That report costs you three minutes. Getting the same report live from a CTO costs you a project.

For non-native speakers, add a layer. I think in German. German is happy to park the verb at the end of a long sentence and let everyone wait for the punchline. Improvised English under pressure is not. In my head, the translation is seamless. Out loud, at minute nine, with a hostile question incoming, I have started sentences whose grammar had no exit strategy. You only find those by producing them.

Some specifics that earn their keep:

👉 Memorize the first 30 seconds verbatim. Adrenaline peaks at the start. Give yourself an autopilot runway, then switch to bullets. Full scripts fail because the moment you lose your place you have nothing to fall back on but the script.

👉 Rehearse the joints, not the paragraphs. Presentations don't collapse mid-section, they collapse at transitions. Practice the five sentences that get you from A to B.

👉 Practice the questions you're praying nobody asks. One hour on the three ugly questions beats six hours on slide alignment. If you can't answer one out loud, that's not stage fright, that's a hole in your case.

👉 Practice the recovery, not just the content. When a word won't come, stop and breathe instead of filling the gap with "um, so, basically." A two-second silence reads as authority. Six filler words read as panic. Drill the pause until it's boring.

👉 Record it once on your phone and watch it. Yes, it is horrible. It is also the only honest mirror you have, and it costs nothing but your dignity, which was never load-bearing.

👉 Same rule for writing. Re-reading your own escalation email in your head applies your intonation, your good intentions and your smile. The customer applies theirs. Read it aloud in the voice of your least patient stakeholder - you will delete two sentences every time.

The confident voice in your head has never once had to stand up, breathe, and be heard by a stranger. Stop taking career advice from it.

👇 What's the worst thing you've ever heard yourself say out loud in a high-stakes meeting - and did you find it in rehearsal, or in the room?

This article is also available in German.

The Quiet Corporate Death Spiral

Tue, 11 Aug 2026 10:12:39 +0200

When Broken Tools Get Buried Under More Processes

There's one unmistakable smell that tells you a company has quietly entered its death spiral. It isn't mass layoffs or missed earnings. It's the moment management looks at a genuinely broken tool, UI, script, or workflow and decides the easiest fix is... another process.

An email goes out. A new KB article appears. Someone records a TOI video. A fresh Slack channel is born. The wiki gets another page that nobody will read after next week. And just like that, the organization has chosen to compensate for bad tooling with human friction.

I watched this exact pattern play out at a mid-sized software company that, on paper, still looked healthy.

The internal escalation tool had a nasty bug in its search function. Simple queries returned incomplete results about 40 % of the time. It had been that way for months. Instead of fixing the underlying indexing issue (which the devs swore would take "only a couple of sprints"), leadership sent the classic memo: "Please use this new workaround when searching for escalations." The workaround involved three extra steps, copying ticket IDs into a separate spreadsheet, cross-referencing with another system, and then posting in a dedicated Slack channel so someone else could verify you hadn't missed anything.

Within weeks, the band-aid became standard operating procedure. Then it snowballed. New KBs were written to explain the workaround. Training sessions were scheduled. A weekly "workaround sync" meeting appeared on the calendar. Before long, the team had three different documents describing four slightly contradictory ways to do the same thing, depending on which version of the bug was currently active.

The power horses 🐎 - the ones who actually kept customer issues moving - started losing track of which process was current. Neurodivergent engineers who thrived on clear, repeatable systems were slowly going insane trying to keep the mental map updated. Simple tasks that should have taken minutes now took fifteen, with a side of anxiety that you'd followed the wrong ritual and would get called out later.

The really dark comedy came when the bug finally got fixed... eight months later. By then, so many overlapping processes, channels, and documents existed that the team spent another three weeks untangling the mess they had built around the original problem. The total time wasted was easily ten times what it would have cost to fix the tool properly in the first place.

That's the brutal truth most leadership teams refuse to accept: broken tooling plus manual workarounds doesn't just create overhead. It compounds negatively. Every new layer multiplies errors, frustration, and context-switching costs across the entire team. The best people eventually conclude the company would rather manage symptoms than cure diseases, and they start looking for the exit.

I've seen the opposite approach too, and the difference is night and day.

The teams that bite the sour apple and fix the tooling upstream experience the opposite compounding effect. One clean fix to a painful workflow can save hundreds of hours per month, reduce errors, lower cognitive load, and make the power horses visibly happier and more productive. The velocity gain is immediate and permanent instead of being slowly bled away by process theater.

For those still stuck in the trenches, here's how to fight this pattern without sounding like the office complainer:

Quantify the pain in hard numbers. Track how many extra hours per week the workaround actually costs the team. Turn it into a simple slide or one-pager: "Current process tax = X hours/week = Y full-time equivalents." Data beats drama every time.
Frame the request as protecting customer outcomes and team capacity, not personal convenience. "This workaround is adding friction that delays critical escalations" lands better than "this sucks."
Keep a living "technical debt list" that includes broken tools and their real business costs. Review it in every ops review. Make it impossible to keep ignoring.

For the neurodivergent brains who just want the system to be predictable: document the workaround clearly once, then immediately start pushing for the real fix. Your clarity obsession is actually a strategic advantage here.

And for leadership reading this: every time you choose another process layer instead of fixing the broken tool, you are quietly voting for a slower, more frustrated, and ultimately more expensive organization. The best companies treat tooling issues as urgent product problems, not support inconveniences. They understand that clean, reliable systems are one of the highest-leverage ways to retain power horses and keep actual work moving.

Fixing broken things upstream always compounds positively. Patching them with human processes compounds negatively until the entire machine grinds to a halt. Pushing additional workload and forcing messy processes onto your team is easy. True leadership requires accountability and willingness to push solutions, even upwards and against other (busy) teams.

The next time you hear "we'll just add a quick process for now," ask the only question that matters: Are we solving the problem, or are we teaching the organization to live with it?

What's the most soul-crushing workaround or extra process your company is currently forcing everyone to follow because the underlying tool is broken? Drop it below. The trenches usually spot these death-spiral signals long before the executive dashboard does. 👇

This article is also available in German.

We Abolished Programming Languages - Then We Reinvented Them - In Prose

Mon, 10 Aug 2026 09:00:26 +0200

German is objectively denser than English. It still makes your prompts worse. And the reason tells you exactly where this is all heading.

A while ago, someone asked me, with the sincere enthusiasm of a person who had just had a Big Idea: "German is so precise. Wouldn't prompting in German be more token-efficient?"

As a German, I wanted this to be true so badly. Finally, a competitive advantage from the language that gave the world Schadenfreude, Kummerspeck and Weltschmerz.

It is not true. But the reason it fails is more interesting than the idea itself.

The German hypothesis is linguistically sound

German really does pack more meaning per word. Compound nouns fuse concepts into single unambiguous units. Datenbankverbindungspoolverwaltung is one word, one concept, and the structure tells you precisely what belongs to what. The English equivalent, "database connection pool manager", are four words that leave you guessing whether the manager manages the pool, the connections, or the database. Add a case system that encodes relationships without prepositions, plus a vocabulary that prefers specific terms over vague umbrellas, and in theory you get fewer words for the same instruction.

Fewer words, fewer tokens, cheaper and sharper prompts. Beautiful theory.

The tokenizer has other plans

Tokenizers were trained mostly on English. So that gorgeous compound noun does not arrive as one dense unit. It arrives shredded: Dat / enbank / verbind / ungs / pool / verwalt / ung. Six-ish tokens of subword confetti, none of which mean anything, versus two or three clean tokens for the English phrase. You wrote one word and got billed by the syllable.

Then the training imbalance piles on. If English is over half the corpus and German is a rounding error, the model's internal reasoning about technical concepts is anchored in English whether you like it or not. Prompting in German means the model quietly translates, reasons, and translates back - a border crossing at every step, and customs take a cut each time.

And the third problem is the one nobody wants to hear: code is English. Function names, library names, error messages, stack traces, documentation. You can write your specification in flawless German, but the moment the model has to reason about ConnectionPoolExhaustedException, it is back in English anyway. You have not added precision. You have added a translation layer with no test coverage.

The intuition was right, though. Just aimed at the wrong target. The problem is not which natural language. The problem is natural language.

Ambiguity is not a bug in human speech. It is a feature. It is how diplomacy, poetry, flirting and performance reviews work. It is catastrophic in a specification.

The circle nobody expected to close this fast

Look at the trajectory of talking to computers:

Assembly: speak the machine's language.
C and Pascal: slightly more human.
Python and Java: "reads almost like English."
Natural language prompts: "just talk to it normally."
Now: strict JSON schemas, XML-tagged context blocks, typed tool-call signatures, prompt modules under version control with a changelog.

The great promise was that you would never need a programming language again. What practitioners actually shipping production systems have converged on is... a programming language. With a nondeterministic runtime, no compiler, and no error messages - just confident nonsense delivered in a friendly tone.

This was inevitable and the mechanism is simple. "Add these two numbers and return just the result" works 98% of the time. In a demo, 98% is magic. In production, 98% is an incident channel. So you bolt on constraints: "return ONLY an integer." "No commentary." "Output valid JSON, nothing else." Each of those sentences exists to close exactly one observed failure mode.

That is not prose. That is a line of code, written in prose, badly.

Which is precisely why typed prompting languages and grammar-constrained generation tools exist - BAML with function signatures, Guidance and Outlines constraining output to a grammar or state machine, LMQL wrapping model calls in query syntax. Every one of them is an honest admission: natural language was a wonderful demo and a poor interface for reliable systems.

What genuinely changed

One thing did change, and it matters. Traditional code specifies HOW - the algorithm, step by step. Structured prompts specify WHAT - the desired outcome plus constraints. That is declarative. Closer to SQL than to C.

So the real evolution reads: imperative (write the HOW) → declarative (write the WHAT) → natural language (vaguely gesture at the WHAT while hoping) → structured prompts (declare the WHAT precisely, with types).

We took a detour through gesturing. It was fun. We are back.

The number that should bother you

Take a rambling 2000-token prompt. Strip out the politeness, the restatements, the three contradictory versions of the same requirement, the "please be thorough and think carefully." What remains as actual decision-relevant content? Often under a hundred tokens.

A 20:1 ratio between what you pay for and what carries information does not mean you need a bigger model. It means the specification is broken. A tight 200-token structured prompt on a cheap model will frequently beat the 2000-token ramble on a frontier model, and cost a fraction. Bigger models mostly buy you tolerance for your own vagueness. Expensive tolerance.

And here is the part relevant to anyone running a support or ops team: the people on your team who are already excellent at this are not the ones with "AI" in their job title. They are the ones who write repro steps a stranger can follow. The ones whose escalations never come back with "can you clarify?" The ones whose knowledge base articles work for someone who has never seen the product. That is the same skill, and you have been undervaluing it for years while it sat two desks over. 🐎

👉 Prompt in the language your tooling, errors and training data live in. For technical work, that is English. Linguistic elegance loses to tokenizer reality.

👉 Density is not precision. Precision is structure: schemas, types, enumerated constraints, explicit failure modes.

👉 Every constraint you add to a prompt is a bug fix. Treat it like one - version it, comment why it exists, and never delete it without knowing which failure it prevented.

👉 Measure the ratio of tokens paid to decisions actually specified. High ratio means fix the spec, not the model.

👉 Declarative beats imperative here. Describe the outcome and its boundaries, not the reasoning steps. Then constrain the output format hard.

👉 Your best "context engineers" are your clearest writers. Find them in support and QA, not in the job postings.

"Context engineering" is just programming with extra steps and worse error messages. The skill was never obsolete - it only changed uniforms.

👇 What is the one constraint you had to add to a prompt after production taught you a lesson the hard way?

This article is also available in German.

Many Eyes, Zero Readers

Fri, 07 Aug 2026 08:00:54 +0200

A hardware wallet built keys from a random number generator it never once called. For five years. The source code was public the entire time.

In a 25-minute window, someone swept roughly 594 bitcoin - about $38 million - out of some 500 unrelated wallets. No phishing. No malware. No supply chain tampering. No 5$ wrench.

Every one of those wallets was protected by a device sold on a single, admirable promise: keys generated offline, on isolated hardware, using a true hardware random number generator, Bitcoin-only to shrink the attack surface, no cloud, no companion app, and open-source firmware you can verify yourself.

The hardware RNG was on the board. Powered. Functional.

For roughly 1,900 days, the firmware never asked it for a number.

The bug is one character wide

The vendor did something entirely sensible: they switched off MicroPython's built-in random path with a build flag, because they had written their own wrapper around the microcontroller's true RNG. Textbook embedded hygiene.

Then a cryptographic support library checked that flag with #ifndef - which asks "does this macro exist?" rather than "is it set to something other than zero?"

The macro existed. Its value was zero. So the library concluded hardware entropy was available and happily bound itself to MicroPython's random function. MicroPython, having read the same macro correctly, had compiled a non-cryptographic software fallback instead of the hardware peripheral.

Two components. Both internally correct. The defect lived in the seam, which is where defects go to enjoy a long and undisturbed retirement, because seams belong to nobody.

The consequence: keys came from a deterministic generator whose entire state was seeded from a chip serial number, a timer with roughly 80,000 plausible values, and a clock register that on some models wasn't even running. Effective entropy landed somewhere near 40 bits. A BIP-39 seed is supposed to carry at least 128. That's not "somewhat weaker." That's a keyspace hundreds of trillions of times smaller than advertised - small enough to enumerate with hardware you can rent by the hour, which is precisely what appears to have happened.

There was a self-test. It rejected sequences containing adjacent repeated values. Every pseudorandom generator ever written passes that. It was a smoke detector calibrated to confirm the absence of smoke.

"You can verify it yourself" is a license, not a control

The firmware was open source, MIT licensed, reproducibly buildable, publicly hosted, for five years. That is more than most vendors offer, and I remain firmly pro open source. I would still rather run code I'm permitted to read.

But be precise about what the license actually delivered: the right to audit. Not an audit.

Distributing responsibility to everyone assigns it to no one. Each reader assumes that someone with more cryptography credentials, more time and fewer children already handled the tedious parts. And seed generation is the tedious part - it's plumbing, not primitives. Reviewers gravitate toward curve math and signature logic, not toward a preprocessor guard in a support library's build configuration. Many eyes is a real effect. It is not a control with an owner, a scope and a date. It's a hope with excellent branding.

Which makes it proof-of-title wearing the costume of proof-of-work. "Open source" became a badge on a product page: reassuring, technically true, and performing none of the labor it implies. The badge asserted that the reading had happened. Nobody had done the reading.

The uncomfortable part: every supply chain control passed

Here's what should genuinely unsettle anyone who has spent the last few years building software supply chain security.

This firmware would have sailed through the entire modern stack. Signed releases: yes. Reproducible builds: yes, bit for bit. SBOM: complete and accurate. SLSA provenance: clean. Dependency scanning: no findings, because there was no known-vulnerable version to match - the flaw was novel, first-party, and lived in a build flag. License compliance: spotless. Vendor with a real upstream track record and responsible disclosure history: also yes, demonstrably.

Every one of those controls answers exactly one question: did I receive the code the developer intended to ship?

Yes. You did. Faithfully, verifiably, cryptographically. The intended code was wrong.

That gap is the actual lesson. We have spent enormous effort industrializing provenance because provenance is automatable, and almost none industrializing correctness because correctness isn't. So the map got beautiful while the territory kept its potholes. A perfect SBOM (Software Bill of Materials) tells you the exact make and model of the brakes. It has no opinion on whether they're connected.

So do we have to rethink open source?

No. We have to rethink the grace period.

The vendor states it had no knowledge of the flaw before the sweep. Practitioners are openly speculating that machine-assisted code analysis helped outsiders find it first. Treat the attribution as speculation. Treat the mechanism as arithmetic.

Reading source code used to be expensive. That expense, not the license, was doing quiet defensive work: a subtle cross-library build-flag mismatch survived five years because auditing is unpaid, unglamorous and slow. The friction was load-bearing and nobody put it on the architecture diagram.

Machine review has collapsed the cost of reading code toward zero. For everyone. At the same time. And the two sides are not symmetric: a defender has to read all of it, an attacker needs one line.

Open source didn't get less secure. It got less slow. The buffer everyone was unknowingly leaning on was never secrecy and never obscurity - it was latency. Latency has now been deleted.

Which lands exactly where instinct says it should: run the AI machines against your own source before somebody else runs theirs against it. Not as a hackathon with pizza. As a scheduled control, with a named owner, a defined scope, and a report that nobody may close with "no findings, looks fine."

👉 Auditable is not audited. Publish the audit, its scope, its date and its author - or state plainly that none exists. "Open source" on a landing page next to a security claim is marketing, and increasingly it's marketing that attracts exactly the wrong readers.

👉 Verify the promise, not the implementation. The claim was hardware entropy. Nobody ever measured the output for entropy. Test what you sell at the boundary you sell it, with a test that can actually fail.

👉 Boring code needs the strongest reviewer, not the spare one. Key generation, seeding, initialization order, build configuration. Attack value is inversely correlated with how interesting a file looks.

👉 Supply chain security answers provenance, not correctness. Keep the SBOMs and the signing. Just stop reporting them as if they were assurance of behavior. They confirm you received the intended bug intact.

👉 Assume adversarial AI machine review is already running against your public repositories. Because it costs nothing, and unlike your reviewers, it does not find seed derivation boring.

Open source was never a security control. It's a permission slip. Somebody still has to do the reading - and from now on, the machines will do it for whoever asks first.

👇 Where in your stack does "it's open source, people would have noticed" quietly stand in for an audit nobody has ever actually performed?

This article is also available in German.

The Kubernetes Guy Is About to Have a Very Bad Year

Thu, 06 Aug 2026 09:00:14 +0200

When your entire career is a YAML file, don't be surprised when someone auto-generates it

A while back, I made an offhand remark somewhere about Kubernetes being overkill for a particular use case. Nothing radical. Just pointing out that a single application serving a few thousand users probably doesn't need a container orchestration platform designed to run Google's entire production fleet.

Within minutes, the clergy arrived.

"C'mon bro. Just pipe your Jsonnet through the Kluster Konfig Kompiler, deploy the sidecar injector via a mutating webhook, add the ChaosMonkeyMesh operator for resilience testing, sync your GitOps state through FluxKapacitor, and tail the logs from the Kloud-Native Kombined Kockpit. It's literally five steps. Why are you so afraid of YAML?"

I'm not afraid of YAML. I'm afraid of people who think memorizing a toolchain is the same as understanding infrastructure.

Here's the thing about Kubernetes. It's a genuinely good piece of technology. Google donated it to the world, the CNCF nurtured it, and it solved a real problem - orchestrating containers at scale across distributed systems. If you're running hundreds of microservices across multiple regions with complex networking, auto-scaling requirements, and zero-downtime deployments, Kubernetes is probably the right call.

But somewhere along the way, "right tool for certain jobs" became "the only tool for every job." And an entire professional subculture emerged around that confusion.

You know the type. Their LinkedIn headline says "Kubernetes Expert." Their resume is a vertical stack of CNCF logos. They've built a career not on understanding distributed systems, but on knowing which flags to pass to kubectl and which Helm chart to install when things get weird. They don't architect solutions. They assemble them from pre-built components and config files, then describe the assembly process in language so dense it functions as a social filter.

That's not engineering. That's IKEA with a steeper learning curve.

The Kubernetes ecosystem has a pattern that should look familiar to anyone who's ever watched a technology become its own industry. It goes like this:

A tool solves a hard problem elegantly.
People adopt it for problems it wasn't designed to solve.
The mismatch creates friction.
New tools emerge to manage that friction.
Those tools create their own friction.
Repeat until you have 347 CNCF projects and a conference circuit.

This is Gall's Law running in reverse. Working complex systems evolve from working simple ones - but the Kubernetes ecosystem keeps bolting complexity onto complexity and calling it maturity. You don't end up with a working complex system. You end up with a Rube Goldberg machine that happens to serve HTTP.

I once watched a team spend three weeks setting up a Kubernetes cluster - complete with Istio service mesh, Prometheus monitoring, Grafana dashboards, ArgoCD for GitOps, and a custom admission controller - to deploy a Django app that previously ran fine on a single VM with a systemd service file. The old setup had one dependency: Linux. The new setup had a dependency graph that looked like a conspiracy theory evidence board.

When I asked what problem Kubernetes solved that they'd actually been having, there was a long silence followed by, "Well, we need to be ready to scale."

The app had 200 users. All internal.

Now here's where it gets existential for the Kubernetes Guy.

Everything that makes Kubernetes painful - the YAML sprawl, the configuration complexity, the debugging of networking policies, the CRD definitions, the Helm chart templating - is exactly the kind of structured, pattern-heavy, well-documented work that AI handles embarrassingly well.

Ask an LLM to generate a Kubernetes deployment manifest with health checks, resource limits, a horizontal pod autoscaler, and an Ingress resource with TLS termination. It'll hand you clean, working YAML in about four seconds. Ask it to write a Helm chart with parameterized values for three environments. Done. Ask it to debug why your pod is stuck in CrashLoopBackOff. It'll walk you through the diagnostic steps faster than most humans can type kubectl describe pod.

The Kubernetes Guy spent years accumulating knowledge that is now mass-producible at near-zero cost.

This is the brutal math of what happens when your skill set is configuration rather than comprehension. Knowing how to wire things together is valuable only as long as the wiring is hard. The moment a machine can do the wiring - and do it faster, more consistently, and without needing to Google the syntax for a PodDisruptionBudget - your value proposition evaporates.

The people who are safe? They're the ones who understand why. Why this architecture and not that one. Why these trade-offs are acceptable and those aren't. Why Kubernetes is the right choice here and a terrible choice there. Why the networking model works the way it does, not just which annotation to add to make the load balancer happy.

That kind of understanding doesn't live in YAML files. It lives in the ability to reason about systems from first principles - to look at a problem and ask "what does this actually need?" before reaching for the tool you happen to know best.

There's a concept I keep coming back to: the idiot index. Take the cost of a finished output and divide it by the cost of the raw inputs that actually matter. When the ratio is enormous, you don't have an expensive input problem - you have a broken process.

Apply this to Kubernetes consulting. The raw input - the actual engineering thinking about architecture, failure modes, capacity planning, security boundaries - might take a senior person a few hours. But the finished output - the deployed, configured, monitored cluster with all its associated tooling - takes weeks of YAML wrangling, plugin installation, troubleshooting, and configuration management.

That gap? That's where the Kubernetes industry lives. And AI is about to collapse it.

Not the architecture thinking. Not the "should we even use Kubernetes" conversation. Not the understanding of distributed systems fundamentals. Those remain deeply human, deeply contextual, and deeply valuable.

But the YAML? The Helm charts? The boilerplate CRDs? The "just install this operator and configure these seventeen environment variables" workflow?

That's dead work walking.

The most telling thing about the Kubernetes defense force isn't their technical arguments. It's their emotional investment. Criticize Kubernetes and they don't respond with "here's a use case where it outperforms the alternative by this metric." They respond with complexity theater - drowning you in tool names and acronyms to signal that you simply aren't sophisticated enough to appreciate the ecosystem.

This is a defense mechanism, not a technical position. Because deep down, on some level, the Kubernetes Guy knows that his moat isn't deep understanding - it's accumulated complexity. And accumulated complexity is exactly the kind of moat that AI fills in overnight.

The people I've seen thrive through every technology shift share one trait: they identify with the problem they solve, not the tool they use. They were the "make it reliable" person or the "make it scale" person, not the "Kubernetes person" or the "Terraform person." When the tools changed, they changed with them, because the problem didn't care about the toolchain.

The Kubernetes Guy identified with the toolchain. And the toolchain just got commoditized.

None of this means Kubernetes is going away. It won't. It's deeply embedded in modern infrastructure and it does its core job well. But the ecosystem of accidental complexity around it - the human middleware of config wranglers and YAML whisperers - is about to get a lot thinner.

If you're reading this and your career is built on Kubernetes expertise specifically, this isn't a funeral notice. It's a weather forecast. You have time. But the move isn't to double down on learning yet another CNCF tool. The move is to go deeper - into networking fundamentals, distributed systems theory, security architecture, capacity planning, cost optimization. The stuff that requires judgment, not just syntax.

Because the next time someone asks "why are you so afraid of YAML?" - the honest answer might be: "I'm not. Neither is the machine that just replaced your job."

👉 If your professional identity is a tool name, your career has a single point of failure. Kubernetes doesn't need you to defend it. It needs you to understand when not to use it.

👉 AI doesn't eliminate infrastructure work - it eliminates infrastructure busywork. The gap between those two things is where a lot of careers currently hide.

👉 Complexity is not depth. Knowing twenty tools one inch deep is not the same as knowing one domain twenty inches deep. The first is automatable. The second is not.

The safest career in tech has never been "the person who knows Tool X." It's always been "the person who knows when Tool X is the wrong answer."

👇 What's your favorite example of a technology that grew an entire industry of unnecessary complexity around it? And did you ever get to rip it out?

This article is also available in German.

Everyone Steals - The Smart Ones Call It Learning.

Wed, 05 Aug 2026 10:00:17 +0200

What the AI distillation wars accidentally teach us about knowledge hoarders in your own org

24,000 fake accounts. 16 million conversations. That's what it allegedly took for a handful of ambitious AI labs to siphon the intelligence out of a rival's frontier model - a technique politely called "distillation," less politely called "photocopying someone else's brain."

The victim was outraged. Letters to the Senate. Talk of industrial-scale intellectual property theft.

The same victim had recently paid 1.5 billion dollars to settle a lawsuit over training its model on roughly seven million pirated books.

You can't write satire anymore. Reality keeps scooping you.

There's an old saying: "rob one person and you're a thief. Rob everyone and you're an institution." The frontier labs scraped the collective output of humanity - every blog post, every forum answer, every Stack Overflow rant written by an engineer who just wanted to help - declared it fair use, and built trillion-dollar valuations on top. Then someone scraped them, and suddenly the concept of intellectual property was rediscovered with the zeal of a fresh convert.

Here's the uncomfortable part: the distillers aren't doing anything humanity hasn't done since the first apprentice watched the first blacksmith.

Distillation IS civilization. Apprentices copying masters. Scientists building on prior papers - the entire citation system is just distillation with receipts. Engineers reverse-engineering competitors' products. Michelin-star chefs doing unpaid stages in other Michelin-star kitchens specifically to absorb and mimic. I learned to cook by watching an unreasonable amount of food television and later YouTube. I learned woodworking entirely from YouTube. Nobody sued me. Knowledge transferred, compounded, and the world got one more person who can produce both a decent braise and a dovetail joint.

Every "stolen" output becomes someone else's input. That's not a bug in the system. That's the only reason the system works.

Which brings me to your org. Because you have a distillation war running right now, and it's costing you more than you think.

Every support and engineering team I've ever worked in had at least one of him: the senior engineer with the private notes file. Years of fixes, workarounds, tribal knowledge - all in a personal document nobody else could see. Ask him why he doesn't put it in the knowledge base and you get a shrug and something about "not having time to write it up." The real answer, which he'll never say out loud, is job security. He thinks his knowledge is his moat.

I spent years as a KCS Ambassador fighting exactly this, and here's what I learned: the hoarder's strategy fails in both directions.

Direction one: the moment he leaves, gets sick, or burns out, the org discovers his moat was actually a single point of failure with a salary. I've watched a team lose six months of velocity because one man's encrypted brain walked out the door.

Direction two - and this is the part nobody tells the hoarder: you cannot be promoted out of a job only you can do. Management isn't stupid about this. If replacing you causes a crisis, you will never be moved, elevated, or given the interesting project. You've built a prison and called it leverage. Meanwhile the power horse 🐎 who documents everything, who deliberately makes him- or herself replaceable, keeps getting handed bigger problems - because s/he can be extracted from the current one without the building catching fire.

The AI labs and the knowledge hoarder are making the same mistake: they're defending the exhaust instead of the engine. A model checkpoint, a private notes file - both are snapshots of yesterday's learning. Anyone who copies them gets your past. If your rate of producing new knowledge is high, being distilled barely matters; the copy is stale on arrival. The panic only makes sense if you secretly suspect your lead is nothing but your last snapshot. That's the confession hiding inside every outraged press release.

👉 Knowledge that isn't transferred doesn't compound. It just depreciates in one person's head.

👉 Judge your moat honestly: is it the artifact (copyable, always) or the machine that produces artifacts (copyable, never)?

👉 If you run a team: reward the people who make themselves replaceable, loudly and visibly. The incentive structure most orgs run does the exact opposite, and then leadership wonders why nothing is documented.

👉 If you're the hoarder: your file isn't a moat, it's a ceiling. Publish it and go build the next thing nobody knows yet.

If someone can copy everything you know and replace you, you were never a source. You were a cache.

👇 Every org has one encrypted brain walking the hallways. What's your plan for the day it walks out?

This article is also available in German.

Nobody Complains About Spyware Anymore

Tue, 04 Aug 2026 09:00:28 +0200

And that silence is the most accurate forecast we have for AI content

Remember when installing a free screensaver was an act of war?

Twenty years ago, the internet had a moral panic with its own industry attached: spyware. Purple gorillas reading your email. Browser toolbars reproducing like rabbits. People wrote furious forum posts. Lawmakers held hearings. Anti-spyware was an entire software category with boxed products and annual renewals.

Today your TV, your car, your phone, and - God help us - your fridge all phone home continuously, and the strongest public reaction is a mildly annoyed click on "Accept all."

What happened? The users didn't win. The word lost.

Spyware became "telemetry." Telemetry became "diagnostics." Diagnostics became "personalized experiences." The practice never changed - the vocabulary did. A controversial technology doesn't need to be accepted to win. It just needs its name retired. Once nobody can say the old word without sounding like a crank in a tinfoil hat, the practice has become infrastructure.

Now watch the same movie on 4x speed.

Stage one: ridicule. Hands with seven fingers. A Hollywood star unhinging his jaw over a plate of spaghetti. That was the golden age - spotting AI was a party trick, and some of us pattern-matchers enjoyed it the way birdwatchers enjoy rare warblers.

Stage two: ubiquity. "Slop" was Merriam-Webster's word of the year for 2025. Researchers tracking the open web say machine-generated articles passed human-written ones around late 2024. One study estimates over half of longer English posts on the big professional network are machine-assisted. Another analysis found roughly a fifth of the short videos served to a fresh account were low-grade AI. The warblers learned to fly silent.

Stage three: renaming. Already underway. Nobody serious says "AI-generated" anymore - it's "AI-assisted," "AI-enhanced," "human-led, AI-accelerated." Give it a few years and the qualifier vanishes entirely, the way "computer-assisted" vanished from design. When did you last demand to know whether a photo was "Photoshop-made"?

Stage four: silence. No ceremony, no surrender speech. One day you'll realize you haven't heard the phrase "AI-generated" in months. That's the white flag - and it's in your own hand.

You can hate this. It's happening anyway. The steam engine of media doesn't care about your opinion. And honestly? The weavers' argument was never as strong as nostalgia makes it sound.

Let's stop romanticizing "human content." Before the machines, the internet was already a slop factory. Content farms paid five dollars for articles written by freelancers who had googled the topic eleven minutes before you did. Listicles recommending products nobody had touched. "Human-written" was never a quality seal - it was a description of the typing. AI didn't lower the floor. It made the floor visible by cutting the cost of production to zero.

This is also where the usual take - "people will pay a premium for human-made content" - collapses. People won't pay it long-term, correct. Nobody uses a typewriter anymore, and "human-written" will become the vinyl record of media: charming, expensive, and mostly a statement about the buyer. But the deeper problem is the label itself. "We don't sell your data" meant "we share it with 400 partners." "100% human-written" will mean "a human pressed paste." Origin labels are badges. Badges cost nothing, and anything that costs nothing gets faked at industrial scale.

What survives is cost. Not "who wrote this?" but "who pays if this is wrong?" A name with twenty years of scar tissue behind it. A company that picks up the phone when the documentation lies. A consultant whose next contract depends on the last one having worked. That's the only signal machines can't counterfeit, because counterfeiting it requires actually bleeding.

Full disclosure, since we're being honest: I use the loom. This site runs on experience, scar tissue, and caffeine, and I won't insult you by claiming I chisel every draft out of marble by candlelight. The difference between slop and leverage isn't the tool. It's whether a findable human stands behind the output when it's wrong.

What this means in the trenches:

Your knowledge base: let AI draft the articles. The value was never the prose - it's the line that says "this fix works unless the customer still runs the 2014 plugin," the edge case you only meet at 3 a.m. in a Sev-1. If your KB contains nothing a generic model couldn't produce, it was slop before any AI touched it. Your power horses 🐎 were never paid for typing speed.

If you lead teams: stop selling "human-made" nostalgia and start selling answerability. Customers won't pay extra for a human on a normal Tuesday. They will pay almost anything on the worst day of their year, when the chatbot enters its third loop of "I'm sorry you're experiencing this." Human accountability isn't a lifestyle product. It's insurance. Price it like insurance.

If you're junior or job hunting: don't train to out-weave the loom. Train to catch it. The scarce job of the next decade is the person who can tell, fast, when a confident machine is confidently wrong.

And yes, the noise will get filtered eventually - but filters aren't weather, they don't just happen. Filters are people and institutions spending reputation. When generation costs zero, trust is the only scarce resource left. The market won't reward "human-made." It will reward "vouched-for."

👉 Controversies die by renaming, not by resolution. When "AI-generated" leaves the vocabulary, the takeover is complete.

👉 AI didn't invent slop - it made slop free. Content with no thinking in it was already slop; the machine just exposed the ratio.

👉 Origin labels are badges, and badges get faked. Ask who pays if it's wrong.

👉 If your skill is producing words, the loom is here. If your skill is knowing which words are true, you just got leverage.

👉 Human accountability won't sell as a lifestyle premium. It sells as insurance - on the worst day of your customer's year.

You can't out-argue a steam engine, and you can't out-type one either. The only moat left is bleeding when you're wrong.

What's the "telemetry" of your industry - the thing everyone hated until it got a friendlier name? 👇

This article is also available in German.

The Comfort Trap

Mon, 03 Aug 2026 09:00:43 +0200

Why most companies slowly die from too much politeness

The customer was paying seven figures a year. The warning would have cost nothing. Guess which one the company protected.

Some years ago I was on the bridge call at a godforsaken hour when one of our biggest customers went down hard in the middle of their peak season. War room, dashboards red, the CEO on the line asking the one question that gets asked in every one of these nights:

"Why didn't anyone tell me?"

Twelve people stared at their laptops. Because everyone had told someone. That was the problem.

A colleague had said it in the weekly review, in plain words: "this defect will take down a major customer the moment their load spikes". His manager passed it up as "stability concerns." His director turned it into "optimization opportunities." The exec deck showed a green square with a footnote about "ongoing scalability investments."

I later read the paper trail of my colleague's warning traveling upward. It was like watching a scream get translated, layer by layer, into a polite clearing of the throat. Each handoff washed the message a little cleaner. By the time it reached the top, it was room temperature.

Truth behaves like heat

This is the part most leadership content gets wrong. They treat this as a courage problem, fixed with values posters and a "speak up" slide in onboarding. That's trying to fix heat loss by repainting the building.

Bad news is heat. Every layer of management, every translation, and every status meeting is a wall it has to pass through - and every wall leaks energy. Engineer, team lead, manager, director, VP: five walls. What comes out the other end is not the message. It's the message's ghost.

You don't fix this with motivation. You fix it the way an engineer would: fewer walls, better insulation, or a heat source at the top that actively pulls warmth upward.

Nobody in that chain was a coward

That's the uncomfortable part. Every person who softened the message was making a locally rational decision. In most companies, the person who names the problem gets assigned the problem. Raising your hand costs you evenings and political capital. Softening costs nothing. Munger's rule applies with brutal precision: show me the incentive and I will show you the outcome.

And it's usually the same profile who raises the hand anyway: the pattern-matchers, the slightly-too-direct engineers, the ones who get labeled "blunt" in calibration meetings and "negative" in the hallway. The org trains them to stop. Then it's surprised when they do.

Meanwhile, every euphemism is a microloan. Each "challenge" that should have been "problem," each "learning opportunity" that should have been "we burned a customer," borrows comfort today against a crisis tomorrow. The interest compounds quietly, and the bill always arrives the same way it did for us: all at once, at 2 a.m., during someone's peak season.

What actually works

The best VP I ever worked for opened every staff meeting with the same five minutes: "What is the worst thing you know that I don't?"

First few weeks: crickets. Then someone brought him a genuine disaster. He thanked her publicly - and this is the part the whole org watched - he did not hand her the disaster to fix alone. He gave her air cover and resources. Word travels fast. Within a quarter, his org had the cheapest escalations in the company because problems surfaced while they were still small enough to be cheap.

His rule, stated once and enforced forever: if you bring it to me early, it's our problem. If you sit on it, it's your problem. Hiding had to become the dangerous option. Until it is, silence will always win.

👉 Go first. A CEO admitting a real miss at an all-hands, once, with specifics, does more than a year of culture initiatives. The top sets the temperature.

👉 Shorten the pipe. Skip-levels that actually happen. An anonymous channel that gets read and visibly answered. Your best engineers able to reach a decision-maker without three layers of translation. Every layer you remove is a wall the truth no longer has to bleed through.

👉 Pay for bad news. Reward the early messenger publicly, and never with the ownership of the mess they flagged. Promotions and visibility belong to people who deliver results and speak plainly - not to the smoothest slide-polishers.

👉 Manufacture dissent. Pre-mortems before big launches: assume this failed, now tell me why. Red-team important decisions. Silence in a room full of smart people is not agreement. It's a risk report nobody is reading.

👉 Outlaw the softener. Say it explicitly: "I would rather hear it ugly and early than polished and late." Then prove it the first time someone brings you exactly that. Everyone is watching that moment. It's the only part of the policy that counts.

The companies that survive are not the ones that feel best in the weekly meeting. They're the ones willing to feel briefly uncomfortable on a Tuesday so they never have to feel catastrophic at 2 a.m.

Your best people already know where the bodies are buried. They told you once, politely, and watched it get laundered into a footnote. Your power horses 🐎 don't dig twice.

Comfort is seductive. Truth is expensive in the moment and priceless over time. And the truth never actually leaves a company when meetings go quiet - it just relocates to the exit interview.

👇 What's the most expensive sentence you've watched die in a meeting - and who ended up paying for it later?

This article is also available in German.

We Scout Eight-Year-Olds for Football. Geniuses Have to Get Lucky

Thu, 30 Jul 2026 10:52:01 +0200

Why "the teacher will notice" is not a talent strategy

The most important talent scout in the history of physics was a random customer with spare tickets.

London, 1812. A blacksmith's son named Michael Faraday is apprenticed to a bookbinder. No formal education worth mentioning. But he reads what he binds, and one day a customer hands him tickets to Humphry Davy's lectures at the Royal Institution. Faraday goes, takes obsessive notes, binds them into a book - of course he does - and sends them to Davy. Davy, who has just injured his eyes in a lab explosion and needs an assistant, hires him.

The result: electromagnetic induction, the electric motor, the generator. The device you are reading this on traces back to a stranger's spare tickets.

That was the net. One man's generosity. And here is the uncomfortable part: two centuries later, the net is still mostly luck. We just added paperwork.

In most countries, the entire identification infrastructure for exceptional young minds is this: a teacher notices. One adult, 25 to 30 kids, measured on class averages and standardized test results, with exactly zero KPIs called "outliers surfaced." A system does what it is paid to do. This one is paid to move the middle of the curve. The edges are rounding errors. Goodhart's law with a school bell, if you want the technical term.

Want to know how good that net is? When one giant US school district stopped relying on teacher nominations and simply tested every child, the number of poor and minority kids identified as gifted roughly doubled. For some groups, it nearly tripled. Same kids, same bar. The only thing that changed was that someone finally cast a net. Which means the old system wasn't catching most fish and missing a few. It was missing most of them and pointing at the empty boat as proof the sea was empty.

In Germany we refine this with craftsmanship. At age ten, a teacher's recommendation largely decides a child's track. Study after study shows that at identical performance, the professor's kid gets the Gymnasium recommendation far more often than the cleaner's kid. Our net doesn't just have holes. It has a class filter and a fixed casting schedule.

And even a great teacher can only spot what the curriculum asks about. A ten-year-old who builds functioning computers inside a video game or can name every locomotive ever built produces zero measurable signal. The test never asks, so the talent doesn't exist. Worse: gifted boredom behaves exactly like a discipline problem. And the twice-exceptional kids - gifted plus autistic, gifted plus ADHD - get missed twice because the gift masks the struggle and the struggle masks the gift. What the system sees is a difficult child. What it loses is the mind.

Now compare the one field where humanity takes talent scouting seriously: football. Clubs run open trials, blanket youth leagues with scouts, house kids in academies from age eight, and pay eight figures for teenagers. Not because club owners are sentimental. Because a missed striker shows up on a balance sheet within five years. A missed engineer shows up nowhere, ever. There is no line item, no dashboard, and no vice president of found geniuses. We have priced the backup left winger. We have never priced the kid who might have cracked fusion. Nets get built where losses are visible - and the genius loss is structurally invisible. You cannot count what never happened. The cure that was never found appears in no GDP statistic. So nobody's bonus depends on fixing it.

In twenty-plus years in tech, I have shared offices with a handful of genuine outliers. The pattern was always identical: spotted late, by accident, by one person who bothered to look. By then, a decade of jobs two sizes too small had done its work. Some of the sharpest minds I ever met spent their best years resetting passwords. And talent without an outlet doesn't disappear politely. Some of it ends up in dead-end jobs. Some of it ends up clever in the wrong direction. The world is full of brilliant people running scams who could have been running labs.

Before any leader reading this feels smug about schools: your company runs the exact same net on adults. Recognition depends on one manager noticing. The job description is your curriculum. Performance reviews measure the middle of the curve. The power horse 🐎 in second-level support who could redesign your entire escalation process is invisible because nobody screens for anything beyond ticket throughput. If you lead people, you are the district administration now. Build an actual net - rotations, open demo days, real paths to show skills outside the job title - or keep donating your best minds to whoever does.

And if it's your kid: you are the net of last resort. Do not wait for the system. The system has 29 other children and a spreadsheet due Friday. That obsession that mildly worries you - the disassembled toaster, the four hundred questions about trains, the reprogrammed family router - might be the asset. Feed it. The good news: most of what a young mind needs costs less than the phone you were going to buy anyway. A library card, a used laptop, a soldering iron, and above all, one adult who takes the interest seriously. That adult is the whole net. And yes, sometimes it IS expensive - the instrument, the club, the laptop, the course. Pay it if you can. I have never met a parent who regretted investing in their kid's talent. I have met plenty who quietly wonder what their child could have been. There is no refund on that.

👉 Teacher nomination misses the majority of gifted kids. Universal screening finds multiples more, especially poor, minority, and neurodivergent ones. If "a teacher will notice" is the plan, most talent never even enters the race.

👉 The system only measures what it tests. Talent outside the curriculum produces no signal - and gifted boredom looks identical to a behavior problem.

👉 Football clubs scout eight-year-olds because a missed striker has a price tag. A missed scientist has no line item. Nets exist where losses are visible.

👉 Parents: fund the weird obsession. It usually costs less than a phone and always less than regret.

👉 Leaders: your org runs the same broken net on adults. Screen beyond the job description, or your best people get scouted by someone else.

The geniuses didn't slip through the net. There never was a net. "The teacher will notice" is not a talent strategy - it's a lottery with homework.

👇 Who was the one adult who noticed you before any system did? And what talent did school completely miss in you?

This article is also available in German.

Everybody Had a Blockchain - Nobody Had a Problem

Wed, 29 Jul 2026 11:00:09 +0200

Some years back, a company that sold iced tea renamed itself "Long Blockchain Corp." The stock jumped almost 300% in a single day. They had no blockchain. They had no blockchain engineers. They had, to be fair, very drinkable iced tea. The company was later delisted, the SEC revoked its registration, and the whole episode ended with insider trading charges around the announcement.

Read that again: the announcement moved the price 300%. Not a product. Not a prototype. A word.

That number shouldn't exist. But it does, and it explains the entire era better than any whitepaper ever did.

The meeting I still think about

Mid-hype, a client asked me to evaluate putting their support knowledge base "on the blockchain." I asked my standard opening question, the one that has ended more projects than any budget cut: which problem does this solve that a database with an audit log doesn't?

Long silence. Then, honestly, to their credit: "Our biggest competitor announced a blockchain initiative last quarter."

There it is. The whole mechanism, in one sentence.

Nobody in that room wanted blockchain. Nobody had derived it from a problem, worked backwards from a customer pain, or hit a wall that only a distributed ledger could break through. They wanted it because someone else visibly wanted it. The desire was borrowed. The entire enterprise blockchain wave was one giant chain of companies watching each other's press releases and concluding "they must know something we don't" - while the other side of the chain was thinking the exact same thing about them.

They didn't. Nobody knew anything. Everyone was copying everyone's homework, and the homework was blank.

The corpses prove it. A global shipping giant and a tech titan built a supply chain platform, poured years into it, and shut it down for lack of commercial viability - translation: nobody outside the founders' press department actually needed it. A national stock exchange burned roughly a quarter billion dollars on a blockchain settlement system before writing the whole thing off. These weren't startups run by kids. These were the adults in the room, and they still couldn't answer my client's silence-inducing question.

Meanwhile, the best engineers - the power horses 🐎 you actually needed on revenue work - got reassigned to feed the initiative because prestige projects always eat the good people first.

And yet Bitcoin is still here

Here's the part that annoys both camps equally. Bitcoin solves a real problem: moving value between parties who don't trust each other, without asking anyone's permission. You may love that or hate that, but it's a genuine problem with genuine demand, and it existed before the solution did. Crucially, Bitcoin is not a company. No sales quota. No quarterly pressure to invent use cases. No CEO who needs an "initiative" for the board deck. It doesn't need you to adopt it, which is exactly why the adoption is real.

Notice the pattern, because it's almost too clean: the only blockchain that survived is the one secured by proof-of-work - actual, measurable, expensive work. Every enterprise chain was secured by proof-of-title: steering committees, innovation awards, keynote slots. Then the reorgs came, the titles moved on, and the chains stopped. Work persists. Titles get reshuffled.

You can run this same audit today. Just replace "blockchain" with whatever word is currently spiking your industry's press releases. The technology changes. The mechanism never does.

👉 Write the problem down in one sentence without the technology's name in it. If you can't, you don't have a problem statement - you have a press release with a budget.

👉 Ask "what breaks if we don't do this?" If the honest answer is "the board presentation," congratulations, you've found the actual requirement. Now you can price it correctly: one slide, not one platform team.

👉 Trust technologies whose users bear real costs to use them. Distrust technologies whose loudest advocates bear only upside - the keynote if it works, a quiet LinkedIn update if it doesn't.

👉 Waiting is not cowardice. It's free QA performed by your competitors' budgets. Let them find the failure modes at $250M a lesson; you can read the postmortem for free.

Hype is just mimetic desire with a marketing budget - and the antidote costs nothing: one sentence, written down, with the buzzword removed.

👇 What's the most expensive "because the competitor did it" project you've watched die - and what problem was it officially solving?

This article is also available in German.

Being Poor Is Expensive

Tue, 28 Jul 2026 17:17:27 +0200

I earned 50k a year and was still broke - here's the physics of getting out

I once earned 50,000€ a year - roughly an average German household income at the time - and I had nothing. No savings, no buffer, overdraft fees every other month. That number shouldn't exist. But it sits in millions of bank accounts, and it proves something uncomfortable: poverty is rarely an income problem. It's a behavior problem wrapped in a physics problem.

This might hurt some feelings. It hurt mine first.

Hand a broke person a pile of money and check back in a few years. Lottery winners do this experiment for us constantly, and plenty end up worse off than before the win. The money didn't change the machine that burns it.

I know the machine from the inside. When I was young, payday meant Amazon order day. A side gig paid me 100€ cash? Straight to McDonald's to celebrate. My family was the hardest-working family I knew, and they lived paycheck to paycheck their entire lives. Not because they were lazy - because they never negotiated, never walked away from an abusive employer, and ruined their bodies for a wet handshake, terrified they'd never find work again.

My mother worked in kitchens for decades. Destroyed her back, her hands, and a good chunk of her mental health. Then she switched to a call center: sitting down, reading scripts, escalating hard questions to engineers, getting compliments on her voice. Easier job, better pay. She was wildly overqualified for it - which is exactly the point. Power horses 🐎 get exploited the hardest, because they're too busy pulling to look up and negotiate. First rule: working with your body only pays well if you own the invoice. If you sell physical labor to an employer, you're selling your spine at wholesale. Second rule: working hard does not automatically get you promoted or leads to better income.

My own start wasn't glamorous either. My first job was cleaning industrial air vents - rat droppings and dead birds out of chimneys and factory-scale AC systems. This while I already knew PHP, SQL, and could build a PC blindfolded, back when that was a rare skill. Bad school grades plus the dot-com crash meant no IT apprenticeship for me. So I took the job that paid the bills and kept learning on the side. Two years later, everyone in the company knew me as "the IT guy" who fixed their Excel formulas and network problems. My boss noticed and offered me an IT apprenticeship. Smooth sailing from there.

Except it wasn't. Because my income went up and my net worth didn't move. Fashion brands to buy social status. A Subaru Impreza I absolutely did not need. McDonald's with friends every day - a full menu plus desserts is 10-20€ daily, which is a car payment you're eating. The grill I used for exactly one season. The motorbike that was fun for one summer and then just cost money. The Nintendo still sitting in a drawer with all the games that were supposed to distract me from misery. Each purchase made me happy for a day, two at most. "Treat yourself, you deserved it" is the devil's favorite sentence.

At 50k a year and still struggling, I finally started reading about finance - "The Richest Man in Babylon" first, then the usual suspects such as "Rich Dad, Poor Dad". And that's when I understood the actual mechanism, the thing nobody had ever explained to me:

Being poor has a tax rate. And it's brutal.

Think of it as escape velocity. Below a certain wealth threshold, almost all your energy is consumed by friction: You put 10€ of gas in the car because you can't afford a full tank - so you drive to the gas station three times as often. You spend hours at the laundromat because you can't afford a washing machine. You commute two hours by bus because you can't afford to live near work or drive. You pay overdraft fees to a bank that pays you nothing. Every one of these is a fee for not having money. The poor pay more per unit of everything - per kilometer, per wash, per calorie, per euro borrowed. That's why "just earn more" doesn't work: the extra income gets eaten by the same friction, plus whatever you buy to feel better about the friction.

And the heaviest friction of all is debt. This sounds counter-intuitive - debt is supposed to help you afford things - but consumer debt is the poverty tax with a signature on it. When I was young, I bought laptops on installments because I couldn't pay upfront, and like most people in that situation, I had no real feeling for how much the interest inflated the price. I knew people who financed a vacation. Two weeks in Bali, back to their miserable everyday lives, and now two years of monthly payments for memories that faded in a month. Save upfront instead. Not just because it's cheaper - because the waiting period is a filter. When you've watched the money accumulate for months, you know exactly what the thing costs you, and half the time you realize you don't want it anymore. Debt exists to delete that moment of clarity. My rule: if you're poor, the only credit card you should own is a prepaid one. Debt as leverage is a rich person's tool - if your investments return more than the interest costs, borrow away. Below the threshold, the same instrument just welds the trapdoor shut.

Above the threshold, everything inverts. So here's what I did, and what I'd tell anyone in the loop: scale back for one or two years. Full monk mode. Dacia instead of Subaru. Lenovo instead of MacBook. Cook at home, invite the friends over - better ingredients, better quality time, fraction of the cost. And critically: move the money somewhere you can't touch it spontaneously. Stocks, commodities, anywhere with friction between you and the "buy now" button. This creates a beautiful psychological trick - your checking account looks poor, so you behave poor, while your actual net worth quietly climbs.

Get to 10k minimum, better 20-30k. And understand what that buffer actually is, because this is the part nobody tells you: it's not an emergency fund. It's negotiating power. My family stayed poor because they could never afford to walk away - from a bad boss, a bad salary, a bad commute. I know self-employed people today who do excellent work and stay broke for the same reason: they don't dare to raise their prices to fair market value, because they can't afford to lose a single client. The buffer is what converts you from price-taker to price-setter. You can suddenly buy the washing machine, fill the tank, sit out a notice period for a better job, and quote what you're actually worth. Every friction fee you stop paying becomes savings, and the flywheel accelerates.

One last proof that the machine matters more than the money: I've known people who got wealthy, lost everything through genuinely bad luck, and were back on their feet within a few years. Not because they got lucky twice - because their actual wealth was never the account balance. It was skills the market pays for, the adaptability to change course, and a network that let them execute on the next idea fast. Strip their money and they rebuild. Meanwhile, I've watched others hand half their daily income to gambling, alcohol, and premium groceries they couldn't afford - and no raise, no windfall, no lottery ticket would ever fix that. The bank account is just the output. The behavior is the machine.

👉 Income doesn't fix behavior. Behavior fixes income - eventually.
👉 Selling physical labor to an employer is selling your body at wholesale. If your body is the product, own the invoice.
👉 The first 10-20k isn't wealth. It's escape velocity - it deletes the poverty tax and buys you the right to walk away or raise your prices.
👉 Consumer debt is the poverty tax you volunteer for. Saving upfront isn't just cheaper - it's a built-in filter against buying things you don't actually want.
👉 Hide your savings from yourself. Feeling slightly poor while getting richer is a feature, not a bug.
👉 Real wealth is skills, adaptability, and connections. People who have those rebuild after losing everything. People who don't stay broke on any salary.

You don't save your first 20k to have money. You save it to stop paying the tax on not having any - and to buy the one thing no salary ever includes: the power to walk away.

👇 What's the most expensive thing being broke ever cost you?

This article is also available in German.

Your Leaky Shoes Might Not Be a Defect. They Might Be a Spreadsheet.

Mon, 27 Jul 2026 14:17:09 +0200

Many moons ago, back when I was an apprentice, a large shoe manufacturer walked into our software shop with a beautifully simple request: make our sole production more efficient.

Their process at the time: punch shoe soles out of the raw material in neat, ordered rows. Like cookies. All facing the same direction, with generous gaps in between. The gaps became scrap, the scrap became cost, and the cost became our project. The ask: write software that arranges the sole shapes in a randomized, compressed, rotated layout - Tetris for footwear - so almost nothing goes to waste.

Technically? A fun little optimization problem. A junior could have shipped it in a week.

But our senior developer did something that took twenty seconds and changed the entire meaning of the project. He picked up a piece of the raw material, squinted at it, and asked:

"Excuse me - I know nothing about shoemaking. But the fibers in this material seem to run in one direction. If we punch soles out at random angles, against the grain... could that hurt the quality of the shoe?"

The customer, without a millisecond of hesitation: "Absolutely. Every sole cut against the fiber flow will be subpar. Those shoes will most likely start leaking early."

Silence.

My colleague dared the follow-up: "Okay... but then why do you want us to build a system that produces subpar shoes?"

And here comes the answer I have never forgotten, delivered in the calm tone of a man reading his grocery list:

"Simple math. We save hundreds of thousands in raw material every year. Roughly 10% of the shoes will be subpar. Of those, fewer than 20% of customers will complain or demand a refund. So: six figures saved, in exchange for about 2% upset customers."

He wasn't ignorant. He wasn't embarrassed. He had a spreadsheet, and the spreadsheet had won.

We took the job. The layout engine worked beautifully. Material waste dropped exactly as promised. And somewhere out there, statistically, are people whose shoes gave up early because of code I helped test as a teenager. You're welcome.

Here is what that neat, "wasteful" row layout actually was: an undocumented quality requirement. Nobody had ever written down "all soles must be cut with the grain" - the ordered punching pattern simply enforced it by accident. The waste wasn't waste. It was insurance. And an optimization project that doesn't ask why the current process looks the way it does will happily delete the insurance along with the cost. Chesterton put up a fence about this once.

The darker lesson sits one level deeper. Our senior's question was perfect - and it changed nothing. Because the decision was never an information problem. The customer knew about the fibers before we did. You cannot fix with facts what was decided with incentives. The 20% who complain are the company's only real quality signal; the silent 80% who shrug and buy new shoes are the margin that funds the whole scheme. Every quiet customer is a co-investor in their own bad product.

👉 Before you optimize away "waste," find out what the waste is paying for. Inefficient legacy processes often encode requirements nobody ever documented.

👉 The one non-technical question - "why is it done this way today?" - is worth more than the entire implementation. Ask it every single time, even when you feel like the dumbest person in the room. Especially then.

👉 When the answer is "we did the math," stop arguing quality. The decision lives in a spreadsheet, and spreadsheets don't read your Slack messages.

👉 Complaining customers are not the problem. They are the only feedback channel with skin in the game. The silent ones are the business model.

We were hired to remove waste. What we actually removed was a quality control nobody knew existed - with the customer's full blessing.

So next time your new shoes leak after a few weeks: it may not be bad luck. It may be math. And whether you become part of the 2% who demand a refund, or the 80% who quietly fund round two - that's your line item in someone else's spreadsheet.

Have you ever "optimized" something, only to discover later what the waste was secretly protecting? 👇

This article is also available in German.

Your Vibe Coders Are Not Building Tools

Thu, 23 Jul 2026 08:00:24 +0200

They Are Filing Bug Reports Against Your Company

A while back I met an old colleague for cocktails. We do this every so often - two people who have seen enough server rooms and steering committees to know that the best incident reviews happen over a Negroni.

He was in a great mood. His company's vibe coding (quickly developing software using AI like Claude without writing (or sometimes even understanding) the code itself) adoption was through the roof. And not just among developers - consultants, architects, support engineers, basically anyone with a pulse and a Claude license was building tools. Management was celebrating. They threw around numbers like trophies: one engineer burned through 100 dollars a day in tokens. Applause. High fives. Slide decks.

And honestly? Fair enough. If a 100-dollar-a-day token bill produces a tool that saves ten hours of engineering time per week, that's the cheapest employee you ever hired. I am not here to rain on token budgets. Fun fact on the side: "vibe coding" went from a casual Karpathy tweet to Collins Dictionary Word of the Year within roughly twelve months. That's faster adoption than most companies manage for a new expense tool.

But while my colleague was celebrating, I was doing what 20+ years in support trenches trains you to do: listening for the alarm underneath the applause.

Because here is what nobody in that celebration meeting asked: "why are your support engineers building internal tools in the first place?"

Let's peel this onion. It has three layers, and each one is worse than the last.

Layer one is the obvious stuff everyone already knows and politely ignores: security, code quality, no reviews, no tests. Non-developers generally don't know what they don't know. Annoying, but survivable. Not my point today.

Layer two is shadow IT with a fresh coat of paint. Every one of those vibe-coded tools is a small, undocumented, unmaintained system. Some of them will quietly become load-bearing. They will run on some forgotten VM, touching real data, long after their creator has left the company. Then one day the tool breaks, the process it silently powered breaks with it, and nobody even knows the tool existed until the postmortem. I have personally watched a "temporary" script outlive three reorgs and two of the managers who never knew it ran. Shadow IT doesn't announce itself. It just accumulates, like plaque.

But layer three is the one that should keep leadership up at night, and it's the one my colleague's management completely missed while popping the champagne:

Every internally vibe-coded tool is an unfiled bug report against your organization.

Think about what actually happened. An employee needed a tool to do their job efficiently. Your company did not provide it. So they stopped doing the work you pay them for, taught themselves just enough to be dangerous, and built it themselves. In a five-person startup, that's Tuesday, and it's beautiful. In a company that sells stock to shareholders and has an IT department, an innovation budget, and a tooling roadmap, that's a confession. It means your internal tooling function failed quietly enough that nobody escalated and loudly enough that your people took matters into their own hands.

And here comes the part that gets filtered out before it ever reaches the SLT: guess who builds these workarounds? Not your coasters. Your power horses 🐎. The exact people who care enough to fix broken workflows are the ones burning their energy compensating for your tooling gaps. They are also the first ones who get demotivated when they realize they are patching the ship instead of sailing it. Nothing burns out a top performer faster than being structurally unable to do good work through official channels.

And there's a wall at the end of this road anyway. Vibe coding only reaches what the employee has access to. The really expensive inefficiencies - the CRM that needs three integrations, the deployment pipeline, the systems behind proper permissions - cannot be duct-taped from a support engineer's laptop. So your most motivated people fix everything within reach, hit the wall, and then sit there staring at the actual problem with no way to touch it. That's not a productivity story. That's a resignation letter with a six-month delay.

So what should you actually do? Not banning vibe coding - that would be punishing the messenger, and frankly the message is a gift. Do this instead:

👉 Inventory what your people have built. Every internal tool that touches real data or real processes. Yes, the list will be embarrassing. Better you find it than the auditor, or worse, the outage.

👉 Read the map. Sort the tools into two piles. Pile one: horizontal convenience - personal scripts, small helpers, quality-of-life stuff. Great, encourage it. Pile two: tools that patch gaps your IT or innovation team should own. That pile is not a tool list. It's your real internal roadmap, written by the people who live in the pain daily, with fidelity no requirements workshop will ever achieve.

👉 Treat prototypes as specifications, not as production systems. A vibe-coded tool proves the need and demonstrates the workflow. Then engineering rebuilds it properly, with ownership, monitoring and a maintenance plan. The difference between "evidence" and "production" is the difference between a cheap dashboard and a very expensive incident.

👉 Promote your best vibe coder into the tooling team, or hire dedicated internal tooling developers. Someone in your org just demonstrated initiative, domain knowledge and builder instinct - for free, on their own time, against your process. That person is telling you what they want to do with their career. Listen before a competitor does.

👉 Fund internal tooling like it's a product, because it is. Its customers just happen to sit inside your building. Nothing compounds more expensively than neglected internal tools: it slows everyone down, breeds shadow IT, and demotivates exactly the people you can least afford to lose.

My colleague's management celebrated the token bills. What they should have celebrated is the free, brutally honest audit their employees just handed them - and then acted on it.

Vibe coding didn't create a problem at that company. It exposed one. There's a difference, and the companies that understand it will eat the ones that don't.

Have you seen vibe-coded shadow IT taking root in your org yet - or are you still in the champagne phase? 👇

This article is also available in German.

The AI Not-To-Do List

Wed, 22 Jul 2026 12:59:56 +0200

Ten Things Your Company Should Never Delegate to a Machine, Ranked by Blast Radius

Classic scenario: an executive pasted an entire acquisition contract into a free public chatbot. He wanted a summary because reading twelve pages was, quote, "not a good use of his time." He got a lovely summary. He also got a confidential M&A document uploaded to a third-party server, which - depending on how you read the NDA he had personally signed - was somewhere between "career-limiting" and "please forward all future correspondence to my lawyer."

The best part: the deal was so straightforward that his own legal counsel could have summarized it in the elevator. He didn't save time. He converted a five-minute conversation into a compliance incident.

Everyone asks what AI can do for their company. Almost nobody asks the more profitable question: what should it never do? So let's invert the problem. If I wanted to guarantee an AI disaster, what would I deploy? Here's the list. Count how many your org is already doing. Two or fewer is excellent. Five or more - well, it was nice knowing you.

The hard no's: where lawyers get involved

1. Feeding confidential or regulated data into unvetted tools. GDPR data, health records, trade secrets, customer contracts. Pasting them into a public chatbot is publishing with extra steps. There's no attorney-client privilege for your chat history - it can be subpoenaed, and courts have already gone fishing in exactly those waters. The chatbot will never sit in the deposition. You will. That's the whole test right there: never delegate a decision to something (or someone) that can't be fired, fined, or sued for it. The AI has no skin in the game. Yours is the only skin available.

2. Drafting or reviewing contracts unsupervised. A contract is precision writing where one wrong clause costs six figures. An LLM is a confidence machine that occasionally decorates its confidence with facts. Lawyers have been sanctioned in real courtrooms for filing briefs with AI-invented case citations - complete with realistic case numbers and fictional judges. The machine didn't lie. Lying requires knowing the truth. It just autocompleted plausibly, which is somehow worse.

3. Final decisions about people. Hiring, firing, promotions, credit, discipline. AI pre-sorting resumes with human review: fine. AI as the last word on someone's livelihood: congratulations, you've automated your discrimination lawsuit intake. Bias in the training data becomes bias at scale, with your company's letterhead on it.

4. Talking to customers without a leash. A chatbot as one support option is fine. A chatbot as the only wall between a furious customer and your brand is how you become a screenshot with 40,000 retweets. A big airline learned this in court after its chatbot cheerfully invented a refund policy, and a tribunal ruled the airline had to honor what its own bot promised. The airline argued the chatbot was "a separate legal entity responsible for its own actions." The tribunal was not amused. Neither was anyone else.

The soft no's: where money quietly leaves the building

5. Tasks where the acceptable error rate is zero. Financial reports, safety documentation, court filings. If every line must be verified by a human anyway, the verification cost eats the efficiency gain and then bills you for dessert. You haven't automated the work. You've added a very eloquent intern who requires full-time adult supervision.

6. Tasks where checking takes longer than doing. Bulk data extraction is the classic trap. The errors are invisible at scale, and you discover them three systems downstream when the quarterly numbers look like modern art.

7. Work where learning IS the point. If your junior engineer has AI summarize every incident postmortem, you get excellent summaries and zero engineers. Fast forward five years: the big outage hits, the AI has never seen it, and the only human who could have handled it spent those years as a prompt courier. You didn't buy productivity. You bought the slow atrophy of your own bench on a subscription model. Meanwhile, your future power horse 🐎 never grew past pony size.

8. Anything a dumb automation solves cheaper. Decision trees, templates, cron jobs. Deterministic, auditable, no hallucinations, no token bill. Using a frontier LLM to select one of ten standard NDAs is like hiring a philosopher to operate a vending machine. He might do it. He might also question whether the customer truly wants the snack.

9. Judging humans from their faces and voices. Some vendors sell AI that scores "trustworthiness" or "leadership potential" from interview videos. This is phrenology with a REST API. Even where it's legal, the reputational blast radius isn't worth whatever it claims to measure - which, spoiler, it doesn't.

10. Anything where authenticity IS the product. The condolence message. The layoff announcement. The personal thank-you to your oldest customer. People can smell machine-generated warmth, and the moment they do, every genuine word you ever wrote becomes suspect retroactively. Some things are expensive precisely because a human spent time on them. Remove the human, and you've removed the product.

The meta-pattern nobody puts on the slide

Here's the insight that ties all ten together: AI doesn't fail like humans do, and your entire review process was designed for human failure.

A tired paralegal makes plausible mistakes - a missed clause, a typo in a date. Your checks were built over decades to catch exactly those. An LLM invents a court case with a realistic citation, a real-sounding judge, and perfect formatting. Your process has no antibody for that because no human ever failed that way. It's not that the machine makes more errors. It makes alien errors, delivered with the confidence of a senior partner.

That's why "human in the loop" isn't a compliance checkbox. It's an engineering requirement - and the human in that loop needs to know what alien failure looks like, not just what human failure looks like.

Notice something about this whole list: it's pure subtraction. Not one item asks you to buy anything, integrate anything, or attend a single vendor webinar. The fastest way to improve your AI strategy is to remove the ten dumbest uses before optimizing anything. Deletion is free. Cleanup is not.

👉 Never delegate to something that can't be fired, fined, or sued. No skin, no game, no decision authority.

👉 If verifying the output costs more than producing it yourself, you've automated nothing.

👉 Protect the tasks where learning happens - or enjoy your engineer-free future.

👉 AI fails in alien ways. Your review process only catches human ways. Close that gap before scaling anything.

👉 Your AI strategy improves faster by deleting bad uses than by adding good ones.

The companies that win with AI won't be the ones who deployed it everywhere. They'll be the ones who knew exactly where not to.

👇 Which of the ten is your company currently doing - and does anyone above you know?

This article is also available in German.

Yes, AI Is the Future. That's Exactly Why I Keep Criticizing It.

Mon, 20 Jul 2026 10:51:29 +0200

People occasionally corner me after a talk or in a comment thread and ask, half accusing: "So you're against AI?"

No. Clear no. I think AI is the future. I also think nuclear energy is one of the greatest inventions of the last century. You can build power plants that bring cheap electricity to millions of people. Or you can build the other thing. The technology doesn't care. The people wielding it decide the outcome - and right now, a lot of them are holding the hammer by the wrong end and wondering why the nail keeps laughing at them.

Being honest about a technology's capabilities, shortcomings, and risks is not opposition. It's the minimum requirement for using it well. Nobody calls a nuclear safety engineer "anti-nuclear."

The number that should end every AI keynote

A study published by the National Bureau of Economic Research surveyed almost 6,000 executives across multiple countries. Roughly 90% of companies implementing AI reported no discernible impact on productivity or employment. Not "underwhelming impact." No measurable effect at all. PwC's global CEO survey landed in the same crater: 56% of CEOs saw neither increased revenue nor decreased costs from AI after a year of deployment.

Read that again. The largest companies on earth, with dedicated AI task forces, data science teams, and budgets that could fund a small country's healthcare system, are mostly unable to prove that any of it worked.

If they can't capitalize on AI without setting money on fire, what makes a mid-sized company with one overworked IT admin think it will?

Why everyone jumped at once

Here's the part almost nobody says out loud: most companies didn't adopt AI because they identified a bottleneck AI could solve. They adopted it because everyone else visibly wanted it. Boards asked "what's our AI strategy?" not because they had a problem, but because the competitor's board asked the same question. Consultants sold the fear, vendors sold the dream, and executives who couldn't spell "transformer" mandated transformation.

Wanting something because others want it is the oldest trap in economics, and it produces the same result every time: bidding wars for the trendy thing, while the actual value sits ignored in the corner. We saw the identical movie with electric vehicles - demand forced top-down through mandates and hype rather than grown bottom-up through genuine pull. The early movers and their shareholders got dirty rich. Everyone who arrived at the party after midnight is now cleaning up the aisle.

Meanwhile, the genuinely valuable move - finding the one unglamorous workflow in your company where AI actually changes an outcome - was available to everyone the whole time. Nobody wanted it because nobody else wanted it. Competition is for losers; the overlooked niche is where the money hides.

The idiot index of your AI bill

Now the invoices are arriving, and CFOs are discovering a fun new metric. Take the cost of an AI-produced output and divide it by the cost of what's actually inside it. A frontier reasoning model, burning tokens like a private jet burns kerosene, summarizing a two-line email. An agentic pipeline with orchestration, monitoring, and retries - to answer a question that a decent knowledge base article solved in 2015 for free.

When the ratio between what you pay and the raw value inside is enormous, the problem is never the price of the input. It's the broken process wrapped around it. Companies are learning this the expensive way: wrong model for the wrong task, AI where a human brain would have been faster and correct, and nobody accountable for the meter running in the background. Forbes recently reported on exploding AI bills as a board-level topic - because "cost per token is falling" turned out to be irrelevant when your architecture multiplies tokens faster than the price drops.

There's a second, quieter cost. Every time someone outsources thinking that they should have done themselves, the output gets worse and the person gets weaker. You're not just paying for compute. You're paying to atrophy your own team.

What I actually recommend

If you're in tech: stay informed. Ruthlessly. The tools are real, the leverage is real, and the people who understand both the capabilities and the failure modes will be worth a fortune. Skills gaps, not tool gaps, are the number one adoption blocker in nearly every serious study.

If you're a decision maker: get into AI, but gather experience before you commit to a budget. Be deeply skeptical of marketing promises and shockingly pessimistic about projected costs. Then find one person - you may already employ this power horse 🐎 without knowing it - and give them the mandate to figure out how to transform your processes safely and integrate proper tooling.

One critical filter: this person must not wear rose-tinted AI goggles. You need someone who can objectively assess where AI helps, where it hurts, and where it silently bleeds money. The last thing you can afford is an AI yes-man who tells the board what it wants to hear. Judge them by a simple test - can they name three things AI should NOT do in your company? If the answer is "AI can do everything," you've hired a salesman, not an engineer.

And the cheapest R&D department in the world: other people's mistakes. The 2023-2025 experiments were paid for by companies far richer than yours. The results are public. Read them before you repeat them.

👉 Being critical of AI hype is not being against AI - it's the prerequisite for profiting from it.

👉 ~90% of companies report no measurable AI impact. Assume you're in the 90% until your own numbers prove otherwise.

👉 Adoption driven by "everyone else is doing it" produces cost, not value. Find the boring workflow nobody's fighting over.

👉 Check the ratio of your AI bill to the actual value inside it. A huge gap means a broken process, not expensive technology.

👉 Hire or empower one realistic assessor with a mandate to say no. An AI yes-man is more expensive than no AI at all.

The vendor got paid, the consultants left, and the AI can’t be sued. Guess whose name is on the cleanup bill.

👇 What's the most expensive AI mistake you've watched a company make - and did anyone learn from it?

This article is also available in German.

Your ESAT Is Probably Lying to You

Thu, 16 Jul 2026 13:00:35 +0200

And the scary part: it's designed to.

Picture the annual all-hands. A slide appears: "80% of the company is happy to work here. Our department: 83%. We are 3 points above average!" Applause. Someone books a team lunch.

Now run that logic forward a few years. "50% of the company is happy. Our department: 54%. Still beating the average!" Same slide, same applause, and half your people are updating their CVs during the meeting. That's the beauty of relative benchmarks: you can be the tallest passenger on a sinking ship and still get a trophy for it.

I've watched this ritual for over two decades in companies large and small, and I'm still not sure whether upper management genuinely doesn't see through it or just enjoys the theater. Either answer is uncomfortable. So let me walk you through why your ESAT is almost certainly measuring the wrong things - and what actually tells you whether your people are one bad Monday away from resignation.

Problem 1: You're benchmarking against a falling reference point

Comparing your department against the company average tells you exactly one thing: your relative position in a distribution you don't control. If the whole company slides into misery, your "above average" score slides with it, and the slide deck still looks green.

The only comparison that means anything is your own department against itself, over the past five years. Trend lines, not snapshots. A department that went 88, 85, 82, 79, 77 is on fire, even if it beats the company average every single year. Everything else is a participation medal.

Problem 2: Your questions are engineered to be agreeable

Most survey questions are so generic that agreeing with them costs nothing and means nothing.

"I am satisfied with my compensation." Sure, the money arrives on time. But try: "I am satisfied with my compensation and believe it reflects my value to the company." Suddenly you're not measuring whether the salary clears rent - you're measuring whether people feel valued. Those are very different numbers, and only one of them predicts resignations.

"My manager supports my career development." Translation: my manager is pleasant in one-on-ones. Compare: "I know how to develop my career here, I see serious growth potential, and I get concrete support for it." One measures vibes. The other measures whether someone can picture themselves here in three years.

More examples of questions that measure nothing:

"I feel connected to the company mission." Nobody knows what this means, including the person who wrote it. Ask instead: "In the last month, I made a decision differently because of a company priority I understood."

"I have the tools I need to do my job." A question so broad that a broken laptop and a broken org chart produce the same score. Ask instead: "In a typical week, how many hours do you lose to tools, approvals, or processes that don't work?" Now you have a number you can actually attack.

And my all-time favorite: "I believe meaningful action will be taken from this survey." What does that measure - trust in management? Institutional memory? The optimism of people who watched last year's results produced a poster and a pizza day? If your employees have a memory better than a goldfish, this question is a trap you set for yourself.

There's solid research behind this, by the way: survey methodologists have known for years that behavioral questions beat emotional ones. "How would you allocate a 10,000 budget across these five improvements?" gets you actionable data. "Do you feel engaged?" gets you a Rorschach test.

Problem 3: Goodhart eats your survey for breakfast

Goodhart's law: when a measure becomes a target, it stops being a measure. The moment ESAT scores land in managers' KPIs - and in most companies they do - the survey stops measuring satisfaction and starts measuring managers' ability to campaign.

You know the routine. Two weeks before the survey: "Remember all the great things we did this year!" A suspiciously well-timed team event. A gentle reminder that "low scores just create work for all of us." Nobody calls it manipulation. Everybody does it. And the dashboard turns a little greener while nothing underneath changes.

The response rate gets the same treatment. Chasing 95% participation with daily reminder emails doesn't get you more truth. It gets you more people clicking 4 out of 5 on everything just to make the emails stop.

Problem 4: Nobody believes it's anonymous, because it isn't

Your survey tool lets HR filter by department, tenure, location, and role. On a team of six, that's not a filter, that's a name tag. Your employees know this. In the age of AI-assisted text analysis, they also know their free-text comment has a writing style, and that writing style has a Slack history.

So they do the rational thing: polite 4s across the board, empty comment field. The people with the sharpest criticism - usually your most engaged people, because indifferent people don't bother critiquing - self-censor first. The survey systematically filters out exactly the signal you need most.

And here's the survivorship bias on top: the truly miserable already left. You're surveying the people who stayed, then congratulating yourself that the people who stayed haven't left. Peak analytics.

So what actually works?

The dashboard is not the employee. The map is not the territory. If you want to know how your people feel, you need signals that are expensive to fake - because anything cheap to fake will be faked, per Goodhart, every single time.

Watch revealed preference instead of stated preference:

Your employee referral rate is the most honest ESAT you will ever get. People do not invite friends into a burning building. If your senior engineers stopped referring people two years ago, that's your survey result, and it didn't cost you a single questionnaire.
Regretted attrition of your top performers. Not overall attrition - losing people you wanted to lose is hygiene. Losing power horses 🐎 is hemorrhage, and one of them is worth more signal than a thousand anonymous 4-out-of-5s.
Internal transfer requests away from a specific manager. Voting with your feet inside the building, before voting with them outside it.

And if you insist on asking questions, at least do it right: short pulse surveys on specific topics instead of the annual 100-question monster. Behavioral questions with trade-offs instead of feelings. Skip-level conversations where a director actually talks to engineers without the middle layer sanitizing the message - because middle management's job description quietly includes making sure bad news arrives pre-softened. And most importantly: visibly fix one real thing per cycle. One. People forgive you for not boiling the ocean. They do not forgive being asked the same questions every year while nothing changes - that's how you manufacture the "survey fatigue" you'll complain about next year.

👉 Compare your ESAT against your own five-year trend, never against a company average that can sink alongside you.

👉 Replace feelings questions with behavioral ones. "How many hours did you lose to broken process last week?" beats "Do you feel supported?" every time.

👉 Assume every score that feeds into a manager's KPI is being gamed. Because it is.

👉 On small teams, anonymity is fiction, and everyone knows it. Price that into every green dashboard.

👉 The real ESAT is behavior: referral rates, regretted attrition, and internal transfers. Expensive to fake, impossible to campaign for.

Your survey tells you what employees are willing to say. Their referrals and resignations tell you what they actually believe. Only one of those two shows up in your slide deck.

👇 What's the most creative pre-survey "morale campaign" you've ever witnessed? Anonymized answers only - ironically.

This article is also available in German.

The Teachers Who Bet Against Us - And Lost Every Single Time

Tue, 14 Jul 2026 11:00:58 +0200

Here is a fun statistic nobody keeps: how many careers get quietly strangled in a classroom before they ever begin. No dashboard for that. No postmortem. Just a tired adult with tenure telling a kid to give up, and the kid believing them.

Many years ago I attended a vocational school for information technology. It was there, ironically, that I met some of the most incompetent people I have ever encountered in IT. Not the students. The teachers.

They were all civil servants. Which in Germany means roughly the professional equivalent of a load-bearing wall - you can repaint it, you can complain about it, but you are not removing it. Performance was optional. Consequences were theoretical. And a few of them wore this like a medal. One openly bragged about his failure rates, as if drowning students early was a public service. In his mind he was a filter, weeding out the untalented before they could embarrass the profession.

Let me introduce you to three of the people he filtered.

👉 The foreigner who came to IT through a broken body.

The first kid had already finished an apprenticeship in a skilled trade. Loved it, was good at it, had a plan. Then a village festival, a fight he did not start, and an injury that ended his ability to do the work he had trained for. The employment office paid for a two year retraining program into IT. That was the deal, and the deal had no plan B. No completion meant no more support. On top of that, he carried a very specific cultural weight - the fear of disappointing his family, which for him was not a mood but a load-bearing beam of his entire identity.

He was fighting on three fronts at once. His native language, our language, and English, because half of IT is just English wearing a lab coat. He clawed his way through two years of it.

Our teacher repeatedly, explicitly advised him to quit. Saw no chance. None.

Today that man runs the entire global printer network for one of the largest car manufacturers on the planet. Every time a factory floor prints a label, somewhere his infrastructure quietly does its job. Which is more than the teacher ever did.

👉 The half-orphan with dyslexia.

He had lost his father a few years earlier to a workplace accident. Then came a dyslexia diagnosis - trouble distinguishing letters, in the broadest sense a reading difficulty. Brilliant kid. Curious, open, technically sharp. Probably a bit on the spectrum too, but that is a different article.

Same script from the teacher: the reading difficulty produces careless mistakes on exams, therefore no realistic chance of passing. Filed under hopeless.

So he did something the teacher never considered - he attacked the actual problem. Specialized training, a measurable drop in his error rate. Finished the program. Then went on to study software engineering.

If you drive a German car, there is a decent chance the code controlling your fuel injection pump was written in part by the boy who could not read properly.

👉 The one who was bad at maths.

Top student. Ones and twos in nearly everything. And a flat six in maths, thanks to Asperger's, which made learning anything he found boring - and maths was boring to him - almost physically impossible. On day one he told the teacher exactly this: I struggle with maths, and especially with the way you teach it, fast and dense. The teacher's reply was that in that case he was probably in the wrong profession.

Small detail. Math was a minor subject.

Then other students started struggling too. The thing got escalated to the principal. Turned out this teacher had a trail of math casualties across multiple classes. He could not be fired and could not be transferred - see load-bearing wall above. So the school did the only thing left: every student at risk of failing purely because of him got bumped from a six to a five (F and D-). You genuinely cannot defend flunking a kid with a 1.4 average score (which is the rough equivalent to an A-/B+).

That student became an escalation engineer at a large US tech company. He is also writing the article you are currently reading. Whether that counts as a valuable contribution to society, feel free to debate.

Here is the part worth keeping.

Three kids. All three were told, by a person with a title and a pension, to walk away. If all three had obeyed, all three would have ended up on the street. Instead one keeps a global corporation printing, one helps your engine run, and one writes for your amusement on a Saturday evening.

The teacher was not evil. He was just certain. And certainty in an incompetent person is the most expensive thing in any organization - because it looks exactly like authority. Same posture, same confidence, same tone. The only difference is the outcome, and by the time you see the outcome, the damage is done. I have watched grown senior engineers do the identical thing to junior colleagues. "Not cut out for this." Said with total conviction, backed by zero evidence, immune to consequence.

The people who actually make it are seldom the ones who fit the filter. They are the ones who had a reason to keep going that was bigger than one man's opinion. A family. A body that forced a second chance. A brain wired differently that still, somehow, found the door.

So if you are a student, or you have kids who are students, and you hit a teacher, a manager, or a "mentor" who has already decided that you cannot, do not confuse their certainty with truth. Question the supposed authority. Fight for what you believe is right. Escalate when the wall will not move. The worst thing that authority ever did was convince talented people it was measuring them when it was really just measuring itself.

The filter was never sorting talent. It was sorting obedience.

Who told you to quit - and where are they now? 👇

This article is also available in German.

The Feature That Burns Your Best People

Thu, 09 Jul 2026 08:00:27 +0200

It looks like a bug, but it's a feature. Every company I've consulted for has one. Some variation of a queue assignment system - either a duty manager eyeballing tickets or some clever algorithm that claims to balance load. And in every single one, there's a small group of engineers who get absolutely hammered with new work. Not by chance. By design.

You try to fix it. Adjust the weights, add a cap, introduce a "max queue depth" rule. It works for a week. Then the algorithm finds its way back to the same victims. The duty manager, faced with pressure to clear incoming tickets, falls back on the one person who actually closes things fast. The poor souls eventually give up and accept that the system just loves them. Or hates them.

These people share one trait: they are power horses 🐎. They work fast. They empty their queue. And as a reward, they get more work. A bigger queue. A fresh pile of tickets waiting for them on Monday morning, while the guy who sits on his inbox for three days gets exactly one new item. The math is brutal.

But the real damage is what this does to their capacity. They never get to participate in projects, initiatives, or cross-team improvements. They can't even start their own. Their entire day is reaction. Meanwhile, the sloths - the ones who prioritize their side gigs or their LinkedIn presence over their actual queue - generate noise. Lots of it. They show up to meetings, volunteer for pet projects, write proposals that never ship. Management loves noise because it's cheap filler for charts and slides.

"Mr Sloth participated in five new initiatives" sounds way more exciting than "Mr Horse solved 20 customer issues." Because solving issues is what Mr Horse is supposed to do. That's his job. No one writes a slide about a guy doing his job.

This isn't just bad luck. It's a systemic glass ceiling for your hardest workers. The very people you need to retain get locked into a hamster wheel of operational work while their less productive peers climb the ladder on visible activity. I've watched sloths get promoted over power horses. They either become lazy with the new paycheck or leave with the title and rust to a competitor who will exploit them next.

The frustration and morale cost is staggering. Teams become cynical. People start gaming the system. The power horse learns to slow down. Or leaves. And then you wonder why your best engineers are leaving.

Here is the fix. Actually. Stop.

👉 Stop routing purely to "available." Cap intake. A power horse with an empty queue is not a resource to be refilled - it is a strategic reserve. Protected slack is where initiative, mentoring, and your next process improvement actually come from. An organization with zero idle capacity has zero capacity to improve itself.

👉 Measure resolved value, not just resolved volume - and weight by difficulty. If clearing a brutal escalation counts the same as closing a password reset, your metrics are lying to you, and your best people know it before you do.

👉 Separate "visibility work" from "real work" in your own head, then deliberately reward the invisible kind. The engineer who quietly prevented forty tickets from ever being filed is worth more than the one who starred in five kickoff meetings. Find a way to put silent prevention on a slide. That is your job, not theirs.

👉 Audit your queue distribution like you audit your finances. Pull six months of assignment data. If the same three names sit at the top of the volume chart every single month, you do not have coincidence. You have a tax, and your best people are paying it.

👉 Give your horses an explicit off-ramp from the wheel. Protected project time. A rotation out of the queue. Anything that signals: speed buys you freedom here, not more weight. Otherwise, the only off-ramp they will find is the exit interview.

The deep irony is that the fix is cheap and the failure is expensive. Sloths are easy to replace. Power horses are not - and they tend to leave in clusters because the first one out the door reminds the others that leaving is an option.

Your assignment algorithm isn't broken. It is doing exactly what you told it to do. The question is whether you ever stopped to ask what you actually told it.

Go pull the data. I would bet you already know whose name is at the top.

Have you ever been the power horse that just gets rewarded with more work? Let us hear your story 👇

This article is also available in German.

When My Favorite Computer Magazine Quietly Became a Shopping Catalog

Wed, 08 Jul 2026 14:00:08 +0200

Every two weeks, like clockwork, I walked to the kiosk and bought the same magazine. This was back when "the cloud" still meant rain. The pages were glorious. Linux distribution shootouts - Debian vs. SUSE vs. Fedora vs. Ubuntu, complete with benchmark tables nobody asked for and everybody loved. Firewall configs. Server hardware reviews. How to set up remote access so you could SSH into your home box from the office and play terminal Tetris when the boss wasn't looking. How to share your "totally legally acquired" movie collection across the family network. Best open-source database. Troubleshooting tips that actually worked.

It was nerd church. I read every word, including the ads.

Then something shifted. First subtle, then about as subtle as a forklift through a glass door.

The Linux comparison shrank to half a page. Then a quarter. Then a sidebar. In its place: best LCD monitor for Photoshop. Best smartphone for the outdoorsy type. Best printer for home photo printing. Music apps you "cannot live without." Best home cinema projector. Dolby surround systems that cost more than my first car.

The magazine hadn't been cancelled. It had been quietly lobotomized. Same logo, same price, same kiosk. Different soul. It went from "build it yourself" to "buy this and consume." And teenage me was annoyed because none of it helped my career. I didn't want to know which speaker thumped hardest, primarily because I didn't have any money to buy one. I wanted to know how to make the server stop falling over.

Here's the part that still fascinates me 20-something years later.

That magazine wasn't dying. It was early.

It was just an ahead-of-the-curve preview of where the entire economy was heading. Away from creation and customization, toward consumption and convenience. I think the first iPhone was a big step in this direction. The magazine didn't sell out. It read the room before the room knew it had been sold.

Fast forward to now. My robot lawnmower has an app. My vacuum has an app and, I'm fairly sure, opinions. My motorcycle has an app. My airbag jacket - the thing whose only job is to inflate before my spine meets asphalt - also has an app, and it would very much like to send me notifications. Everything is bigger screens, higher resolution, richer audio, more video, more feed, more pull. The whole online economy now runs on a single currency, and it isn't money. It's your attention. Money is just the exhaust.

This is the bit the smart people figured out a while ago. When everything becomes abundant - storage, compute, content, even decent software - the only thing left scarce is human focus. So that becomes the battlefield. Social media is just the most honest example. The lawnmower is the funniest one. In essence, people care less about if and how things work and more if they look good and are easy to operate.

Now here's where it gets interesting for anyone reading this who, like me, built a career on knowing the deep technical stuff. You don't have to like what comes next; I certainly don't, but it's your best toolset to survive this economy.

I spent years being the person who could go three levels down where the documentation ends and the screaming begins. The kind of engineer companies kept slightly hidden from HR, because if HR met us in the wild, they'd have questions about the eye contact, or lack thereof. For a long time, that was enough. You could be the network guru living happily in the server room, fluorescent tan, ashtrays, and all, and the world routed around your social quirks because your knowledge was irreplaceable.

That deal is mostly off the table now. Not entirely - a handful of companies still need humans who know one thing so deeply it borders on a personality disorder, and they'll happily pay to keep them away from meetings. But that's a shrinking list. The market reorganized itself around the attention economy, and it didn't ask the nerds first.

So if your entire career is built on pure technical depth, here's the unglamorous advice nobody wants to hear:

👉 Learn enough "normie" to translate. Some web dev, some basic design sense, some understanding of how things are sold and marketed. Not to become a marketer. To stop being illegible to the people who control budgets.

👉 Understand attention as a system. Why people click, why they don't, why a beautiful dashboard gets funded, and a brilliant, ugly one gets cancelled. You don't have to like it. You have to see it. Engineers who understand the attention game stop losing arguments to people with worse ideas and better slides.

👉 Make your work visible. The deepest technical save in the world is worthless to your career if it happens silently in a terminal at 3am and nobody upstairs ever hears the story. Packaging your value isn't selling out. It's self-defense. My old manager told me: "do good and talk about it". I hate it, you hate it, but this is how it works.

👉 Treat empathy as a technical skill. Understanding "normies" - meaning, you know, most humans - isn't a betrayal of the nerd identity. It's a hard skill that makes you better at support, better at architecture decisions, and better at not being the engineer who's technically right and professionally invisible.

And for the leaders reading this: the lesson runs in the other direction too. Your magazine-reading server gremlins 🐎 are still the ones who actually keep the lights on. The shift toward shiny and consumable doesn't mean depth stopped mattering. It means depth got harder to see from the executive floor because middle management filters out anything that doesn't fit on a slide. The engineer hiding in the server room didn't become useless. They became hard to find. There's a difference, and confusing the two is how companies lose their best people to the one competitor who still knows the difference. So if you can, try to at least protect them a little; they are likely struggling in this new world without even knowing so.

I never did find out which projector was best. But I learned the more useful thing my old magazine accidentally taught me on its way out: when the whole world pivots from building to consuming, the rare and valuable move is to stay someone who can build - and learn just enough of the consumer's language to make the builders matter again.

What did your favorite tech magazine slowly turn into? And did you broaden out, or double down on the depth? 👇

This article is also available in German.

The 14 Demands Your European Tech Company Should Be Making of Every Vendor

Tue, 07 Jul 2026 12:32:37 +0200

(And Why Their Sales Team Will Say Yes)

If your European tech company is not making these demands of every vendor, you are subsidizing the offshoring of your own economy and gambling with your sovereignty. I once sat through a postmortem with a German SaaS company that had a Severity 1 outage lasting 38 hours. Their vendor had a platinum support contract with "30-minute first response" but the first response was from Bangalore, asking, "Have you tried restarting the service?" After escalating for 6 hours, they got someone who knew the product - but that someone was in the US and needed to wake up. The contract had no teeth, the data was on AWS us-east-1, and the vendor's escalations went through three continents before reaching someone with decision power.

This is not a support experience. It is a hostage situation.

If you are a larger European tech company, you are actually in a position to make demands. You have the leverage. Use it. Here is the minimum you should enforce with every vendor and service provider. Do not apologize. Do not negotiate on the top items.

Top Priority - Non-Negotiable Core

Data hosted exclusively in Europe

Your PII, your customer data, your telemetry, your configuration, your logs - everything must be stored and processed within the EU. That means no data replication to US regions, no backup in Israel, no disaster recovery in Singapore unless it meets the same standard. The US has the Cloud Act and the Patriot Act. Europe has GDPR, and it is the strongest data protection framework on earth, but it only works if your data never leaves. Include contractual language that forbids data transfer to any territory without adequate protection, with explicit penalties for violating data residency.

Data transfer agreement with EU model clauses

Even with EU hosting, ensure the contract includes the standard contractual clauses for any data transfer and that the vendor agrees not to rely on the Privacy Shield or any US adequacy decision that gets invalidated.

Right to audit

The vendor must allow independent security and process audits by an EU-based firm of your choosing. This covers their data centers, access logs, employee screening, and subcontractor compliance. If they have nothing to hide, they have nothing to fear. Audit at your discretion, at your expense, but with contractual cooperation.

All remote access from EU IPs

If the vendor needs remote access to your systems, it must originate from a fixed set of EU-based IP addresses. No exceptions. This gives you an audit trail and prevents lateral access from uncontrolled locations.

No phone-home to non-EU servers

The vendor's software and agents must not transmit telemetry, usage data, or any information to endpoints outside the EU. This includes license validation servers, error reporting, and anonymous analytics. If they need to collect data, it must go to an EU-hosted endpoint.

Penalties for non-compliance with exclusivity of EU support

If the vendor violates the EU-only contact clause - even for a single interaction - they pay a predefined penalty per incident, and you have the right to suspend payment until compliance is restored.

Termination for cause when vendor fails these

If the vendor violates any of these clauses more than once in a rolling 12-month period, you have the right to terminate the contract without penalty and with a full refund of unused prepaid fees. That gives you an exit if they treat compliance as optional.

High Priority - Negotiate Firmly

Real SLAs with fix deadlines, not response theater

Vendors love to offer "first response within 15 minutes" because it is cheap to staff a call center that reads a script. You need a clock that starts when the incident is logged and ends when a workaround or fix is in place. Demand specific timeframes for actual resolution, not contact:

Critical (security breach or production down): fix or workaround within 4 hours, or fine
High (major feature broken, performance collapse): 8 hours
Medium: 24 hours

The fine needs to be painful enough that it gets the vendor's CEO attention. Do not accept "continuous engagement" language. If they cannot fix it within the window, the issue gets formally escalated to their VP of Engineering or your legal team, and the fine triggers automatically. Companies love to send "somebody" on a call with you to meet their obligations. Demand that you get a subject matter expert that actually has experience with the product and the related issue you are facing.

European-only contacts

You are not paying for a warm body in a global queue. You are paying for expertise that understands your context, your language, and your time zone. That means no routing your ticket to an offshore resource pool where the next available agent is in a country where "critical" means something different. Demand that all assigned contacts be employees of the vendor's European entity, physically located in the EU. This includes technical account managers, support engineers, escalation managers, and solution architects. If they cannot staff it, they are underinvested in your region.

No subcontracting to non-EU entities

Vendors love to subcontract support and engineering work to third parties in cheaper jurisdictions. Ban it. The vendor itself must perform all obligations using its own EU-based employees. If they need to subcontract, they must request explicit written approval from you for each subcontractor, and that subcontractor must meet the same EU-only requirements.

Escalation path within EU time zones

The escalation chain must be reachable during your business hours, in your time zone. No follow-the-sun model that routes your emergency to someone who just started his day in a different hemisphere. Your critical incidents should be handled by people who are awake and caffeinated when you are.

Lower Priority - Valuable but Flexible on negotiations

Source code escrow

For any software or platform you depend on, and that is not already open source, the vendor must place the source code in escrow with an EU-based escrow agent. If the vendor goes bankrupt, gets acquired by a hostile entity, or fails to maintain the software, you get the code. This protects your investment.

Key personnel clause

The vendor must commit to a minimum number of named, experienced engineers dedicated to your account. These engineers must be EU-based and cannot be rotated off without your approval. This prevents the "we promoted your best support engineer to project manager" bait and switch. They will try to charge you extra for this option; it's up to you to accept or pressure, depending on your investment and contract level.

Language and documentation

All communication, documentation, and handover materials must be in the language of your contract (usually applies to French and German only) and must be produced by native or near-native speakers in the EU, if you desire so. No broken English from a non-EU hub or AI-translated slop. You are paying for clarity.

These demands are not unreasonable. They are the baseline for any serious vendor relationship when you are a European company with real obligations to your customers and shareholders. If a vendor balks, they are telling you they cannot deliver the quality and security you need. Walk away.

Europe has the talent, the infrastructure, and the regulatory environment to support its own tech ecosystem. The only thing missing is the self-respect to demand it. Start now. The truth is, many companies offer similar services to bigger customers or US customers. So they are capable; they just don't want to go the extra mile and have the extra overhead for you. But if you spend at least 1 million euros per year with a vendor, you should absolutely make those demands. You will be surprised how those things are suddenly possible when there is cash on the table and the end of the quarter approaches for the sales team.

This article is also available in German.

When Efficiency Tools Collide with Human Nature

Mon, 06 Jul 2026 08:00:09 +0200

How Bureaucracy and Broken Recognition Killed Productivity

I walked into a mid-sized tech company a while ago expecting to find a classic story.

They had done everything right. Deployed AI agents. Integrated KCS workflows. Set up sophisticated collaboration platforms. The brochure checklist was complete. Management was baffled because their investment had produced the exact opposite of what they wanted.

Engineers were complaining about high workload. Vehemently. The kind of complaining that kills morale and spreads like a cold in an open office.

But here is where it got interesting. The volume was actually down. Significantly. The AI agents and self-service workflows were deflecting the easy stuff before it ever reached a human. The ticket count had dropped by a healthy margin.

The problem was that the remaining work was harder. The easy fruit had been picked. So each ticket now required more in-depth investigation, more context switching, and heavier cognitive load. But that alone did not explain the misery.

After two weeks of 1:1s and quiet observation, I found the real killers. Two of them. And they are a lot more common than leaders want to admit.

The first killer was bureaucracy dressed up as process.

The company had grown from startup chaos into something that needed structure. That is fine. But somewhere along the way, structure became an end in itself. Every action required documentation. Every decision needed a sign-off. Every change had to go through a review board that met once a week.

The engineers were not solving problems anymore. They were filling out forms. And the smart ones figured out that the path of least resistance was to quietly bypass the system and get things done through backchannels. That worked for a while. Until the system caught up and punished them for not following the rules.

You end up in a stupid loop. Engineers spend more energy hiding their work from management than actually doing it. Productivity drops. Morale drops. And management doubles down on compliance because they think the problem is a lack of discipline.

It is not. The problem is that you replaced trust with paperwork.

The second killer was more subtle. And it is the one that really stung.

Collaboration died.

Not because people became antisocial. Not because they suddenly hated each other. But because the system actively punished generosity.

I sat down with one engineer who was widely regarded as the quiet backbone of the team. He knew the system inside out. People came to him for help constantly. He always helped. Patiently. Thoroughly.

Then I asked him about his KPIs.

He showed me his dashboard. His ticket resolution time was mediocre. His personal numbers looked average. When quarterly reviews came around, he had to explain why he was not performing like the isolated cowboys who just churned through their own queue and ignored everyone else.

He stopped helping.

Not because he wanted to. Because he had a mortgage. And management had made it loud and clear that being generous was a liability.

The tragedy is that management never intended to kill collaboration. They just never made it visible. They never measured it. They assumed it would happen magically because they put Slack channels and AI agents in place.

Tools do not create culture. Incentives do.

If you reward individual output and ignore collective intelligence, you get a team of solo players who hoard knowledge like it is a scarce resource. The irony is that the AI tools they bought to accelerate work only made this worse. Senior engineers now spend their time reviewing AI-generated code that is almost right but not quite. They are slower, not faster. And they get no credit for the invisible labor of fixing what the machine churns out.

The data backs this up. Experienced developers in controlled studies take up to 19% longer with AI assistance when you account for review and debugging time. Yet they perceive themselves as faster. The cognitive load has just shifted from creation to curation. And it is exhausting.

Your best people are not lazy. They are drowning in a system that rewards busywork and punishes collaboration.

So here is the lesson. And it is a hard one.

If you want collaboration, measure it. Track who answers questions. Track who mentors. Track who reviews other people's code with patience and insight. Make that visible in performance reviews and compensation decisions.

If you want efficiency, trust your people to do the right thing and remove the bureaucratic friction that makes them lie to you.

And if you want AI tools to actually deliver on their promise, stop measuring lines of code and start measuring outcomes. Reward the engineer who prevents a bug, not the one who generates a thousand commits that look correct but break in production.

Your tools are not the bottleneck. Your culture is.

This article is also available in German.

The Foreign Manager's Survival Guide to German Engineers (Yes, We Know We're Weird)

Thu, 02 Jul 2026 09:00:26 +0200

When I was 17 and still an apprentice, I once walked into the office holding a B+ from business school like a cat presenting a dead bird. Proud. Expecting a head pat.

My team lead looked at it, looked at me, and said: "Well. Nobody yelled at you. That's praise enough."

No joke. That sentence raised a generation of German professionals.

And if you've ever managed, hired, or simply tried to befriend a German colleague and walked away thinking "this person is mildly broken" - congratulations, you've met us. Let me translate.

👉 Why your German only reports bad news

Here's the operating system you need to understand: in the German mind, the good is assumed. It's the default. Things working correctly is not an event worth mentioning. Why would you celebrate a server that's up? It's supposed to be up.

So your German engineer walks into the standup and reports only the three things that are broken. To an American manager, this reads as negativity, low morale, maybe even a flight risk. To the German, it's a complete and efficient status report. The other 97 things are fine. You're welcome.

This is conflict number one, and it's a brutal one. American culture runs on positive reinforcement and "great job, team!" German culture runs on the absence of disaster. One side feels starved of praise. The other feels buried in pointless noise. Neither is wrong. They're just running incompatible firmware.

The fix is embarrassingly simple: tell your German directly that you actually want to hear what's going well too, and explain why - it helps you allocate budget, defend the team upstairs, whatever. Give them a reason. Germans don't do things "because it's nice." They do things because there's a logical case. Build the case, and they'll comply with terrifying consistency.

👉 The "how are you" trap

Do not, under any circumstances, answer the question honestly.

When a German asks "how are you," it is not an invitation to share. It's a flowery placeholder, and frankly, half of us resent having to say it at all. The only acceptable answers are "good," "fine," or - if you want to sound worldly - the Irish "not too bad."

If a German senses you're actually struggling and asks again, this is 100% a trap. Smile. Say "all good." Whatever you're carrying, carry it home. We are not equipped, and more importantly, we did not budget the time.

This isn't coldness. It's boundaries. The German emotional warmth is real - it's just reserved for family, lifelong friends, and possibly a dog. Everyone else gets competence and reliability, which we genuinely consider a form of love. Showing up on time is, to us, a deeply romantic gesture.

👉 The robot comparison nobody asked for

There's a running joke that chatting with a default AI feels like talking to a German: blunt, structured, allergic to small talk, straight to the solution. I'll own it. We do that.

A German colleague hears your problem, processes it, hands you a solution, and if you don't want the solution - they turn around and leave. The conversation, in their mind, is over. You had a bug. They patched it. What else is there?

This is where Americans and southern Europeans recoil, because sometimes a person doesn't want a fix; they want to be heard. The German has no module for that with non-family. It's not that they don't care. It's that "being heard" is, to them, an inefficient way to not solve a problem.

If you just want to vent, tell us up front: "I don't need a solution; I just need to complain for two minutes." We'll be confused, but we'll allocate the two minutes. Like a calendar entry.

👉 The geography of the German soul

Think of Europe as a temperature gradient. Scandinavians on the cold end - polite, distant, will let you freeze in the lobby. Southerners on the warm end - feeding you within four minutes of arrival, whether you asked or not.

Germans sit dead center. We are the "this guy, huh? Super weird" (Rick and Morty reference) of European emotional life. Will a German invite you in for a meal? Genuinely a coin flip. Could go either way, and even we don't know which until the moment arrives.

But here's the upside that catches everyone off guard: we are nicer than we appear on first contact. The cold shell is just a cover for a surprisingly loyal core. Invite a German to your BBQ. Get them slightly relaxed. One of two things happens: you find a friend for life, or you discover a creature you'd cross continents to avoid. Especially after the third beer. I warned you. There is no middle outcome.

👉 How to actually manage one

Put a German where they can work without friction. Remove the bureaucratic gravel from their shoes, and they'll out-produce teams twice their size - the quiet, diligent power horse 🐎 who just wants a clean problem and the runway to solve it.

But not every German is the diligent type. Some are deeply, gloriously rebellious: allergic to process for its own sake, ready to argue with you about why the process is dumb. The trick is figuring out which one you've got.

The good news: you can simply ask. Germans are radically, sometimes alarmingly honest. You don't need an engagement survey or a skip-level. Just ask "do you prefer structure or autonomy" and you'll get a true answer, possibly along with feedback on your management style that you didn't request.

And if you really want the unfiltered version, tell a German to be "extra honest." They will deliver. Just make sure HR isn't in the room, and maybe have a glass of water ready - for you.

👉 The neurodivergent footnote

A lot of what reads as "German" overlaps neatly with what reads as autistic or ADHD-flavored: pattern-driven thinking, low tolerance for social theater, brutal honesty, deep focus on systems. Germany didn't invent precision engineering by accident. There's a whole population here that found a culture that rewards their wiring instead of punishing it.

Which is maybe the real lesson for managers everywhere: the people who skip the small talk and obsess over the broken thing are often your best builders. The culture just decides whether you label that "rude" or "elite."

And yes - we do have humor. It lives somewhere between dark British dryness and pure cynicism. Mr. Bean was wildly popular here, which should tell you everything. The reason you can't always tell we're joking is that our delivery is identical to a server outage report. That's not a bug.

Bottom line: with German engineers, you get what you pay for, rough edges included. Reliable, honest, allergic to drama, weird in the best way. If you like the good kind of strange - and most great teams are built on it - it's almost always worth it.

How does your culture handle those aspect? Share it with us. 👇

This article is also available in German.

The Horizontal Promotion Trap: How You Turn Power Horses Into Pack Mules

Wed, 01 Jul 2026 13:00:28 +0200

You know the scene. Klaus (or whatever name your local power horse goes by) has been carrying the team for 18 months. Bug fixes, feature work, on-call rotations, mentoring the new grad, troubleshooting the architecture mess the previous lead left behind. He does it all with quiet competence. The quarterly IDP comes around. His manager beams: "Klaus, we're promoting you to Distinguished Engineer." Handshake, new title in the HR system, a 7% bump and a vague promise of "broader responsibilities."

Fast forward three months. Klaus is drowning. He still does everything he did before, plus the project planning, the cross-team alignment meetings, the compliance documentation, and the performance review feedback for his peers. He has no more authority. He has no more decision rights. He just has more work. The new title was a horizontal shuffle dressed up as a promotion. And now he's a pack mule, not a power horse.

I watched this happen at three different companies over the years. Always the same pattern: brilliant individual contributors get "promoted" into roles that expand their scope horizontally without giving them any real leverage. They don't get a seat at the table. They don't get budget authority. They don't get a voice in strategy. They get an extra hour of meetings each day and a new section in the org chart that just means more people can dump work on them.

The result is predictable: burnout, quiet quitting, or a resignation letter that says "pursuing new opportunities" but really means "I refuse to be buried alive in operational sludge."

Here's the simple truth the midwit management playbook misses. Promotions should be about power and influence, not just scope and title. If you want to keep your top talent doing what they do best (and doing it brilliantly), give them money instead. Flat out. A raise that says "you're so valuable we don't want you to even think about leaving." Money is a hygiene factor, not a motivator - but lack of it is a demotivator. Pay them enough that they never feel stuck, and let them stay in the work that lights them up.

If you do promote vertically, give them something real: budget ownership, hiring authority, veto power over architectural decisions, or a direct line to the VP. Stack their deck so they can actually move the needle. Otherwise, you're just adding weight to a horse already galloping at full speed. That ends in a breakdown.

👉 A horizontal promotion that only adds tasks is a demotion dressed up.
👉 If you want someone to stay in their zone of genius, give them a raise, not a workload.
👉 If you promote, promote with teeth - power, voice, and privilege, not just a new email signature.

Your power horses are not donkeys. Stop loading them like one.

👇 Ever been "promoted" into a burnout trap? Share your story.

This article is also available in German.

The People Framework

Tue, 30 Jun 2026 11:24:34 +0200

Why Your "Troublemakers" Are Your Most Valuable Assets (And Your "Sheep" Are Your Foundation)

You know the type. The engineer who has been in the same role for five years, never missed a single SLA, never complained, never suggested a change, never even looked at the process documentation because they had memorized it by year two. They just. Do. The work. Steady. Predictable. The kind of person you could set your watch by.

And then you know the other type. The one who, on day three, discovered a "creative" way to bypass the VPN because the VPN was slow and they had work to do. The one who asks "why" six times per meeting. The one who treats every rule like a suggestion and every process like a puzzle to be solved. The one who makes your compliance officer twitch.

Which one do you want on your team? Trick question. You want both, but not in the same seat. The problem is most companies treat them the same. They hire for one archetype, then promote based on another, and end up with a team that's either a zombie parade or a rebellion.

Let's be honest about human variance. Some people are deeply comfortable inside systems. They find safety in predictability. They execute reliably. Others are allergic to systems; they feel trapped by them, suffocated. Their brains light up when they spot a loophole or a way to optimize. Neither is good or bad. They are different operating systems. And if you place either one in the wrong environment, you get disaster.

Place the system-tolerant person in a role that demands constant creativity and challenge? They burn out or become deadweight. Place the system-resistant person on a team that needs process adherence? They become a disruption. But put them where they belong, and you get a power horse.

The Two Categories

Category A: The System-Tolerant.

They don't question the guardrails. They don't fight the tooling. They follow the playbook, and they follow it to the letter. In a ticket queue, they handle the backlog with zero drama. In operations, they keep the lights on. They are the backbone of any mature organization. They are also the first to stagnate if you don't give them new playbooks to follow. They don't need a why; they need a how. This makes them invaluable for compliance-heavy roles, regulated industries, senior support tiers where consistency is king, and any position where deviation means legal trouble or data loss.

But put them in a startup or a team that's building something from scratch? They will wait for instructions that never come. They will spin their wheels. They will look lost. That's not their fault. That's your fault as a leader.

Category B: The System-Resistant.

These are the people who rewrite the automation script that was working fine because they think it should be faster. They are the ones who skip the approval step and ask forgiveness later. They break things by accident because they were trying to improve them. They are also the ones who find the zero-day before the attackers do, who spot the process gap that saves the company millions, and who build the internal tool that cuts resolution time by 80%. They are your innovators, your security hunters, your process killers.

Put them in a strict SLA environment with rigid escalation paths? They will hate you, and you will hate them. They feel like prisoners. They will either leave or become toxic. Put them in R&D, architecture, threat hunting, or a role that explicitly rewards 'breaking the rules to find the better way'? They thrive.

How to Identify Them in Hiring

You cannot ask "Are you a rule-follower or a rule-breaker?" because everyone will give you the safe answer. You need behavioral evidence.

Ask: "Tell me about a time you followed a process you thought was wrong. What happened? What did you do?"

The System-Tolerant will say "I followed it anyway because it was the process." They might add that they documented the issue. They will not have tried to bypass it. This is not weakness - this is reliability. You want this person for certain roles.

The System-Resistant will say something like "I bypassed it to prove it was unnecessary, then I automated the whole thing." Or "I escalated directly to the VP because the process was blocking a customer fix." Or "I wrote a script that did the work without the 5-step approval because the approval took two weeks." They took action. They broke the rule. They are a compliance nightmare and a productivity goldmine.

Ask also: "What kind of work makes you lose track of time?"

System-Tolerant: "When I have a clear queue and I can just execute."
System-Resistant: "When I have a hard problem with no clear solution and I can experiment."

The Strategic Placement Matrix

High compliance need, high repetition, low variation: Hire System-Tolerant. They will be happy, they will be consistent, and they will stay for years. Bonus: they are often excellent mentors for junior staff because they teach the process by example.
High variation, high autonomy, high ambiguity: Hire System-Resistant. They will need oversight that is 'invisible' - you need someone who can guide their energy without boxing them in. Give them problems, not tickets. Give them outcomes, not steps.
Mixed teams: This is where your leadership skill matters. You need a lead who can translate between the two worlds. The System-Resistant person will want to change the process. The System-Tolerant person will resist. As a manager, you must protect the System-Tolerant from being overwhelmed by change and the System-Resistant from being suffocated by rigidity. You create a "safe zone" for innovation (e.g., 20% time or a dedicated improvement backlog) and a "stable zone" for execution (clear boundaries for when innovation is not acceptable).

The Dark Side of Each Type

System-Tolerant, over time, can become "zombie workers" - present, but not present. No initiative. No ideas. They can also become passive-aggressive if you change the process too much. They need stability, but not too much stability. Rotate their tasks. Keep them learning new playbooks.

System-Resistant, if mismanaged, become "cowboys". They will break production. They will ignore compliance. They will create shadow IT. They can also become arrogant, thinking they are smarter than everyone else. They need a strong technical authority they respect who can say "no" when necessary, and they need clear guardrails for the "sandbox" they're allowed to break.

The Uncomfortable Truth

Most companies over-index on System-Tolerant in hiring because "culture fit" often means "someone who won't challenge me." This leads to teams that execute but never innovate. Then they wonder why they can't keep up with competitors.

The best organizations deliberately hire a percentage of System-Resistant people and protect them from the bureaucracy. They give them the "hard problems" and shield them from the process. They treat them like valuable outliers, not threats.

If you are a leader, look at your team right now. Do you have a balanced mix of system-tolerant and system-resistant people? Or do you have a room full of people who all do exactly what they are told without ever questioning it? If it is the latter - a homogeneous team of compliant executors - you have something predictable, stable, and dangerously fragile. If it is the former - a genuine mix of both archetypes - you have something a little chaotic, innovative, and occasionally painful to manage. But that mixed team wins in the long run. Both types require careful handling, but the mix gives you resilience and adaptability.
Still, this only works if you actually know which category each employee falls into and whether they are currently positioned well. If you do not have that clarity, it is time to build an internal index - a simple map of each person's natural tendencies - and redistribute roles accordingly. The wrong placement kills motivation; the right one unlocks a power horse 🐎.

So next time one of your engineers complains about the process for the hundredth time, don't sigh. Ask yourself: "is this person a System-Resistant power horse in the wrong paddock?" Move them. Don't kill them.

And the one who never complains? Give them a medal. Then give them a new playbook. They will thank you.

👇

This article is also available in German.