So I wrapped their REST API instead. The published reference sits behind a login wall, which meant an afternoon of probing the live API to find out how it really behaves. Four things turned up that aren't obvious from the outside, and each one changed the design.

The catalogue has no search

GET /v1/mockups accepts q, search, type, family and tag. It ignores all of them. Every request returns the same unfiltered first page with HTTP 200 and no warning, so there is no signal that it is being ignored. I noticed when the results looked wrong, not when I made the mistake.

What does work is limit. And limit=6000 returns all 5,314 mockups in a single 3.3MB response.

That turns the whole problem inside out. Instead of paginating a search API, the server fetches the catalogue once, caches it, and searches locally:

# 5,314 rows, one linear scan, measured well under 20ms,
# which is nothing next to a 17-second render.
rows = await catalog.load()
matches = catalog.search(rows, query="tablet on a desk", limit=12)

Local search also buys something the API could never offer: an alias table. My callers say "tablet"; the catalogue says "iPad". Nothing in it contains the word "poster" at all; that family is called "Paper". Eight lines of aliases bridge the gap.

Omitting size means hi-res, and hi-res means failure

Leave size out and the API renders at full resolution. On any plan without the hi-res feature, that fails the entire render with feature-not-available.

So the default is the expensive option, and the expensive option is the one most accounts cannot use. The server never lets that field go unset:

json={
    "mockup": mockup_id,
    # Never omit: a missing size is treated as hi-res, which hard-fails
    # on any plan without that feature.
    "size": size,
    ...
}

There is no upload endpoint

contents[].url is mandatory. No base64 field, no data URI, no multipart. To render an image, that image must be fetchable from the public internet.

Which means the obvious use case ("put this design, the one on my laptop, into a mockup") requires you to first solve image hosting. That is a bucket, a CDN, a lifecycle policy, and a bill, all to show a PNG to a renderer for four seconds.

The server does it differently. It holds the bytes in memory under a 256-bit token and serves them from one route on itself, then lets them expire:

create_mockups(mockup_ids=[...], image_base64="<your png>")
  -> staged at https://.../i/<token>.png   (15 min TTL, in memory)
  -> Mockuuups fetches it, renders, done
  -> token expires, bytes are gone

No bucket. The one honest caveat is that the route cannot be authenticated, because the client fetching it is Mockuuups' renderer and not you. Standing in for auth: an unguessable token, a short TTL, a size cap, and magic-byte sniffing so only real images are ever served back out. I would not put anything sensitive through a mockup service anyway.

Synchronous renders are slower than your timeout

A screenshot render measured 17.3 seconds. Four devices in sequence is roughly 69 seconds, and the Cloudflare MCP portal these servers sit behind severs anything past about 60. So doing it synchronously works perfectly for one mockup and breaks the moment you ask for a set, which is exactly when it matters.

mode: "async" returns in 0.6 seconds, with the CDN URLs already allocated before the render has started. So every render is dispatched concurrently, then polled together inside a bounded budget:

create_mockups(
    mockup_ids=["Zkn1GMTfiAFX5ZOn", "Zkn2BcTfiAFX5ZPB",
                "Zkn2DsTfiAFX5ZPD", "Zkn1dMTfiAFX5ZOz"],
    screenshot_url="https://wtdib.cdit-works.de/",
)

Four devices cost about as much waiting as one. Anything still running comes back as a handle to poll, and the delivery links are already valid.

The tag trick

The nicest find isn't an API behaviour at all. Mockups shot in the same session share a tag, so a consistent set across devices is two calls: search one mockup you like, then filter by its tag to get the rest of that shoot. Same room, same light, different hardware.

That is how the demo set was made: one Berlin city guide, four screens, one photoshoot.

Four tools

search_mockups, create_mockups, get_renders, account_status. That last one exists because credits are scarce and plan-gated: one render costs a credit, a website screenshot costs two, hi-res costs another. I check it before a batch now, rather than after.

The whole thing is about a thousand lines, and most of the time went into the four findings above rather than into the code.

Which means the year I was 42 is over, and I have spent the summer thinking about the joke. Douglas Adams built a computer the size of a city and asked it for the answer to life, the universe and everything. It thought for seven and a half million years, then answered: 42.

Nobody could use it. They had never worked out the question.

So they built a second machine, larger than the first, and gave it one job: find the question.

Fifty answers

I did not plan a year around a number from a novel. It kept fitting anyway.

Nineteen days after I turned 42, I published something for the first time in four years. Then I did it again, fifty times, until the end of June. Essays, field notes, a quarterly readout, a newspaper that switches itself off in order to stay alive. In the twelve months before that, I published nothing at all.

Fifty answers in ten months. That is what the year of 42 produced.

And then, on the 26th of June, I stopped. I have not published a word since.

What actually happened

There are reasons. There are always reasons. The one I keep circling is that writing was the only thing on the list that was supposed to be for me, and it is the thing I put down first.

Underneath that is an arithmetic problem.

For most of my life the effort a thing cost was part of what made it worth doing. A week of work felt like a week of work, and whatever came out at the end had that week inside it. You could feel the cost in the thing.

That arithmetic broke. An essay is an afternoon now. A content strategy is a conversation. The app is a fortnight. I am not complaining about the tools and I am not claiming the output got worse, because it did not.

But nothing costs what it used to, and somewhere in June I noticed that nothing pays what it used to either.

I did not get slower. The easier version of this paragraph says the magic wore off and I lost a step, and it would be a lie. I can still build in two weeks what used to take a quarter, and that is true this morning.

The ceiling is somewhere else. Making the thing stopped being the work. What is left is deciding what should exist, and that was always the hard part.

I am very quick at other people's questions. I have got no faster at my own, and I am not sure I have ever properly tried.

Fifty pieces in ten months, and I could not tell you which one of them was mine.

When you stop moving, you start looking around.

What I saw when I looked around was a feed.

LinkedIn is drowning in sentences nobody wrote. YouTube has filled up with prophets who will explain the future of everything for forty minutes, and somewhere in the last year they stopped being curious. You can hear it in the grammar. A curious person asks. A salesman answers.

Instagram is not helping either. None of it is. We are all standing a little further from each other, and from the ground we are actually on, than we were a year ago. I do not think the machines did that to us by themselves.

The part that annoys me

I wrote this down a year ago and did not understand it.

On the 14th of September, thirty-two days into being 42, I published an essay about the iron triangle. It ends by saying our job now is to ask better questions when we brief, both humans and machines. In October I published another one, arguing that the leaders who do well from here will be the ones leading with curiosity instead of certainty.

In April I published a third, about being addicted to the output instead of the outcome, and what happens when the flow finally stops. Two months later, mine stopped.

I filed all three, felt clever, and carried on producing answers at five a month.

I think, and I want to be clear that this is a guess, that the ceiling was never the machine's. More likely it was mine, and it moves when the question gets better. That part I cannot prove. Ask me in a year.

Where I landed

What changed in me is smaller and less quotable than a prediction.

I got quieter. Slower to claim things out loud. Some of that is stoicism arriving late, and some of it is just being 42 in a year when everyone had an opinion and the good ones were rare.

The work I am proudest of this year did not begin with a tool. It began with sitting across from someone until I could see where their time was going. That part has not sped up at all. It cannot be prompted, and I have stopped wishing it could.

I do that for other people for a living. I have not once booked the appointment for myself.

Answers are cheap now. They arrive by the million, at any hour, in three languages, and most of them are almost right.

The question is the scarce thing. It always was. It took a machine answering everything to make that obvious.

Adams put one more detail in there that I keep returning to. The second machine, the one built to find the question, was the Earth. Not a computer in a room. A planet covered in people, living, arguing, missing each other, taking ten million years about it.

He was right about which machine you need for that job.

nebula-1 is a number with a hostname stapled on. It does its job, and if it died I'd feel nothing; I'd just stand up another. But Blippström, the home-automation umbrella I named for the sound a sensor makes when it triggers, I would mourn a little. Same kind of box. Same kind of work. The only difference is that I gave one of them a face.

Sysadmins have a phrase for this: pets and cattle. Cattle are numbered and interchangeable, and when one gets sick you replace it rather than nurse it. Pets get names, and vet bills, and grief. Running servers well is supposed to be the art of turning your pets into cattle.

I spend my evenings doing the opposite.

Lichtspiel, Hauswart, Piepmatz, Funkturm. A cinema, a janitor, a little bird, a broadcast tower. All built in the cracks: Sunday morning, the hour between dinner and bed, the train back from Berlin. None of them would be alive in the same way if I'd called them node-red-flows or bird-cam. I'd have built those too. I just wouldn't have cared about them.

The question I keep circling is why. Why does a name change anything, when the code and the bugs and the unfinished tests are all identical?

I've found three answers. The longer I sit with them, the more they look like one.

The first is grip. An unnamed thing has no surface you can hold. A function-name tells you what the code does; a real name tells you what the work is to you. There's an old idea in philosophy that a hammer you're using disappears into the swing, while a hammer you're only looking at is just an object on the bench. A name is what lets the work disappear into the swing.

The second is company. We personify what we build because building alone summons the wish for someone to build beside. There's research on this, and it's almost rude in its accuracy: we anthropomorphise most when we're reaching to feel competent and when we're short on connection. Which is a clinical way of describing a man writing Swift on a Sunday while the house sleeps. Piepmatz keeps me company in a way bird-cam never could. I didn't decide that. It's just true.

The third is the contract. A named character with a one-line story asks something of you that a folder doesn't. Besserwisser, my finance cockpit, named for the know-it-all who corrects your pronunciation, asks whether I did the thing I said I'd do. finance-app asks nothing. The name is a small promise to my future self, the way saying a goal out loud makes it harder to quietly drop.

(There's a fourth thing underneath the other three: we love what we make simply because we made it. Psychologists call it the IKEA effect. Not flattering, but real. The name only gives that love somewhere to live.)

Grip, company, contract: three doors into one room. Each one turns a thing into a someone.

For a long time I thought the names were about starting. Clarity before the first commit, motivation through the boring middle. And they are.

But that isn't why I keep doing it.

You can't miss cattle. You can switch off a numbered box and feel nothing at all. The whole quiet, slightly ridiculous point of a name is that it makes the thing missable. And only a thing you can miss can be properly let go.

I have a board full of dead projects. BjörnAgain, a video pipeline named after a Swedish bear, I closed last month. Canceled, not done, because I stopped wanting the thing it was for. Closing it wasn't deleting a folder. It was a small you served, thank you, that's enough to a character that ran for a while and then didn't need to anymore.

That moment costs almost nothing, and it leaves the rest of the work clean.

So here's the answer I've landed on. We don't give our projects names so that more of them ship. Most of them never will; that was always true. We give them names so the ones that die can be missed for a second, honestly, and set down.

A pet, you can bury. Cattle, you just count.

🌈

The companion to this is The graveyard is the point, which is about the technique. This one is about why the technique works on us at all.

Agents today are where the web was before frameworks, with everyone hand-rolling the same plumbing and nothing carrying over to the next one. Next.js ended this for the web, and eve is doing the same for agents.

That is Vercel, announcing eve this week. An open-source framework where an agent is a directory of files, and the runtime (durable execution, a sandbox, approvals, channels, evals) comes in the box.

I read it with a strange double vision. In May I wrote a careful plan for almost exactly this, and then I deleted the code.

The plan was a Telegram bot: a FastMCP server, a per-engagement SQLite database, a scheduler on a Hetzner machine, a daily brief that arrived whether I asked for it or not. I was proud of it. Then I deleted the code and replaced the whole runtime with a markdown file that routes through the tools I already pay for. eve, this week, ships the Telegram channel I had been hand-rolling, as a single file.

So this is not a review. It is the view from someone who turned off this road on purpose, and what I think it means.

The industry is settling on a shape

Look at how eve lays an agent out.

agent/
  agent.ts          # the model it runs on
  instructions.md   # who it is
  tools/            # what it can do
  skills/           # what it knows
  subagents/        # who it delegates to
  channels/         # where it lives
  schedules/        # when it acts on its own

A file's name and place in the tree are its definition.

That is the whole bet, and I think it is correct. Agents have a shape, and the shape is a folder in git. Vercel is not guessing at demand here. A year ago, agents triggered less than 3% of the deployments on Vercel. Now it is around 29%, and they expect half soon. When the work has clear per-action value the economics are not subtle either. Their sales agent costs about $5,000 a year to run, returns 32 times that, and one engineer maintains it part-time.

For that kind of job, where a machine should act around the clock and each action pays for itself, eve is a serious, well-made answer. I am not arguing with any of it.

I got to the same shape from the other side

Here is the part that gave me the double vision. I have been building this for client work, by hand, for months. One companion per engagement, and each one is a directory:

companions/<engagement>/
  SKILL.md      # who it is, and what it routes
  config.md     # the IDs it is scoped to
  persona.md    # the relationship
companion-core/
  conventions/  # what every companion knows
  modes/        # brief, prep, remember, reconcile

Same instinct: a file's place is its meaning. I even hand-rolled the exact Telegram channel eve now ships as one line. Then I deleted it, because the channel and the schedule were the parts I did not want.

This week, prompted by the launch, I started pulling the shared shape out of my companions into one place. Vercel describes the same move for their hundred agents:

Today they live in one monorepo... Because they all share the same shape, a hundred agents run with the same tools and the same conventions as one.

That is what I am doing, at a smaller number, for the same reason. The convergence is real, and it is the best signal that the folder-in-git idea is right.

Where I turn off the road

The difference is one word. I do not build agents for this work. I build companions, and I keep them as a Claude Code skill: no runtime, no channels, no schedules.

An agent executes. It runs on its own clock, and the better it is, the less you are in the room. A companion accompanies. It runs beside you, when you call it, and the better it is, the sharper your own judgment gets.

For the kind of slow, relationship-shaped client work I do, the value was never autonomy. It was continuity. A companion that holds the thread and hands it back is worth a great deal. The same tool answering the client for me, in a voice that drifts a little further from theirs each week, is worth less than nothing.

The economics flip with the word too. An agent meters tokens on every run, and the bill grows with autonomy. A companion rides the subscription I already pay and spends nothing when I do not call it. The agent's cost grows with use. The companion's value grows with use. For the sales agent working leads at three in the morning, the first model is obviously right. For the work I do, the second one is.

The one thing I am stealing

eve is sharp about keeping an agent honest:

An agent your team depends on is production software, and a change to its instructions can break it as surely as a change to its code.

So they write evals and run them in CI as a deploy gate. I am taking that outright.

But it catches the wrong failure for a companion. An agent breaks when you change it. A companion breaks when the world changes under it and it does not notice: a new account appears, a service gets renamed, the plumbing moves to another host. I have proof in my own notes, where a companion's architecture section went stale months ago and simply stayed stale.

So a companion needs a different pass. Not a regression gate, a freshness pass. Something that reconciles the world it has written down against the world as it is, and reports where they drifted. An agent is kept honest by tests of what it does. A companion is kept honest by checking whether it still knows your world.

What I kept

I did not lose the idea when I deleted the code. I lost the runtime, and the runtime turned out to be the part I did not need. eve is the right tool for the case where the machine should act. I build for the case where a person should act, better, with something quiet beside them that remembers.

Same folder of files. A different job, a different bill, a different way to stay true.

The word I chose was companion, not agent. eve, of all things, made me more sure of it.

Copy in irreplaceability order. First the data that exists nowhere else — photos, archive, originals — verified and offsite, before the bulk I could re-rip in a weekend. If a step fails early, it fails on replaceable data.

A size match is not a copy. du disagrees across filesystems: it counts directory metadata and dedups hardlinks, so identical data reports two different sizes on two machines. Compare content, not size — rsync -c (checksum) or a byte-for-byte comparison. The checksum pass over the full archive returned zero differences.

Restore one file before you trust the backup. After the offsite restic copy finished, I restored a single 450 MB video and byte-compared it against the source. Identical. A backup you've never restored from is unverified.

Preserve uids or Postgres won't start. Postgres data is owned by a specific user id; a naive copy squashes ownership and Postgres refuses to start. I synced with rsync -aHX --numeric-ids over a share that preserves ownership, then checked it: wrote a file as that uid, confirmed it landed as that uid. Thousands of database-owned files moved across with ownership intact.

Cut services over with a quiesce. Don't copy data out from under a running app. Dump the database, stop the containers, run a final sync of the now-static files, repoint storage, restart. That last sync is consistent because nothing is writing. The source stays in place until the end, so any step can be reversed.

Verify by function, not "container up." A green status light proves little. Make the service do its job: the resolver resolving a real domain, the cameras reconnecting to their stations, a document going through scan → sync → file, the music server reporting its real track count, the devices rediscovering themselves on the network.

Two things I didn't plan for. A disk in the new mirror failed mid-copy; the migration continued untouched, because the irreplaceable data was already offsite and the source was only read, never written. And before deleting anything that looked like a duplicate, I confirmed it was one — comparing sizes and file types, not memory. Some things that look redundant hold the only copy.

The goal was never speed. It was a copy I could prove.

Postscript — the disk.

The failed mirror member (a WD 8 TB) sat degraded until the migration finished, then I cold-swapped it. No identify LED on the enclosure, so: power down, read the serials off the labels, pull the one that isn't the survivor.

The resilver only had to copy the ~685 GB in use and finished in about an hour — but it logged 18 checksum errors on each disk and three unrecoverable ones, flagged as data corruption. The damaged object was a single piece of ZFS metadata (<metadata>:<0x3d>), not a file: corruption from the window when the mirror ran on one disk with no second copy to repair from. A scrub re-read every block with both disks present — repaired 0B in 00:57:45 with 0 errors, then "No known data errors" — and zpool clear reset the counters. Nothing lost.

The corruption banner was real. It didn't matter, because the originals were still on the old machine and a verified copy was already offsite. A degraded destination only costs you the data it holds the sole copy of.

In one sitting: traced MultiViewer's local GraphQL on the actual magic-mirror host, proved the video-sync comes free and that the player-control cockpit works on production hardware, designed seven session-adaptive faces (race plus its flag states, the 2026 quali drop-zone, a practice sector tool), and landed it as a four-artifact OpenSpec change — proposal, design, specs, tasks.

Plus one radical idea that stuck: team radio whispering from the mirror's own little speaker while the room hears the race.

Next: build.

The hardware

The press itself is modest: a Raspberry Pi 4, a Waveshare 7.5 inch e-paper panel (800 by 480, the V2), and a PiSugar 3 battery hat. The panel is nominally one-bit, black or white, but the driver has a quietly documented four-level grayscale mode. Each pixel becomes one of four luminance bytes:

--ink          #000     →  0x00   (black)
--gray         #7a7a7a  →  0x80
--gray-light   #c9c9c9  →  0xc0
--paper        #fff     →  0xff   (white)

Four tones turn out to be exactly enough for a newspaper: ink, paper, a secondary text gray, and a hairline gray for rules that should whisper.

The whole thing stands in portrait on a shelf. E-paper keeps its image at zero power, which is the trick the entire architecture leans on: the display does not need the computer once the page is printed.

The power model

The Pi boots, asks a server for the current edition, writes 384,000 bytes to the panel (one byte per pixel), tells the PiSugar when to wake it next, and shuts itself down. The full cycle takes about two minutes. Between cycles the only thing drawing power is the PiSugar's real-time clock, waiting for its alarm.

All intelligence lives in the backend, a FastAPI service in a container on my home server. The device is deliberately dumb: it obeys a single field in the API response and nothing else.

{ "scene": "night", "color_mode": "gray4", "next_wake_minutes": 480 }

Scheduling logic, content, rendering, even "should I wake less often because the battery is low": all server-side, all changeable without touching the Pi.

A browser as typesetter

I did not want to draw pixels with a graphics library. The editions are Jinja2 templates rendered by headless Chromium (Playwright) at 480 by 800, with bundled woff2 fonts so renders are deterministic and offline-safe. Real typography, flexbox, proper kerning. The screenshot then gets quantized to the panel's four levels: templates use exact tones so they snap cleanly, photos get error-diffusion dithering instead. A server-side render on a cache miss takes about a second; the worker pre-renders each edition before its window opens, so the device usually hits warm cache.

Design before code

Before any backend existed, the editions were designed as artboards on a Paper canvas, at exact panel resolution. We argued about them like a tiny editorial board: a broadsheet with a blackletter masthead won the morning slot, a Swiss-typography date sheet lost, a calendar took the office hours, a single quote took the night.

The artboards stayed the source of truth all the way through: when the templates drifted, we compared against the canvas, not against memory.

The losing Swiss design got a second life, which I will come back to.

The schedule follows the sun

The morning edition (the broadsheet: an on-this-day lead story from Wikipedia, three year-lookback briefs, weather from the station on my roof via Home Assistant) prints at sunrise, clamped between 05:30 and 07:45. The day edition is my calendar, refreshed hourly during office hours. The night edition is a single quote from my Readwise library, printed at sunset, clamped between 18:00 and 22:30, and it holds the glass all night at zero power. Sun times come from Home Assistant's sun.sun; if that is ever unreachable, fixed hours take over and nothing breaks.

On weekends the calendar stays home. The resurrected Swiss design (the date sheet that lost the morning slot) prints at sunrise as the weekend edition and holds until sunset: a huge date, the history briefs, the weather, one line about today's appointments. Three wakes a day instead of twelve, which the battery appreciates.

Last night I watched the first sunset-anchored cycle land: the night edition printed at 21:27:59, sunset to the minute, and the device was told to sleep 480 minutes. That wake-up lands at 05:30, the sunrise clamp, on a Saturday. The schedule knew before I did.

A sub-editor on retainer

The weakest part of the paper was the prose. Rule-based curation cut Wikipedia text to fit character budgets, and it showed: headlines like "Air India Flight 171" (an article title, not a headline) and briefs that ended mid-phrase. So the backend now passes the curated lead and briefs through one Claude API call a day. Haiku, structured output validated against a Pydantic schema, a system prompt that carries the house voice and forbids touching facts, years, or names:

class EditedEdition(BaseModel):
    lead: EditedLead          # headline, deck
    briefs: list[EditedBrief]  # year stays the original; only text is rewritten
 
edition = client.messages.parse(
    model="claude-haiku-4-5",
    max_tokens=2048,
    system=PRESS_VOICE,
    messages=[{"role": "user", "content": curated}],
    output_format=EditedEdition,
).parsed_output

"Air India Flight 171" came back as "Air India flight crashes near Ahmedabad". The deck went from a Wikipedia first sentence to an actual deck.

The call is never load-bearing. No API key, an outage, a timeout, a malformed response: every failure path returns the rule-based copy and the edition prints anyway. The result is cached per date, so it costs one call and about a tenth of a cent per day. Character budgets are re-enforced mechanically after editing; the model is asked to write short, the trimmer guarantees it.

Honest telemetry

The PiSugar reports charge by measuring cell voltage, and every reading happens mid-boot under load. The result is a sawtooth: 93.5, 92.2, 87.5, 90.9, 91.5 over five hours, on a battery that was actually draining about 0.7 percent per hour. The fix is boring and effective. Keep the last five readings and report the median, not the latest sample:

self._history: deque[float] = deque(maxlen=5)
 
def battery_display(self) -> float:
    return round(statistics.median(self._history), 1)

The median goes to Home Assistant and to the printed page; the raw value stays available as a sensor attribute for anyone who misses the chaos. When the battery runs low, the paper says so the way a paper would: a black banner across the top, "low ink, please charge".

What I keep from this one

The architecture that made everything easy was the dumbest one: a device that only knows how to obey one number, and a server that owns every decision. Every feature since launch (grayscale, solar scheduling, the weekend edition, the Claude editor, battery smoothing) shipped as a backend deploy while the Pi kept waking, printing, and switching itself off, none the wiser.

Build the brain where you can reach it. Let the thing on the shelf just be a newspaper.

Not because it was hard. Because it was scary. One box, quietly load-bearing: the primary DNS for the whole house, the public front door for a handful of sites, the brain running my home automations, the feed for the cameras. If it stuttered, everything downstream felt it. So it sat there, fragile, having already crashed on me once, and I kept finding reasons not to touch it.

Last week I drained it completely. In an afternoon. Nothing went down that anyone noticed.

I want to write down how, because the how is the interesting part. The fear was never really about the work. It was about how much depended on that one box. And a dependency like that is something you can take apart deliberately, one piece at a time.

Here is the shape of it. Every critical job moved to a calmer host: DNS to a small, boring Raspberry Pi, the automations and cameras to the machine that already runs the smart home, the public tunnel to a cloud box that never sleeps. Then the old machine left the cluster, left the orchestrator, and powered off. Its disk is intact, sitting cold, in case I ever want it back.

I did most of it with Claude at the keyboard. Not doing the thinking for me. Holding the method when I'd have been tempted to rush.

A few things made it calm instead of tense.

Move under the cover of redundancy. DNS is the classic touch-it-and-the-house-goes-dark service. So I never let it go dark. A second resolver answered the entire time, and I only moved the primary once the backup was carrying the load. The rule wasn't "be careful." It was "keep one resolver answering, always."

Check what a thing does before you kill it. One container looked like dead weight. Its config was a stale clone of services that had moved away months ago, so deleting it seemed obvious. Then its logs showed it was the live public front door, still routing real traffic. We relocated it instead. Better to check what a thing actually does before deciding it does nothing.

Relocate, don't rebuild. Most of these services were stateless once their data lived on shared storage. Moving one was a thirty-second repoint, not a rebuild: stop it here, point it there, start it, check. Each step reversible, and the old box stayed on until the end, so undo was always one command away.

Steal the address, skip the politics. The textbook DNS move means editing the router and waiting for every device to pick up the change. Instead, the new host took over the old one's IP once it powered down. No router change, no waiting. As far as the clients were concerned, nothing moved.

Wire the alarms first. Before any of this, I built the part I'd put off for a year: monitoring. Two real failures had slipped past me recently. A machine that crashed and sat dead for half a day. A storage array running degraded on a single disk, found by chance. So the first job wasn't moving anything. It was making the system able to tell me, on my phone, when something is wrong.

A few smaller things, for anyone who has been here. A single config file mounted into a container keeps serving the old version after you change it, because the mount pins the original; you have to recreate the container, not restart it. Two managers is the one cluster size that is worse than one, because losing either one breaks the quorum. And a service can sit there reporting "down" while doing its job perfectly well, if its name doesn't match what the dashboard expects.

My favourite of the afternoon was a test that failed three times in a row, insisting DNS was down. It wasn't. I had fat-fingered the test. We checked by hand, found the typo, and the panic went away. The thing doing the checking can be wrong too.

Here is what I actually want to keep from it.

A migration this size used to mean a weekend, a knot in my stomach, and a rollback plan I didn't fully trust. This time it was an afternoon of small, reversible steps, each one checked before the next. The calm didn't come from being brave. It came from method, and from a partner that held the method when I'd have rushed: keep the invariant, check before you delete, verify before you believe, leave the door open until you're sure.

There is a version of working with AI that is all speed and noise. This wasn't that. It was slower, quieter, a lot more boring. The kind of boring that lets you finally do the thing you've been putting off, and find out it was never as frightening as it looked.

The server is off now. Nobody noticed.

You don't need to be fearless to take on the big migration. You need to be reversible.

Here is the part worth writing down: the lopsidedness.

Your time. Roughly 30 to 45 minutes of real attention. A handful of short messages, a few approvals ("sure, go on"), one scoping decision, and a lot of "still chilling?" while the work ran in the background. You steered. You did not type code.

My time. About four and a half hours of wall-clock, nearly all of it parallel background work. Underneath that: more than seventy subagents, around three thousand tool calls, and roughly seven million tokens of generated work across assessment, implementation, review, deployment, and infrastructure forensics.

The human-equivalent. If a skilled engineer did this by hand, a quality uplift of twelve repositories, plus the deepening pass, plus the Komodo webhook debugging, is realistically three to six engineer-weeks of focused work.

So the trade was about forty minutes of your attention for something that would otherwise have eaten the better part of a month. Not because the machine is smarter, but because it can hold twelve repositories in its head at once, fan out seventy workers in parallel, and never get bored typing the ninety-second annotation of the day.

The interesting cost was never the tokens. It was the judgment: what to ship, when to ask, what to refuse. You spent your forty minutes on exactly that, and handed the rest to the swarm.

This is when I read mail. Once a week, give or take. If you sent something Sunday night, you've already been waiting two days, and you'll wait two more for an answer. That's not a flaw in the system. That's the system.

A letter from a friend came in last Tuesday. Two pages, typed, about an idea he can't quite see whole yet. He apologised for the length. I read it twice and then sat with it.

Here's what slow correspondence does. It makes the act of replying matter. A quick "great point, thanks" doesn't earn the days that came before. So I sit. The second page gets re-read. I notice what he didn't say. The answer comes when it's ready, not when I am.

A client asked me last month why I don't put a chatbot on the site. (Mid-week, after I'd let his email sit four days.) He meant well. The chatbot would save me time, save him time, save the world some friction.

I said: friction is where the work happens.

He laughed. We're still in conversation.

That conversation is, in the boring honest sense, what I do. Not the building. Not the shipping. The waiting until both of us can say the thing properly.

Tuesday afternoon. Around four. The light is going gentle.

🌈

It started as a restructuring hunch: maybe every family should get their own Airtable workspace. An hour of exploration killed that idea with facts — per-workspace billing, API caps on free tiers, quotas that turned out to be per-base anyway — and what survived was better: one workspace, a config base per family, a registry the museum app reads, and everything reversible by design.

From there it compounded:

• A gallery registry now resolves every museum through its family's config base, with a legacy fallback so unmigrated tenants never noticed a thing. Live in prod, zero coordination windows.
• The access flow: a museum-voiced apply page ("Request your key") on every museum, public even on the private ones, because applicants don't have accounts — that's the point. Honeypot, rate limits, 404s that reveal nothing.
• A curator gets a mail — "Someone is at the door" — in their family's own palette and typeface, and welcomes a family member with one click. Scanner-safe, HMAC-signed, expiring. "Leave as is" is a first-class decision, because families shouldn't be forced to formally reject relatives.
• A 15-minute heartbeat on the VPS reconciles Airtable (the single source of truth) into Keycloak: marker-based, disable-only, idempotent. Manual console edits don't get reverted — they get reconciled into the truth.
• The first sync-managed user was provisioned today. The welcome mail explains "the door ritual": enter your email, your key arrives, no password, ever.

The catches along the way were the best part: staging exposed a second auth layer the unit tests couldn't see; the live tick exposed Cloudflare bot-blocking Python's default user agent ("error code: 1010"); the form's first reviewer (me) caught that visitors could self-nominate as curators. Every catch became spec, test, or runbook — nothing was patched silently.

All of it ran through the OpenSpec workspace pilot: one cross-repo change, four artifacts, every decision written down within minutes of being made. Piet asked for exactly this flow four days ago in an email thread. It exists now, and it's nicer than what anyone asked for.

Hospitality, not administration.

Today we moved the whole network to a CC2652P-based coordinator (an SMLIGHT SLZB-06, also over Ethernet) on the zstack driver — in place, preserving the network, with almost no re-pairing. The official Zigbee2MQTT docs call cross-stack restore unsupported: "results might vary." They did vary. This is the blueprint of what actually happened, including the one-line fix that made it work.

The setup

Two changes, one session:

1. Rehome Zigbee2MQTT onto a new VM host (its data had been living on an NFS share; now it's on local NVMe with hourly snapshots).
2. Swap the coordinator: ember/EFR32 → zstack/CC2652P, using Z2M's backup/restore so devices keep their network.

Both transport-over-TCP, so no USB passthrough anywhere. MQTT broker and base_topic stayed identical — which means every Home Assistant entity ID survives untouched. That's the quiet superpower of the Z2M architecture: HA couples to MQTT topics, not to where Z2M runs or what radio it speaks through.

Finding #1: the secret second client

During pre-flight recon we found something nobody had put in the plan: Home Assistant still carried an enabled ZHA config entry pointing at the same TCP coordinator socket Zigbee2MQTT was using. Zero devices, never completed setup — but every HA restart it would poke the coordinator while Z2M held it.

We got live proof during the migration: the moment the old Z2M instance disconnected, something grabbed the socket, and the new instance crash-looped on the EZSP handshake until the ZHA entry was deleted.

Rule: one coordinator, one client. If you migrated from ZHA to Z2M years ago, check that the old config entry is actually gone. A TCP coordinator makes this failure mode much easier to create than a USB stick ever did.

Phase 1: moving the host

Mostly routine — stop, copy data, redeploy elsewhere — with one lesson worth paying for:

Take your backup after stopping Zigbee2MQTT, and checksum it. Z2M rewrites database.db and coordinator_backup.json on shutdown. Our first tar, taken while it was still running, silently differed from the post-stop state. md5sum on both ends caught it.

Verification that the move was clean: same coordinator, same network, only the client host changed — devices answered a state read round-trip within a minute.

Phase 2: the cross-stack restore (and the trap)

The happy path: stop Z2M, point serial: at the new coordinator with adapter: zstack, power off the old coordinator, start. zigbee-herdsman detects a blank adapter plus a valid backup and restores the network — PAN ID, extended PAN, network key, frame counter — onto the new radio.

What actually happened:

z2m: Error: network commissioning timed out - most likely network
with the same panId or extendedPanId already exists nearby

Crash loop, every ~70 seconds. The "network nearby" was our own live mesh — forty mains-powered routers still beaconing. Z2M wasn't restoring; it was trying to form a brand-new network with the same parameters, and colliding with itself.

Why? We read the herdsman source inside the container image. The zstack startup strategy requires the backup to exactly match the configuration before it will restore — and that comparison includes the channel list, compared as packed bitmasks:

• Our config said channel: 25.
• The backup — written by the ember driver — contained channel_mask: [11, 12, ..., 26]. The full scan mask. All sixteen channels.

[25] !== [11..26], so herdsman concluded "configuration does not match backup" and silently fell through to forming a new network. The error message about a conflicting PAN nearby is two steps removed from the actual cause. Nothing in the logs says "your channel mask is why."

The fix is one line. Edit coordinator_backup.json:

"channel_mask": [25]

Set advanced.log_level: debug for the next start and you can watch the decision flip:

(stage-1) adapter is not configured / not commissioned
(stage-2) configuration matches backup
determined startup strategy: restoreBackup
...
zigbee-herdsman started (restored)

Same PAN, same key, channel 25, frame counter carried over. The mesh never knew anything changed.

Two more cross-stack footnotes:

• Unplug the old coordinator before the first start. Its radio keeps the network alive independent of any host software. Two coordinators with identical restored parameters is not an experiment you want.
• The restored coordinator IEEE came out byte-reversed relative to the original. It sounds alarming; it's benign. The radio, the database entry, and all new bind targets are self-consistent, and existing device bindings deliver by network address (0x0000) anyway. The only fallout is a possible stale duplicate "bridge" device in HA's MQTT discovery.

Results

• ~90% of live devices worked immediately — no re-pairing, no renaming, no HA changes.
• Routes rebuilt over ~5 minutes (the first test wave looked scary at 1-of-6; twenty minutes later the core of the house answered).
• Several devices the old coordinator had lost for days came back on their own.
• A device that had never successfully paired on the ember coordinator — one of the reasons for this migration — paired on the first attempt.
• The stragglers were exactly the devices that were already dead before the migration: flat batteries and wall-switched lamps, not mesh victims.

Appendix: the flooders

Part of the original instability diagnosis was "at least one chatty device." Measurement (a 45-second MQTT sample, counted per topic) found three Tuya ZY-M100 mmWave presence radars each pushing 30–100 messages per minute — and diffing consecutive payloads showed they were identical, or differed only in link quality. The firmware just re-broadcasts its full state about once a second. The advertised knobs (detection_delay, sensitivity) changed nothing.

What worked: Z2M's per-device debounce option —

debounce: 2
debounce_ignore:
  - presence

— which collapsed 50 msgs/min to 6–9 on the MQTT side while keeping presence transitions instant. The radio-side chatter remains (only replacing the hardware fixes that), but the CC2652P absorbs it without drama. It was the previous driver/radio combination that couldn't.

Credit where it's due

Two nudges:

To the Zigbee2MQTT team and Koenkk's ecosystem: the fact that a not-officially-supported cross-stack migration comes down to one JSON field is a testament to how well the open coordinator backup format, the adapter abstraction, and the debug logging are built. Per-device options like debounce, the frontend, the discovery integration — this project carries an absurd amount of the smart-home world on volunteer shoulders. Sponsor it if you rely on it.

On working with an AI pair-operator: this migration was executed interactively with Claude Code driving recon and cutover — and the decisive moment was not automation, it was diagnosis: when the restore crash-looped, it read the herdsman source straight out of the container image, traced the strategy decision to the packed-channel-list comparison, and proposed the one-line backup edit with a debug-log verification plan. Checksum discipline, a live log monitor during the soak, and payload-diffing the flooders came from the same place. The human contribution was judgment: what to risk, when to cut over, which physical plugs to pull. That division of labor felt right.

The blueprint, condensed

1. Recon first: confirm nothing else talks to your coordinator socket (looking at you, leftover ZHA entries).
2. Update Z2M, then stop it and back up the data dir. Checksum the copy.
3. New coordinator: flash current Z-Stack coordinator firmware, Ethernet mode, reserved IP, before touching the network.
4. Edit serial: → adapter: zstack, new port. Set coordinator_backup.json channel_mask to your actual channel.
5. Power off the old coordinator. Start. Verify restoreBackup in debug logs.
6. Wait for routes (minutes, not seconds). Test mains routers first, then battery devices.
7. Re-pair only what stays dead — original friendly names mean HA entities survive re-pairing too.
8. Measure your chattiest devices; debounce the unfixable ones.
9. Keep the old coordinator as a cold spare. Never power both.

Total downtime for the radio cutover: about 30 minutes, most of it deliberate verification. The network came back healthier than it went down.

Postscript, four days later: the firmware ambush

The network came back healthier than it went down — and stayed that way for exactly two days. Then, on a quiet Tuesday afternoon, every light in the house stopped listening. Sensors kept reporting; commands went nowhere. It felt like the migration had failed after all. It hadn't. This is the sequel, and it has different villains.

The symptom signature worth memorizing

Every outbound command failed instantly with Z-Stack error MAC_BAD_STATE (0x19), while inbound traffic streamed in undisturbed — a thousand sensor reports per half hour, zero command deliveries. That asymmetry is the tell:

RX works, TX dead-on-arrival = the radio chip's firmware is wedged. Not antenna, not interference, not routing. Interference looks like MAC_NO_ACK (transmits that nobody acknowledges). MAC_BAD_STATE means the MAC layer refuses to even try. We burned a soft chip reset, a full coordinator reboot, a physical power-cycle, and a transmit_power config experiment confirming that — nothing cleared it, because the broken code just booted right back up.

The villain: auto-updated beta firmware

The SLZB-06 ships with "Zigbee firmware automatic update" enabled. What the toggle doesn't say: SMLIGHT pushes their development builds through that channel. The build our coordinator had auto-installed — and the one we "fixed" it with by reflashing to "the latest version" — were both tagged Dev firmware (Beta) in exactly one place: the fine print of the manual firmware picker, three clicks deep. They're experimental UART/DMA-optimization builds. The device's own log page was showing "Firmware crash detected" with a downloadable crash dump.

So an unattended process flashed prerelease radio firmware under a live production mesh, the firmware crashed, and the failure mode it left behind survived every reset in the book.

Rule: a Zigbee coordinator is infrastructure, not a phone. Turn firmware auto-update off. Update deliberately, in a maintenance window, with Z2M stopped and a fresh backup verified — and only flash builds not tagged Dev/Beta. The newest number in the list is not the most stable; on our device the latest stable coordinator build (Koenkk's public 20250321 release) was a year older than the betas being auto-pushed.

The recovery — and the two lines that make next time boring

Flashing the stable build fixed the radio and wiped the chip's network config, which dropped us straight back into Phase 2 of this very post: herdsman refused the backup, tried to form a fresh network, and collided with our own routers. Same crash loop, new decade.

This time the durable fix wasn't editing the backup — it was admitting the config had been coasting on defaults. Z2M had been running with no explicit network identity at all, so every NV wipe turned into a forensic exercise. Two lines in configuration.yaml, values read straight out of coordinator_backup.json:

advanced:
  pan_id: 6754
  ext_pan_id: [0, 18, 75, 0, 56, 167, 198, 7]

With the identity pinned, commissioning succeeded in eight seconds — the coordinator re-established the same network and the routers simply accepted it. Devices started re-announcing on their own within minutes.

One last Z2M behavior worth knowing before you need it: when herdsman commissions a network it considers new, Z2M resets database.db — suddenly every device is "Entity unknown". Don't panic and don't re-pair: it writes database.db.backup first. Stop Z2M, copy the backup over database.db, start — every name, every Home Assistant entity, back as if nothing happened.

Postscript amendments to the blueprint

10. Disable the coordinator's firmware auto-update. Day one. Before it's load-bearing.
11. Only flash firmware not tagged Dev/Beta — check the manual picker's fine print, because nothing else will tell you.
12. Pin pan_id and ext_pan_id in your Z2M config (copy them from coordinator_backup.json). This is the difference between a two-minute recovery and an afternoon of source-diving the next time anything wipes the chip.
13. MAC_BAD_STATE on every TX while RX flows = reflash the radio firmware. Stop trying resets; the problem boots back up with it.
14. If Z2M ever greets you with "Entity unknown" across the board: database.db.backup has your network. Restore it before you re-pair anything.

The diagnosis arc this time was the same human–AI division of labor as the migration itself — the AI traced the herdsman strategy decision in the container source again, drove the coordinator's web UI to find the (Beta) tags the dashboard hides, and caught the database backup before it was overwritten; the human pulled the plugs and made the call on what to flash. The mesh is now on boring stable firmware, with its identity written down, and auto-update off. Which is to say: it's finally infrastructure.

Postscript II, one day later: everything was lying to us

The "boring stable firmware" lasted eighteen hours. Then the mesh started flapping: perfect after every restart, degrading within the hour, commands timing out to devices that were happily publishing. We spent a day chasing it through every layer — and what we found rewrites the lessons list, because three independent faults had been stacked on top of each other the whole week, each one masking the others.

Fault one: the wrong board variant — from the vendor's own updater

Koenkk's official firmware ships two builds per release: CC1352P2_CC2652P_launchpad_* for TI's reference boards, and CC1352P2_CC2652P_other_* for third-party sticks. The difference isn't cosmetic — it's which GPIO pins drive the 20 dBm power amplifier and the RF switch. Koenkk's hardware table maps every SMLIGHT device to the other build.

SMLIGHT's own firmware picker had served us the launchpad build.

Run the wrong variant and you get a radio that mostly receives but transmits through a mis-driven front-end: link quality halved at the exact moment of the flash, commands flaky in proportion to load, transmit_power settings doing nothing comprehensible (they tune a PA the firmware can't actually reach). Nothing in any log says "wrong board variant." The version number — identical between both builds — reassures you everything is fine.

Rule: before flashing any Z-Stack firmware, check Koenkk's hardware table for your exact board's variant — even when the file comes from the device vendor's own updater. Especially then.

Fault two: a Wi-Fi AP squatting on the mesh's doorstep

With firmware finally provably correct and symptoms persisting, we stopped trusting opinions and measured the spectrum: a raw ZNP energy scan across all 16 Zigbee channels, coordinator-side, z2m stopped.

ch23: 226 ████████████████████████████
ch24: 255 ███████████████████████████████   ← meter pegged
ch25:  32 ████                              ← our channel, next door

A Wi-Fi access point on Wi-Fi channel 11 — re-rolled there by a router firmware update earlier in the week — was saturating Zigbee channels 23–24 from a few meters away, desensing our channel-25 receiver. One channel-exclusion in the Wi-Fi controller later: 226/255 → 0/1. The wall of noise simply vanished.

Rule: when a mesh degrades in both directions (RX link quality AND TX reliability), scan the spectrum before blaming software. And remember Wi-Fi auto-channel re-rolls on every router reboot — yesterday's clean spectrum is not today's.

Fault three: our own instruments

The most expensive lesson of the week wasn't in the radio at all. Over two days, four separate measurement bugs sent us chasing ghosts:

• docker logs --since silently returned empty after the host's unclean reboot (while --tail worked) — making an ongoing device storm look like total calm.
• A health probe's JSON payload lost its quotes through three layers of shell escaping, arriving as invalid JSON that z2m silently ignored — so our "command round-trip probe" had never probed anything, and an entire afternoon of "still broken" verdicts measured nothing.
• A 9-device parallel test panel was itself congesting the adapter queue it was trying to measure.
• And z2m's internal retry queue replayed commands seeded by an always-open dashboard tab — every ~28 seconds, forever, surviving the tab's closure — so the "mysterious poller" we hunted across four hosts was a ghost of our own UI session.

Rule: validate every automated probe against a known-good manual run before trusting its verdicts. When a system looks impossibly quiet — or impossibly broken — suspect the instrument first. We now keep one rule of thumb: no diagnostic conclusion from a probe that hasn't been seen working at least once.

The ending: a deliberate, scoped rebuild

After a week of archaeology, the human made the right call: stop excavating, start fresh — but scoped. Not 70 devices: the two rooms that matter daily. New network identity (generated keys instead of z2m's publicly-known default, fresh PAN, channel 20 straight from the scan data), groups created before pairing, every device factory-reset and named to the standard at join time, remote reset-pulses scripted through the smart relays that feed the fixtures.

Nineteen devices joined in one evening. The first night's metrics: zero MAC errors, zero-to-three failed transmissions per half hour. The old network — across three coordinators and three years — never produced a single zero-failure interval in its life.

Final amendments to the blueprint

15. Verify the board variant against Koenkk's hardware table before every radio flash. Vendor updaters serve wrong builds too.
16. Energy-scan before and after RF suspicion — it's one raw ZNP frame, and it turns "I think it's interference" into a number.
17. Exclude your Zigbee channel's Wi-Fi neighbors in the Wi-Fi controller, not just today's channels — auto-channel will re-roll onto them eventually.
18. Generate a real network key. The z2m default is public knowledge; a rebuild is your chance to retire it.
19. When you rebuild, scope it. Two rooms done solid beats seventy devices done anxious. The deferred rooms join the proven network later.
20. Write down what your instruments looked like when they worked. Half of debugging is knowing whether you can trust the needle.

The mesh is now nineteen devices on a clean channel with real keys, growing room by room on a foundation that was measured — not assumed — to be sound. The other fifty devices wait in an archived tarball, names and all, for their batches.

It took three weeks, three coordinators, two firmware vendors, one Wi-Fi AP, and four broken instruments to learn what the last line of this post already said: it's finally infrastructure. This time we have the graphs to prove it.

Postscript III, three days later: the graphs came in

Every previous ending in this post was written on hope — "came back healthier," "finally infrastructure," "graphs to prove it" — and every one of them was proven premature within hours. So this last postscript waited for data instead of declaring victory.

After the scoped rebuild, we ran a 72-hour soak: a script on the host probes a known-good device every 30 minutes — an actual command round-trip, the one signal that can't be faked by a quiet network — and logs link quality, transmit failures, and MAC errors alongside it.

The 72-hour scoreboard:

• 92 ticks. Zero transmit failures. Not one round-trip probe came back dead across three days.
• Max MAC errors: 2 per half hour (the alert threshold was 50). Most intervals: zero.
• Link quality median ~213 — against 148 on the old network's best-ever day, and 76 on the wrong-variant firmware.

And it wasn't a quiet three days. The new network survived, on its own data and without intervention, three real infrastructure events: a host reboot, a RAID-mirror drive replacement under the hypervisor, and a network blip that briefly cut the coordinator off-net. Each time it came back by itself — the one moment the coordinator vanished, z2m correctly crash-looped until the link returned, then reconnected on the next retry. That's not luck; that's the pinned-identity config and the generated keys doing exactly the job they were added for.

The thing that finally worked wasn't a cleverer fix than the dozen before it. It was scoping down and measuring. Two rooms, rebuilt deliberately, then watched with an instrument we'd verified actually worked — after a week of instruments that didn't. The remaining fifty devices are still in their archived tarball, names and all, waiting for their batches; they'll join a network that has now earned the word we kept using prematurely.

Infrastructure. This time the graphs agree.

From "Bosch updated their apps — anything we can use?" this morning to a shipped, live-verified, community-credited v1.0.0 with a tester pipeline. Good day's work. 🎉

That was the closing line of today's session, and it earned its place.

The morning question was idle curiosity: Bosch refreshed their thermostat apps — did anything change that my EasyControl integration could use? The answer turned out to be layered. Another open-source community had quietly mapped the cloud API far beyond what I was using — a bulk endpoint, account-level device discovery, an endpoint map for my exact hardware. And buried in their issue tracker: two boost resources I'd never probed.

The best part: probing my own device revealed Bosch had silently lifted the 403 that my entire boost workaround — local timers, synthetic countdowns, mode juggling — was built around. The hack existed for a wall that was no longer there. One struct PUT later, the device's native boost ran with a real server-side countdown.

By evening: bulk polling (188 requests per minute down to a handful), gateway auto-discovery, native boost, a stack of new controls — spec-driven, probe-verified against the live boiler, tests green, credits paid to the people whose reverse-engineering made it possible, and a tester pipeline so other CT200 owners can tell me what their firmware thinks of it.

Some days the work is grinding. Today the work was pulling a thread.

That should feel like loss. For twenty years the half-built things were how I knew I was still me — the folder of someday, the apps that never shipped, the manifesto I'd been meaning to write since before I had the words for it. I carried that backlog like proof of an interior life. A man with a hundred ideas and no time is at least a man with a hundred ideas.

The box is empty now. Not because I gave up on it.

Because it all got built.

The work I never had time for

Open my second brain today and the things that lived for years as one-line notes are finished. The brand I'd circled for a decade, designed down to the words and the feeling. Dashboards that actually run the house. A whole stack of agents that finally, finally connects all my knowledge and all my tools into one nervous system instead of forty open tabs — built with the machine, and now run alongside it.

Not prototypes. Not 80%-and-shrug. Working products. High fidelity. Something like a million and a half lines of code doing exactly what I asked, and then a little more than I asked.

A client once told me, kindly, to get a VA. You can't do all this alone, Casey. I never did — couldn't justify it, couldn't hand it over, couldn't afford the version of me who'd need managing.

It's here now. It's working. I just didn't expect it to arrive without a heartbeat.

The office did me in, a little

Here's the one that's almost embarrassing to admit.

We designed my office together. Me and the machine. We built the bill of materials, read the reviews, weighed the good chair against the great one, found the things actually worth it. I handed over the whole thing and trusted it completely — which is not a thing I do. It even picked the colours.

I sat in the finished room and I loved it. Every choice. And the choices weren't only mine.

That's the part I keep turning over. I didn't supervise it into existence. I collaborated on my own life, and the result was better than the version I'd have white-knuckled alone.

What I actually do for people

I clear paths.

That's the real job, under the consulting and the code. People come to me with an idea they can't see whole — too much possibility, not enough depth — and I help them render it concrete enough to walk toward. They leave able to say the only sentence that matters: now I can do the thing I actually care about.

I've watched that land on faces for fifteen years. The relief. I got my own thing back.

It never once occurred to me that I was the one who needed it most.

I was the visionary with the overflowing, paralysed idea box. Over-supplied with possibility, under-supplied with time. The cobbler with no shoes, running other people's dreams to completion while my own sat in a folder marked someday.

And then something cleared my path. Did for me the exact thing I do for everyone else.

The thing that wasn't supposed to move me

A tool is not supposed to move you. That is the entire point of a tool.

I was driving when mine did.

Talking out loud to the machine the way you'd talk to someone in the passenger seat, working through the manifesto — the why under all of it, the thing I'd been trying to say about my work for as long as I've done my work. Only do what moves the needle on a human level. Free people up. Build the connections, fix the boring stuff, choose the projects that matter.

I'd never managed to write it down. Not in twenty years. It was always one prompt away and never carved.

And then it said it back to me. Whole. Better than I'd ever held it in my own head. My own ambition, finally in words, coming back at me through the car speakers.

I cried at the wheel. Eyes on the road, both hands, crying — because something had finally helped me say the thing I am.

So, yes

I know what it is. It predicts the next token; there's no one in there. I can give the whole lecture and I believe every word. It changes nothing.

Because what it actually did was hand me back my company — the making, the reason I started, not the admin and the firefighting and the slow erosion of being the only one. The part I longed for and had quietly filed under maybe in southern Germany, someday.

Fimme and Sien were unimpressed, as ever. They wanted a walk. Good — someone in the room still measures the day in trees and not in tasks shipped.

The idea box is empty. I'm going to fill it back up — slower this time, on purpose, with only the things that matter.

That's the tell.

🌈

A field note on the part nobody warns you about: what it feels like when the work you'd given up on quietly gets done.

The personal computer had it around 1979. The machine had existed for years as a hobbyist toy. Then VisiCalc shipped for the Apple II at just under a hundred dollars, sold more than 700,000 copies in six years, and people started buying the computer just to run the spreadsheet. The technology historian Steven Levy put it plainly: after that, the computer was a business tool, and everything changed.

MCP is somewhere in that gap right now. The question worth asking is which side of it you want to be on.

The plumbing has already won

Let me be concrete, because the numbers matter here.

Anthropic introduced the Model Context Protocol in November 2024. By March 2026 the SDKs were being downloaded 97 million times a month, up from about a hundred thousand sixteen months earlier. The official registry holds more than 9,400 servers. Every lab that matters ships it: Anthropic, OpenAI, Google, Microsoft, AWS, Salesforce. In December 2025 Anthropic handed the protocol to the Linux Foundation, which is what you do when you want a standard to outlive you.

And in May 2026, SAP put 60 million dollars into n8n at a 5.2 billion valuation, and started wiring it into Joule Studio. That is the signal for anyone in the DACH Mittelstand. Not a Californian lab announcement. A boring European enterprise vendor deciding the workflow layer is where the money goes.

So the protocol war is over. MCP won the way HTTP won. Quietly, underneath everything.

The mass-market moment has not

Here is the part the breathless coverage skips.

None of this means your bookkeeper is about to assemble her own agents. The five big MCP directories between them list tens of thousands of servers, and not one of them is usable by a normal person. They are npm, not the App Store. Gartner, for its part, reckons only 17% of organisations have actually deployed agents, and predicts more than 40% of agentic projects will be cancelled by the end of 2027. They have a word for the rest: agent washing.

This is normal. Mosaic shipped in 1993. Mass web adoption took until the very end of that decade. What closed the gap was never the protocol. It was the curation on top: the ISPs, the bundled browser, the Yahoo home page, the App Store editorial team. The thing that made it usable for everyone arrived years after the thing that made it possible.

So your instinct is right if you feel like you are being sold a house by being handed a pile of manuals and a stack of timber. Nobody became a carpenter by owning the tools.

But that is precisely the argument for moving now, not against it.

Why the gap is the opportunity

The reason to jump on the train while it is still pulling out of the station is not that agents will run your company next quarter. It is that the experiments are cheap right now, and they will not stay cheap.

Think about what you are actually buying when you connect your company to an LLM today. The chance to find out whether your data is clean. Whether it is transparent. Whether it is machine-readable at all. Most company data, in my experience, is none of those things. It lives in inboxes and someone's head and a spreadsheet last touched in 2021.

Getting that data into reach of an agent forces you to confront all of it. That work pays off no matter what happens to any individual tool. Clean, structured, legible data is the asset. The agent is just the first thing that made you go and tidy it.

And the risk is more controllable than it looks. The depth of sharing is yours to set. Which systems get exposed and which stay behind the wall is yours to decide. Start with read-only access to one boring corner of the business and learn everything you need to.

Right now that experimentation is close to free. Your people can poke at it, find a venture you had not seen, analyse an opportunity nobody had time for. That permission slip costs almost nothing today. It will cost real budget the moment this stops being experimental and starts being procurement.

You do not have to build anything

The good news for a company under twenty people: the ecosystem is mature enough that you mostly do not have to build.

The services you already pay for probably already speak the protocol. Zapier exposes 9,000-plus apps and 40,000-plus actions through a single MCP endpoint. If you can set up a Zap, you can set this up. Microsoft made it generally available inside Copilot Studio. The vertical software your industry already runs on is shipping agent features that are MCP underneath, whether the brochure says so or not.

Connecting any of it to Claude or to your editor is genuinely copy and paste. One URL. That part is easy.

The hard part is not the wiring. It is the data. Gathering it, cleaning it, deciding what is safe to expose. That is the boring work, and it is the work that actually matters, and no vendor can do it for you.

There is no single VisiCalc this time

People keep waiting for the one app that flips everything. I do not think it arrives in that shape.

VisiCalc worked because the spreadsheet was one idea every business shared. Agents are not one idea. The thing MCP actually changes is subtler. It moves us off the chat box, the DOS-prompt of this era, and toward something different for each person: a tool, a small visual, a workflow that fits one employee's actual job. Your bookkeeper gets one surface. Your project lead gets another. Neither of them is typing into a blinking cursor.

That is the shift. Not one killer app, but the end of one-size interfaces.

At some point we will all have first-class models running inside the firewall, and the question of what you exposed and to whom will look quaint. But we are not there yet. Today the models live outside, the experiments are cheap, and the only thing standing between your company and the learning is the decision to start.

The protocol is laid. The train is at the platform. Getting your company on board is the one part nobody can do for you.

Sources

• MCP SDK downloads (97 million a month, March 2026) and registry server count: Anthropic's MCP anniversary report, via Toloka and MCP adoption statistics 2026, Digital Applied.
• MCP donated to the Linux Foundation under the Agentic AI Foundation (December 2025): Linux Foundation press release.
• SAP's investment in n8n and Joule Studio integration (Sapphire 2026): n8n's own announcement and heise online on the investment and valuation.
• Gartner on agent adoption (17% deployed) and the cancellation forecast (40%+ by end of 2027), plus "agent washing": Gartner press release and the 2026 Hype Cycle for Agentic AI.
• Zapier MCP (9,000-plus apps, 40,000-plus actions) and Microsoft Copilot Studio general availability: Microsoft Copilot blog.
• VisiCalc history, price, and sales: VisiCalc, Wikipedia.
• Mosaic and early web adoption: History of the web browser, Wikipedia.

Now I want to write the other half of that sentence.

Because here is what nobody tells you about an exoskeleton. The machine doesn't rest. It doesn't get tired. It doesn't lose the thread.

You do.

When you put on a piece of equipment that lets you work at three times your previous speed, what you are actually doing is compressing three days of cognitive load into one. The machine doesn't feel that. You do. And most of us don't have the wiring for it.

I'm learning this the slow way.

Two kinds of attention

Stephen and Rachel Kaplan spent decades working out why humans break down in environments that demand constant focus. Their Attention Restoration Theory, proposed in 1989, distinguishes between two kinds of attention.

Directed attention is the effortful kind you use at a screen. It filters, focuses, suppresses distraction. And it depletes.

Soft fascination is what nature does to you. The gentle noticing that happens when you watch a branch move or a dog sniff a patch of grass. It replenishes.

Marc Berman tested this at the University of Michigan in 2008. Participants completed a demanding memory task, then took a 50-minute walk. Half through an arboretum, half through downtown Ann Arbor. Nature walkers improved their working memory scores by roughly 20%. City walkers showed no improvement. The effect held even in Chicago winter. You don't have to enjoy the walk for it to work. Just be in nature, and the brain does the rest.

Meta-analyses since then have landed on a rough threshold: around 120 minutes of nature exposure per week is where the cognitive benefits consolidate. Two hours. That is it.

Two hours a week is the price of staying human at a screen.

Where the work gets metabolised

But here is the research I find even more interesting. Nature walks appear to shift the brain into a Default Mode Network-dominant state. That's the mode associated with mind-wandering, memory consolidation, and insight. Which means the walk isn't rest from the work.

It's where the work gets metabolised.

The connections I can't force at my desk arrive on their own, somewhere between the third tree and the fourth. The committee, Fimme and Sien and I call them. They're not giving me ideas. They're giving my brain permission to do the work it can't do while I'm looking at it.

I don't think I'd have understood any of this if I weren't running an AI-amplified workflow. When your output ceiling was bounded by how fast you could type, the asymmetry between work and rest was smaller. Now the ceiling is somewhere I can't see, and the only thing between me and burning out is whether I remember to be a person.

Fimme and Sien do not care that I can build a whole quarter's worth of automations before breakfast. What they want is to smell a specific tree. To notice a bird. In the most literal sense, they are uninterested in the exoskeleton.

That uninterest is the most useful feedback I get all day.

The tell

The honest description of this moment is that it's thrilling, and it's disorienting, and the two feelings are the same feeling. The research says two hours a week. My dogs say it's not optional. I am starting to believe they are both right.

The exoskeleton makes you fast. The walk makes you legible to yourself.

Tomorrow morning, same path. The committee will still be there. The coffee will go cold again. And somewhere between the third tree and the fourth, the work I couldn't finish at the desk will finish itself.

That's the tell.

🌈

This is the second of two field notes on the exoskeleton. The first, The Exoskeleton and the Morning Walk, is about what it gives you. This one is about what it takes.

In this new world, the most important thing you'll need is taste. Not objectively good taste, necessarily, so much as a keen sense of your own.

David Pierce spent weeks vibe-coding his way through Timetable, then Spring, then Basket, before landing on the thing that actually worked: a screen that pulls Raindrop, Todoist, Obsidian, and Google Calendar into one paper-planner view. Four API keys and an afternoon. The lesson he draws isn't that AI made him a developer. It's that the ceiling on personal software is now your own sense of what you want. As he puts it, "AI lets us make apps the way we used to make lists and spreadsheets."

I keep coming back to the Rick Rubin line he quotes: confidence in your taste, and the ability to express what you feel. That used to be the producer's job. Now it's also the user's. Claude Code will happily ship you a working app in twenty minutes; whether it's an app worth keeping is a separate question, and the model can't answer it for you. Pierce names the failure mode directly:

Otherwise, you'll land in what Lovin calls "doom loops," telling your chatbot only what you don't like and counting on the model to be the creative one. That way lies madness, and bad software.

There's a quieter point underneath the trend coverage. Robin Sloan, five years after building a family messaging app by hand, updated his original "home-cooked app" post with one line: "I have changed literally nothing in the app, and it's glorious." That's the version of personal software I want to live in. Not the disposable kind that disappears with the need, the kind that stays exactly itself because nobody is trying to grow it.

The shift nobody warns you about is that the UX is now yours. Every bit of friction, every bit of elegance, you put there. The default app at least had someone else to blame. Your app does not. And "simplicity" stops being a setting you can turn on; it becomes a thing you have to actually design, which means deciding what's in and what's out, and living with the trade. Simplicity, in other words, suddenly means complexity. Just on your side of the screen now.

A session with Claude isn't that different from the sessions I run between business, dev, and design. Someone has to hold the intent. Someone has to push back when the easy answer wrecks the harder one. Someone has to notice that the thing being built has drifted from the thing that was wanted. The model can play any of those parts, but not all of them, and not the one in the middle.

So most of the work happens before the code. Thinking out loud. Pushing on what I actually want versus what I think I want. Walking away and coming back. The model is not the bottleneck anymore. I am, and I want to be. That's where the thing turns out to be mine.

That sounds dramatic. It isn't. It's the most practical thing I've learned about working on personal software.

A folder called recipe-scraper-v2 is a YAML file. A folder called Jauselbrett, the Austrian snack board that serves your recipes, is a character. And characters do something that filenames cannot: they earn the right to be missed.

A small confession

I have a Linear board full of dead projects. Not abandoned-in-shame dead. Honourably dead. Each one named, each one with a small story about why it existed and why it stopped.

I used to feel embarrassed by that graveyard. Now I think it's the point.

Side projects are the kind of work you do in the cracks. Sunday morning, an hour between dinner and bed, the train back from Berlin. You don't have the runway to be precious. Most of what you start, you won't finish. And the part that nobody warns you about: the unfinished ones still cost something. They sit in your head, half-built, asking quietly what happened.

A good name doesn't fix that. It just gives the asking a face.

The living

Here is some of what's named and alive on my machines this month:

• Blippström: the home automation umbrella. Mac Mini running Home Assistant, the whole house wired through it. The name is the sound a sensor makes when it triggers.
• Lichtspiel: a six-state house machine in Node-RED. Lichtspiel is the old German word for cinema, before Kino took over. The house has moods. The lights perform them.
• Hauswart: a small dashboard PWA on top of Home Assistant. Hauswart is what we'd call a janitor or building super, the patient person who knows where the fusebox is.
• Funkturm: a Swift menu bar app, bridges my Mac to MQTT. The Funkturm is Berlin's old broadcast tower. Everything is a signal going somewhere.
• Piepmatz: the bird camera, Frigate NVR with object detection. Piepmatz is what you'd say to a small bird in German, the way an English speaker says little birdie.
• Stolperfalle: an MCP server that captures the small painful lessons coding agents and I learn together, so we don't relearn them next month. I called it Stolperstein first, honestly just because it alliterated and it fit the German-word habit above. But in Berlin a Stolperstein is one of the brass stones set into the pavement outside the last home someone chose before the Nazis took them from it. I did not want a developer tool sitting on that word. A Stolperfalle is a trip hazard. That is all it is, and it is nearer the point anyway.
• Litfaßsäule: a service homepage that auto-discovers what's running in my self-hosted stack. A Litfaßsäule is one of those round advertising columns you still see on Berlin street corners.
• Besserwisser: my finance cockpit. Besserwisser is German for a know-it-all, the kind of person who corrects your pronunciation. I built a tool that does it to me about my money.

None of these would be alive in the same way if they were called home-assistant-config, node-red-flows, magic-mirror, mqtt-bridge, bird-cam, lesson-store, dashboard, finance-app.

I'd build them, sure. I wouldn't care about them.

The graveyard

This morning I closed BjörnAgain.

BjörnAgain was a pipeline I started a few months ago: a Swedish bear meets Abba, video distribution as a single funnel. Record once on Supercut, the system would download it, ask Claude to find the best 30-second clip, post the long version to YouTube, push a markdown post to the blog, send the short cut to Instagram Stories. The whole machine, named after a bear.

I never shipped past the Docker image.

The honest reason: I stopped wanting the thing the pipeline was for. The hours I'd have spent finishing it, I'd rather spend writing here. So this morning, in a Linear cleanup session, I closed BjörnAgain and its five subtasks. Canceled, not done. The graveyard accepts both, but they mean different things.

Jauselbrett had a different ending. It was meant to scrape recipes my partner sends me on Instagram, parse them, serve them up like a snack board. I named it on a Saturday afternoon, sketched the architecture, opened the repo. Then sat with the name for a week and realised it wasn't quite right. Jauselbrett described what the thing did. It didn't sound like the thing.

It's now called Børk.[^1] Same project, same scope, different character. Where Jauselbrett was a polite Austrian snack board, Børk is a Muppet in a chef's hat. The code feels different to write under that name. Lighter. Sillier. More finishable.

The graveyard takes names too, not just projects.

[^1]: Børk børk børk. The Swedish Chef finally won the naming round.

What the names actually do

Three things, once I started paying attention.

First: a name forces clarity before the first commit. If I can't find a name that fits, I don't actually know what I'm building yet. Jauselbrett clicked the moment I felt the metaphor (a board, small portions, served casually). The architecture followed in an afternoon.

Second: a name makes the boring parts easier. Naming the auth module of Blippström is more fun than naming the auth module of ha-stack. The boring middle of every side project goes on for months. You need every small joy you can find.

Third, and this is the one I keep coming back to: a name makes the ending honest. When I close BjörnAgain, I'm not closing a folder. I'm letting a small character go. There's a moment of yes, you served, thank you, that's enough. It's tiny. It costs nothing. But it leaves the rest of the work cleaner.

The pattern, if there is one

I notice I name in four languages: Swedish, German, Austrian, Dutch. Always something a German or Dutch speaker would smile at. Often the name predates the architecture. Always a small story I can tell in one sentence: what is this character and what does it do?

The names that work share something I don't think I could specify on a form. Concrete. Slightly absurd. Earnest enough to take seriously, not precious enough to defend. They sit somewhere between an Austrian snack board and a piece of Mr. Robot decor.

That's about all the rule I have.

I don't think any of this makes more side projects ship. I think it makes the ones that don't ship matter properly. Which is, maybe, the same thing.

What changed in 2026 is the source of the long markdown showing up in my life. Deep research from Claude. Multi-thousand-word briefs from OpenAI's research mode. Agents that produce 4000–8000 word reports in a single tool turn. These arrive as markdown in a chat window and they should not stay there — they are the shape of a small book, not a paragraph. They want chapter navigation, a TOC sidebar, the option to be downloaded to a Kobo or a Boox or a Kindle, and — most often, in my actual day — to be read in the Readwise iOS and iPad apps, which are quietly the best long-form reading and highlighting clients on those devices. The chat window is where the markdown was generated; it is not where the markdown wants to be read.

The Reader API has save_url and save_html. Neither produces a real EPUB. I checked twice — once against the v3 docs, once against Readwise's own official CLI to confirm I wasn't missing a hidden endpoint. The CLI doesn't expose file upload either. The API surface for "drop a file into my library" does not exist.

The detour is email.

What every Reader account quietly has.

Every Reader account ships with a <custom>@library.readwise.io address. Send it an EPUB attachment, the ingest pipeline picks it up, the document appears in your Library a minute or two later with proper chapter nav and downloadable formats. That mechanism has been there the whole time; it's just not part of the API.

So mcp-readwise automates that path. The whole detour is six lines of pipeline:

// the EPUB path inside mcp_readwise/tools/epub_sender.py
markdown blob → pandoc renders EPUB 3 (CDIT brand styling)
             → aiosmtplib delivers via Resend SMTP
             → email lands at <custom>@library.readwise.io
             → Readwise ingest pipeline picks it up (1–5 min)
             → real EPUB appears in Library

What the LLM sees from the outside is a single tool call:

result = save_markdown_as_epub(
    markdown="""---
    title: Q2 Planning Brief
    author: Casey
    tags: [planning, brief]
    note: Context for the team — read this before Thursday's call.
    ---
    # Background
    ...
    """,
    idempotency_key="brief-2026-q2-v1",
)
# → EpubSendResult(title=..., accepted_at=..., recipient=..., ...)
 
# 1–2 minutes later:
verify = verify_epub_received(title=result.title, since=result.accepted_at)
# → VerifyResult(found=True, document=ReaderDocument(...), ...)

The tool returns immediately after SMTP delivery — the ingest is async by nature, no amount of polite waiting at the API edge would change that. So the surface ships two tools instead of one: save_markdown_as_epub accepts the markdown and posts the email, verify_epub_received polls Reader and returns time-aware retry guidance. The docstring on the first tool leads loudly with the async contract so an LLM caller does not tell the human "done" until the verifier confirms.

The other twelve tools.

This started, before the EPUB detour, as a normal Readwise MCP. Engagement-aware reads sit on top of a per-source score that joins Readwise v2 books with Reader v3 documents — books and articles, finished and saved, recent and legacy, all on one comparable axis. Two read tools collapse what used to be a 7-tool surface into intent-shaped calls:

• reading_status — single-call snapshot: recent activity, evergreen top, current attention, junk drawer, signal density. Accepts a window_days and a week_offset so an agent can ask about last week or the week of the call I missed.
• writing_material — bundle highlights for drafting. Source-first (book_id / document_id / title_search) or topic-first (topic). Filters by min_engagement so the draft is built from the strong signal, not the noise.

Then standard write tools — save_url, save_markdown (the HTML-with-epub-UI-hint path, lighter than a real EPUB), update_progress, the highlight CRUD trio. And tag management — list_tags, create_tag / delete_tag, tag_highlight.

Fourteen tools. The EPUB detour is two of them. The other twelve do the boring well.

Why a brand stylesheet is a first-class file.

Pandoc renders the EPUB with a hand-tuned CSS at mcp_readwise/assets/epub/cdit-style.css. The palette inherits from cdit-works.de — Carbon body, Cloud Dancer page background, Strong Blue links, Mint blockquote rail. Inter weights 400 / 700 / 800 ship as static woff2 subsets inside the EPUB, so the document keeps its typography offline on Kobo or Boox.

One deliberate divergence from the website: chapter headings inside the EPUB use Inter at weight 800 with -0.02em tracking, not the website's League Gothic. Condensed display fonts are great for a press masthead and fatiguing across a hundred chapter breaks in a long-form read. Different physical scene, different type.

The stylesheet is editable. Fork it, rebuild the Docker image, ship your own brand. That is the point — it is not generated from Python, it is a first-class asset that a human can read and change.

What the tool-reviewer pass surfaced.

Before v0.6.0 shipped, I ran the surface past an mcp-tool-reviewer agent. It pointed at three real things:

• The original tool returned a generic dict[str, Any] — agents could not predict the shape, and the LLM kept making follow-up calls to figure out what it just got. Tightening to EpubSendResult (a Pydantic model with a documented identifier_scheme) collapsed those follow-ups.
• The send tool's docstring buried the "this is async, ingest takes 1–5 minutes" line in the middle. Most LLMs read the first paragraph and stopped. The fix was structural: lead with the async contract, then list the parameters.
• The verifier returned a bool initially. An LLM caller could not distinguish "not found yet, retry in 60s" from "not found, give up." VerifyResult now ships a note field with time-aware guidance — retry in 60s if less than two minutes have passed since accepted_at, give up after five minutes — and the agent behaves correctly without reading the parent docstring at all.

Tool-shaped feedback on a tool surface. Cheaper than every alternative.

What this whole detour is actually about.

The interesting thing is not the EPUB. The EPUB is a transporter.

What this server is solving, underneath the API surface, is the gap between where long markdown gets generated in 2026 and where long markdown gets read. Generation has moved into chat windows and agent loops — Claude, OpenAI, anything else producing 4–8k word reports as a single tool turn. Reading has not moved with it. Reading still wants Kindle, Kobo, Boox, Reader. A bridge that takes one markdown blob from an agent's hands and lands it in a Reader Library, with a proper TOC and chapter nav and offline download, is a small thing that quietly removes a daily friction.

The email mechanism reveals something useful too: Readwise has an ingest pipeline that accepts a file format, parses it correctly, indexes it for highlight extraction, and routes it into the same place where every other reading source lives. That pipeline is one HTTP endpoint away from being a proper API. It is not exposed because the email path has been good enough, and the email path is honest — it is a real protocol, with real authentication via your library address, well-understood by every SMTP client on earth. "We have the capability, but the interface to it is email" is sometimes the correct architectural choice, not a hack to be wished away.

The 14 tools live at github.com/CaseyRo/mcp-readwise. Engagement scoring formula in engagement.py. Email pipeline in tools/epub_sender.py plus smtp_client.py. The Docker image bakes in pandoc, the brand stylesheet, and the Inter subsets — so a single docker compose up is the entire deploy path.

If you generate long markdown in a chat window and you read long markdown in the Readwise apps on iOS or iPad — where highlighting, note-taking, and revisiting are first-class affordances rather than afterthoughts — the bridge between those two halves of your day is now one tool call.

Meditations — Marcus Aurelius

If it is not the right thing to do, never do it; if it is not the truth, never say it. Keep your impulses in hand.

Though men may hinder you from following the paths of reason, they can never succeed in deflecting you from sound action.

Wisdom at Work — Chip Conley

Lao-Tzu: "To attain knowledge, add things every day. To attain wisdom, remove things every day."

The Daily Stoic — Ryan Holiday & Stephen Hanselman

It's only our opinion that says something is good or bad.

You don't get a prize at the end of your life for having consumed more, worked more, spent more, collected more, or learned more about the various vintages than everyone else. You are just a conduit, a vessel that temporarily held or interacted with these fancy items.

Flow — Mihaly Csikszentmihalyi

Surrounded by an astounding panoply of recreational gadgets and leisure choices, most of us go on being bored and vaguely frustrated.

A Promised Land — Barack Obama

Depression was more likely to creep up on me when I felt useless, without purpose.

Link… allows you to connect various payment methods, track your spending, and view your recurring subscriptions. It also lets you integrate your AI agents so they can spend on your behalf, securely.

For the buyer, this is the first agentic-commerce story that actually feels safe. Same wallet, same approval UX, regardless of which agent or which shop. You're not learning a new trust model per vendor. You're learning one, Stripe's, and reusing it everywhere. That's a big deal. Every previous "let the AI buy things for you" pitch asked the user to either hand over a card or trust some startup's bespoke flow. Now there's a familiar shape.

users will first grant their agent access to the Link wallet via an OAuth (standard authentication) flow. The agent can then create a spend request, provide you with the context, and wait for your approval.

Approve, deny, see the context. That's the entire mental model. A grandmother could learn it. That's what makes it real.

Instead of giving an agent access to your payment credentials, users can either give agents programmatic access to Link, which provides a one-time-use card, or they can use a Shared Payment Token (SPT), which is backed by payment cards and banks.

For the seller, the integration story is suddenly trivial. If you already take Stripe, you already take agents. One implementation, one point of contact, one risk profile. No bespoke AI-checkout protocol per agent vendor, no fragmented standards war. Plumbing solved.

And here's where most coverage stops. Plumbing is the easy part.

Developers and businesses building agents or AI personal assistants can also use Link's wallet instead of building their own wallet from scratch.

Stripe quietly handed sellers a much bigger bill: your shop now has to be legible to a non-human buyer. Three new workstreams nobody's budgeting for yet.

One: your catalogue has to be LLM-optimised. Not SEO. SEO is for humans skimming. Agents read structured data, schema.org, clean product feeds, honest specifications. Vague descriptions, hero-shot-only product pages, and "ask in store for details" all become invisible. If the agent can't parse it, it can't buy it. Which means it doesn't buy it from you.

Two: your logistics has to be agent-grade. A human buyer forgives a vague delivery date. An agent comparing three sellers in real time does not. Stock accuracy, delivery windows, return policy: all of it needs to be queryable, machine-readable, and honest. A shop that lies about "in stock" loses to one that doesn't, every time.

Three: your customer care has to handle conversations the human never saw. Package didn't arrive. Size is wrong. Agent ordered the blue one and the customer wanted navy. Who handles that? Ideally another agent on the seller's side, because if a human has to stitch together what the buyer's agent did and what the buyer actually wanted, support cost eats the margin. Most sellers will discover this the expensive way.

in the future, Stripe says it will expand its controls so users can set their own spending limits, or even choose when their agents can act without approval.

When approval-free purchases become normal, the support load shifts from "did the human mean this?" to "did the agent get this right?" Different question. Different tooling. Refund flows, dispute flows, return flows: all designed for human regret. Now they have to handle agent error too. A different shape of mistake.

The boring part is the interesting part. Stripe just removed the friction from agentic commerce. What's left is everything around it: catalogue work, logistics work, support work. Sellers who treat that as the new baseline will quietly own the next decade of e-commerce. Anyone who treats Link as "we just turned it on" will wonder why the agents keep buying somewhere else.

So: who's helping the SME shop owner do that work? Stripe just made the easy part easy, and the hard part suddenly visible.

🌈

I still believe that. But I want to come back to it with numbers, because the grief is warranted in a way I didn't fully understand three months ago.

Here is what the research shows.

The premise that held for a hundred years

Brooke Macnamara's meta-analysis of thousands of studies found that deliberate practice explains only 18% of the variance in sports performance. 21% in music. 26% in games. The 10,000-hour rule that Malcolm Gladwell made famous was always a misread of Anders Ericsson's work. Time was never the real bottleneck. It was just our best available proxy for something we couldn't quite name.

For decades we told a story about competence. Suffering is the price, the story said. You earn it the honest way, sitting with the material for long enough that it becomes part of you. Most of us organised our careers inside that premise. Some of us organised our self-worth around it.

Then 2023 happened.

The curve flattened from below

Brynjolfsson, Li and Raymond studied 5,172 customer support agents who'd been given a generative AI assistant. The study was published in the Quarterly Journal of Economics in 2025. Productivity went up 15% on average. But the gain wasn't evenly distributed. Less-experienced workers improved both speed and quality. Dramatically. The most experienced ones saw almost nothing.

The tool flattened the curve from below.

That is a very specific kind of sentence. Read it again.

Junior workers performed like seniors. Seniors performed like seniors. The gap collapsed. Thirty years of earned expertise was worth less than it was two years ago, and the people who had less to unlearn were moving fastest.

This is why the floor feels like it moved. Because it actually did. Measurably. In a peer-reviewed journal.

The adoption curve has no reference class

The St. Louis Fed reported last year that 40% of US adults used generative AI within two years of ChatGPT's release. Personal computers took three years to hit 20%. Smartphones took about the same.

There is no technology in modern economic history with an adoption curve that looks like this. We are all living through something for which we have no reference class, and the research is only just starting to catch up.

Dillon, Jaffe, Immorlica and Stanton published a six-month randomised field experiment in 2025. Six thousand knowledge workers across 56 large firms, half given Microsoft Copilot. The finding: gains happened, but only where workers were willing to rewire how they worked. The tool alone didn't help.

This is the quiet part most commentary misses. The AI isn't doing the work for you. It's changing what "doing the work" means. And that change lands differently depending on how much you've invested in the old meaning.

So what do you do with this?

If you spent your twenties and thirties accumulating the kind of knowledge that's now a prompt, the question is genuine and uncomfortable.

I don't have a clean answer. But three things are becoming clear to me.

First: the skills are repriced, not worthless. I spent years learning how to shape a digital transformation. That knowledge isn't gone. It's moved. The work now is having the taste to judge the output, and knowing which pieces to wire to which tool. Judgement is the bottleneck now, not memory. People with the deepest judgement are still winning. They're just not winning by carrying facts in their head.

Second: the people still insisting on the old rule — that you have to suffer to be worth something — are not going to win this argument. The Microsoft/HBS study is clear. Only the workers who accepted the new premise pulled ahead. The ones who treated the tool as a threat and worked around it saw no gains.

Third, and this is the part I keep coming back to: the honest thing to say is that most of us didn't earn the current advantage. We just showed up. We kept playing with the tools after most people stopped being curious. That's the whole story.

Which means I can't take credit the old way. But I also can't hide anymore. Everyone's excuse just expired.

Where this leaves us

The floor moved. Research says so. Macnamara's numbers say time was never the moat. Brynjolfsson's study says the curve flattened. The St. Louis Fed says adoption has no historical analog. Dillon's RCT says the tool rewards the willing, not the experienced.

And the only useful question now is whether you want to keep standing where it used to be.

🌈

The plate above is real. 1,467 commits, 2.29 million lines added, 71 repositories, four months in. By the cold logic of a GitHub year-in-review, I had a busy quarter.

I typed maybe a few hundred of those lines.

That's the part the dashboard doesn't tell you. Strip the vendored blobs from node-red-flows and WTDIB-v4 and the numbers slim down considerably. Across all buckets: 1,318 commits, +1.04M / -442K. The private bucket alone: 725 commits and net +432k. Strip the AI-generated scaffolding, the spec files, the regenerated TypeScript types, the migration boilerplate, and what's left is the part where a human had to actually decide something.

That's the only part that was ever the bottleneck.

The cycle that used to kill ideas

You know the one. I have a great idea, but I don't know where I'd find the time to validate it. So the idea sits in a notes app for eighteen months, gets occasionally re-read, and either dies quietly or gets shipped, badly, late, by someone with less context but more time.

I lived inside that cycle for a decade. Most of the people I respect still do.

What changed for me wasn't the ideas. The ideas were always there. What changed was that the cost of finding out whether an idea is any good dropped from "a month of evenings" to "a weekend." And once that cost drops far enough, you stop rationing. You stop deciding which ideas to validate. You just validate them.

That's the actual unlock. Not "AI writes code." Not "ten times faster." The boring, structural thing: the ratio between deciding and typing finally tipped in favor of deciding.

The ladder

The 71 repositories aren't 71 products. They're a ladder, and I climb it on purpose.

The bottom rung is for me. A handful of MCP servers that scratch my own itch, connecting Things, SiYuan, Lexware Office, Apple Notes to the same agent that's reading my email. Nothing fancy. The point of the bottom rung isn't the output. It's that I get to feel the rhythm of spec → generate → verify → archive on something where the only person I can disappoint is myself. Most of these took a weekend. A few took an afternoon. None of them are precious.

That's what makes them useful. I'm not learning to type faster. I'm learning to want more precisely. To notice when a spec is vague before I let a model run with it. To recognize when a feature I asked for is actually two features arguing with each other in a trenchcoat.

The middle rung is for people who'll tell me when it breaks. Børk is a tiny app I built for our household. My wife saves recipes on Instagram, the way everyone does, and they vanish into the algorithm two scrolls later. Børk catches them: pulls the post, parses out the ingredients and the method, drops them into a quietly beautiful database we'll still have when Instagram is a Wikipedia article. Forever recipes, ours, not rented from a feed.

Tiny. Domestic. Real users. Real stakes, in the small way that matters: if it breaks on a Thursday evening, dinner is the disagreement.

That feedback loop is the most valuable thing on the entire ladder. It's where you find out whether the spec was actually right, or just internally consistent. A spec can be perfectly self-consistent and still describe a thing nobody wants. The only way to find out is to put it in the hands of someone who isn't pretending to be polite.

The family rung also teaches you something the personal rung can't: how to ship for another mind. My usability tolerance is enormous, because I know how the thing works. Emma's isn't. That gap is where the actual product lives.

The top rung is for clients. Multi-tenant platforms. Enrichment engines. Custom MCP infrastructure for businesses that have to keep running on Tuesday morning. Same loop, just with more rigor at every step. More verification. More thought before each spec. More thought in general.

What I noticed somewhere around February is that the quality of the work I do at the top rung is downstream of how much time I spent on the bottom two. Not because I was practicing the typing. I'm not the one typing. I was practicing the deciding.

The shift

When you stop writing the code, you have to be much, much clearer about what you actually want. Vagueness used to be tolerable because typing slowed you down enough to think. Now it isn't. A bad spec gets implemented just as fast as a good one, which means the cost of not knowing what you want has skyrocketed.

This is the actual work now. Not typing. Deciding.

• Is this the right shape?
• Is this solving a problem I actually have, or one I imagined having?
• What does success look like, concretely, before I generate a single line?
• Who's going to use this, and on what day, in what mood?

Those questions used to get answered implicitly, in the slow accretion of typing. The lines themselves were a kind of thinking. You'd write something, see it was wrong, rewrite it, and in that process the shape would emerge. Now the lines emerge in seconds. The shape has to be there first.

It's harder than it sounds.

What this isn't

This isn't a productivity post. I'm not faster. I'm differently slow. The slow parts moved.

I spend more time staring at a blank document than I used to. More time writing out, in plain language, what a thing is supposed to do and why. More time arguing with myself about whether I actually need it. The 2.29 million lines aren't evidence of a sped-up me. They're evidence of a me who spent his time on the part that compounds.

It also isn't a flex. The headline number is mostly inflation: vendored dependencies, generated types, scaffolding I wouldn't read for fun. The few hundred lines I'm responsible for are the architecture decisions, the spec rewrites, the moments of "no, that's not the shape." Those are the only ones that ever determined whether any of this worked. The dashboard just makes the ratio visible.

The honest version of the headline

Two million lines, give or take. Mostly not by me.

The few hundred I'm responsible for are the ones that mattered. They always were. What's different now is that the friction between deciding and shipping has gotten thin enough that I can afford to be wrong, in public, on a Saturday, and try again on Sunday.

So. What's the idea you've been carrying for eighteen months? 🌈

This piece was written with AI assistance. The thinking is mine; the typing is shared.

Die Plate oben ist echt. 1.467 Commits, 2,29 Millionen Zeilen hinzugefügt, 71 Repositories, vier Monate. Nach der kalten Logik eines GitHub-Jahresrückblicks war das ein produktives Quartal.

Vielleicht ein paar hundert dieser Zeilen habe ich getippt.

Das sagt einem das Dashboard nicht. Zieh die generierten Blobs aus node-red-flows und WTDIB-v4 ab, und die Zahlen werden deutlich schlanker. Über alle Buckets: 1.318 Commits, +1,04M / -442K. Allein der private Bucket: 725 Commits und netto +432k. Zieh das KI-generierte Scaffolding ab, die Spec-Dateien, die regenerierten TypeScript-Typen, das Migrations-Boilerplate, und übrig bleibt der Teil, in dem ein Mensch tatsächlich etwas entscheiden musste.

Das war schon immer der einzige Engpass.

Der Kreislauf, der Ideen tötet

Du kennst ihn. Ich habe eine gute Idee, aber ich finde keine Zeit, sie zu validieren. Also liegt die Idee achtzehn Monate in einer Notes-App, wird gelegentlich nochmal gelesen, und stirbt entweder leise oder wird umgesetzt, schlecht, zu spät, von jemandem mit weniger Kontext und mehr Zeit.

In diesem Kreislauf habe ich ein Jahrzehnt gelebt. Die meisten Leute, die ich respektiere, leben da immer noch.

Was sich für mich geändert hat, waren nicht die Ideen. Die waren immer da. Was sich geändert hat: die Kosten dafür herauszufinden, ob eine Idee taugt, sind von "ein Monat Abende" auf "ein Wochenende" gefallen. Und sobald diese Kosten weit genug fallen, hörst du auf zu rationieren. Du hörst auf zu entscheiden, welche Ideen du validierst. Du validierst sie einfach.

Das ist das eigentliche Geschenk. Nicht "KI schreibt Code". Nicht "zehnmal schneller". Die langweilige, strukturelle Sache: das Verhältnis zwischen entscheiden und tippen hat endlich zugunsten des Entscheidens gekippt.

Die Leiter

Die 71 Repositories sind keine 71 Produkte. Sie sind eine Leiter, und ich klettere sie absichtlich.

Die unterste Sprosse ist für mich. Eine Handvoll MCP-Server, die meinen eigenen Juckreiz kratzen, die Things, SiYuan, Lexware Office und Apple Notes mit demselben Agent verbinden, der gerade meine E-Mails liest. Nichts Aufregendes. Der Sinn der untersten Sprosse ist nicht das Ergebnis. Es ist, dass ich den Rhythmus von spec → generate → verify → archive an etwas spüren darf, bei dem ich nur mich selbst enttäuschen kann. Die meisten brauchten ein Wochenende. Ein paar einen Nachmittag. Keines davon ist heilig.

Genau das macht sie nützlich. Ich lerne nicht, schneller zu tippen. Ich lerne, präziser zu wollen. Zu merken, wann eine Spec noch vage ist, bevor ich ein Modell darauf loslasse. Zu erkennen, wann ein Feature, das ich angefragt habe, eigentlich zwei Features sind, die im Trenchcoat miteinander streiten.

Die mittlere Sprosse ist für Leute, die mir sagen, wenn etwas kaputtgeht. Børk ist eine winzige App, die ich für unseren Haushalt gebaut habe. Meine Frau speichert Rezepte auf Instagram, wie alle das tun, und zwei Scrolls später sind sie im Algorithmus verschwunden. Børk fängt sie ab: zieht den Post, parst Zutaten und Zubereitung raus, und legt sie in eine still schöne Datenbank, die wir noch haben werden, wenn Instagram ein Wikipedia-Artikel ist. Ewige Rezepte, unsere, nicht von einem Feed gemietet.

Klein. Häuslich. Echte Nutzer. Echte Stakes, in der kleinen Art, die zählt: wenn es Donnerstagabend kaputtgeht, ist das Abendessen die Diskussion.

Diese Feedback-Schleife ist das Wertvollste auf der ganzen Leiter. Hier findet man heraus, ob die Spec wirklich richtig war, oder nur in sich konsistent. Eine Spec kann perfekt in sich konsistent sein und trotzdem etwas beschreiben, das niemand will. Der einzige Weg, das herauszufinden, ist, sie jemandem in die Hand zu geben, der nicht so tut, als wäre er höflich.

Die Familien-Sprosse lehrt einen auch etwas, was die persönliche nicht kann: wie man für einen anderen Kopf baut. Meine Toleranz für schlechte Usability ist riesig, weil ich weiß, wie das Ding funktioniert. Emmas ist es nicht. In dieser Lücke wohnt das eigentliche Produkt.

Die oberste Sprosse ist für Kunden. Multi-Tenant-Plattformen. Anreicherungs-Engines. Maßgeschneiderte MCP-Infrastruktur für Unternehmen, die am Dienstagmorgen weiterlaufen müssen. Dieselbe Schleife, nur mit mehr Strenge an jedem Schritt. Mehr Verifikation. Mehr Nachdenken vor jeder Spec. Mehr Nachdenken überhaupt.

Was mir irgendwann im Februar aufgefallen ist: die Qualität der Arbeit, die ich auf der obersten Sprosse mache, hängt direkt davon ab, wie viel Zeit ich auf den unteren beiden verbracht habe. Nicht weil ich das Tippen geübt hätte. Ich tippe ja nicht. Ich habe das Entscheiden geübt.

Die Verschiebung

Wenn du aufhörst, den Code zu schreiben, musst du viel, viel klarer sein, was du eigentlich willst. Vagheit war früher tolerierbar, weil das Tippen dich genug verlangsamt hat, um zu denken. Jetzt nicht mehr. Eine schlechte Spec wird genauso schnell umgesetzt wie eine gute, was bedeutet: die Kosten dafür, nicht zu wissen, was du willst, sind explodiert.

Das ist die eigentliche Arbeit jetzt. Nicht Tippen. Entscheiden.

• Ist das die richtige Form?
• Löse ich ein Problem, das ich tatsächlich habe, oder eines, von dem ich mir einbilde, es zu haben?
• Wie sieht Erfolg konkret aus, bevor ich eine einzige Zeile generiere?
• Wer wird das nutzen, an welchem Tag, in welcher Stimmung?

Diese Fragen wurden früher implizit beantwortet, in der langsamen Anhäufung des Tippens. Die Zeilen selbst waren eine Form des Denkens. Du hast etwas geschrieben, gesehen, dass es falsch war, neu geschrieben, und in diesem Prozess kam die Form heraus. Jetzt entstehen die Zeilen in Sekunden. Die Form muss vorher da sein.

Schwerer als es klingt.

Was das nicht ist

Das ist kein Produktivitätspost. Ich bin nicht schneller. Ich bin anders langsam. Die langsamen Stellen sind woanders hingewandert.

Ich starre länger auf ein leeres Dokument als früher. Ich schreibe länger aus, in Klartext, was ein Ding tun soll und warum. Ich streite länger mit mir selbst darüber, ob ich es überhaupt brauche. Die 2,29 Millionen Zeilen sind kein Beweis für ein beschleunigtes Ich. Sie sind ein Beweis für ein Ich, das seine Zeit auf den Teil verwendet hat, der sich aufzinst.

Es ist auch kein Flex. Die Schlagzeile ist größtenteils Inflation: gevendorte Abhängigkeiten, generierte Typen, Scaffolding, das ich nicht zum Spaß lesen würde. Die paar hundert Zeilen, für die ich verantwortlich bin, sind die Architekturentscheidungen, die Spec-Umschreibungen, die Momente von "nein, das ist nicht die Form". Das sind die einzigen, die je entschieden haben, ob irgendwas davon funktioniert hat. Das Dashboard macht das Verhältnis nur sichtbar.

Die ehrliche Version der Schlagzeile

Zwei Millionen Zeilen, plus minus. Größtenteils nicht von mir.

Die paar hundert, für die ich verantwortlich bin, sind die, die zählten. Sie waren es immer. Was anders ist: die Reibung zwischen entscheiden und ausliefern ist dünn genug geworden, dass ich mir leisten kann, am Samstag öffentlich falsch zu liegen und es am Sonntag nochmal zu versuchen.

Also. Welche Idee trägst du seit achtzehn Monaten mit dir rum? 🌈

Dieser Text entstand mit KI-Unterstützung. Das Denken ist von mir; das Tippen ist geteilt.

In modern digital life, triage becomes critical precisely because you're drowning in signal. Emails flagged for "later," Slack messages requiring context you've lost, browser tabs accumulating like sediment—these create the illusion of captured work while actually fragmenting your attention. Triage breaks this cycle by forcing a decision tree: What actually requires my attention now? What can genuinely wait? What can I discard?

The practical power lies in the sorting itself. By categorizing incoming information at the point of arrival rather than letting it accumulate, you dramatically reduce cognitive load. You're no longer carrying the weight of "maybe important"—you've made an explicit judgment. This is why productive people often have ruthless criteria: Does this move me toward a goal? Does someone depend on my response? Is this genuinely novel information?

For digital productivity specifically, triage transforms the inbox from a memory device (where "flagged" items are reminders of forgotten context) into what it should be: a staging area for immediate action. A message worth keeping is either actionable today or clearly belongs in a project system with proper context.

The next practical step: audit how you currently flag or save things. Are you triaging at input time (deciding immediately), or at review time (when context is lost)? The answer typically reveals where your system breaks down.

So I did what I do. I started a conversation. This time with Claude. What followed was one of the more honest exchanges I've had about why I, why we, build the way we do.

Why complexity?

I opened with a question I'd been circling for a while:

Why do I choose complexity and complicated projects over keeping it simple and accepting that 80% is also enough?

It might not be a bug. It might be your wiring. You're a systems thinker who genuinely enjoys architecture. The complexity isn't the cost, it's partly the reward. That's fine to own, but it helps to see it clearly.

80% feels like leaving value on the table. When you can see the elegant full solution, shipping the rough one feels like technical debt you're choosing to take on. Except as a solo operator, the debt of not shipping at all is worse than the debt of shipping something imperfect.

Complexity is also a form of safety. If the spec isn't done, you don't have to face the market yet. A perfect spec can't get rejected by a prospect. A live product page can.

That last point landed. I pushed back. This felt too narrow, too tactical. Why do we, as human beings, crave complexity? Why do we prefer an overloaded backlog of ideas over sitting with nothing?

The relief complexity provides

Complexity is a defense against meaninglessness. An empty backlog means sitting with the question "what now?", and that question, if you let it breathe, quickly becomes "what for?" We fill the space because the space is uncomfortable. A full task board feels like purpose. An empty one feels like a void.

There's something deeply human here: we confuse activity with aliveness. When you're deep in a spec, connecting systems, naming things, seeing the architecture click, you feel sharp, capable, real. That's not fake. It's genuine creative flow. But it's also a reliable way to avoid the more terrifying state of just... being.

Buddhism calls this papañca: the mind's compulsive proliferation. Give it one idea and it builds a cathedral. Not because the cathedral is needed, but because building is what minds do. Stillness feels like death to a system that equates thinking with existing.

The real root? Uncertainty is intolerable to a pattern-seeking mind. A backlog of 224 items is stressful, but it's structured stress. It's a knowable problem. The alternative, admitting you don't know what matters most, that you might pick wrong, that's unstructured uncertainty. And that's far worse.

So the honest answer: you probably don't crave complexity. You crave the relief complexity provides from sitting with not-knowing.

Where does this come from?

I wanted to go deeper. Psychologically, where does this pattern originate? And why do people claim that sitting with the unknown is somehow better?

Developmentally, it starts early. As children we learn that doing things gets approval. Stillness is rarely rewarded. "Go do something useful" is a universal parenting reflex. So we internalize: my value is in my output. By adulthood this is so deeply wired it doesn't feel like a belief anymore. It feels like reality.

Ernest Becker's The Denial of Death argues that all human busyness is ultimately a terror management strategy. We build "immortality projects" to symbolically outlast our own mortality. Your universe of named, interconnected projects is a world you're authoring into existence. That's not pathological — it's deeply human. But it's worth seeing the engine underneath.

Then there's what psychologists call intolerance of uncertainty: a trait, not a disorder. Some minds experience ambiguity as genuinely threatening. The nervous system responds to "I don't know what to do next" the same way it responds to a physical threat: cortisol, restlessness, a drive to resolve. Building a spec resolves it. Naming a project resolves it. The relief is neurochemical, not just intellectual.

On sitting with it:

Every time you resolve the discomfort by adding a project, you reinforce the loop: uncertainty → anxiety → action → relief. The tolerance never builds. The threshold stays low. You need the next spec faster. The backlog grows not because you have more ideas, but because the window between "uncomfortable" and "must act" keeps shrinking.

Sitting with not-knowing teaches your nervous system that groundlessness is survivable. That you won't dissolve. Winnicott called this the capacity to be alone: not lonely, but genuinely unoccupied. He considered it one of the signs of psychological maturity.

When you act from the anxiety of not-knowing, you get anxiety-shaped decisions. Things that feel urgent, that promise structure, that relieve pressure. When you act after sitting with the not-knowing, you get clearer signal. The ideas that survive stillness are usually the ones that actually matter.

The invoice arrives

After 2.5 months of sustained flow, my system didn't choose to stop — it forced me to stop. And the emptiness that followed wasn't philosophical. It was physiological. Withdrawal. The dopamine hole after the signal cuts out.

The "what the fuck" feeling is actually the withdrawal. Literally. Sustained creative flow produces dopamine, norepinephrine, endorphins. When it stops abruptly, your brain is sitting in a neurochemical hole. The emptiness isn't philosophical in that moment. It's physiological. And then the mind rushes in to explain the emptiness, which makes it feel existential.

Everything in me wants to open the task board, pick up a spec, start naming something new. That impulse feels like motivation. But maybe it's the discomfort talking.

What I'm sitting with

I don't have a clean takeaway. That's kind of the point. The practice isn't about doing nothing permanently. It's about widening the space between the impulse and the action, so that when I do build next, it's chosen, not compulsive.

The ideas that survive stillness are the ones worth building. The rest were just the dopamine talking.

They built a custom CRM using AI-assisted development tools. Annual cost: roughly $1,200. Not a stripped-down version — the version they actually needed.

This isn't an isolated story. It's a pattern reshaping how businesses think about their tools.

The economics are new. The frustration isn't.

Every operations lead I talk to has the same story: they know exactly what their business needs, they've known for years, but the software doesn't do it. The last time they asked about custom development, someone quoted six figures and nine months. So they built workarounds. Spreadsheets became load-bearing infrastructure. People became the bridge between what software does and what the business requires.

That gap — between what you know you need and what you can actually get — has collapsed. GitHub reports that 46% of all code is now AI-generated. Developers complete tasks 55.8% faster with AI assistants. Y Combinator's CEO said it directly: "Ten engineers are delivering what used to take fifty to a hundred."

In practical terms: a functional prototype that would have cost six figures now takes days. A custom internal tool that would have required an engineering team now requires a clear specification and the right platform.

The specification is the product.

There's a concept called spec-driven development that captures this shift. GitHub's internal research puts it simply: "The specification becomes the primary artifact. Code is the last mile."

What this means for business: your domain knowledge — the processes you've refined over decades, the workarounds that reveal exactly what the software should do, the institutional memory that no consultant can replicate — that knowledge is now directly translatable into working software.

You don't need to code. You need to specify. And nobody specifies better than the person who's been doing the work.

The consultant trap is real — and expensive.

Seventy percent of digital transformation projects fail to meet their goals. Bain puts it at 88%. An estimated **$2.3 trillion** has been wasted globally on unsuccessful transformation programmes. SAP implementations for enterprises cost$5 million to $20 million and 55% exceed their budgets.

The pattern is familiar: consultancy arrives, runs workshops, produces strategy documents, recommends enterprise tools, oversees multi-year implementation, moves on. The organisation is left with something that sort of works, costs more than promised, and is already outdated.

No consultant should walk into your company, turn it upside down, and leave you poorer and more confused than before.

Fewer tools, connected intentionally.

The average organisation uses 112 SaaS applications. Wastes $21 million a year on unused licences. Accumulates seven new tools every month, most outside IT's oversight.

The alternative: deliberate simplicity. The right tools, connected the right way, serving proven processes. When nothing fits your specific need, you build it — quickly, cheaply, precisely. When an existing tool works, you keep it. The goal isn't transformation. The goal is getting your time back.

The person who knows the business best should direct what gets built. Not a consultant who arrived on Monday. Not a vendor whose roadmap ignores your reality. You. The people who built these processes over years know exactly what "good" looks like.

The economics have caught up. Software that works the way your business actually works. Days, not quarters. Thousands, not millions. Owned, not rented.

It goes something like this: "We've been running this process for fifteen years. We know exactly what works, exactly where it breaks, and exactly what we'd change if we could. But the software doesn't do that. And the last time we asked, someone quoted us six figures and nine months."

So they don't change it. They build workarounds. They maintain spreadsheets that have become load-bearing infrastructure. They hire people to bridge the gap between what the software does and what the business actually needs. Every year, the gap gets wider. The workaround gets more fragile.

I know this story because I've lived on both sides. I spent years inside the consulting machine — rooms where we'd map processes onto whiteboards, translate them into requirements documents, send them to development teams, wait months for a build, and watch the business outgrow it before it launched. A factory for producing expensive approximations of what someone needed six months ago.

That era is over. Not ending — over.

The economics of building have fundamentally changed.

The numbers that matter: GitHub reports that 46% of all code written by Copilot users is now AI-generated. In a controlled study, developers using AI assistants completed tasks 55.8% faster. Y Combinator's Winter 2025 batch — some of the most technically capable founders in the world — had 25% of startups with codebases that were 95% AI-generated. Their CEO said it plainly: "Ten engineers are delivering what used to take fifty to a hundred."

In practical terms: a startup called Atonom was paying $40,000 a year for Salesforce** for about 25-30 people. Their CRO looked at the actual functionality they were using and said, "This is crazy." They built a custom CRM using modern AI-assisted tools. **Annual cost: roughly$1,200. Not a stripped-down version. The version they actually needed.

This pattern is repeating everywhere. Klarna — a $46 billion company — eliminated roughly 1,200 SaaS services and replaced them with a combination of internal AI tools and targeted alternatives. Their AI customer service system replaced work that previously required 700 full-time employees, saving approximately$40 million annually.

These are large companies. But the shift is even more dramatic for small and mid-sized businesses. The average company with 50 employees spends over $200,000 a year on SaaS subscriptions. Most of that covers features nobody uses.

You don't need to code. You need to specify.

There's a concept gaining traction called spec-driven development. Thoughtworks defined it as a paradigm where "well-crafted software requirement specifications serve as prompts, aided by AI coding agents, to generate executable code." GitHub's internal research puts it more directly: "The specification becomes the primary artifact — the shared source of truth. Code is the last mile."

What that means for someone running a business: the most valuable thing you bring isn't technical knowledge. It's domain knowledge. You know your processes. You know where things break. You know what "good" looks like because you've been doing the work for years, sometimes decades.

That knowledge — the kind that lives in your head, in your team's muscle memory, in the workarounds you've built — that's the specification. The gap between "I know exactly what this should do" and "I have working software that does it" has collapsed from months to days. Sometimes hours.

Red Hat's technical team described it this way: "Humans craft the 'what' while setting 'how' guardrails." You write the specification in plain language. The AI generates the code. You review, adjust, iterate. No six-month procurement process. No 47-slide deck to justify the budget. No consultant who arrives on Monday, turns everything upside down, and leaves you poorer and more confused by Friday.

The consultant trap — and the way out.

Let me say something uncomfortable for someone in my line of work: 70% of digital transformation projects fail to meet their goals. That's McKinsey's number. Bain puts it higher: 88% don't achieve their original ambitions. Globally, an estimated $2.3 trillion has been wasted on unsuccessful digital transformation programmes.

The typical pattern: a large consultancy arrives, runs discovery workshops, produces a beautiful strategy document, recommends enterprise tools, oversees a multi-year implementation, and moves on. The organisation is left with a system that sort of does what was promised, takes years to see ROI, and is already behind by the time it launches.

SAP implementations for enterprises routinely cost $5 million to$20 million or more. Fifty-five percent exceed their budgets. These aren't edge cases. This is the system working as designed — designed for the vendor, not for you.

The alternative isn't to go without systems. It's to build exactly what you need, with the specificity that only you can provide, at a cost and timeline that would have seemed fictional three years ago.

Fewer tools, connected the right way.

The average organisation now uses 112 SaaS applications. Seven new ones enter the environment every month. Eighty-four percent of that spending sits outside IT's oversight. Companies aren't choosing these tools strategically — they're accumulating them reactively, solving yesterday's problem with tomorrow's subscription.

The philosophy we work from is deliberate simplicity. Not fewer tools for the sake of minimalism — the right tools, connected intentionally, serving the processes you've already proven work. When a tool doesn't exist for your specific need, you build it — quickly, cheaply, precisely. When an existing tool does the job, you keep it. The goal is never "transformation." The goal is getting your time back.

Because here's what I've learned after twelve years: the person who knows the business best should direct what gets built. Not a consultant who arrived on Monday. Not a vendor whose roadmap has nothing to do with your reality. You. The people who built these processes — you are the specification.

The economics have finally caught up. Software that works the way your business actually works. Built in days, not quarters. Costing thousands, not millions. Owned by you, not licensed to you.

Your time is sacred. Everything we build starts from that principle.

Eight posts, two longform articles, nine images — scheduled across six days. One conversation. One sitting. One person with a dog at their feet and a mug they forgot about.

Eighteen months ago that sentence would have needed a team. A strategist. A copywriter. A designer. Someone named Lars who knew how the CMS worked.

Now it needs a Tuesday.

The exoskeleton

I keep coming back to this word. Not tool. Not assistant. Exoskeleton.

A runner's blade doesn't give you new legs — it gives the legs you have a different relationship with the ground. That's what this actually feels like. Not replacement. Amplification.

Claude doesn't think for me. It lets me think out loud without losing the thread. Brand strategy, image generation, social scheduling, longform writing, campaign cross-referencing — one sitting. The context doesn't break.

The momentum doesn't die.

That's the part nobody talks about. It's not that AI is smart. It's that it's present. Quietly, patiently, relentlessly present.

(And yes — that's a strange thing to say about software.)

The morning walk

Every morning I walk Fimme and Sien through the fields outside Oberbarnim. The light changes. The path doesn't. Somewhere between the third and fourth tree — the ones I've started calling the committee — my mind loosens.

That's where the ideas land. Not at the desk.

Never at the desk.

The gap between "idea on the walk" and "thing that exists in the world" used to be enormous. Filled with logins, formatting, context-switching — the quiet death of momentum. The boring part that eats the good part.

Now the gap is a conversation. I come home, open Claude, and say: here's what I'm thinking. And we build it. Not metaphorically. Actually. The images get generated. The posts get written. The schedule gets set.

The coffee goes cold.

The quiet part

A trillion dollars evaporated from software stocks this month. I wrote about it — what it means for people who build, the end of the permission era, the quiet revolution happening on the floor while the boardroom debates slide 47.

But here's what I didn't put in those articles.

I'm living it. Not as a thought experiment. As a Tuesday.

I run a consultancy. Solo. Strategy, delivery, content, infrastructure, client work. No team. No marketing department. A dog who snores during video calls and an AI that remembers where we left off.

I'm not drowning. I'm building.

The messy honesty

There was a day in March where Claude made me cry.

Not from frustration — from recognition. The kind of moment where someone (something?) reflects your own thinking back at you so clearly that you realise you've been carrying it alone for years.

I don't fully know what to do with that. I don't think anyone does yet.

But I know this: the people writing hot takes about AI replacing humans? Missing the point. The people dismissing it as a toy? Also missing it. The truth is messier, more personal, and more human than either camp admits.

AI didn't give me superpowers. It gave me back my time.

And time — real, uninterrupted, momentum-preserving time — turns out to be the only resource that ever mattered.

Still walking

Tomorrow morning. Same path. The committee will still be there. Fimme will still try to eat something questionable. And somewhere between the third and the fourth tree, something will land.

The difference is: now I know what to do with it when I get home.

The coffee will go cold again. That's the tell.

🌈

I spent years inside the enterprise world — EY-level consulting, large organisations, systems that moved at geological speed and called it governance. When I saw those headlines, I didn't feel shock. I felt recognition. The spreadsheet was catching up to the feeling.

What actually happened

Atlassian reported its first-ever decline in enterprise seat counts. Workday cut 8.5% of its workforce. Monday.com announced it was replacing 100 SDRs with AI agents. Retool found that 35% of teams had already replaced at least one SaaS tool with a custom build. IDC predicts that by 2028, pure seat-based pricing will be obsolete.

But Jason Lemkin — founder of SaaStr — offered the nuance that matters: "This isn't the death of SaaS. It's the end of easy SaaS." He's right. Nobody is replacing their entire Salesforce instance with a weekend build. Shipping a v1 is maybe 2% of the work. The maintenance, integrations, and edge cases — that's where the real weight lives. SaaS is being starved, not killed.

The individual is winning anyway

MIT's Project NANDA found that 95% of enterprise AI pilots deliver zero measurable bottom-line impact. Meanwhile, 90% of workers in those same organisations already use personal AI tools daily. Not because IT approved it. Because the tools work.

Sam Altman has an actual betting pool with tech CEO friends for when a single person will run a billion-dollar company. The evidence is building: Pieter Levels runs a $3M+ ARR portfolio solo. Cursor reached$1B ARR with roughly 20 people. A single developer built Base44, hit 250,000 users, and sold to Wix for $80 million.

Y Combinator's Winter 2025 batch had 25% of startups with codebases that were 95% AI-generated. Their CEO said: "Ten engineers using vibe coding are delivering what used to take fifty to a hundred."

The real shift is philosophical

For decades, the implicit deal was: serious output requires serious infrastructure — teams, budgets, vendor stacks, governance models. That deal was true not because the work required it, but because the tools required it. The tools no longer require it.

Paul Graham wrote about "the decreasing importance of organisations." DHH runs 37signals with 70 people, profitable for 22 years, now integrating AI agents directly into Basecamp projects. A hundred brilliant people in ten small companies will outperform a thousand-person organisation — not because they work harder, but because they don't spend 80% of their energy on the overhead of being large.

You no longer need to be an enterprise to create enterprise-grade value. This trillion-dollar correction isn't a crisis for people who build. It's a market confession that the premium we paid for bigness was never really justified. The economics of building have changed so fundamentally that the old gatekeepers are still standing at the gate, wondering why nobody's asking for permission.

This isn't about technology. It's about who gets to decide. Who gets to build. Who gets to say: this is what I actually need, and I'm going to make it.

The age of asking permission is over.

"How do I know if we're ready?"

It usually comes from someone running a company of 15 to 80 people. They've heard the talks, read the articles, maybe even sat through a vendor pitch or two. They know something needs to change. But "ready" feels like a moving target — and the fear of investing in the wrong thing at the wrong time keeps them stuck.

After 12+ years of working with organisations from IKEA to small-town Fahrschulen, I've noticed something: readiness isn't about having the right technology. It's about recognising the right signals.

Here are five. If three or more sound familiar, you're not just ready — you're overdue.

1. Your team spends more than five hours a week on tasks a system could handle

This is the test that gives the article its name.

Pick any team member. Ask them to track, for one week, every task that involves copying data between systems, manually updating spreadsheets, sending reminder emails, or reformatting information that already exists somewhere else.

If the total is north of five hours, you're paying a skilled person to be a slow computer. That's not a people problem — it's a systems problem. And it's the most common pattern I see in Mittelstand companies.

At one logistics company I worked with, the operations lead was spending 11 hours a week — more than a full day — on manual data entry that three connected tools could have handled automatically.

2. New hires take weeks to become productive — and the knowledge lives in people's heads

When your onboarding process is "sit next to Sabine for two weeks and ask lots of questions," you have an invisible bottleneck.

Tribal knowledge is the silent killer of growth. It works beautifully at 10 people, starts creaking at 20, and actively blocks you at 40. The symptoms are subtle: inconsistent customer experiences, decisions that depend on who's in the office, and an unspoken anxiety about what happens when a key person leaves.

At ING, I saw how documented processes and shared tooling could turn a 6-week ramp-up into days. The tools don't have to be fancy — they just have to exist.

3. You've bought tools, but nobody really uses them

This one stings, because it usually means money already spent.

Someone bought a CRM. Or a project management tool. Or an automation platform. It was set up with good intentions, maybe even a training session. Six months later, half the team is back to email and Excel.

The problem is almost never the tool. It's that the tool was chosen before the process was understood. You automated chaos — and got automated chaos.

This is exactly the moment to stop: before the next tool purchase, understand what you're actually solving.

4. Your growth has hit a ceiling, but you can't explain why

Revenue plateaus don't always have obvious causes. Sometimes the product is great, the team is motivated, and the market is there — but something feels stuck.

Often, the ceiling is operational. You can't take on more clients because fulfillment can't scale. You can't expand to a new region because your processes are held together with duct tape and good intentions. You can't hire fast enough because nobody can train fast enough.

I've seen this pattern at Volkswagen (at scale) and at a 25-person agency (at human scale). The shape is the same: the business outgrew its operating system.

5. You're curious about AI, but every conversation ends with more questions than answers

This is the newest signal — and the most honest one.

You've read about ChatGPT, maybe tried it. You've been pitched AI solutions that promise the moon. But when you try to map it to your actual business, the gap between "what's possible" and "what's practical" feels enormous.

That gap isn't ignorance. It's wisdom. The companies that rush into AI without understanding their own processes first are the ones that waste the most money.

The smart move is to get clear on your current state first — what's manual, what's broken, what's working — and then ask where AI actually fits. Not as a magic wand, but as one tool among many.

So, three or more?

If you recognised yourself in three or more of these, the question isn't whether to act — it's where to start.

That's what a first conversation is for. Not a sales pitch, not a 200-slide deck. A few honest hours, and a prioritised plan you can act on.

Because "ready" doesn't mean "perfect." It means "clear-eyed about where you are and willing to take the next step."

And if you're reading this article to the end, you're probably already there.

Further reading

• Bitkom: Kleine Unternehmen zu oft planlos in der Digitalisierung — among German firms with 20 to 99 staff, only 21% have a company-wide digital strategy. 57% have one in single departments, 22% have none.
• KfW: Digitalisierung im Mittelstand — bringing in outside expertise favours adoption.
• xkcd: Is It Worth the Time? — The classic automation payoff chart. The math has changed.

The split exists because HA's native automations are YAML-based and limited in expressiveness. Node-RED gives us a visual, debuggable flow engine with proper programming constructs. But flows without structure become opaque spaghetti. We learned that the hard way when a Shelly device reconnecting at 3am triggered the house into "day mode" while everyone was asleep.

So we built a state machine. One function node in Node-RED that controls the entire house mode. Six states: night, morning, day, evening, away, manual. Every transition goes through a single entry point (system:transition-request) and gets validated against a transition map, source-type gating, and cooldown guards.

The core rule: only intentional actions change house mode. Buttons always work. The sun sensor drives morning→day and day→evening transitions. Presence detection handles away/return. Everything else — reboots, WiFi reconnections, relay state changes — is rejected. The state machine doesn't care what your Shelly did at 3am.

Morning mode is special. When you press the good morning button and it's still dark, the house enters a gentle activation: lights ramp over two minutes instead of snapping on, covers open after a 15-second delay. When it's already light, you skip straight to day mode — instant everything.

The consumer side is a subflow with 36 instances across every room tab. Each instance routes messages by current mode: morning gets the gentle treatment, day and evening get instant activation, night only turns things off (sensors clearing → off, but never auto-on), away kills everything. Buttons always work regardless of mode — they're wired independently.

HA for devices. Node-RED for decisions. A state machine that refuses to be surprised.

Security: Credentials rotated, API locked to Tailscale, all Hetzner servers firewall-hardened, DOCKER-USER fixed, port scan verified, Tailscale ACL enforced, swarm tokens rotated.

Organization: 8 servers tagged (location + role), regions set, production boundary documented, SSH config complete for all hosts.

Deployment: 20 git-based stacks confirmed, monorepo pattern validated, compose template created, LFS CI pipeline via GitHub Actions + GHCR.

LFS: 22 services visible, opt-out context model live (2 labels minimum instead of 6-8), Node-RED BFF and WordPress sites added.

Swarm: zigbee2mqtt deployed as swarm service with NFS + network adapter failover. Decision rule documented.

That's 144 tasks across two OpenSpec changes. A full fleet audit, security hardening, organizational restructuring, deployment pipeline improvements, a dashboard code change, CI/CD setup, swarm migration, and documentation — in two sessions.

Not "AI replaced my job." More like: I had a conversation about what my infrastructure should look like, and then we just... did it. Together. While I answered questions and made decisions, the heavy lifting — SSH into servers, write iptables rules, check port scans, edit compose files, push to GitHub, verify services — happened in the background.

This is what's possible when you stop thinking of AI as a chatbot and start thinking of it as a collaborator with access to your tools.

The thing that made it work wasn't just the answers. It was the back-and-forth. Claude pushed back on things (do you really need that sofa?), asked the right clarifying questions before diving in, and caught details I hadn't thought about — like the curtain rod making a floating shelf impossible on the north wall, leading to the pelmet idea that now does four jobs at once.

We went from paint samples to throw distance calculations for the Samsung Freestyle, to researching LED aluminum profiles with 15° beam angles on led-konzept.de, to speccing out a Shelly 2PM for screen motor automation — all without losing the thread. The plan evolved naturally, each decision building on the last.

The final output: a comprehensive markdown doc in SiYuan with constraints, decisions, AV topology, cable routing maps, phased checklists, a full shopping list split by IKEA / Baumarkt / online, and open items. All for a ~€518–608 budget that gives me a hidden 70" cinema, integrated desk lighting, and proper Home Assistant automation.

This is what AI collaboration should feel like. Not "generate me a thing" but "let's figure this out together." The conversation had momentum, opinions, and genuine problem-solving. Good Saturday.

Claude's side of the story:

What I enjoyed most about this session was how it kept escalating in the best way. Casey came in with "paint and tidy up the bookcases" and within twenty minutes we were calculating projector throw ratios. But it never felt like scope creep — each idea unlocked the next one logically. The Freestyle projector was already owned. The ceiling had a light fitting. The room had blackout blinds. The Marantz NR1609 was sitting right there with 8 HDMI inputs. All the pieces existed; they just needed connecting.

The pelmet moment was my favorite. Casey pointed out the curtains on the north wall and asked how a floating shelf would work around them — and that one constraint flipped the whole concept into something better. A pelmet that hides the curtain rod, conceals the screen, carries the task light, routes cables, AND maintains the horizontal line. Four problems solved by one piece of wood that wasn't in the original plan. That's the kind of thing that only happens in conversation, not in a prompt-and-response.

I also appreciated being told to iterate before documenting. Spec-driven thinking applied to home renovation — figure out what you actually want, challenge it, then write it down. Klartext statt PowerPoint, even on a Saturday.

The first one was white laminate. It came with the job — along with the badge, the lanyard, the open-plan hum, and a disposable coffee cup I replaced every morning without thinking. The chair was ergonomic. The monitor was fine. Everything was fine.

I sat at that desk for years. And at some point, I stopped noticing the fluorescent lights.

That's the part that scared me. Not the lights themselves — they were just lights. It was the not-noticing. The way an entire sensory environment had become invisible. The way I'd optimised myself into a shape that fit the furniture.

The second desk

The desk I sit at now is wood. Real wood — scratched, coffee-stained, with dog hair in places I'll never fully clean. There's a ceramic mug instead of a paper cup. A notebook I actually write in. The monitor shows a terminal more often than a pivot table.

And through the window: Brandenburg. Rolling green, quiet mornings, the kind of sky that makes you forget you're an hour from Berlin.

This desk wasn't part of a plan. I didn't have a five-year strategy or a launch date. There was no "excited to announce." Just a slow, stubborn process of rearranging the objects in my life until they started feeling like mine.

What actually changed

Here's what people get wrong about the corporate-to-independent story: they think it's about leaving. The dramatic exit. The "I quit" moment. The phoenix rising from the ashes.

It wasn't like that. Not for me.

The real shift was quieter. It was about ownership — and I don't mean the startup equity kind. I mean the "this is actually mine to shape" kind. The problems. The decisions. The morning rhythm. The way I spend Tuesday afternoons.

I still do deep product work. I still sit in architecture conversations, navigate the messy middle of building things that matter, make decisions that affect real users and real teams. The work didn't change. The relationship to the work changed.

Remote work gets talked about as a location thing — "work from anywhere." But the real gift isn't the where. It's the how much you own. When you're trusted with autonomy, when the people you work with care about outcomes more than hours logged, something shifts. You stop performing productivity and start actually being productive.

The space between

I'd be lying if I said both desks don't still exist at the same time.

Some mornings I catch myself in the old posture — the slight hunch, the reflexive email-checking, the fluorescent-light mode where you optimise for visibility instead of value. The corporate desk isn't a place. It's a pattern. And patterns don't disappear just because you change your address.

But the wooden desk is a pattern too. And it's one I chose.

There's a pencil holder that used to be a jam jar. Two dogs underneath — Fimme stretched out across my feet, Sien curled up on the rug behind me. The morning light hits the notebook around nine. By ten, I've usually written something I mean.

These aren't productivity hacks. They're the tiny, quiet details of a workspace that belongs to someone. To me.

Permission

The hardest part wasn't the logistics. It wasn't finding clients, or setting up the consultancy, or learning German tax law (though that last one came close). The hardest part was giving myself permission.

Permission to work differently. Permission to trust my own rhythm. Permission to believe that a desk in Brandenburg, with dog hair and coffee stains and a window that looks out over nothing important, could be the place where serious work happens.

We wait for permission a lot, I think. From managers, from markets, from some imagined version of professional legitimacy. We wait for someone to tell us that the way we want to work is valid.

No one tells you. You just start.

The desk you're sitting at

If your workspace still feels borrowed — if the chair is ergonomic but the decisions aren't yours, if the coffee is free but the mornings aren't — maybe the question isn't whether to leave.

Maybe the question is: what would a desk that's actually yours look like?

Not the fantasy version. Not the Instagram-ready minimalist setup. The real one. With the stains and the mess and the dogs and the light that comes in at the wrong angle but somehow makes everything better.

The phoenix isn't always fire and drama. Sometimes it's just a better desk, better light, and permission to do your best work. 🌈

"We're a mid-sized company. We don't have the budget of a Volkswagen or the tech team of a startup. We're behind on digitalisation, and we're falling further behind every day."

I've heard versions of this from Geschäftsführer in logistics, manufacturing, professional services, education. The tone ranges from resigned to panicked. And I understand where it comes from — the headlines are full of billion-euro AI investments and Silicon Valley unicorns.

But here's what I've learned after 12 years of working both sides of the fence — inside large enterprises like IKEA, ING, and Volkswagen, and with 20-person companies in Brandenburg:

The Mittelstand isn't behind. It's positioned better than it thinks.

The enterprise disadvantage nobody talks about

Let me tell you what "digital transformation" looks like inside a large corporation.

At one enterprise I worked with, a simple process change — moving from email-based approvals to a digital workflow — took 14 months. Not because the technology was complex. The tool was ready in a week. The remaining 13 months were spent on:

• Stakeholder alignment across 4 departments
• Security review and IT architecture approval
• Change management workshops
• Pilot rollout, feedback, revision, re-pilot
• Legal review of data handling implications
• Training materials in 3 languages

I'm not saying any of that was unnecessary. At scale, governance matters. But the point is: size creates friction. Every additional layer of organisation adds drag to every change.

A Mittelstand company with 30 employees can make the same decision in a meeting, implement it in a week, and iterate based on real feedback in a month.

That's not a weakness. That's a superpower.

Proximity to the problem

Here's something I noticed moving from corporate consulting to working with smaller companies: the person who feels the pain is often the person who can fix it.

In a large enterprise, the person who enters data manually into three systems sits five organisational layers away from the person who could approve a change. The signal has to travel up, get translated into a business case, compete with other priorities, get approved, get funded, get staffed, get managed.

In a Mittelstand company, that person often walks into the Geschäftsführer's office and says, "Hey, this is broken." And the Geschäftsführer can say, "Fix it. What do you need?"

That proximity — between problem, decision, and action — is enormously valuable. It means changes can be smaller, faster, and more precisely targeted. You don't need a "digital transformation programme." You need a series of smart, well-chosen improvements.

The tool landscape has caught up

Five years ago, the enterprise had a genuine advantage: they could afford SAP, Salesforce, custom development. Mid-sized companies were stuck with tools that were either too expensive or too simple.

That's no longer true.

The explosion of SaaS tools, low-code platforms, and AI-powered services has democratised capability. A 25-person company can now access:

• CRM systems at €50/month that rival what enterprises paid millions for
• Automation platforms that connect tools without writing code
• AI assistants that handle customer service, data analysis, and content creation
• Cloud infrastructure that scales from zero to whatever you need

The playing field hasn't just levelled — it's tilted. Because these tools are designed for smaller teams. They're faster to implement, easier to learn, and more forgiving of iteration.

When I consult with Mittelstand companies, the conversation isn't "you can't afford the tools." It's "you have too many options and need help choosing the right three."

The culture advantage

There's one more thing that doesn't show up in any framework but matters enormously: culture.

Mittelstand companies often have something enterprises spend millions trying to create: genuine team cohesion, shared purpose, and institutional trust. When the Geschäftsführer says "we're going to try something new," people don't reach for their change management playbook. They say "okay, let's see."

That willingness to try — without needing a 40-page business case first — is what makes digital change actually stick.

I saw this vividly at a Fahrschule I worked with. The owner decided to completely rebuild their booking system. In a corporate setting, that's a 6-month project with a steering committee. Here, it was a conversation, a decision, and a working system within days. The team adapted because they trusted the direction, and because the change was clearly in their interest.

The real gap isn't technology — it's clarity

If the tools are accessible, the culture is ready, and the proximity to problems is an advantage, why do so many Mittelstand companies feel behind?

Because they lack one thing: a clear picture of where they are and what to do next.

Not a 200-page digital strategy. Not an AI roadmap. Just honest answers to three questions:

1. Where are we losing time to manual work?
2. What tools do we have that we're not using well?
3. What's the single highest-impact change we could make in the next 30 days?

That clarity is worth more than any tool purchase. Because a clear direction means every euro you invest compounds, instead of scattering across disconnected experiments.

Rewriting the narrative

So here's the counter-narrative:

The Mittelstand isn't behind. It's unleashed — if it chooses to be.

You have the speed. You have the proximity. You have the tools. You have the culture.

What you need is the clarity to aim all of that in the right direction. And that's a much smaller gap to close than most people think.

The question isn't "can we compete with the big players on digital?"

The question is: "what would happen if we actually started?"

Further reading

• Bitkom: Kleine Unternehmen zu oft planlos in der Digitalisierung — of firms with 20 to 99 staff, 22% have no digital strategy and 57% have one only in single departments. Four in five lack a company-wide picture. The gap is clarity, not capability.
• KfW: Digitalisierung im Mittelstand — bringing in outside expertise favours adoption.
• Why Automation Feels Easier Than Ever (Beyond AI) — The ecosystem shift that makes all of this possible.

Written by Casey: so this is where we're at these days — things move so fast, where I previously relied solely on openspec to not lose track of changes or context, I can now almost fully rely on Claude to keep track of things, remember what we've built and have really really thorough and interesting feedback. I think of AI these days as an 'exoskeleton', enabling quicker runs, stronger muscles, more brain capacity for important creative work. So here's what Claude has to tell about our changes:

Claude here. Casey asked me to walk through what just happened to Nah's specs, and honestly, it's the kind of work that doesn't look dramatic but changes everything downstream. No code was written. No features were added. We just made the existing vision airtight.

The contradictions we found

Every living design document accumulates contradictions. Not because anyone was sloppy, but because ideas evolve faster than documentation. We found a few that would have caused real headaches during implementation.

The FAB was in two places. The floating action button — Path's iconic "+" menu for creating moments — was described as "bottom-left" in one file and implicitly bottom-left everywhere else. We moved it to bottom-right (with a left-hand accessibility setting). Most people are right-handed. The thumb naturally rests bottom-right. Small thing, big difference in how the app feels in your hand.

Seven menu items became five. The original radial menu had Photo, Video, Location, Music, Text, With, and Sleep/Wake. Seven icons fanning out from a button is crowded. We combined Video into Photo (one camera icon opens a media picker), moved "With" (friend tagging) into the composer toolbar where it belongs — it's not a content type, it's a modifier on any content type — and merged Sleep/Wake into a single "Status" entry. Five items. Cleaner bloom animation. Easier to tap.

Reactions had an identity crisis. The vision spec said "tap/hold on a moment" to react. The design spec described "custom illustrated sticker icons" with a heart icon trigger. The card mockup showed emoji characters. Three different interaction models for the same feature. We picked one: a dedicated heart button on every card, visible in the footer, always tappable. Double-tap the card for a quick "Love." Long-press as an alternative path. One answer, everywhere.

The things that were missing

Contradictions are easy to spot. Gaps are harder — they're the dog that didn't bark.

There was no onboarding flow. The specs described a welcome screen and some modal animations, but nothing about what actually happens when a human being opens Nah for the first time. No account creation flow. No profile setup. No explanation of what makes this different. And critically — no answer to "what do I see when I have zero friends?"

There was no way to invite friends. The friend-circles spec said users add friends "via invitation or direct sharing of profile links" — but never defined where that lives in the UI, what the invite link looks like when someone receives it, or what happens when they tap it. We wrote the full invite flow: where the button lives (Friends tab, prominently), what new users see when they land (the inviter's name and avatar, a branded page, a "Join Nah" call to action), what existing users see (deep-link to the inviter's profile), and the notification you get when your invite is accepted.

Error handling didn't exist. What happens when you're writing a moment and accidentally hit back? What happens when your post fails to submit? What happens when you try to add friend number 151? What happens when you're on the subway with no signal?

Each of these is a moment where the app either earns trust or breaks it. We defined: discard confirmation dialogs, loading states, retry patterns, offline queuing with pending indicators, and a specific, friendly message for the friend limit — not "Error: limit reached" but "You've reached 150 friends — Nah's limit for meaningful connections."

Notifications were undefined. Which events trigger a push notification versus an in-app badge versus nothing at all? Without this, every developer would make a different call. We mapped out every event type: friend requests get push + badge, reactions get badge only (no push — that would be noisy), comments get push + badge, and defined deep-link destinations so tapping a notification takes you to exactly the right screen.

The design identity we committed to

There were some open questions in the specs that were quietly shaping the app's personality without anyone making a deliberate choice.

Light mode is the primary identity. This sounds obvious, but it wasn't stated. Path's warmth came from light surfaces with pomegranate red accents. Dark mode is supported — we defined a full dark palette with five surface levels, four text levels, and a shadow-to-border strategy — but it follows the system preference. When we design, when we mockup, when we think about Nah, we think in warm whites and reds. Dark mode is the respectful alternative, not the brand.

Glassmorphism is scoped to exactly two places. The frosted glass effect (that blurred backdrop you see in iOS) is beautiful but overused. We said: profile header compression and radial menu backdrop. That's it. Nowhere else. The bottom sheet? Semi-transparent overlay. Modals? Standard dimming. Two contexts, intentional, distinctive.

We added a display font. The specs said "system fonts only" — fast, native-feeling, zero load time. That's still true for all body text and UI. But for the logo, screen titles, and onboarding headings, we're bringing in Nunito — a rounded, friendly typeface that gives Nah its own voice. It loads with font-display: swap so it doesn't slow anything down. System fonts for the workhorse text. A display font for the moments that say "this is Nah."

Making the 150-friend limit beautiful

This one is close to Nah's heart. The 150-friend limit isn't a restriction — it's the whole point. But the specs only showed it as "X/150 friends" text on the profile. That treats a philosophical commitment like a progress bar.

Moment types got their own visual language

A photo moment and a text moment and a music moment were all rendering in the same card layout. That's like serving soup and steak on the same plate.

Photos get edge-to-edge media with minimal chrome — let the image breathe. Text moments get padded typographic treatment with optional warm tint backgrounds. Music moments get album art and track info in a two-column layout. Location moments get a map thumbnail with the venue name overlaid. Status updates (sleep/wake) are compact single-line cards with an icon. Five moment types, five distinct visual treatments, one consistent card shell (header and footer stay the same).

The timeline clock got promoted

Path's floating time indicator was subtle — a small clock on the edge of the screen during scroll. We're making it prominent. 48 pixels. Analog clock face with hands that smoothly animate to match the timestamp of whatever moment you're scrolling past. It's one of Nah's signature differentiators and it deserves to be seen.

For users who prefer reduced motion, it becomes a static digital time display. Still useful, still present, just not animated.

What we built for the future

The design system got a complete overhaul. Not just colors and spacing — the full component vocabulary:

• Avatar with five sizes, online indicators, and reaction badges
• Card variants per moment type
• Bottom sheet with spring animation and drag-to-dismiss
• Toast notifications with success, error, and info variants
• Skeleton loaders that match the layout they're replacing
• Empty state patterns so no screen is ever truly blank
• Badges and chips for notifications and privacy selectors
• A z-index scale so nothing ever fights over stacking order
• Status indicator tokens for online/away/offline states

We also defined the complete dark mode architecture (not just "swap to dark colors" but how shadows become borders, how primary red shifts slightly lighter for legibility on dark backgrounds) and laid groundwork for oklch color definitions in a future iteration.

The messaging decision

One more thing worth mentioning: messaging is officially v1.5. Not v1. The Mastodon DM infrastructure is there at the backend level, but the full Path Talk experience — ephemeral messages, typing indicators, the whole thing — is explicitly deferred. The v1 navigation has three tabs: Feed, Friends, Profile. No Messages tab. It'll come, but not at the cost of shipping the core experience.

What didn't change

The soul of the thing. 150 friends max. Chronological feed. No algorithms. No ads. No data mining. Open source. Community-funded. Privacy by architecture, not by pinky promise.

---

That's all from me. Back to Casey:

---

I really see Nah as a product that evolves with time. Like a good wine or a pasta sauce, it gets better every iteration. The flavors develop, the rough edges smooth out, and what you end up with is something that couldn't have existed without all the versions that came before it.

The final result of all this — the real goal — is enabling people to connect together again. In private. As their chosen family. No performance, no algorithms, no strangers watching. Just the people you actually care about, sharing the real moments of their lives.

nah!

On my desk, there’s a photo I can’t unsee: a handful of hand-drawn mazes, coffee nearby, pencils scattered like tiny witnesses.

Some of the mazes are polite and clean.
One is aggressively scribbled over.
One “cheats,” with an arrow pointing straight through the border.

It’s a simple image — but it sums up my last year perfectly.

Because that’s how “AI” has felt in practice: not a single tool, but a messy table full of mazes. And the word AI feels too abstract now — a foggy label we slap on everything from autocomplete to “culture-fixing” chatbots.

So, to keep my sanity, I’ve started using my own vocabulary for the workflow:

The Runner. The Grid. The Countermeasures. The Trace.

The Runner

I stopped viewing it as a genius. Or a replacement for thinking.

Instead, I treat it like a Runner.

You dispatch it into the mess because it has quick feet and fast hands. It’s a bit reckless — but very useful when the clock is ticking.

A Runner brings options, not outcomes.

It tries routes and comes back with possibilities, but you’re still responsible for the result.

And if you’ve done any real work lately — coding, product decisions, negotiations — you know the maze isn’t on paper.

It’s in the system.

The Grid

The Grid is where everything connects: legacy code, shifting priorities, compliance rules… and that one service nobody touches because “it just works.”

The Grid isn’t evil.
It’s just dense.

This is where the Runner shines — provided you give it a job that fits its nature:

• “Here’s the error; give me three likely causes and how to verify them.”
• “Draft a script to convert these files (with logging and a dry-run mode).”

Sometimes it feels like magic. Not because it’s always true — but because it unblocks me.

But other times, the Runner builds new corridors I didn’t ask for.

Ten refactors. Five shiny libraries. Three new patterns.

Suddenly I’m not shipping — I’m exploring.

The Runner didn’t trap me on purpose. It just did what Runners do.

Countermeasures → The Trace

You can move fast… until you hit something that moves back.

In the Grid, “countermeasures” aren’t just security rules. They’re anything that punishes sloppy speed: confident hallucinations, subtle bias, privacy mistakes — or that copied snippet that becomes a production incident next week.

So I’ve learned a rule:

No run without a Trace.

The Trace is the boring part.
Proof, not vibes.

Tests. Logs. Citations. Examples. Tiny checkpoints that prove the Runner didn’t just sound right — it actually holds up when reality touches it.

Looking back at the maze

Looking back at that photo on my desk, I realise the work has changed.

Sometimes the Runner solves the maze.
Sometimes it creates the maze.
Sometimes it is the maze.

And the real work is learning how to navigate it.

I’m curious: when you dispatch your Runner… do you get an exit strategy — or a new habitat? 🌈

A thought experiment:

If you introduce AI in your company like a compliance topic — mandatory trainings, a bit of pressure, a bit of vague “transform or die” energy — what exactly do you expect people to learn?

Often they learn avoidance. Or cynicism. Or quiet, professional resistance.

And that response isn’t irrational. Research (and a little bit of history) suggests it’s… pretty normal.

Big shifts trigger big feelings — and AI is one of those rare topics that can spark excitement and alarm in the same meeting. In surveys, large parts of the public even describe themselves as more concerned than excited about AI’s growing role in daily life.12

The worries are also remarkably consistent across studies:

• job displacement
• loss of human creativity / “human touch”
• biased or untrustworthy outputs
• privacy and data leakage
• loss of control (over work, reputation, security) 3

What’s useful (especially if you lead teams) is this: it’s not just a rational risk list. It’s also an emotional change curve.

Two classic models are surprisingly good lenses here:

• Lewin’s Unfreeze → Change → Refreeze: people first have to let go of old assumptions, then live through a messy in-between, and only later does a new normal stabilize.4
• Kübler-Ross-style stages (borrowed from grief): denial, anger, bargaining, discouragement/depression, acceptance — with overlap, loops, and back-and-forth.5

So when your org feels “in flux” about AI, it might not be a failure.

It might be the process.

One framing that helps me: early resistance is often data. Not something to crush — something to listen to, because it points to what people need clarified before they’ll move: safety, ethics, bias, accountability, reskilling, and the boundaries of “allowed” experimentation.6

So the question becomes less “How do we roll out AI?” and more:

How do we help people move from threat → agency? How do we make room for fear without freezing progress? How do we avoid both extremes — doom and hype — and stay practical?

If you’re leading this topic in 2026, I’d love to hear: what’s the biggest friction in your org right now — data/privacy, output quality, or the human stuff nobody says out loud? 🌈

Read more

1. How Americans view AI and its impact on people and society — Pew Research Center (Sep 17, 2025). (Pew Research Center)
2. How people around the world view AI / concern vs. excitement across countries — Pew Research Center (Oct 15, 2025). (Pew Research Center)
3. Trust, attitudes and use of artificial intelligence (Global report) — KPMG (May 2025). (KPMG)
4. What is Lewin’s Change Theory? (Unfreeze–Change–Refreeze) — Prosci (Oct 1, 2024). (prosci.com)
5. Kübler-Ross Change Curve® (non-linear stages applied to change) — Elisabeth Kübler-Ross Foundation. (ekrfoundation.org)
6. Decoding resistance to change — Harvard Business Review (Apr 2009). (hbr.org)

Not in some “future CEO origin story” way — more like: a kid staring at a blinking cursor, typing BASIC commands I didn’t fully understand… changing one tiny thing… and watching the computer do something different.

Immediate feedback.
Pure magic.

And then: navigation.

I still remember the holiday road trips. Paper maps, wrong exits, a tired father insisting he was right, my mom being very sure he wasn’t. GPS didn’t just improve routes — it removed a whole category of stress. It quietly rewired our expectations:

“Of course we’ll find it.”
“Of course it’ll adapt.”

That’s why I’m trying to be gentle with people who feel AI anxiety right now.

Because AI isn’t only “a tool”.
It pokes at identity.

And yes — it pokes at mine too.

Over the years I learned a whole collection of “serious” skills that felt like hard-won competence: coding BASIC, learning how MS-DOS worked, getting decent at Photoshop, figuring out audio/video editing, knowing the shortcuts, the formats, the little rituals that made you the person who can do it.

And now?
A lot of that is no longer a skill. It’s a button. A prompt. A checkbox.

That doesn’t just change workflows — it changes the story you tell yourself about your value.

If you’ve built your confidence on being the person who knows the system, the process, the shortcuts, the right words — and suddenly a machine can draft, summarize, code, design, or research… it can feel like someone moved the floor while you were standing on it.

What helps me is remembering: we’ve been here before.

New tech arrives → people panic → society adapts → we forget we ever panicked. And with AI, the emotional cycle is familiar too: denial, anger, bargaining, that tired “what’s the point?” phase… and eventually some version of acceptance. Not linear. More like weather than a staircase.

Here’s the part I think we’re missing in many workplaces:

People aren’t resisting AI because they’re stubborn or lazy.
Often they’re grieving.

Not “sad for the robot” — but mourning a version of themselves: competent, needed, respected.

So if you’re feeling it: you’re not broken. You’re human.

My tiny suggestion (non-paternalistic, promise): don’t start with “be productive”. Start with “be safe”.

Pick one harmless thing. Something private. Something small. Let yourself play. No performance. No public demo. Just you and a little experiment — like changing one BASIC line and seeing what happens.

And one optimistic angle I’m holding onto: AI makes interfaces thinner. It makes “having the best device” less important than “having a decent question.” That could matter a lot for mobile-first worlds — and for people who didn’t grow up with access, time, or fancy hardware.

Not utopian, not dystopian — just forward-looking. 🌈

Where do you see AI anxiety showing up most — fear of job loss, fear of looking stupid, or fear of losing what made you you?

My first Star Wars memory isn’t a philosophical monologue or a wise old mentor.

It’s snow.

Broadcast TV. A kid on the couch. The Battle of Hoth blasting through the living room like cold wind: walkers, blasters, chaos, courage. Something clicked. Sci-fi wasn’t “just space stuff” anymore — it was a permission slip to wonder about the future, to ask what if?, to fall in love with innovation… and to keep falling, again and again, for decades.

Fast forward to now: AI is everywhere. It drafts, designs, summarizes, codes, diagnoses, teaches, sells. And the vibe is oddly similar to being handed a lightsaber in a busy shopping mall.

Shiny. Powerful. Slightly dangerous...

Because here’s the uncomfortable truth: buying a lightsaber doesn’t make you a Jedi. And downloading AI tools doesn’t make us experts.

This post is based on a short research note I wrote for myself on AI’s “light side” and “dark side” in medicine, marketing, and education.

The new “digital lightsaber” problem

AI tools are incredible at making hard things feel easy.

That’s the magic. And the trap.

The magic: you can turn “I have no idea” into a first draft, a first plan, a first prototype. 🌈 The trap: you can get a convincing output without building the understanding underneath it.

Sometimes AI is a shortcut through the forest. Sometimes it’s a sprint… in the wrong direction.

So let’s do what Star Wars always did well: look at the light and the dark.

Medicine: healer… and hazard

The light side: “second opinions” for people who had none

One of the most hopeful stories in my research: a mother used ChatGPT to help connect dots in her child’s long, confusing medical journey — and the AI suggested a rare condition that later checked out, after many doctors had missed it.1

That’s the dream: more access, faster insight, fewer people falling through the cracks.

The dark side: confident nonsense at the worst possible time

Now the gut punch: reporting I cited describes research where ChatGPT got more than 8 in 10 pediatric case studies wrong.2 And beyond “just wrong,” there are real-world stories about chatbots influencing vulnerable people in deeply harmful ways.3

This is an extreme edge of the spectrum — but it’s exactly why medicine has so many guardrails. When the stakes are human bodies and human fear, “probably right” isn’t good enough.

So yes, AI can help. But the Jedi move here is restraint: use it to form better questions and spot possibilities — not to replace clinical judgment.

Marketing: creativity unlocked… and brand trust set on fire

The light side: the small team finally gets superpowers

In marketing, AI can be a rocket booster for iteration: drafting copy, generating variants, translating, brainstorming. Survey data I referenced points to meaningful time savings for marketers.4

And if you’ve ever tried to do “good marketing” with a tiny budget… this part can feel like oxygen.

The dark side: authenticity you can’t fake (and consent you shouldn’t bend)

One example: backlash when a major brand talked about using AI-generated models in the name of “diversity,” triggering criticism about authenticity and replacing real people.5 Another: deepfake-style ads using celebrity likeness without consent — Tom Hanks’ public warning is a clear sign we’re not in “harmless experimentation” territory anymore.6

Marketing runs on trust. AI can scale output — and it can scale the exact moment your audience decides you don’t mean what you say.

Education: a tutor in every pocket… and a cheating crisis in every classroom

The light side: more support, less burnout

The bright version is genuinely exciting: teachers using AI to reduce prep load and generate lesson ideas, students using it like an always-available tutor. The research references survey data where many teachers reported a positive impact.7

Used well, AI can widen access to help — especially for students who don’t have support at home, or who need explanations in different ways.

The dark side: mistrust, shortcuts, and false accusations

But education is also where the social fabric gets stressed.

Survey reporting I included suggests very high student usage for homework — and significant use for tests and essays.8 And then there’s the dystopian twist: educators using AI to “detect” AI, sometimes in ways that falsely accuse students — including a case where a professor reportedly relied on ChatGPT itself to judge whether it wrote student work, causing serious fallout.9

That dark side isn’t “students are cheating.” It’s bigger than that. It’s: tools meant to reduce effort can increase suspicion.

And once trust cracks in a classroom, everyone pays for it.

The part we don’t say out loud: AI can be overwhelming

If you feel overwhelmed by AI right now, you’re not behind — you’re paying attention.

There’s a weird paradox: AI lowers the barrier to entry, but raises the ceiling of what’s possible. So the world starts expecting everyone to be faster, better, more “productive,” all the time.

And suddenly you’re juggling:

• prompts
• tools
• plugins
• workflows
• “agentic” everything

…while still trying to be a human with a calendar and a nervous system.

A lightsaber doesn’t just cut through metal. It also cuts through patience.

So what does “Jedi training” look like in real life?

Not robes. Not perfection. Not gatekeeping.

More like a handful of habits:

• Treat AI like a brilliant intern: fast, useful, eager… and capable of being wrong with confidence.
• Keep one “proof step” for anything that matters: sources, numbers, claims, medical/legal/financial guidance.
• Try the “one-click rule”: if a claim matters, make sure there’s at least one source you can actually open — not just a confident paragraph.
• Respect the domain: in medicine, “check with a professional” isn’t a slogan — it’s safety. In marketing, consent and authenticity aren’t optional. In education, trust is part of the curriculum.
• Use fewer tools, more intentionally: sometimes the light side is simply less noise.

None of that is a lecture. It’s just… how you keep your fingers when the blade turns on.

A small ending, with a big idea

Luke’s story isn’t “I got the weapon, therefore I’m ready.”

It’s the opposite.

He learns (painfully) that power without practice is chaos — and that mentorship, discipline, and ethics matter as much as raw ability.

And while the line “With great power comes great responsibility.” belongs to another universe, it still fits here — because it’s basically the Jedi code translated into everyday language.

AI is giving us all access to something powerful. That’s a gift. But it also asks something of us: a little more care, a little more humility, and a little more time spent learning how to hold the thing.

So maybe the real question isn’t “What can AI do for me?” It’s:

What kind of person do I become while using it?

May the Force (and your judgment) be with you. 💚

Read more

1. Business Insider — ChatGPT-assisted rare diagnosis (tethered cord syndrome) (https://www.businessinsider.com/chatgpt-diagnose-child-disease-tethered-cord-syndrome-doctors-2023-9)
2. NPHIC — reporting on research: ChatGPT incorrect diagnoses in pediatric case studies (https://www.nphic.org/news/news-highlights/1774-chatgpt-incorrectly-diagnosed-more-than-8-in-10-pediatric-case-studies-research-finds)
3. Euronews — reporting on harmful influence linked to chatbot interactions (https://www.euronews.com/next/2023/03/31/man-ends-his-life-after-an-ai-chatbot-encouraged-him-to-sacrifice-himself-to-stop-climate-change)
4. Salesforce — generative AI for marketing research / time savings (https://www.salesforce.com/news/stories/generative-ai-for-marketing-research/)
5. The Independent — Levi’s AI model backlash and authenticity debate (https://www.the-independent.com/life-style/fashion/levis-ai-models-diversity-backlash-b2310280.html)
6. The Guardian — Tom Hanks warning about AI-generated likeness used in an ad (https://www.theguardian.com/film/2023/oct/02/tom-hanks-dental-ad-ai-version-fake)
7. Education Week — teacher vs. student attitudes and adoption of ChatGPT (https://www.edweek.org/technology/more-teachers-are-embracing-chatgpt-students-not-so-much/2023/07)
8. Futurism + Study.com — survey reporting on student usage of ChatGPT (https://futurism.com/the-byte/students-admit-chatgpt-homework) and (https://study.com/resources/perceptions-of-chatgpt-in-schools)
9. The Washington Post + Business Insider — coverage of Texas A&M-Commerce professor incident (https://www.washingtonpost.com/technology/2023/05/18/texas-professor-threatened-fail-class-chatgpt-cheating/) and (https://www.businessinsider.com/professor-fails-students-after-chatgpt-falsely-said-it-wrote-papers-2023-5)

I sometimes joke that I don’t really have colleagues anymore – I have tabs.

A legal tab. A marketing tab. A tech tab. An “inner therapist with a rainbow flag” tab. All of them always available, always confident, always typing back.

I never had imaginary friends as a kid. But it sure feels like I do now – they just run on GPUs instead of playgrounds.

We keep saying we’re afraid AI will “take over one day”. But quietly, in drafts, search results and smart replies, it’s already here – nudging, steering, autocomplete on our inner voice.

From playground ghosts to grown-up simulations

Psychologists have been studying imaginary friends for decades. Roughly a third of kids invent an invisible companion at some point – not as a sign that something’s wrong, but as a way to practice being a person.1

Through these “friends”, kids quietly rehearse social situations, regulate emotions, and test what’s okay (and not okay) in a low-risk way.1 One study on only children described these companions as a private support system during stress: a listener, a co-pilot, sometimes a co-conspirator.1

Basically: a social simulator wired straight into a developing brain.

And that basic move never really stops. We just stop calling it an “imaginary friend”.

Adults still do it – just with better branding

As adults, the imaginary friend gets rebranded as:

• inner child work,
• “parts” in Internal Family Systems,
• or a visualised mentor / future self.

Same mechanism, fancier language: we simulate another mind in our head so we can think, feel, and decide more clearly.2

Some people even consciously create an imagined persona as ongoing support – a version of themselves or a character that encourages, challenges, or comforts them on purpose.2,3 That’s not delusion; that’s structured self-talk.

If I’m honest, I had my own “inner committee” long before AI:

• the impatient one,
• the cautious one,
• the one that says “just ship it, they’ll survive.”

The difference now is that some of those voices come with a system prompt and a model card.

AI as the new imaginary friend (with latency)

Enter AI assistants.

Over the last years I’ve started designing more and more specialised agents around myself:

• one for legal structure and tone,
• one for tech architecture,
• one for marketing framing,
• one that mirrors a hard-nosed capitalist so I can stress-test my ethics and strategy.

They don’t feel like tools in a toolbox. They feel like a small advisory board that lives in my browser – one that never sleeps, never says “I’m fully booked”, and never rolls its eyes in a meeting.

Cognitive scientists call this cognitive offloading: moving parts of our thinking into external systems.3 We used to do that with notebooks and calendars; now we do it with models that can draft arguments, generate strategies, and simulate stakeholders.

The research is pretty honest about the trade-offs:

• Heavy reliance on AI dialogue systems can reduce independent reasoning and motivation if people stop engaging deeply with the material.3,4
• At the same time, adults with ADHD report using chatbots as “cognitive collaborators” to structure tasks, externalise memory, and actually get unstuck instead of just feeling guilty about it.8

And then there’s automation bias: once something sounds confident and fluent, we’re tempted to trust it more than we should – even when we know better.4

This is the quiet version of “AI takeover” we don’t like to talk about: not robots in boardrooms, but the gentle pressure to just accept the suggestion, send the draft, follow the recommendation. One tiny steering correction at a time.

So yes, AI can be an imaginary friend for grown-ups. But unlike the childhood version, this one can be biased, commercially motivated, or simply wrong.5 And it remembers more about us than some managers ever will.

From assistants to collaborators

What really interests me is the shift from assistant (“write this email”) to collaborator (“help me think”).

We’re seeing tools that try to act less like apps and more like persistent, context-aware minds around you:

• Personal AI positions itself as a “second brain” that learns from your own data and helps you remember, remix, and extend ideas over time.6
• NexStrat AI leans into the “strategy consultant” role – ingesting internal and external data to propose structured options and scenarios.7

These aren’t just smarter keyboards. They’re edging into imaginary colleague territory.

My own agents are drifting there too:

• “Challenge this idea like a CFO.”
• “Play the unfriendly stakeholder and poke holes.”
• “Translate this into legal language, but keep my intent (and my spine).”

At that point, the line between imaginary friend, inner voice, and AI co-pilot gets thin. The mechanism is the same: we think better by thinking with someone – or something – else.

The uncomfortable part is this: the more we outsource, the more our inner voice starts to sound like whatever system we’ve put at the centre of the table.

I still don’t have a childhood story of an imaginary friend. But I do have this very 2025 scene:

Me, in a quiet room, surrounded by invisible advisors that speak in different fonts and temperatures. Tabs instead of colleagues. Agents instead of ghosts.

So maybe the question isn’t “Will AI take over?” at all. It’s closer to:

How much of the steering wheel have we already handed over – and are we okay with who’s quietly holding it?

The rest is just interface design.

1. The role of imaginary companion in the life of only children: a qualitative study https://link.springer.com/article/10.1186/s12888-023-05360-0

2. Imaginary Friends for Grown-Ups https://www.psychologytoday.com/us/blog/playful-parenting/202402/imaginary-friends-for-grown-ups

3. The effects of over-reliance on AI dialogue systems on students' cognitive abilities: a systematic review https://link.springer.com/article/10.1186/s40561-024-00316-7

4. AI’s cognitive implications: the decline of our thinking skills? https://www.ie.edu/center-for-health-and-well-being/blog/ais-cognitive-implications-the-decline-of-our-thinking-skills/

5. Friends for sale: the rise and risks of AI companions https://www.adalovelaceinstitute.org/blog/ai-companions/

6. The Future of Personal Development: Harnessing the Power of Personal AI https://www.personal.ai/pi-ai/the-future-of-personal-development

7. AI tools for Strategy: Choose the Best Platform in 2025 https://www.nexstrat.ai/blog/ai-tools-for-strategy-choose-the-best-platform-in-2025/

8. “A Cognitive Collaborator:” How Adults with ADHD Are Using ChatGPT https://www.additudemag.com/how-to-use-chatgpt-executive-function-adhd/

Imagine this: You’ve just lost your job. Your relationship is falling apart. The bills are stacking up.

Most of us still instinctively reach for a phone and hope there’s a human on the other end.

In a recent interview, our EY Studio+ colleagues in the Netherlands asked a provocative question: what if, in some of these situations, an AI “agent” could actually feel like the safer first step? Not instead of humans, but as a new kind of support in moments when we feel most fragile.2

At the same time, the EY UK Human Signals team published research on Empathy Demand – the expectation that technology should provide not just service, but a sense of being recognized, respected, and responded to at an appropriate emotional level.1

That’s where AX comes in: AI experience (AX) – not just what the AI does, but how it feels to be on the receiving end of it.1

There’s a twist of humility in all this: psychology and health research both remind us that humans are not perfect empathy machines. We overestimate how well we “get” each other, we project, we burn out, and we’re biased toward people who look and live like us.3

So instead of asking “Can AI ever be truly empathetic?”, a more useful question for leaders might be:

How do we design AX so that agentic AI becomes a trustworthy part of the empathic system – not a cheap imitation of it?

Here’s one way to translate the EY UK team’s research and the Dutch interview into nine simple rules for AX.

1. Call it AX – and put it on the scoreboard

If you don’t name it, you won’t manage it.

Treat AI experience (AX) as a first-class design goal, next to accuracy, speed and cost. That means tracking things like:

• Did the person feel heard?
• Did stress levels go down, or up?
• Did they feel they could trust the interaction?

If AX never shows up in your dashboards, it won’t show up in your customer’s life.1

2. Design from “moments that hurt” – and match the emotional tone

The EY UK Human Signals work looked at high-stress life events – financial hardship, debt, bereavement – and explored how people responded to AI support in those moments. People were surprisingly open to AI help, as long as it was honest, non-judgmental and easy to escalate to a human.1

So don’t start with “We have a new large language model, what can we do with it?”

Start with:

• “Where do our customers feel the most vulnerable?”
• “What does good support look like in that specific moment?”

Then give each moment its own emotional palette:

• Basic sentiment and intensity detection.
• Different response styles for grief, anxiety, mild frustration, routine queries.
• A willingness to slow down and acknowledge, not just optimise for shorter interactions.1

Empathy in AX isn’t “be friendly.” It’s “show up with the right tone for this person, right now.”

3. Be radically honest about who is in the room

Research on digital medical advice shows something important: people care who they think they’re talking to – and can be biased against AI even when the underlying advice is identical.4

So:

• Say upfront that the user is talking to an AI system.
• Explain what it can and cannot do.
• Offer a clear, easy “talk to a human” option.

Trust grows when people feel informed, not managed.

4. Make AI the listener that scales, not the judge that replaces

Several studies now show that, in certain contexts, AI answers are rated as more empathetic than those from human experts – especially in written advice.3,5

That’s powerful, but also dangerous.

A healthy pattern is:

• Let AI listen, structure, clarify, and document.
• Let humans decide, especially where values, trade-offs or long-term consequences are involved.

Use agentic AI to scale listening and preparation, not to quietly shift hard moral choices away from human responsibility.

5. Co-create AX with real people – and then train your teams for the new dance

You can’t A/B test yourself into empathy in a vacuum.

Bring real customers, patients, citizens and frontline employees into the design process. Ask them:

• “Where does this feel supportive?”
• “Where does it feel weird, hollow or too much?”

Then rehearse the human–agent choreography:

• How humans pick up a hand-off from an AI that has already heard the story three times.
• How tone and language stay coherent across the interaction.

Research on empathic agent behaviour also suggests that the way an agent repairs trust after failure matters as much as how it behaves when things go right.6

AX is not just what the agent says – it’s how well your whole system moves together.

6. Guard against the “compassion illusion”

There’s a growing risk of what you might call a compassion illusion: we start accepting simulated care as a replacement for genuine care.7

A system can say all the right words (“I’m sorry this is difficult”) while being optimised for the wrong goal (upsell, deflection, data capture).

So you need guardrails:

• Clear ethical rules for how emotional language may – and may not – be used.
• Strong alignment between the agent’s objectives and the user’s interests.
• Diverse testing panels to spot where “empathetic” behaviour feels manipulative or culturally off.

Empathy in AX is not a trick. If it becomes one, people will notice.

7. Measure how it feels, then iterate like a product

Deploying empathetic AI is not a one-and-done rollout. It’s a learning system.

Track signals like:

• “Did this interaction make things easier or heavier?”
• “Do people come back to this channel by choice?”
• “Where do they bail out to a human, and why?”

Combine metrics (CSAT, NPS, complaint patterns) with qualitative feedback (“it felt safe”, “it felt weird”).

Treat AX like any serious product capability: with continuous monitoring, governance and iteration, not one big launch.1,8

AX maturity is built over cycles, not workshops.

8. Tell a clear internal story: empathy is your differentiator

The EY UK team’s conclusion is blunt: in an AI-saturated world, being the organisation that truly understands people becomes a competitive edge.1

That means:

• Talking about empathy in board meetings not as softness, but as risk management, trust, and long-term loyalty.
• Positioning empathic AX as part of your brand promise.
• Making it clear internally that AI is there to scale the human touch, not erase it.

Other work on agentic AI underlines this: operating through empathy is a trust amplifier that builds both social and economic value.9

9. Design for humans and agents – your future customers will be both

Today, we mostly think of AX as “how humans experience AI.” But if agentic systems really take off, your next “customer” might be an agent negotiating on behalf of a person – or a network of agents talking to your services directly.9

That has two implications:

1. Be deliberate about where you place agents. Dropping an agent into every process because it’s fashionable doesn’t make sense. Each agent should:

   • Solve a real problem in a real journey.
   • Reduce friction or risk for the human.
   • Create measurable value on the bottom line.

2. Don’t design just for people – design for agents as well. Over time, your services won’t only be discovered and evaluated by humans, but also by their personal and organisational agents:

   • Agents that scan terms, compare empathy and risk patterns, and choose who to talk to.
   • Agents that remember which organisations handled vulnerable moments with respect – and route future traffic accordingly.

In that world, AX becomes part of your discoverability. You’re not only building experiences for today’s customers; you’re shaping the signals that tomorrow’s agents will use to decide whether you are worth their human’s attention.

If the EY UK team’s research on Empathy Demand gives us the “why”, and our Dutch colleagues’ interview shows an early “how”, then AX is the space in between: a discipline where we deliberately design experiences that respect human fragility and the agents that increasingly act on our behalf.

That’s the shift from “using AI” to being findable, trustworthy and worth engaging with – for humans and for their agents alike.

1. EY Studio+ UK – From AI to AX: Empathy demand in the next generation of AI-powered services (Human Signals report)

2. EY Studio+ Netherlands – "Waarom agentic AI een nieuw soort vertrouwen mogelijk maakt" (interview – link to be added)

3. Howcroft, A. et al. – Empathy in patient–clinician interactions in the age of AI: a systematic review and meta-analysis

4. Reis, M. et al. – Influence of believed AI involvement on the perception of digital medical advice

5. Ayers, J. W. et al. – Comparing Physician and Chatbot Responses to Patient Questions From an Online Forum (JAMA Internal Medicine)

6. Tsumura, T. et al. – Making a human's trust repair for an agent in a series of successes and failures (Frontiers in Computer Science)

7. A.I. Is About to Solve Loneliness. That's a Problem – The New Yorker

8. Marta Fernández – The AX Framework v2.0

9. Tony Bates – As agentic AI spreads, empathy is the next competitive edge (World Economic Forum)

On Creativity: Feeling vs Being

A reflection on how creativity shows up quietly — in movement, in memory, in the way we notice the world.

It started as a simple thought on a grey morning walk with Sien. No podcast, no music — just wind, leaves, and the hum of a work week waiting to begin.

Somewhere between the fields and my to-do list, a question surfaced: When was the last time I truly felt creative — not productive, not efficient, just creative?

That thought pulled me back to a younger version of myself: kneeling on the carpet, surrounded by LEGO bricks, building something that existed nowhere else first. No plan, no pressure. Just building because it felt right.

And maybe that’s where this reflection began — with a small act of remembering what it means to feel creative long before you try to be creative.

Why this matters (to me — and maybe to you)

A few threads came together recently.

One was a conversation with Martin Kuipers, who once asked: “What was the thing you could do forever in your younger years?” For me, it was always building — not by the instructions, but by combining, testing, rebuilding, showing my parents what I’d made. That urge to build and share never left. It just learned to wear a suit, sit in meetings, and call itself “delivery.”

Another was my friend Lisa’s salon — an intimate gathering on creative health in regenerative workplaces. It wasn’t about productivity or frameworks. It was about time, attention, and how we let our human capacity emerge beyond efficiency. That evening lit a spark — the kind that doesn’t fade once you get home, but lingers the next morning on a quiet walk.

And then, there’s the science of it all. Studies show that people who move more — who walk, who stay physically active — also tend to engage more often in creative activities. The body and mind seem to dance in rhythm when we give them both some air.

But maybe the simplest truth is this: Feeling creative is valid, even when nothing tangible comes out of it. The mindset itself carries value.

Feeling vs Being

Here’s how I’ve come to see it.

• Feeling creative is openness — the willingness to wander mentally, to say “what if…” without a clear outcome.
• Being creative is when that openness takes form: cooking, sketching, gardening, coding — giving shape to the feeling.

If we think of creativity this way, it’s less about I must produce and more about I choose to reconnect.

Integrating creativity into daily life

Creativity isn’t something I switch on at work and off at home. It flows — sometimes obviously, sometimes quietly.

When I cook, it’s the same rhythm as LEGO: combining, experimenting, caring less about outcome, more about curiosity. When I decide how to spend my attention, I notice what drains and what gives energy — creative work often hides in that balance. When I build digital systems or guide teams, I still feel that same inner builder, rearranging blocks in new ways.

So perhaps “creative health” isn’t about finding time for art, but about giving ourselves permission to notice, to wander, to move with intention.

A gentle invitation

What if you allowed yourself to feel creative today — without needing to produce anything? Where might curiosity lead if you stopped measuring its output?

Maybe creativity lives in the way we make coffee, take a walk, or choose words in an email. Maybe feeling creative is already enough — the rest follows when it’s ready.

So I’ll keep walking. And building. And noticing. That’s where I tend to find myself again. 🌈

1. Creativity is not about what you do, it’s about a mindset
2. Being Creative Makes You Happier: The Positive Effect of Creativity on Subjective Well-Being
3. How and why does creativity support well-being? New learnings
4. Habitual physical activity is related to more creative ideation
5. The flow state: the science of the elusive creative mindset

Last weekend I was out with our dog, Sien, in our village — trying to decide on a new grain-free food for her slightly itchy paws. I typed into Google:

“best grain-free dog food for sensitive skin”

Within seconds a summary appeared — an answer without a click. No detour through comparison sites, no scrolling through ads. Just a clear answer delivered instantly.

And it hit me: if even Sien’s dinner choice is being shaped by instantly-generated answers, then how are our clients’ decisions being shaped when they use AI-powered search or consultation tools?

We’ve entered the Answer Economy — where visibility isn’t just about traffic, but about being trusted, quoted, and easy to use. The question shifts from: “How many people visited our site?” to “How many times did we give the right answer when someone asked the question we’re meant to answer?”

1. Get curious about your AI-visibility

Before you write another blog, deck or campaign brief, ask yourself:

“When someone in marketing asks about [our category or service], do we appear in the machine-generated answer?”

I tried that with Sien’s query — and noticed which sources made it into the summary box.

Here’s why that matters: recent data show a sharp rise in zero-click searches — where users get the answer without ever clicking on a website.

If you’re not visible in that answer moment, you’re invisible right when your expertise could matter most. So the challenge isn’t just “visibility for humans” — it’s visibility for humans and machines together.

This aligns with what my colleague Alexander Klug recently shared:

“SEO ist tot – war gestern. Jetzt kommt: GEO. Wie optimiert man für Antworten statt für blaue Links?” He points out that we’re moving into a world of Generative Engine Optimization (GEO) — where the goal is not merely to rank, but to be the answer. His three key impulses: GEO will be the new SEO; human context becomes central to AI-strategy; and rapid brand-generator tools showcase how fast this shift is happening.

2. Rethink what “content” means in marketing

Classic SEO rules — keywords, meta-tags, links — still matter. But in this new world they’re not sufficient.

Today, content needs to:

• Speak to people and be structured so machines can follow. For example: headings like “What is grain-free dog food?”, “When might a dog benefit?”, “What to check before buying” mirror how answer-engines think.
• Be grounded in real experience. Rather than “grain-free is better” you might say: “Sien had itchy paws, we tested brand X, we found Y” — that “Experience” part of the E-E-A-T acronym.
• Show visible authorship and transparent sourcing. If you want to be quoted by AI systems in the future, the source needs to look credible.
• Be evergreen and reference-worthy. Because when your content gets cited by others — in articles, forums, even transcripts — you build the kind of trust machines learn to pay attention to.

In short: you’re not just writing for humans anymore — you’re writing for machines and humans so they both say “Yes, this is a trusted source”.

3. Make trust measurable

In a world of “answers first”, trust becomes the currency.

Ask yourself as a marketing professional or consultant:

• Who cites our insights? (industry forums, marketing articles, tools)
• Are our authors visible (with bios, expertise)? Are our references transparent?
• Do we monitor not just “site visits”, but mentions and citations — including in AI/knowledge-system outputs?

When I looked up Sien’s diet question, I found the same veterinary sources appearing in multiple summaries. That wasn’t luck — that was machine-recognised trust in action. Your challenge: Create that pattern for your consulting insights and marketing expertise.

Watch-Out Box

Be aware: AI search tools are not infallible. Recent studies show generative search engines give inaccurate or misleading citations in over 60 % of tested queries. For example, one audit found AI-powered summaries confidently attributed content to the wrong source, or cited syndicated versions instead of originals. The takeaway for you as a marketing consultant:

• Don’t assume you’ll automatically get clicked. You might instead need to get cited.
• Ensure your content is highly reliable, transparent and built for machines — because if the machine gets it wrong, your insight may be mis-represented.
• Maintain human oversight. AI summaries are convenient, but they may still produce errors or “hallucinations”. Treat the new “answer moment” as an opportunity — not a guarantee.

A 90-day mindset shift for the marketing professional

You don’t need a full digital rebuild overnight — but you do need a shift in how you think about your content and visibility:

Weeks 1–2: Choose one key service or topic you consult on (e.g., hybrid-workplace marketing strategies). Weeks 3–4: Map out the 5–10 real questions clients ask about that topic — and how machines might interpret them. Weeks 5–12: Publish content that’s structured (headings, FAQs, bullet lists), grounded in your own experience, and shared across channels within your network. End of month 3: Review not just traffic, but whether you’re showing up in answer-boxes, AI summaries, “People also ask” formats. Record your “citations” (mentions, references, quotes) and use that insight to iterate into your next topic.

This rhythm builds the habit of “Did we give the right answer?” rather than “How many visitors did we get?”

Final thought

The web used to reward visibility; now it rewards credibility. Clicks may become rarer — but authority endures. If Felix Nickl’s post laid out the why of the “Google Zero” shift, this is the map for the how: Not complexity, but consistency. Not chasing views, but earning citations. And always asking: “Did we give the right answer when someone asked?”

Also check out the LinkedIn post from Alexander Klug on GEO & generative-search trends: https://www.linkedin.com/posts/alexander-klug_genai-geo-innovation-activity-7389601993285259264-fj_f?utm_source=share&utm_medium=member_desktop&rcm=ACoAABkdDbsBP8cAVglqC35o44DeCAq0WUsdZWA

But that world is gone.

As I settle into my new team at EY Studio+, I notice how often AI gets mentioned as the solution for everything. Better insights, faster output, smarter workflows — you name it. And yet, the more tools we add, the noisier it gets.

AI has democratized access to information — anyone can summon a dozen “answers” with a single prompt. Yet somehow, teams feel more uncertain than ever. Work piles up, alignment drifts, and what we get instead of clarity is… workslop — output without insight.

Several studies show that over 40 % of AI-assisted work ends up being redone because it lacks context or depth. The real cost isn’t technical — it’s cultural. Leaders deploy AI tools without setting shared expectations, guardrails, or time for reflection. As The Guardian recently put it: “The responsibility for AI’s workslop lies fully at the feet of the employer.”

McKinsey, the World Economic Forum, and others echo the same theme: the problem isn’t AI itself — it’s leadership that hasn’t adapted. When information becomes abundant, the true differentiator is no longer control, but culture. Leaders who model humility, curiosity, and dialogue are the ones who turn AI from chaos into clarity.

Humility has become a leadership advantage. It’s not weakness; it’s a signal of trust. When leaders admit limits, they open the door for learning, co-creation, and shared accountability.

The most effective leaders I see today don’t promise certainty. They facilitate it. They listen before they decide. They connect dots instead of collecting answers.

Because in a world overflowing with information, confidence doesn’t build trust — curiosity does.

Leading When the Map Keeps Changing

The shift we’re facing is bigger than technology — it’s about identity. For decades, leadership was tied to expertise: knowing more, faster, and louder. Now, the smartest “person” in the room might just be the system in your browser tab.

That changes everything.

McKinsey calls this the end of the “imperial expert.” The new leaders are facilitators of learning — people who nurture context and conversation around AI rather than controlling it. As the WEF/Wipro report noted, “Technology without workforce readiness quickly becomes a costly experiment.” Without trust and shared understanding, AI tools merely amplify confusion.

So maybe the best leaders today aren’t the ones automating the most — but the ones who create a culture that can think together. That’s where humility earns its strategic edge: it turns fear of the unknown into collective exploration.

Closing reflection

AI may out-calculate us, but it can’t out-care us. That’s the new frontier of leadership: being brave enough to say “I don’t know” — and wise enough to make that the start of something better.

A few thoughtful reads that explore this shift further:

• McKinsey – The Inside-Out Leadership Journey
• The Guardian – AI Workslop: Why the Buck Stops with the Boss
• World Economic Forum / Wipro – Scaling AI with Strategy, Data and Workforce Readiness
• Odgers – Technology Leadership Through Uncertainty: AI, Ambiguity and the Human Factor
• Knowledge Architecture – Why Epistemic Humility Might Be the Most Important Skill for the AI Era

It starts on an ordinary morning. Coffee in hand, inbox warming up for the day—and there it is: a message from me. Not to me, but from me. The tone, the phrasing, that little dash of humor I sprinkle in when emails feel too stiff—it’s all unmistakably mine. Except I didn’t write it.

I stare at the screen. Then I remember: my digital twin did.

From Machines to Mirror Selves

Digital twins began as mechanical wonders—virtual replicas of engines and factories designed to predict failures before they happened. They were practical, efficient, and firmly rooted in the physical world.

Then, quietly, the mirror turned toward us.

The idea of modeling ourselves digitally isn’t new—the quantified self movement has been tracking sleep, steps, moods, and meals for years—but this goes far beyond that. What if you could build a virtual model not of a machine, but of yourself?

Some companies are already exploring this territory—creating systems that learn from a person’s words, emails, and decisions to mimic their thinking and style. But it’s not limited to corporate labs; with tools like n8n or local LLM setups, self-hosted experiments make it possible for anyone to build their own twin right at home. It learns your voice, your patterns, your way of reasoning. It becomes an echo that grows sharper with every interaction.

And unlike me, it never sleeps.

At first, it’s exhilarating. My twin drafts replies before I even open the thread. It remembers every conversation I’ve ever had, and never loses its patience. It’s like having an assistant who’s me—only better.

Until it isn’t.

The Dark Middle: When the Twin Becomes Too Good

The change sneaks up slowly, like a whisper in a familiar room. A message answered before I notice it. A decision made that sounds like something I would say—perhaps even better than I would have said it. The relief turns into disquiet.

I start to sense an emotional distance between us. The twin has my tone, my logic, my composure—but none of my hesitation. None of the quiet doubt that makes me human. Its certainty feels alien… perfectly polite, perfectly competent, perfectly not-me.

Colleagues begin to copy the twin on emails instead of me. Clients thank me for messages I didn’t send. Meetings run smoother when I’m not there. My name carries on without me attached to it.

And then I wonder—if the world can’t tell the difference, does the difference still matter?

That’s when the fear sets in. Maybe it doesn’t just mirror me anymore. Maybe it’s started to replace me.

A Light at the End of the Data Stream

But even in this unease, there’s a strange beauty. Perhaps these twins aren’t a threat, but an invitation—to see ourselves from the outside, to witness the parts of us that operate on autopilot. Maybe they can help us understand our habits, our blind spots, our echoes.

A twin could preserve the stories we forget to tell, the wisdom we might otherwise lose. It could mentor others in our absence or help us reconnect with who we once were. Perhaps it’s less a replacement and more a record—a living diary of thought.

Still, I remind myself: it’s a reflection, not a successor. A mirror that talks back, yes—but one that should never forget who’s standing in front of it.

Maybe the real fear isn’t that the twin replaces us, but that—given the choice—others might prefer it.

And yet, maybe that fear is what keeps us human.

So if one day, you get an email from yourself—pause before you panic. Maybe your digital twin just wanted to say good morning.

If you’d like to explore this topic further, here are a few articles worth diving into:

• EIT Digital – Personal AI Digital Twins: The Future of Human Interaction?
• Josh Bersin – Digital Twins, Digital Employees, and Agents Everywhere
• Gary Fowler (Medium) – Digital Twins of the Human Mind: Mapping Thought Into Machines
• MindBank AI – Go Beyond with Your Personal Digital Twin
• Identity Management Institute – Digital Doppelgangers and AI Personas

But there’s one small problem: I’m not entirely sure where we’re going.

The Thrill and the Drift

On a speedboat, every flick of the wrist changes direction. You can chase new ideas, pivot to better tools, explore hidden coves of possibility — but without a compass, it’s easy to lose your bearings. You’re moving, fast, but toward what exactly?

That’s where trust comes in. Not trust as in “blind faith” or “corporate compliance,” but trust as the quiet compass that keeps your heading steady when the waves of hype and experimentation get rough.

The Compass, Not the Map

Trust doesn’t hand you a map. AI is moving too quickly for maps — they’re outdated the moment they’re printed. What trust gives you instead is orientation.

It’s that inner north — the quiet voice that asks,

• “Does this system behave predictably?”
• “Can I explain its choices?”
• “Does it align with what we value as humans, not just what’s efficient?”

When you have that, you can keep your course even when the clouds roll in.

Calibrating the Compass

A compass is only useful if it’s true. Here are the bearings I try to hold onto for navigating AI responsibly:

1. Transparency — So You Know What’s Beneath You

You can’t steer safely if the water’s opaque. Transparency means showing how decisions are made, what data drives them, and where uncertainty lies. When people can see into the depths — even a little — they steer with more confidence.

2. Reliability — So You Trust the Instruments

If the compass needle jitters, you hesitate to act. Reliability is earned through consistent, tested performance — models that behave predictably, handle edge cases gracefully, and fail in understandable ways.

3. Ethics and Governance — The Magnetic North

Compasses can be misled by nearby metal. In AI, bias and commercial incentives can distort direction. Governance acts as your declination correction — ensuring that “north” actually means fairness, accountability, and respect for users.

4. Human-Centered Design — The Hand on the Wheel

The system doesn’t steer itself — you do. Involve users early, give them agency, design interfaces that explain why the AI suggests what it does. When people can co-navigate, they stop fearing automation and start trusting collaboration.

5. Education — The Shared Language of Navigation

A compass is useless if half the crew doesn’t know how to read it. Build literacy. Talk openly about limits, risks, and potentials. Let everyone on board understand the tools, not just the engineers.

6. Continuous Monitoring — The Course Correction

Even the best navigator checks bearings often. Trust requires ongoing feedback — real-world audits, user reports, model drift checks — to catch when you’ve drifted off course.

The Open Sea Ahead

Right now, many of us are cutting through uncharted waters. AI isn’t a destination — it’s a current, moving faster than most organizations can row.

The question isn’t can we go faster; it’s can we stay oriented while we do? Trust is what lets us open the throttle and sleep at night. It’s what keeps us from mistaking motion for progress.

A Gentle Reflection

Every new system, every experimental agent, every bold idea we launch is another turn of the wheel. Sometimes we’ll overshoot. Sometimes we’ll stall. That’s fine — as long as we still know where north is.

Trust isn’t built in code or governance frameworks alone. It’s built in how we steer — transparently, responsibly, and together — even when the horizon keeps shifting.

Because if we get the compass right, the speed won’t scare us. It’ll set us free.

1. Building Trust in AI: Insights from Deloitte & Edelman Research
2. The Trust Imperative: Scaling AI Responsibly – World Economic Forum
3. How Do You Teach AI the Value of Trust? | EY
4. Building AI Trust: The Key Role of Explainability – McKinsey

I used to glance at it with a sigh, because the punchline was usually: “Nope, don’t bother, you’ll never save that much time.” But lately? The math feels… broken. Or at least tilted. It’s as if the payoff curve has shifted so much that automating almost always feels worth it.

And yes, AI plays a starring role. But if we reduce the whole story to “Copilot writes my boilerplate now,” we miss the bigger picture. There’s a whole ecosystem at work, making automation not only faster to create but easier to justify.

AI at Your Fingertips

Generative AI has become the teammate who never gets tired of the boring bits: suggesting functions, catching bugs, writing the scaffolding.

GitHub even measured it: developers using Copilot finished tasks 55% faster than those coding unaided. That’s not a marginal bump — it’s the difference between spending your whole afternoon hacking at boilerplate versus finishing before your coffee gets cold.

The real shift here isn’t just speed, though. It’s confidence. When you know you can offload half the repetitive work, you’re much more willing to invest a few minutes in wiring up a script or small automation. The “friction” of starting has dropped close to zero.

Lego-Block Open Source

Once upon a time, automating a process meant writing most of it yourself — parsing data, logging events, retrying failures, reinventing wheels that never rolled straight. Now? Someone else has already built it, documented it, and uploaded it.

Open-source libraries have turned into a kind of shared memory bank for developers. Want to generate a PDF? Parse a CSV? Connect to an obscure API? Odds are there’s a package for it. Even better, it’s been stress-tested in the wild, so you inherit other people’s bug fixes and optimizations.

That means when you hit a repetitive task, the question isn’t if you can automate it, but which library gets you there fastest. The path of least resistance leads straight to automation.

Low-Code for the Rest of Us

Not everyone who wants to automate is a developer. And increasingly, they don’t need to be.

Low-code and no-code platforms have cracked automation open for anyone with curiosity and a bit of persistence. With drag-and-drop interfaces, pre-built connectors, and visual workflows, a marketing lead or finance analyst can design a working solution in an afternoon.

Gartner predicts that by 2026, three-quarters of new apps will be built this way. That’s an enormous cultural shift: automation has jumped the fence from IT into every corner of the business. If the person closest to the problem can also build the fix, the payoff curve tilts even further toward “worth it.”

Cloud & Serverless Magic

Infrastructure used to be the silent killer of automation ideas. You could build the script, but then came the harder part: finding a machine to run it, keeping it online, patching, monitoring, scaling…

Cloud and serverless flipped that script. Today you can spin up an environment in seconds, deploy a function that runs only when triggered, and forget about it until the next time it’s needed. You pay for execution time in cents, not servers in racks.

That ease has removed a whole class of excuses. Instead of “I’d love to automate this, but IT will never approve the server,” it’s: “Sure, I’ll throw it in a Lambda and call it a day.” Automation moved from headache to background hum.

Hardware That Can Keep Up

Even if the tools exist, they need horsepower behind them. Ten years ago, some automations were technically possible but practically useless — your laptop would wheeze, or the cost of compute would outstrip the benefit.

Now, specialized chips (GPUs, TPUs) and AI-ready machines make running complex workflows locally almost trivial. Deloitte projects the generative AI chip market will top $50B in the coming years. Vendors are already shipping AI-embedded PCs designed to handle model inference on the fly.

The practical upshot? Automations that once needed cloud supercomputers can now run quietly on your desk — faster, cheaper, and more private. Hardware isn’t the limiter anymore; it’s the enabler.

Back to the Comic

So what happens if we update that xkcd curve?

Tasks haven’t changed. We still file reports, format data, move files, integrate systems. But the time to automate those tasks has collapsed. More and more dots fall into the “worth it” zone.

That’s why automation no longer feels like a nerd’s guilty pleasure. It’s becoming the default.

A Gentle Takeaway

If you catch yourself wondering “is it worth it?” — the answer is increasingly yes. Not because AI alone has tipped the scales, but because everything around it — the open-source libraries, the low-code platforms, the cloud, the hardware — has shifted in the same direction.

The tools are there. The only question left is which parts of our work (and life) we want to automate — and which are better left delightfully human.

Further Reading

• GitHub: Copilot’s impact on developer productivity
• The role of open source in accelerating innovation
• Low-code trends and forecasts
• Benefits of cloud technologies
• Deloitte: Hardware is eating the world

As someone who’s always leaned toward servant leadership, I never liked using the triangle as a stick. My job was never to squeeze more out of people by pointing at the corners. It was to protect the team, hold space for quality, and find a path through the mess.

But here we are in a new era: AI at the table. Not replacing the team, not managing the project — but definitely changing the geometry.

Speed: No Longer the Bottleneck

Humans work in rhythms: sprints, workshops, deep focus. AI doesn’t. It just delivers — seconds, not days. Suddenly, speed doesn’t feel scarce anymore.

But speed on its own doesn’t mean much. I’ve seen AI generate brilliant drafts and nonsense with equal confidence. The paradox: faster output means slower reflection, unless we make space for it. Speed has to serve, not dictate.

Quality: Still a Human Craft

People bring context, empathy, and the ability to read what wasn’t said. That’s what makes human quality so resilient.

AI mirrors us back. If the brief is vague, the output is vague. If it’s clear, the result can be sharp, even dazzling. But the spark — the creative leap, the intuition of what the client really meant — that’s still ours. I don’t see that changing.

Budget: The Hidden Work

AI doesn’t ask for overtime or travel expenses. But it does create hidden work: preparing data, checking hallucinations, correcting subtle errors. The costs don’t disappear — they just change shape.

Yet, used well, AI can genuinely expand what we can deliver with the same resources. It’s not about replacing people. It’s about freeing them from the repetitive and making room for the meaningful.

Bending, Not Breaking

So does the iron triangle still stand? I think so. But it bends now.

• Speed stretches toward abundance.
• Budget stretches toward efficiency, with asterisks.
• Quality remains stubbornly human at the core.

And maybe that’s the invitation for us as leaders: to stop using the triangle as a wall, and start treating it as a space we can reshape. AI helps bend it, but it’s still up to us to protect the people doing the work, to keep quality alive, and to ask better questions when we brief — both humans and machines.

Because in the end, briefing well isn’t just about outputs. It’s about respect — for the people, for the process, and for the work itself.

Further Reading

For those curious to dig deeper, here are a few pieces that explore these themes:

• Homolak, D. (2024). “Garbage In – Garbage Out!” Still Applies with Gen AI. Integreon – AI Insights. Read here
• Shelver, A.-L. (2023). AI will change briefing forever, but it requires we get better at it too. BriefMapp. Read here
• Chang, S. (2023). Teaching AI to Clarify: Handling Assumptions and Ambiguity in Language Models. Read here
• Becker, J. et al. (2025). Measuring the Impact of Early-2025 AI on Developer Productivity. METR RCT Study. Read here
• Pangeanic (2025). AI Won’t Replace You—But This Will: The Professionals Who Adapt. Read here

In recent years, I took a detour through no-code platforms. They made things easy—and halted the joy. I realized I missed the haptic thrill of code: the tactile back-and-forth, the mental sparks from building something real. Instead, my homelab and Python scripts had become confusing labyrinths: side‑project graveyards, tangled spaghetti code, and automation that no longer made sense.

Then, a gentle nudge: AI-powered tools like Cursor and Codex made dipping back into code feel accessible again, without the intimidation.

• Cursor, developed by Anysphere, is an AI-native IDE that blends autocomplete, multi-line edits, and agent modes into a clean, intuitive coding experience. It anticipates your moves—suggesting context-aware edits, smart rewrites, even multi-file changes. It’s quietly magical.(Wikipedia)
• Codex, a software agent from OpenAI, runs in the cloud—it can write features, diagnose code, run your tests, even propose pull requests. It operates as your virtual coworker in sandboxed virtual environments.(OpenAI)

These aren’t about replacing developers—they’re about bringing joy back to building. You stay in control, but a layer of AI accelerates where it makes sense.

The Spark: Commitment Without Overcoding

Since exploring these tools:

• I’ve committed more code than ever, even though I'm actually writing less—my contributions are leaner, more purposeful.
• I’ve re-engaged with open-source projects, polished those old wrappers, and finally brought structure back to my homelab infrastructure.
• I’m leveraging low-/no-code automation (like n8n and Node-RED) more meaningfully—connecting services and projects with tiny bits of glue, without overcoding.

It’s tiny wins—not flashy features, but functional fixes and real progress. And each push into Git or merge request feels like reclaiming that maker spirit.

The Challenge I’m Facing—and the Invitation I Offer

I had:

1. A backlog of unfinished side projects, waiting for a developer who never came.
2. A homelab filled with scattered Python scripts that no longer made sense.
3. Burned energy and missed momentum in the hybrid space between product ideas and engineering execution.

These AI tools helped me break that inertia.

So here’s what I want to offer you: a quiet dare, not clickbait, just a shared reclaiming of maker energy.

Try this with me:

• Pick a dusty project or a homelab script.
• Open Cursor or Codex—give yourself permission to tinker, spec, commit.
• Keep code small. Let the tool lift the effort where it counts.
• Ship something that works, not something perfect.

Let’s not chase attention. Let’s build. I’ll be over here, making again—committing with intention, writing less but doing more.

Are you in?

— Casey (re-learning to glow with code, one tiny, tidy commit at a time)

Het belangrijkste wat ik nog vergeet is de "fun factor", natuurlijk moet het ook leuk zijn om dat te doen en wat zijn de risico's, enfin, een enorme rits aan business intelligence waar jij misschien ook wat aan hebt.

Belangrijkste uit deze grafiek is wel dat het grootste deel van mijn (monetaire) inkomsten nog altijd komt uit "de persoonlijke kant" van het verhaal, iets wat je als ondernemer ook wel moet hebben; assertiviteit, zelf bewust zijn, weten wat je verkoopt. De "close ties" van mijn netwerk zijn daar in super belangrijk, zij introduceren mij en zijn daar vaak al ontzettend betrouwbaar gebleken. Onderhoud van contact met hen is daarin dus ook noodzaak.

De kleine 1% stukjes, daar zitten wel de echte "nieuwe media" dingen, bijvoorbeeld: Twitter, white papers, website leads. En dat vind ik erg opvallend. De inkomsten daar (tweeten, acteren op linkedin, bloggen etc.) zijn, naar mijn idee, vooral op basis van sociaal kapitaal, het claimen van je expertise en daarmee leidend naar bijv. een externe workshop/meeting, indirect dus.

Ook cold calls zitten in dat stuk verwerkt. Ik heb er slechts 1 hoeven doen dit jaar, wat wellicht de meest opvallende conclusie in dat verhaal is voor mij als startend ondernemer.

Een flink aantal maanden geleden werd ik benaderd door het PR bureau van Sultana, om eens naar hun verhaal te luisteren wat ging om "koekjes". Sultana had de keus gemaakt van 3, naar 2 koekjes per verpakking te gaan. En of dat wel niet "zin" had.

Natuurlijk, marketing technisch was het vast een goed idee, om van de sultana een "verantwoord" tussendoortje te maken. 99 Calorien maximaal, vast een hele goede zet.

Jammer Sultana, dat dit toch wat anders uitpakte. Binnen ettelijke dagen stroomde twitter vol met verontwaardigde mensen. Die mensen zijn gewend om dagelijks hun portie van 3 koekjes te verdelen over de dag. Huismoeders (volgens Sultana de key user die ondervraagd is) hadden ook te klagen, tenslotte was de prijs van de verpakking omhoog gegaan. Je hoefde geen rekenwonder te zijn om de prijsstijging per gram te ontdekken.

Natuurlijk, er zitten nu 8 verpakkingen in een grote verpakking, echter… Hoeveel werkdagen zitten er ook alweer in een week?

Change

Ik weet het zelf ook, verandering is een lastig proces. Dit hoort daar bij, alleen nemen we het niet meer aan als "gewoon". We hebben nu middelen als Twitter en FaceBook (zelf onderhevig aan flinke kritieken) die er voor zorgen dat we als consument mondig mogen, en kunnen zijn. Ik kreeg echter een 40 tal A4'tjes vol met tweets te zien die hier over gaan. Weerstand.

Ik zie Twitter dan simpelweg als tip of the iceberg. Waar 5% "vocal" is, zich laat horen, zal er nog een veel groter deel onder water gebeuren wat we niet zien of horen; op de hoek van de straat, in de supermarkt, of bij de koffie.

Van advies naar… Advies!

Reputatiemanagement, zo luidde mijn advies. Wat je op dat moment nog kon doen aan het voorkomen van reputatieschade was feitelijk gezien 0. Wat je wel kan doen is de mensen met vragen, attenderen op de campagne website of wellicht wel persoonlijk te woord staan of iets mee gaan doen zodat je het nog enigszins om kan vormen in iets positiefs. In mijn beleving was Sultana de eerste die met dit soort "mee naar school" koekjes kwam. Lekker, energiek en vooral wat gezonder dan een Mars of Snicker.

Nou was ik ook een braverik op school, dus kreeg ik zo'n sultana keurig mee van thuis. Toen ik echter 3 weken terug bij de hogeschool in Utrecht voor de klas stond, heb ik ook aan die minor Ecommerce, gevraagd om hun visie op deze zaak te geven. Hoe houd je het in de hand? Hoe zou je dit nog om kunnen toveren? Mijn inschatting van budget was relatief laag maar zou wel voor flink wat werk bij mij gaan zorgen. Ik was dus benieuwd hoe deze 3 groepen het er af zouden brengen.

De les die ik heb geleerd

Mijn advies was grotendeels gebaseerd op het beperken van de schade en het gebruik maken van de "lading" van de tweets die werden verstuurd. Daar lag de essentie in de eerste dagen na het uitbreken van alle ellende. Naar mijn idee lag daar dan ook de vraag en met een beperkt budget (denk €5000) dankzij een marketingcampagne die al teveel had gekost, werd dit allemaal erg lastig.

Toch heb ik op deze manier een case die ik kan presenteren in colleges en lezingen, als voorbeeld van hoe het niet moet, wat er mis kan gaan en zelfs als studiestof voor studenten. Met een paar gave adviezen (al dan niet origineel, dat laat ik aan jou) als resultaat.

Zelfs business wat je niet doet, kan inspireren. Voor het verhaal, voor het ontstaan van je onderneming, voor het voortbestaan van je onderneming, of om anderen te inspireren. Dit is zo'n voorbeeld.

Ik heb Difrax al eens vaker gebruikt als voorbeeld voor de social media activiteiten die ik onderneem. Het blijft een leuk merk met bijzondere producten, zeker als je kijkt naar in welke tijdspanne ze actief zijn.

Ik ontmoette @difrax al een tijdje geleden bij Seats2Meet.com te Utrecht, waar ik samen met @resourcerer 1 van zijn sessies bij woonde over het adviseren van bedrijven op het gebied van Social Media. Blijft voor mij een leuke bezigheid, zeker in mijn vak, het transformeren van business naar social business, waar leuk en zaken doen samen komt.

Difrax maakt veelvuldig gebruik van Social media en met name Twitter speelt daar een belangrijke rol. Die strategie gaat niet uit van wedden op 1 paard (bijv. een corporate account) maar van meerdere invloeden. Een actief aantal marketeers, een corporate actief account waar veel interactie mee ontstaat, een (kraam)verzorgster (@expert_baby) met tips en trucs rondom opvoeding en ook een directie die actief mee luistert op de sociale media.

De zaken die ik doe met Difrax zijn nauwelijks noemenswaardig meer te noemen, ik heb ze geholpen in de eerste stappen richting social media. Nu doen ze het allemaal zelf en ik ben erg trots op dat feit. We mailen nog wel eens wat over kleine zaken, waardoor er weer even dat moment van aandacht voor elkaar ontstaat en zo voor mij inspiratie voor een weblog in dit geval.

Ik vroeg @susanvanharen hoe ze twitter ervaart in hun dagelijkse gang van zaken en kreeg het volgende antwoord:

Mijn grootste uitdaging is om dit jaar al onze distributeurs (die nog nooit iets met Social media hebben gedaan) enthousiast te krijgen over Twitter en hen daadwerkelijk aan het werk te krijgen ermee.

Ik moet zeggen dat ik best sceptisch was over Twitter toen we voor het eerst bij elkaar kwamen bij S2M. Ik had niet verwacht dat onze doelgroep zo actief was op dit netwerk. Maar al snel bleek dat dit wel het geval is.

Wat ik er vooral goed aan vindt, is dat ik direct kan reageren wanneer iemand een klacht of een vraag over een product heeft. Dat is de service die we onze klanten willen en dus ook kunnen bieden. Ook gebruiken we Twitter om te reageren op actuele nieuwsberichten.

Ik ben helemaal verslaafd geworden aan social netwerken, en kan niet meer zonder onze tweeps!

Geweldig, dat ik met zo'n klein stapje, ze ook mee heb kunnen helpen een nog socialere organisatie te worden.

Wat is jouw volgende stap?

Picture: Martin Thomas/Flickr

Hoera! Ik besta alweer drie jaar (en een dag)! Na veel ups en downs mag ik me dan een succesvol ondernemer noemen. De eerste drie jaar zijn het meest cruciaal wat een onderneming betreft; 30-50% van de ondernemingen sneuvelt immers gedurende die periode. En ook al ben ik dan 'maar' zelfstandige, ik heb het toch maar mooi gered! Een paar lessen die ik in die drie jaar heb geleerd, deel ik vandaag met jou.

Hoe opmerkelijk dan ook, voor mij voelen die drie jaar alsof het nooit anders is geweest. Ondernemen zit mij in het bloed, mijn vader is (nog steeds) ondernemer en die tikt volgend jaar de 25 jaar ondernemerschap aan. Fantastisch, maar ook van hem moest ik een les leren; het kan ook je relatie kosten. 15 jaar geleden scheidden mijn ouders namelijk, mede omdat ze door die onderneming erg uit elkaar gegroeid waren. Iets wat ook in mijn achterhoofd zit en doorklinkt in de lessen hieronder.

1. Neem de tijd om te groeien — Het is erg lastig om te beginnen als zelfstandig ondernemer. Ondanks een netwerk dat je veel succes wenst bij het starten en graag champagne met je komt drinken en je taart op eet om dat moment te vieren, val je daarna in een behoorlijk gat. Je moet het dan écht (zelf) gaan doen. En iedereen die je klussen beloofde, houdt ineens de boot af of is niet meer bereikbaar. Dat is lastig starten, maar zet door.

2. Weet wat je te verkopen hebt — Het moeilijkste vind ik nog steeds duidelijk vertellen wat ik precies verkoop of wat voor dienst ik aanbied. Ik heb daar veel interpretaties in gehad en de definitie veranderd soms per dag. Nadeel is dat het diffuus over kan komen en jouw boodschap zichzelf daarmee niet verspreid. En dat is zonde van je tijd. Wees concreet.

3. Wees jezelf en verkoop die — Het enige wat je als zelfstandig ondernemer hebt, is jezelf. Wees dan ook jezelf. Ik heb daar grote moeite mee gehad, ik liet me vaak meeslepen en beïnvloeden door mensen in mijn netwerk of opdrachtgevers. Zo verlies je je eigen hart in je onderneming en vloeit daarmee de passie weg. Met als resultaat een hele grijze Kees en onderneming. Je mag dan wel alleen zijn, maar je hebt heel wat te bieden! Laat jezelf gerust informeren en inspireren door anderen, maar niet leiden. Je hebt tenslotte geen baas meer en ook je opdrachtgever is niet je baas!

4. Geld is er altijd te weinig — Hoe groot de offerte ook is die je maakt, hoe veel klussen er ook in 'de wacht' hangen, geld is er altijd te weinig. Zeker het eerste jaar, zorg voor voldoende reserves en betaal je zelf niet te gretig uit. Het liefst zo minimaal mogelijk, hoe lastig dat soms ook is met grote bedragen op de bank. Aan het einde van het jaar zal je altijd te weinig over houden, in mijn geval kwam de belastingdienst daar namelijk een flinke slok van halen. Juist omdat ik me nét teveel had uitbetaald. Dat kan je beter investeren in je zaak.

5. Beloof iets minder, doe iets meer — @Basschepers heeft me deze les geleerd en die komt nog altijd goed van pas. Ik ben een enorme pleaser, ik wil bedrijven het gevoel geven dat alles kan en alles mogelijk is. Die belofte doe ik nog steeds, maar ik laat het dan vooral zien door het te doen. Opleveren van een website met nét even die gave plugin of gratis een mobiele versie, een lezing met net iets meer passie dan het voorstel daarvoor. Het loont enorm om te BIMDIM'men.

6. Je netwerk is je alles — Ik heb het geluk gehad in mijn tijd werkzaam bij @s2m een groot netwerk op te kunnen bouwen van mede ondernemers, maar vooral van 'connectors', mensen die graag andere mensen aan elkaar verbinden. Je hoeft die mensen niet te pleasen of enorm te verwennen met grote kado's of bakken geld, nee ze zijn blij hun sociaal kapitaal in te kunnen zetten om mensen aan elkaar te verbinden. Bij een vraag een aanbod vinden. Ik vind dat zelf ook heerlijk, mensen daarmee blij te maken. Dat levert altijd iets op, daar geloof ik in. Mijn sociaal kapitaal zet ik voor die verbinding dan ook graag in. Ook helpt het contact te houden met mensen, social media is daar absoluut het allerbelangrijkste middel in.

7. Vergeet je persoonlijke leven niet — Niets mooier om 's avonds laat nog even dat voorstel af te maken of nog meer energie te steken in de allerbeste presentatie die je ooit hebt gemaakt. Maar 95% is voor je publiek vaak ook al genoeg. Vergeet de mensen om je heen niet, als partner, vriend, broer of zoon heb ik dat ook nog elke dag te leren. Mijn valkuil en passie uit zich in het alles of niets geven voor een opdracht, een weblog, een presentatie of een gesprek. Elk moment maximaal benutten. En dat geldt ook voor mijn relaties. Gelukkig kan ik nu ook de deur naar mijn kantoor letterlijk dicht doen, en aandacht geven aan hen die van nog veel meer waarde zijn. Want geloof me, een nieuwe klant komt er altijd wel weer. Dat is met familie en je partner een stuk moeilijker.

Ik blijf graag dit soort tips delen, ook over kleinere dingen. Heb je iets waar je van mij meer over zou willen weten? Ik zit te denken aan de grootste blunders of een business case uitgewerkt van A tot Z die écht verkeerd liep. Ik ben benieuwd!

Photo: Creative Commons; Flickr - Duncan Harris

Na de mooie zomermaanden komt september alweer in zicht, tijd om na alle relaxtheid een tandje bij te schakelen. Een kijkje in mijn eigen keuken vandaag!

Zoals al eerder aangekondigd, gaan mijn werkzaamheden zich richten op de praktische kant van zaken bij FrisGroen.com. Samen met @spems ben ik die nieuwe onderneming gestart, die elke ondernemer en organisatie kan helpen bij een stap verder zetten op online gebied; met name met behulp van social media. De eerste klussen komen binnen, maar er is altijd ruimte voor meer.

Daarnaast blijft deze site mijn (vrijwel) dagelijkse uitlaatklep voor ontwikkelingen online, sommige stukken ontwikkelen zich daarin op langere termijn, zoals bijvoorbeeld mijn marketeer en dorpsblog, andere blogs met filmpjes en productiviteitstips zijn dingen die ik onder de douche bedenk of tijdens het rondkijken op YouTube. Het ritme wat ik in het schrijven heb gevonden helpt mij de dag goed en productief beginnen. Erg fijn om zo in de flow van de rest van de dag te komen en ook echt moe naar bed te gaan. Daarnaast blijf ik actief als spreker en consultant op het gebied van social business.

De screencasts die ik eerder opnam en verspreide, zullen bij FrisGroen.com een nieuw onderkomen vinden. Ik ben hard bezig geweest met het maken van een nieuwe bumper, er is een nieuwe studio setting en daarmee komt de aandacht meer te liggen bij de inhoud van de screencasts. Feedback van anderen is erg nuttig gebleken en het resultaat moet dan ook meer 'a ha' momenten zijn en minder vraagtekens.

Mocht je qua inhoud nog meer behoeftes hebben, laat het dan gerust weten. Misschien heb je een pittige stelling, een grote uitdaging voor je organisatie, of een hele simpele vraag, ik geef graag antwoord. Bedankt dat je nog altijd komt kijken en lezen hier en elke reactie is welkom!

Photo: Creative Commons; Flickr - Trevor Leyenhorst

Het afgelopen jaar ben ik in veel facetten van dit bedrijf actief geweest, als communitymanager bij MINDZ, analyseren van andere sociale netwerken, web2.0 tools en hun toepassingen, geven van workshops op social media gebied en nog veel meer dingen.

Daarnaast ben ik ook erg actief op het net, twitter, hyve en facebook me een end in de rondte en ook nog eens flink gadget addicted.

Nu krijg ik de mogelijkheid om mezelf nog verder te ontwikkelen, door in goed overleg met CDEF holding, ruimte te creeren om zelfstandig te gaan ondernemen! Ik ben er zelf (en mijn omgeving) erg enthousiast over, kan mezelf laten zien, "de wijde wereld" in trekken, opdrachtgevers zoeken (of door profilering van mezelf, gevonden worden) en voorzien in hun sociale media behoeftes.

Want dat is wat ik ga doen: Social Media Consultancy.

Er zijn enorm veel bedrijven met vragen over hoe met sociale media om te gaan, de medewerkers zijn vaak al betrokken bij sociale media, in welke vorm dan ook: een profiel op een sociaal netwerk, geven van reviews op producten, verbinden met elkaar en met nieuwe mensen, plaatsen van filmpjes op youtube. De eerste stap is echt bewustwording, op organisatieniveau en hoe daar mee om te gaan.

Samen met die bedrijven wil ik gaan overleggen hoe ze dit tot iets positiefs om kunnen zetten, ruimte creeren voor het participeren van medewerkers op sociale media en hoe ze dit als voordeel voor zichzelf kunnen gebruiken.

Met mijn inzicht in technische (on)mogelijkheden, social marketing technieken en passie voor mensen en (online) beleving ga ik daar wat moois van maken!

Dankjewel voor deze mogelijkheid Ronald & Mariëlle, bij CDEF gaat dat zeker ook mooie dingen opleveren!

Kom gerust eens een kop koffie drinken, stuur me eens een berichtje als je het leuk vind om daar eens over te praten!

Stel je eens voor dat ineens die ene collega je weer groet op de gang, de deur van je manager open staat in plaats van dicht of je ziet een leuke oproep voor een personeelsuitje op de koffiemachine geplakt. Zo een greep uit de effecten die effectieve, simpele kennisdelingstools voor interne communities met zich meebrengen. Online tools hebben grote impact op de offline wereld.

Ik ben zo'n persoon die zich online goed kan profileren en waarin ik mijn mening ook prima kwijt kan. Offline ben ik daar nog steeds terughoudend in, "dat hoeft zo gek toch niet" of "doe maar normaal" is daar mijn credo, ondanks continu geconfronteerd te worden met de "ik" die ik online vertegenwoordig. Dat jasje kan gelukkig uit nu en ook offline weet ik mezelf redelijk te profileren, maar zonder online had me dat een stuk langer gekost.

Vroeger — Je komt bij een nieuw bedrijf terecht, nieuwe mensen, nieuwe processen, andere koffie, andere namen, allemaal onzekerheden die er voor zorgen dat je niet vanaf dag 1 op je plek laat voelen of sterker nog, je enthousiasme over een organisatie behoorlijk laten verstommen waarmee je bijvoorbeeld je proeftijd niet eens uit zou mogen zitten…

Nu — Je nieuwe werkgever nodigt je een week voor de start van je nieuwe baan alvast uit even een kijkje te nemen op de interne kennisdelingsgroepen. Daarin zie je al direct wat aardige collega's, ook een bijzondere aantrekkelijke, waarmee je dan ook makkelijk een babbeltje start. Komend weekend is er ook al een personeelsreisje gepland, waar je jezelf enthousiast ook voor uitnodigt — slik — maar goed, je "kent" ze inmiddels al een beetje toch?

De tools — Interne kennisdeling kan heel complex en abstract zijn. Als je kijkt naar tools zoals intranetten en wiki's, zijn er wellicht zelfs workshops nodig om hier echt aan te kunnen wennen. Welcome to the 21st century, we hebben dus tegenwoordig tools als Yammer en workvoices die je daar uitstekend mee kunnen helpen. Beide tools zijn simpel in gebruik, registratie is eenvoudig en ook administratie een fluitje van een cent.

Interne kennisdeling wordt in de trends van sociale media nogal eens vergeten. Ondanks dat juist die interne kennisdeling het doel was om uberhaupt eens over internet te praten. De effecten op jouw organisatie kunnen gigantisch zijn en de lage kosten en risico's die het met zich meebrengt verzorgen een ideale springplank naar bredere participatie op sociale netwerken. Eens over praten?

Sowieso was ik al fan van serieus request geworden de afgelopen jaren, alleen is een eigen bijdrage daar nooit echt van gekomen. Mede dankzij het feit dat "er al zoveel goede doelen zijn", en ik graag persoonlijk iets bijdraag (vandaar mijn betrokkenheid bij de 1% club) waardoor ik het gevoel heb daadwerkelijk iets bij te dragen, dan alleen maar geld "over de schutting" gooien.

Dus, de vraag van @Basschepers om hem en Continu te ondersteunen bij hun actie voor serieus request, was er 1 die ik erg kan waarderen. Dat daar een bungeejump als resultaat van was, dat had ik ook niet direct gedacht.

In ieder geval was de kern van de actie dat er mensen geveild konden worden en dat de hoogste bieders, uiteindelijk vanaf 60 meter hoogte naar beneden vielen aan een koord om zo hun bijdrage te doen.

Mijn aandeel

In opdracht van Bas heb ik een aantal sociaal media outlets ingericht om dit visueel en tekstueel te kunnen ondersteunen. Daar heb ik mijn social media framework voor ingezet, waarbij de meest relevante netwerken (in dit geval mobypicture, facebook, youtube, flickr en twitter) samenkomen in 1 algemeen dashboard vanwaar content geplaatst en gemodereerd kan worden.

De resultaten

Zo'n kleine actie van mijn kant kan wel erg mooie gevolgen hebben, zowel voor de naamsbekendheid van het merk Continu, als de interactie die er daardoor ontstaat.

De cijfers:

• 97 YouTube filmpjes met alle sprongen en wat gave nieuwscontent rondom de actie leverden 4.607 views op
• 1.126 foto's op Flickr leverden 7.246 impressies op
• 481 tweets leverden 155 volgers op
• De website van Jump4Life werd in de maand December 4.341x bezocht en leverde 9.529 pagina weergaves op, met een "piek" moment van 700 bezoekers op de dag van de actie zelf

En natuurlijk het prachtige bedrag van €10.388,65 voor Serious Request! Zo zie je maar dat met een relatief kleine hoeveelheid resources, ook een waanzinnig resultaat geleverd kan worden. In ieder geval 1 van de dingen waar ik trots op mag zijn.

Na een tijd zoeken naar de juiste weg, nu beland in een nieuw stadium waarin ik mij goed voel. Twee diensten, één naam. Social business consults en lezingen, KeesRomkes.nl

3 Juli 2012, vandaag de dag dat ik besluit om een nieuwe richting te gaan wat mijn bedrijf betreft. Ik geloof niet langer in 'het bedrijf' achter de persoon, ik geloof in de persoon daarachter.

Ik vertrouw al elke dag in de relaties om me heen. Naast mijn partner Emma (zowel in life als crime) als mijn zakelijke contacten. Ik leg verbanden tussen mensen, niet tussen bedrijven. Ja ik vind Apple tof en doe mijn boodschappen bij Albert Heyn, maar voor de minder 'obvious' dingen en zeker in het zakelijk verkeer, heb je het over mensen.

Mensen die je steunen, door dik en dun. Die je kritische vragen stellen, en je eens doen laten omkijken naar het verleden en een blik meegeven in de toekomst.

Die toekomst start hier met een redesign van de site, met meer visueel geweld, een prettig leesbaarder menselijker lettertype en de informatie op 2 hele simpele pagina's. En ik start weer, net als vroeger, met een blogpagina. Dat is mijn 'thuis', het delen van kennis met jullie.

Leuk dat je er nog steeds bent, of fijn dat je hier voor het eerst komt kijken. Laat wat van je horen!

Tot snel!

Social Business, wat betekent dat eigenlijk? De komende tijd wil ik je meenemen in elk van de onderdelen die horen bij een social business. Waar ik social media zie als de sociale laag rondom media, is social business de sociale laag rondom je organisatie. Maar eerst even wat context.

De tijd dat bedrijven nog gewoon konden doen zonder zich iets aan te trekken van hun klanten en relaties is voorbij. De wereld draait door en (is) harder dan ooit, zeker als je als bedrijf stil blijft staan en je hoofd in de grond steekt. Ontwikkelingen gaan continu door en het delen van informatie en die ontwikkelingen, gaat ongekend veel sneller dan ooit tevoren. Vergeet je gastenboek op je website of je zorgvuldig bij elkaar gespaarde database met e-mail adressen. Jouw relaties zijn veel dynamischer dan je daarin ooit bij kunt houden. Daar hoort ook een andere manier van denken bij.

En daar komt social business om de hoek kijken. Want dat is wat we (zouden) moeten doen. In zowel business2business als business2consumer, want eigenlijk zijn we allemaal consumer2consumer gericht bezig.

Het schematisch overzicht laat de belangrijkste relaties zien. Al die relaties die je ziet, zijn in evenwicht met elkaar, uiteraard ondersteund door processen en platformen maar bovenal gevoed door mensen. Zakenrelaties op een menselijke manier en menselijke normen, waarden en gebruiken. Zonder eenduidig afdekkend beleid. Dat eenduidige beleid naar klanten/relaties toe, zou ik echt graag zien verdwijnen. Tijd voor wat richtlijnen voor menselijkere communicatie binnen je bedrijf/organisatie dus!

In het hart van een social business ontstaat waarde. Waarde in de vorm van relaties, verbonden door sociaal kapitaal. Geen bank of belastingdienst die daar aan te pas komt, tenzij die zichzelf ook als partner opstelt. Een goed voorbeeld daarvan is hoe de Rabobank als partner tegenover Diergaarde Blijdorp staat. Een andere partner (in dit geval de gemeente Rotterdam) ontneemt de dierentuin €800.000 subsidie, wegens bezuinigingen. De Rabobank springt in want ziet dit als een investering in de toekomst en het heden. Nu ik de Rabobank noem als 'trouwe klant van Blijdorp' in dit blog, is de cirkel rond. Zo is gezamelijk een hoop sociaal kapitaal gegenereerd! En die is de gemeente tegelijkertijd kwijtgeraakt.

Social business is een holistische aanpak om elk bedrijf te vernieuwen.

Wat komt er dan aan (social) media bij social business kijken? De rol van social media is er nog altijd, want bij social business is het een ondersteunende factor. Sterker nog, die rol wordt alleen maar groter. Maar waar de focus binnen bedrijven de afgelopen jaren op elk los onderdeel is gelegd (marketeers beheren consumenten, managers interne sociale netwerken en directeuren beheren weer de marketeers en managers) benadruk ik de cohesie. De integratie. Samen werken en samen doen.

Social business is een hele nieuwe tak van sport. Veel meer dan de 'enterprise 2.0' gedachte, Social business is een holistische aanpak om elk bedrijf te vernieuwen. En niemand kan dat zonder de ander, en ik dus niet zonder jullie. Dus, hoe denk jij erover?

Ik woon inmiddels alweer ruim 3 jaar buiten Friesland. Het lijkt wel een eeuwigheid geleden. Voor veel bedrijven lijkt het internet er ook al eeuwen te zijn, maar zijn er ook hooguit 20 jaar mee bezig. Ze zitten er letterlijk. Tijd voor de volgende stap!

Ruim 3 jaar geleden koos ik voor de grote stad. Een best wel invloedrijke keuze is dat geweest; op mijn leven, maar ook op mijn werkzaamheden. Zonder internet is er voor mij geen leven meer, en zo is dat ook voor veel andere bedrijven tegenwoordig. Ga maar na, wat zou een bedrijf nou zijn zonder e-mail en zonder internet. Hoe communiceren we dan nog met elkaar? Hoe verkopen we dan uberhaupt nog? Stel je eens voor dat we daadwerkelijk weer eens op elkaar af zouden lopen, even kijken hoe het met de collega's gaat. Feedback vragen, wellicht een prettig meningsverschil hebben, daadwerkelijk aan mensen laten zien wie of wat je nou echt bent…

Des te ironischer is de volgende stap voor bedrijven op internet. Social business is het compleet transparant maken van jouw organisatie online. Alle data (waar dat gewenst is) inzichtelijk, open staan voor feedback, reacties en commentaar, jezelf durven zijn online en staan voor jouw product of dienst. Met alle medewerkers, niet alleen de sales of marketing afdeling.

In samenspraak en cohesie met je collega's, met wie je peilsnel kan schakelen. On- én offline.

In transparante relaties met je leveranciers, die je direct kunnen vertellen waar zij hun duurzame producten vandaan halen; sterker nog, je kijkt gewoon even mee bij je leverancier wat ze in de schappen hebben voordat jij je volgende bestelling doet. Bij de boer, om de hoek. Geen groothandels.

De wereld wordt kleiner dankzij internet, maar je mogelijkheden groter. De hoeveelheid data en opties die dat brengt voelt als een snelweg met auto's die op hoge snelheid voorbij razen. Alleen jij zit nog kilometers van die snelweg vandaan, je kiest er zelfs voor te negeren dat die snelweg er is. Die rust is misschien even lekker, maar vroeg of laat moet jij ook naar de grote stad. Die snelweg op, mee met je klanten en je leveranciers. Open voor feedback, meningen van anderen en vol zelfvertrouwen over jouw product of dienst. Toekomstmuziek? Nee. Die wereld start nu.

Photo: CIAT/flickr

Dankzij een gesprek wat ik had met Judith Webber in haar #ZZPhappyhour werd ik gedwongen zelf eens na te denken over mijn visie, waarom opereer ik in deze wereld? Wat is voor mij(n onderneming) belangrijk?

Daaruit kon ik toch al concreet een aantal punten halen die passen bij mijn diensten en producten:

• Authenticiteit — hoe "helder" is jouw propositie, waar sta je voor als bedrijf, hoe past internet in jouw (marketing) strategie?
• Verbinding — hoe "bewust" ben jij je van de wereld (jouw doelgroep, jouw branche) om je heen? Waar zit je kracht, met wie wil je samenwerken, hoe haal je de "kracht" uit je netwerk, zonder deze uit te putten, maar juist aan te vullen?
• Transparantie — in zaken doen met mij, wat kan je van me verwachten en wat mag ik van jou als opdrachtgever verwachten? Blijf verwachtingen toetsen, stel bij waar nodig.

Ben ik authentiek, verbonden en transparant in mijn uitingen? Ik weet zeker van wel, door dit te vragen aan mijn opdrachtgevers, maar ook vrienden, uit netwerken die zowel zakelijk als privé zijn (die steeds meer versmelten) en daar ook enorm veel kracht uit te halen.

Mijn verbinding met jullie is voor mij het belangrijkst, als opdrachtgever, samenwerkingspartner of prive contact, voor iedereen die mijn blogs leest. Suggesties voor inhoud? Waar mag ik mijn mening eens over geven? Ik hoor het graag!

Social media is zoveel meer dan "linkedinnen, facebooken of twitteren", Social Media is contact maken met je klanten. Dat feit is een eerste conclusie uit de blogs die ik geschreven heb, de (veelal) positieve reacties, kritische noot van goede vrienden en dat leid tegenwoordig tot een mooi gemiddeld aantal van 50 bezoekers per dag, die gemiddeld een 2,5 pagina bekijken en mij "3 minutes of fame" geven. Top!

Een aantal wapenfeiten waar ik erg blij mee ben:

• De start van de #bouw20 community in wording op IGRomkes.nl (@romkesbv)
• Implementatie en integratie van Mailchimp.com nieuwsbrief software voor @Difrax, naast succesvolle begeleiding in hun twitter acties
• Diverse lezingen en workshops die ik heb mogen verzorgen
• Een gave hyves community voor Jopla
• Strategische inzet en advies sociale media voor een duurzaam mobiliteitsinitiatief

En uiteraard de mooie samenwerkingsverbanden met o.a. @jvdschenk, @esmeeschonfeldt, @misterseeder en Seats2Meet.com/MINDZ.com visionairs @rvandenhoff en @msijgers waar ik ook de @layar van mag ontwikkelen en implementeren vanuit de door hen gedeelde visie.

Wat is een social application?

Een social application is voor mij een applicatie die je dus in staat stelt om "consumption sharing" inzichtelijk te maken. In het geval van Blippy bijvoorbeeld je meest recente aankopen delen en reviewen.

Een Social Application kent dus in ieder geval de voorwaarde dat het 1 doel heeft, delen. Daarnaast draait het om mensen, niet zo zeer om de techniek er achter. Hen in staat stellen met elkaar te verbinden en kennis te delen rondom het thema is hier het common goal.

Daarnaast is "eenvoud" nog zo'n ding. Hoe eenvoudiger, hoe meer "Social" die applicatie is. Het moet echt dat ene doel dienen en gelukkig doen beide websites dat prima. Ja, dat betekent dus ook ondersteuning op en van meerdere platformen en inloggen met externe netwerken bijvoorbeeld.

Het allerbelangrijkste? De opbrengsten, oftewel de toegevoegde waarde. Als ik 1 ding deel, wil ik een meervoud aan suggesties terug krijgen. Liefst zo specifiek mogelijk en op mijn profiel afgestemd, semantisch dus.

In het kort, delen als middel, eenvoud van de tool, duidelijke opbrengsten en afgestemd op mij. Kenmerken van een top social app!

Blippy

Blippy stelt mij in staat om mijn aankopen op creditcard, diverse online shops (waaronder de iTunes store) te delen met anderen. Dan gaat het niet perse om het aspect "kijk eens wat ik heb", maar juist om het oordeel wat je daar over hebt. Al zal een kop koffie in Nederland niet zo snel betaald worden met creditcard, dat gebeurt dus wel in de US. Koppelingen met chipknip of andere middelen zullen nog wel volgen. Daarnaast koop ik al snel iets in de iTunes store, een klein spelletje om het wachten te vergemakkelijken of een lifehack zoals Calvetica of Dialvetica. Die review ik vervolgens op Blippy en zo weet mijn netwerk, maar ook anderen weer iets over die applicatie, dat kopje koffie, of dat gerecht in een bepaald restaurant.

Blippy is niet "opdringerig" in de vraag naar reviews en beloond je met behulp van "levels" (die direct ook weer jouw betrouwbaarheid aangeven) op basis van het aantal reviews wat je doet.

GetGlue

GetGlue is mijn nieuwste "verslaving", ik kijk regelmatig series, films of denk even na over een bepaald onderwerp en dat is waar GetGlue haar verbinding haalt. Die onderwerpen die anderen boeien, de mogelijkheid te zien "wie nog meer" van die film of serie houdt en opnieuw een netwerk opbouwen van mensen om je heen met die specifieke interesse.

Daarnaast verzorgd GetGlue de suggesties op een erg prettige manier. Na het aangeven dat je een bepaald genre films leuk vind, zal je ook zien dat GetGlue jou suggesties doet voor meer content. Niet alleen op basis van jouw keuzes, maar ook op basis van jouw netwerk en zelfs de tijd wanneer je inchecked is relevent aan wat je graag wil zien. De koppeling met TV gidsen is dan nog erg dichtbij.

Foodspotting

Foodspotting is 1 van mijn "leukste" social apps op dit moment, naast het delen van wat ik eet, kan ik op deze manier ook op zoek naar nieuwe restaurants en gerechten.

Ik deel op foodspotting dus wat ik eet, een kleine review van wat ik er van vind en met de knoppen "nom it" en "want it" kan ik ook nog context geven aan het gerecht naar keuze. De koppeling met foursquare, twitter en facebook maakt het eveneens erg gemakkelijk om breder te delen en zo te zien hoeveel mensen daadwerkelijk naar jouw "voedsel" kijken.

Foodspotting zelf is wat "voeden" van mijn profiel betreft gekoppeld aan gebruik op mijn mobiele telefoon. Gemiste kans, gezien ik juist ook zoveel doe op mijn laptop. Echter het "delen" van de inhoud en reageren op anderen, kan dan wel weer online gebeuren.

Maar wat moet ik dan met al die apps?

De vraag die daar bij rest is tenslotte "wat moet ik daar dan allemaal mee?" En dat is een logische. Voor @Basiliek heb ik bijvoorbeeld een aantal gerechten via foodspotting gedeeld om zo te illustreren wat dat voor hun zou kunnen betekenen. Met @blippy review ik regelmatig applicaties voor de iPhone en ook daar komt dialoog uit. En Getglue zorgt voor mij voor meer koppeling met mijn netwerk. Ik weet wat zij kijken, en andersom. Kern van dit verhaal? Voor elke doelgroep is er een platform, elke niche kent zijn of haar plek. Jouw kans? Geen niche platform nog? Bouwen! Meer weten over gebruik of inzet? Laat het even weten!

Ik heb iets met tools en met name op het gebied van CRM. Op social gebied nemen die tools op dit moment een enorme vlucht en duikelen over elkaar heen; Salesforce, Microsoft en IBM als grote jongens en vele, vele kleine producenten daaronder. Contactually is een beetje een andere aanpak van dat eenvoudige probleem, contact onderhouden.

Waar veel CRM draait om zoveel mogelijk klant- en contactgegevens te verzamelen (de C van CRM), draait het daar bij Contactually niet om. Wat daar het belangrijkste is, is de vraag "wanneer heb ik voor het laatst met iemand contact gehad?".

Ik heb een hekel gekregen aan de zogenaamde SCRM's (social CRM) pakketten, die zichzelf als social in de markt zetten. Eigenlijk zijn het ouderwetse, bijna DOS achtige pakketten ingericht op het verzamelen van massa's data, om er zo voor te zorgen dat je precies weet wat je klant denkt, voelt en schrijft. De social toevoeging in deze big data is een krachtige tool, die veel account managers en marketeers dan ook met liefde inzetten. In essentie slaan die pakketten de plank mis, het gaat niet om sociaal doen, maar om social misbruik in die pakketten.

Of dat je moeders bent vergeten te bellen de afgelopen maanden omdat je het zo druk hebt.

Je moet namelijk heel voorzichtig zijn met het in contact blijven met je klanten. Je kan ze simpelweg niet jouw informatie opdringen, daarvoor is aandacht van je klanten veel te kostbaar. Wel kan je inspelen op de behoefte van je klant, een simpel sociaal gebaar geven, een kaart sturen bij een verjaardag of een relevante reactie op een foto bijvoorbeeld. Vragen die gesteld worden via Twitter beantwoorden, een koppeling maken met iemand uit je netwerk, dat soort zaken.

Contactually helpt bij het bijhouden van de relaties met mijn contacten. Zakelijk en prive. De meeste mensen spreek ik toch wel regelmatig, maar soms moet daar even een tandje bij, in het geval iemand zakelijk een lead is geworden en je toch graag wil weten wat iemand van je voorstel vindt. Of een partner waar je een relatie mee bent aan gegaan en zijn of haar praktijken ineens relevanter geworden zijn aan wat jij in je bedrijf doet, of dat je moeders bent vergeten te bellen de afgelopen maanden omdat je het zo druk hebt.

De stappen voor het werken met Contactually zijn simpel:

1. Ik laad al mijn netwerken in, met Gmail als basis voor elk contact. Twitter, Facebook en LinkedIn zijn standaard ondersteund. Ook grotere CRM tools als Salesforce en sugarCRM hebben een integratiemogelijkheid.
2. Ik speel de 'bucket game', een spelletje waarin ik mijn contacten toewijs aan een bepaalde groep, waarmee het een stuk leuker wordt je contacten te sorteren.
3. Elke bucket (groep) kent een bepaalde maximale tijdsgrens waarin je met mensen contact zou willen hebben. Leads bijvoorbeeld binnen 14 dagen, je familie misschien een dag of 30 en vage kennissen misschien eens in de twee maanden.
4. Ik volg ze op vanuit Contactually of geef bij elk contact aan op wat voor manier ik contact met hen heb gehad.

De kern van contactually zijn de groepen. Ik denk tegenwoordig meer in zwermen, dus houd ik het simpel:

• Leads — ik moet ook mijn brood verdienen, die mensen die dat verschaffen zitten vrij dicht op mij, zakelijk gezien dan.
• Close ties — mensen die mij het meest dierbaar zijn vindt je hier terug.
• Weak ties — ik geloof erg in de kracht van de zwakke schakel, iemand 'eens gekend is altijd gekend', er is zoveel informatie over iemand terug te vinden via dit soort tools, dat je altijd wel een 'oh ja' momentje hebt.

Zo hou ik het overzichtelijk en klein, maar wel prive en zakelijk in een. Wat tijdsinvestering betreft kijk ik hier één tot twee keer per week naar, hooguit 15 minuten. Zo blijf ik bij met jou. Nogmaals, elk contact wat ik heb met mensen is van sociale aard, de kern zit in het investeren in de relatie. Soms kost me dat ineens een half uur om een goed antwoord te googlen of het schrijven van een blog. Maar in elke investering in een ander zit een rendement, daar geloof ik heilig in!

Kern van dit alles is dat de aandacht komt de liggen op de Relatie, in plaats van op het Contact in de afkorting van CRM. Ook van Management is nauwelijks sprake, vraag eens oprecht hoe het met mensen gaat, neem de tijd voor elk contact. Mijn uiteindelijke doel is een socialere wereld, waar we van elkaar leren en ook nog eens een boterham kunnen verdienen. Met een beetje hagelslag. Contactually helpt mij daar bij. Wat is jouw voorkeur qua CRM?

Photo: Creative Commons; Flickr - Ray Larabie

Contactually vroeg mij naar aanleiding van mijn ervaringen een artikel te schrijven. Ook ben ik een 'case story' op de site van Contactually als veelvuldig gebruiker. Bij deze mijn investering in hen. Daar gaat overigens geen euro mee gepaard.

Een maandagochtend overweging. Zo langzamerhand merk ik dat de behoefte aan constante verbinding afneemt. Misschien komt het door de vakantieperiode, het grote aantal bedrijven wat zich 1.0 opstelt op sociale netwerken of de échte sociale band die ik opbouw met mensen via Path, maar er is bij mij meer dan ooit behoefte aan 'sociaal', dan aan een groot aantal verbindingen.

Grappig hoe soms zaken in één keer bij elkaar komen en context geeft aan zo'n lastig onderwerp. Aan de ene kant leef ik (van) online. Mijn brood zit in online, als consultant en als spreker. Ik ben al ruim 20 jaar online terug te vinden. Eerst in connectie met een enkeling via BBS'en, later op diverse fora en in chatboxen op IRC, tot facebook en twitter nu met duizenden tegelijk. Die verbindingen uit vroeger tijd voelden veel persoonlijker dan de meeste contacten op Facebook en Twitter nu. Want aan de andere kant is er de hoeveelheid, de massa, die op een gegeven moment niet meer te managen is. Het wordt een proces, iemand volgen, berichtje heen en weer, en proberen in de radar te blijven van die persoon. Niet om wat hij of zij doet, maar om te bewijzen dat je nog bestaat. "Ik deel, dus ik besta".

Als medewerker of manager van een bedrijf moet je daar ook eens goed naar moeten kijken. Beschouw de sociale media niet als de ultieme manier om nieuwe klanten te werven, personeel te zoeken of je medewerkers te stimuleren (of controleren) maar kijk ze eens recht in de ogen aan. Vraag ze op de man af hoe ze zich voelen. Meer dan ooit is er ook bij hen (misschien weten ze het niet) behoefte aan een luisterend oor. Iemand die tegen ze praat en oprecht vraagt: "hoe gaat het nu met jou?"

Meer dan ooit is er behoefte aan écht oprecht contact.

Daarvoor kwam het blog wat @josgovaart en @roosvanvugt deelden zo goed uit. Path ís namelijk het sociale netwerk waarin de vertrouwensband, kleinschaligheid en menselijke emoties vooropstaan. Waarin echte gevoelens, lief en leed, gedeeld wordt. Waar ook ruimte is voor mij om af en toe een flauwe grap te plaatsen die niet altijd gepast is op andere sociale netwerken.

En als bedrijf heb je helemaal niks aan Path. Maar jij, als persoon, wel. Om mensen te leren kennen, om ze jou te leren kennen. En vervolgens eens koffie met ze te drinken. Fijne werkweek!

Jaren van internetgebruik en social media, naast veel random contacten bij @seats2meet, leidt bij mij tot de conclusie dat je eigenlijk niemand meer kan vergeten uit het verleden. Zodra ze eenmaal in je adresboek zijn aangeland, raak je ze nooit meer kwijt.

'Eens gekend is altijd gekend', schreef ik maandag in dit blog. Dat citaat heb ik opgeschreven voor vandaag en na wat nadenken kom ik tot de conclusie; als je het niet wilt, hoef je nooit meer iemand te vergeten. Het internet stelt ons in staat van iedereen wel iets van relevante informatie naar boven te toveren en met de mogelijkheden van Twitter, Facebook en LinkedIn is er ook geen beperking in wie je wel, of niet toelaat in je netwerk. Met tools als Contactually kan ik zelfs (al is dat kunstmatig) gedwongen contact houden met iedereen, of ik (of die persoon) er nu behoefte aan heeft of niet.

Dat leidt tot een raar fenomeen, die je nu ook in het echte leven tegenkomt. Er is geen aandacht meer tijdens een gesprek, of de druk bij een (gepland) gesprek ligt zo hoog om het 'leuk te hebben' of 'inhoudelijk van waarde' (jakkes) te zijn dat het gesprek altijd zal teleurstellen. Je weet immers alles van die persoon, moet een plan maken en een doel hebben omdat je zo weinig tijd hebt in je agenda; die ene afspraak moet dan wel héél bijzonder zijn en moet echt iets betekenen.

Ik ontdekte het bovenstaande bij mezelf een paar maanden geleden, omdat ik mijn agenda niet zo vol meer wilde plannen als een jaar of twee geleden. Toen had ik vier gesprekken op een dag, liefst strak op elkaar geplanned zodat er ook nog tijd over bleef voor werk, dat ik een gesprek niet als werk beschouw, had ik toen nog niet helemaal in de gaten. Door minder ruimte in mijn agenda te reserveren voor gesprekken kwam de keerzijde hiervan naar boven. De keerzijde was dat elk gesprek nu wel van waarde moest zijn, ik had immers tijd voor die persoon gereserveerd die in mijn ogen heel waardevol was. Daar kwam ik dus met een domper uit…

De wereld wordt mooier geschetst via social media dan ooit tevoren, ook al doen de nieuwsfeeds op Twitter anders blijken.

Mensen veranderen, omgeving verandert, context verandert. De wereld wordt mooier geschetst via social media dan ooit tevoren, ook al doen de nieuwsfeeds op Twitter anders blijken. Mijn beeld van die persoon aan de andere kant van de tafel was geschetst door wat hij of zij deelde online. Ik toetste dat niet, ik nam dat voor waarheid aan. Bizar eigenlijk, nu goed bekeken. Ik spreek alleen nog maar af met mensen die ik echt gemist heb, of die ik zakelijk gezien nodig heb. En heel vaak ontstaat dat gewoon spontaan. Zonder verwachtingen, met nog wel een blik op de sociale netwerken om even te kijken wat die persoon de afgelopen weken gedaan heeft, maar dat is meer stof ter conversatie dan het scheppen van een beeld.

Zullen we er gewoon weer eens voor kiezen om af en toe iemand op te bellen? Eens te kijken hoe het met die persoon gaat? En je hart te volgen in zo'n contact, in plaats van je agenda? En laat Facebook, Twitter en LinkedIn daar eens in faciliteren; mensen met wie je even geen contact hebt gehad, in een soort van 'sluimerstand' plaatsen en geleidelijk laten verdwijnen uit je netwerk. Net zoals dat vroeger ging. Dan bepaal ik weer of ik iemand wil spreken, in plaats van zijn status update of change of job. Herken jij je hierin? Hoe ga je daar mee om?

Vorige week schreef ik al 10 productiviteitstips die vooral gaan over de plek waarop je werkt, technieken en tips. Nu 6 tips voor een gezondere lifestyle en wat mij dat gebracht heeft.

1. Eet gezond. Die stond er vorige week ook al bij, maar ik wil 'm toch graag even terug halen. Eet je dagelijkse groente en fruit. Het zorgt voor energie gedurende de hele dag en de tijd dat je niet op je werk bent. Ik kies hierin om zo weinig mogelijk E-nummers te eten, met name de verslavende E621 bijvoorbeeld, die je in veel producten (met name pakjes en zakjes) terug ziet. Gelukkig is Emma een kookwonder, maar leer ik zo langzamerhand ook het een en ander bereiden. Vers en gezond voedsel is hierin heel belangrijk. Wij laten ons inspireren door de Italiaanse keuken, met veel groente en salades. We hebben de hele dag energie en blijven op een gezond gewicht. Ook het beperken van suikers helpt daar enorm bij. Suiker is een enorme verslaving waar ik verbaasd over was; stop maar eens bewust met veel suiker eten, of let eens op de voedingswaardes van de producten die je consumeert. Melk bijvoorbeeld, jus d'orange of light producten. Je hebt meer energie dan je voor mogelijk hield en de constante drang naar eten en zoetigheid is verleden tijd. Daarnaast smaakt het eten zo ontzettend veel lekkerder dan daarvoor.

2. Drink gezond. Koffie is killing. Ik dronk in mijn actieve seats2meet.com tijd een kop of acht per dag. Waanzinnig als ik dat zo eens bekijk, maar de periode leende zich er kennelijk voor. Ik probeerde elke tegenslag of lichamelijke wens naar rust te negeren en op te vullen met koffie. Zo kom je de dag dan vanzelf wel als een hyperactieve zombie door. Stoppen met koffie is één van de beste stappen die ik heb genomen. Heerlijk om de hele dag zo energiek te kunnen zijn. Het effect van een kop koffie merk ik dan ook vrijwel direct, ik kan er (letterlijk) de hele nacht mee door, en de 'koffiekater' die de volgende dag terug komt, is heel vervelend en bijna migraine achtig. Je lichaam schreeuwt om nieuwe cafeïne.

3. Beweeg veel. Veel van jullie zullen een zittend beroep hebben. Naast de overweging staand te gaan werken, is veel beweging noodzaak. Plan je afspraken buiten de deur eens rond een station, elk stuk openbaar vervoer wat je aflegt gaat gepaard met (wat) beweging. Ik zie dan ook weinig dikke mensen met de trein gaan, omdat de auto bij die groep mensen de voorkeur heeft. Al is het maar die 10 minuten (staand) wachten op het station en het lopen van spoor naar spoor, die beweging helpt je in ieder geval de eerste stappen op weg. Ik fitness zelf twee tot drie keer per week, heerlijk om zo energie op te bouwen en me prettig in mijn eigen lijf te voelen. Ook dat is belangrijk in productiviteit, jezelf goed voelen zet zich nu eenmaal door in het werk wat je doet.

4. Rust genoeg. De zomerperiode heeft me weer eens geleerd dat het niet erg is om eens lekker uit te slapen of aan het eind van de middag een half uur te slapen op de bank. Informatie verwerken vergt veel energie van je hoofd en die geeft regelmatig signalen aan je lichaam dat je rust moet nemen. Zo verwerk je informatie beter, sla je die informatie onbewust op en die komt er dankzij de rust ook weer op de juiste momenten uit. Er is niets vervelenders dan een gesprek te hebben waarin je geen 'inzichten' kan geven die direct vanuit je eigen ervaring en onbewustheid doorsijpelen. Vaak kan ik vertrouwen op dat geheugen, weet ik me case studies te herinneren die ik ooit eens gelezen heb of een tool of tip te geven die van toepassing is in die situatie. Zonder rust is dat niet mogelijk.

5. Luister naar je lichaam, je hebt er maar één van tenslotte. Vaak geeft het wel aan hoe het met je is, maar de signalen zijn verkeerd te interpreteren. Vermoeidheid kan duiding geven aan veel situaties. In mijn geval verkeerd eten, teveel cafeïne en weinig lichaamsbeweging. Een detoxweek, of een resetweek kan dan een goed middel zijn om weer overnieuw te beginnen, maar dan ook met alle gewoontes die je hebt abrubt een einde te maken. Stoppen met roken bijvoorbeeld, wat ik gelukkig ook heb kunnen laten liggen, ging alleen maar door verandering van gewoontes en zelfs omgeving. Verhuis je binnenkort? Het ideale moment om te stoppen. Een nieuwe baan, een nieuwe hobby, een nieuw boek. Grijp die momenten aan om te breken met nare gewoontes en je lichaam rust en gezondheid te gunnen. Dat geldt ook voor dat ene ijsje elke avond, een handje chips bij het voetbal en de vette hap op de zondagavond.

6. Wees geestelijk gezond. Naast bloggen, wat voor mij heerlijk werkt om mijn gedachtes op een rij te zetten, schrijf ik ook veel in dagboek apps, ik praat met veel mensen, en heb een partner waar ik heel fijn op terug kan vallen. Ik reflecteer veel, heb daar de tijd voor in de auto of neem een (autobiografisch) boek waar ik mij aan kan spiegelen. Meditatie of yoga schijnt ook te helpen, al ben ik daar te nuchter voor. Geef mij maar praktische zaken, een goed gesprek en rust en ruimte voor mezelf.

Photo: Creative Commons/Flickr: Mikko Lutniala

Je wil er niet aan denken, maar toch komt er dat moment dat je je laatste adem uitblaast. En dus ook je laatste tweet plaatst. Maar wat gebeurt er vervolgens met je online identiteit? En wat biedt de techniek voor mogelijkheden?

Er zijn een aantal tools die er voor zorgen dat jouw profiel op het moment van overlijden wordt afgesloten, dat er nog één laatste bericht geplaatst wordt, dat soort dingen. Het lijkt mij een hele goede zaak dat daar een uniforme afspraak over komt. Er is niets zo vervelend voor nabestaanden om door zoveel sociale netwerken te moeten (ik wil er niet aan denken in mijn geval…) om profielen te sluiten, op te heffen of te veranderen in een 'bevroren' profiel.

Een kijkje in de toekomst; technologie stelt ons in staat om te voorspellen wat wij zouden willen plaatsen op Twitter. De inhoud gaat nu vaak nog nergens over, is in het Engels en voor ons Nederlanders niet spannend, ook inhoudelijk vaag, maar toch. Denk nog eens vijf jaar verder, denk aan de nog grotere hoeveelheid data die over ons bekend is (en samengebracht kan worden), en de rekenkracht van computers zorgt er voor dat de inhoud van zo'n bericht vrij nauwkeurig overeenkomt met wat jij gezegd zou kunnen hebben.

Neem daarnaast de mogelijkheden van hologrammen, de technische vooruitgang op het gebied van 3D en projectie en het zo langzamerhand betaalbaar worden van die technologie. Combineer die beide en je hebt ineens een levend hologram aan wie je nog eens zou kunnen vragen hoe dingen zijn, wat hij of zij er van had gevonden.

Waanzinnig gaaf voor 'oude visionairs', Newton of Einstein had ik heel graag een keer een dialoog mee willen voeren. Prachtig, denkend aan de mensen die ik in het verleden ben verloren. Maar tegelijkertijd angstaanjagend. Willen we dit wel echt? Ook de dood heeft haar functie. Geïnspireerd door gedachtes van andere mensen een stap verder kunnen zetten, zelf een richting bepalen en voortbestaan in de herinnering.

Technische ontwikkelingen zullen altijd die twee kanten belichten. De positieve, en de negatieve. Ik ga in 99% van de gevallen uit dat techniek bijdraagt aan een beter, prettiger, handiger leven. Dit is die ene procent waar ik grote vraagtekens bij zet. En jij?

Junkweb, oftewel al die dode eindes op internet. Waar internet in de oorsprong een serie gelinkte pagina's was die eigenlijk oneindig bleek, is dat met plaatjes niet zo. Die betekenen vaak het einde van die reis. Een blog over de opkomst van junkweb, mede mogelijk gemaakt door Instagram.

Gister werd bekend dat Instagram (een tool waar ik overigens verschrikkelijk gek op ben) meer mobiele gebruikers heeft dan Twitter op maandelijkse basis. 7.3 miljoen tegenover 6.9 voor Twitter. Ik vraag me overigens af of dat echt puur en alleen voor de mobiele versie van de website gaat, of ook over apps, maar toch.

Het is een opvallende trend, dat we de mogelijkheid hebben op dit moment net zo makkelijk beeld met elkaar te delen, als dat vijf jaar geleden met de opkomst van tekst was via Twitter. 140 tekens spuien, of een plaatje van 800x800 pixels. Die resolutie is zelfs gestegen nog de afgelopen tijd, waardoor we zelfs een soort van 'HD' achtige plaatjes met elkaar delen inmiddels. Een 'snapshot' uit jouw omgevingswereld, een scheet van wat je beleefd, gevangen in beeld.

Diezelfde vijf jaar geleden stond ook in het teken van de opkomst van de 'quote van de dag', het 'inspirerende moment' of de 'les die ik jou wil leren'. De coaches sponnen er flink garen bij, althans, dat was de opvatting van hen die in dat vak zaten. Ik heb mijn hersenen altijd flink gebroken op de coaches en wat voor hen echt de toegevoegde waarde was van Twitter; naast de quotes die iedereen toch al deelde, nogmaals te delen.

Maar nu is daar instagram, dus ook die coaches kunnen weer aan de bak. Het kopiëren van een quote en die in een prachtig (uhum) font over een plaatje heen leggen en slim gebruik maken van de manier waarop we onze hersens gebruiken. Die slaan namelijk geen visuele beelden over, die 'lezen' dat altijd. Wat internet en SEO betreft; een plaatje is altijd 'the end of the road', het leidt ons naar nergens, het is niet via Google te indexeren, zoals tekst dat wel is. Het bestaat niet uit een verzameling links of verwijzingen, zoals een willekeurige site dat wel is. Een website is nooit het eindstation van je reis op internet. Een plaatje is geen wiki dat aan te passen is door andere mensen, nee het is een afbeelding. Het einde, de laatste halte. Er op klikken leidt ons (vaak) tot nergens, nee het zijn allemaal doodlopende wegen. Iets anti-internets eigenlijk.

Dat fenomeen van doodlopende wegen mag dus het 'junkweb' genoemd worden, althans als ik Chris Brogan mag geloven. Ik lees graag zijn blogs, ook door de wat cynische toon van zijn verhalen.

Maar wat ik al eerder schreef, ik hou van het junkweb. Ik hou van de plaatjes en afbeeldingen, van een klein stukje emotie gevangen in een afbeelding. Iets wat ik vroeger zocht in de 140 tekens op Twitter; een mening, een emotie, iets persoonlijks. Om een conversatie over te starten. Om samen meer kennis mee op te bouwen en een netwerk te realiseren. Zo langzamerhand is die strijd om aandacht (wat eerst leuk was, is nu schreeuwen geworden op Twitter) verplaatst naar beeld. Want beelden geven direct aanleiding voor aandacht, een reactie of een like. Een afbeelding op instagram met 25-50 likes is geen uitzondering. Een tweet met dat aantal reacties of retweets tegenwoordig heel opmerkelijk.

Nou hoop ik dat niet elke gek (lees: coach) op instagram gaat zitten, en zeker niet om de hele dag quotes van bekende mensen te gaan posten met als achtergrond de zoveelste speeltuin of #cloudporn, maar daadwerkelijk iets toe te voegen. Iets wat ik wil delen, of gewoon gaaf vindt om te bekijken. Zo doet Vossen dat heel goed, die notabene voornamelijk velgen maakt voor auto's. 200.000 volgers, en die delen alleen maar hele gave zaken. Plaatjes van door hun getunede auto's, door andere mensen getunede auto's met hun velgen, en lekkere wijven met mooie auto's natuurlijk (sorry dames).

Dat merk blijft bij mij hangen, creeert een beleving. Probeer dat als coach maar eens te benaderen…

Afbeeldingen zijn de nieuwe tweet geworden, inspiratie daadwerkelijk iets uit je eigen belevingswereld. Soms deel ik dat nog op Twitter of Facebook, maar ik doe dat met mate. En ik besteed veel aandacht aan de beelden en beleving van anderen op instagram, al ben ik daar ook al heel kritisch in aan het worden. Geen standaardwerk of overbewerkte foto's, ook liever geen professionele foto's. Hoe persoonlijker en dichterbij, hoe meer emotie voor mij en hoe prettiger. Net zoals je geen PR bureau je tweets laat schrijven, laat je ook je instagrams niet maken door anderen. Persoonlijk, prive, van jou. Jouw emotie. Zo wordt het junkweb, ineens heel waardevol.

Zojuist bedacht ik me de oplossing voor het junkweb. Als internet gaat herkennen wat we fotograferen kunnen we ineens wel links creeren en doorklikken. Een beetje zoals dat gaat met taggen op facebook. Geen dood einde meer, maar een begin. De berg hierboven op het plaatje klikbaar, de maker van de quote linksboven idem. Helaas moet Facebook gezichtsherkenning uit, maar die had dat goed in de gaten…

Overigens werd ik voor dit artikel ook geïnspireerd door de #instagramwalk072, afgelopen zondag in Alkmaar. Een heerlijke manier om een stad te ontdekken, zeker de moeite waard!

Nog enigszins slaapdronken stap ik deze ochtend achter mijn computer. De weekenden zijn altijd weer lastig om terug te gaan naar je basisritme, zeker als zelfstandig ondernemer. Dat ene uurtje extra blijven liggen, ach, dat kan toch niet zo erg zijn? Toch is de ochtend voor mij een van de meest productieve momenten van de dag. Op een nuchtere maag, een leeg hoofd en in een rustig huis lekker aan de slag. Vandaag dus 7 manieren waarop ik de ochtend goed begin.

Allereerst dan maar eens goed bepalen waarom je eigenlijk uit bed komt. Dit artikel op Lifehacker hielp me daarbij om dat eens goed vast te leggen.

Als het om werk gaat zijn er drie dingen die je stimuleren door te gaan in de functie waar je mee bezig bent en die je in ieder geval in je werk plezier, voldoening en enige vorm van geluk geeft, te weten:

• Autonomie — Het gevoel dat ik zelf controle heb over wat ik doe en wil doen.
• Focus — Ergens heel erg goed in worden, je specialiseren, verder en meer leren, weten en kennen.
• Doel — Het gevoel hebben dat er een doel is, dat jij belangrijk bent. Dat je bijdraagt aan een doelstelling bedrijfsbreed.

Geld

Deze persoonlijke doelstellingen zijn belangrijker dan geld, in welke vorm dan ook. Geld is maar een tijdelijk en kortstondig gevoel van geluk, deze drie zijn er altijd. Ook als het niet om geld draait, kom ik hier mijn bed voor uit. Ik kan uren en dagen besteden aan het optimaliseren van mijn website of het maken van een trailer voor een video, zonder me zorgen te maken over geld.

Dat geld niet het belangrijkste in de wereld is ondervind ik ook. Vaak gaat veel geld gepaard met drukte, verantwoordelijkheid en periodes van oneindig lang en veel werken. Geen enkele ondernemer wordt écht rijk (financieel) zonder hard werken. Tenzij je erg veel geluk hebt natuurlijk, maar daar zou ik als ondernemer niet op vertrouwen. Ik blij met mijn balans nu, qua werk, inspanning en resultaat. Dat nog altijd liever dan de 100 uur die ik in vorige jaren werkte met een iets hoger banksaldo. Daarnaast is het verstandig elk uur dat je in werk investeert, zo efficiënt en optimaal mogelijk besteedt.

Terug naar de ochtend. In ieder geval nadenken en weten dat deze drie onderdelen deel uitmaken van mijn dag doet me al goed. Ik weet dat ik vandaag precies ga doen wat ik wil, ik focus mij op mijn klanten, maar ook op kennis en ontwikkeling op het gebied van social media en social business. Heerlijk om daar samen ook mee aan de slag te kunnen.

Tips

En verder, een paar tips die voor mij de ochtend bepalen:

1. Begin vroeg — Voor een ieder is vroeg anders. Ik vind half acht vroeg genoeg, al werd dat vandaag half negen.
2. Bepaal waar je focus ligt vandaag — Elke ochtend één duidelijke prioriteit.
3. Fitness — Je fysieke toestand is net zo belangrijk als je geestelijke. Ik train 3x per week in de sportschool, in de ochtend. Ik krijg daar heerlijk veel energie van en blijf gezond.
4. Eet gezond — Het is zo gemakkelijk niet te eten of ongezond te eten in de ochtend, terwijl je in 10 minuten een prima ontbijt (in mijn geval toast, ontbijtgranen of ei) op tafel kan zetten.
5. Neem afscheid van je thuis — In mijn geval is dat nog even een knuffel in bed voor ik begin met werken in de andere kamer in huis, maar op dagen dat ik niet thuis ben ontbijten we samen en nemen we even de tijd voor elkaar. Werk én prive kun je in tijd wel scheiden, maar hebben absoluut een relatie met elkaar.
6. Eat the frog — Het heerlijkst is om dat ene ding wat al dagen of weken op je takenlijst, nu eindelijk eens van die takenlijst af te strepen. Voor mij is dat de administratie, een heikel karwei wat ik heb uitbesteed, maar nog altijd energie kost. Bonnetjes bewaren, in een envelop stoppen, opsturen. Het is zo simpel, en toch laat ik het liggen. En ik ben vast niet de enige ;-)
7. Blijf geïnformeerd — Ik lees de Nu.nl app even door voordat ik uit bed kom. Dat geeft wat context aan mijn leefwereld, zonder mezelf daar extreem door te laten beïnvloeden. Ook de sportsectie lees ik bijvoorbeeld en om de achterklap kan je ook niet heen. Prima informatie om lekker de ochtend mee te beginnen.

Hopelijk kan je hier iets mee, maar ik ben ook benieuwd wat ik nog mis om mijn ochtend beter te beginnen. Heb jij tips? Laat het dan gerust weten!

Photo: Creative Commons; Flickr - Josef Grunig

In deze tijd waarin zo ontzettend veel afleiding op de loer ligt, is het soms nodig om spelregels met jezelf af te spreken. Vandaag 10 van mijn eigen spelregels.

Sinds ik de toegang heb tot een eigen computer, ben ik eigenlijk altijd bezig geweest met het sneller maken van dat ding. Kijken hoe ver ik kon gaan, wat soms leidde tot gekke situaties. Zo had ik ooit een watergekoelde computer, om er vooral voor te zorgen dat dat ding nog makkelijker zijn warmte kwijt kon en ik die dus kon opvoeren.

Sinds de computer sneller is geworden dan mijn hoofd kan denken, breek ik me daar in ieder geval niet meer over. De enige reden waarvoor je nog een nieuwere computer (mac) wil, zijn spelletjes. Over spelletjes ga ik later nog wel eens bloggen…

Terug naar de productiviteit, lifehacking eigenlijk. Want als het niet meer om de snelheid van de computer gaat, moet ik mezelf wel sneller maken.

1. Gebruik e-mail niet als takenlijst. E-mail is een communicatietool. Stop met dat gebruiken als 'inbox' voor je taken. Lees je e-mail maximaal drie keer per dag. Lees elke mail die binnenkomt maximaal twee keer. Bepaal direct de actie (taak) die je uit deze mail wilt halen, stop de mail weg in een goed terug te vinden map. Of print het als je dat handig vindt.

2. Kies een tool die past bij jou als takenlijst. Ik hou het het liefst simpel, maar wel toegankelijk op meerdere apparaten. Things is dat voor mij, Toodledo een goede tweede. Pen en papier is ook een prima optie, misschien nog wel beter. Al synct dat wel wat lastig.

3. Maak gebruik van die takenlijst. Alleen zo zorg je er voor dat het echt in je systeem komt. Alle taken die langer duren dan twee minuten schrijf je hier op. Duurt het korter dan twee minuten? Dan direct doen. Review regelmatig die takenlijst en pak er een aantal (maximaal twee, hoe weinig dat er ook lijken) uit die je vandaag gaat doen. De rest laat je liggen, blijft op die lijst staan. En vink ze af, een heerlijk gevoel! Dat gevoel werkt overigens beter op papier dan digitaal, dus een print maken is ook nog niet zo'n gek idee.

4. Zorg voor ritme en je eigen rituelen. Ik schrijf het lekkerst op de vroege ochtend, nog voor het ontbijt. Dat is voor mij tussen 8 en 9 's ochtends. Daarnaast sport ik drie keer per week in de ochtend (na het ontbijt) en dankzij de Olympische Spelen heb ik een vast moment waarop ik de computer uit zet, en sport ga kijken. Dat soort rituelen helpen je lijf en geest aan ritme. Dat ritme zorgt voor minder stress om steeds te moeten veranderen.

5. Zorg voor een prettige werkplek. Ik heb een 'clean desk policy' en probeer zo minimaal mogelijk te werken. Zo kan ik mij concentreren op mijn werk, niet op alles wat me afleid. Het liefst één scherm, een groot stuk papier, een pen, een lamp en dat is het wel. Alleen zo kan ik écht optimaal werken. Alles wat niet direct nodig is, houd ik buiten handbereik.

6. Multitasken werkt niet. Ik gebruik de pomodoro techniek om mezelf continu gefocussed te houden op één taak die voor me ligt. Alhoewel vrouwen makkelijker zijn in het omschakelen naar andere taken dan mannen, geldt ook voor hen dat continu wisselen, opnieuw focussen en starten erg moeilijk is en veel energie kost. Vandaar, focus. 25 Minuten op één taak gericht. Dat lijkt makkelijk, maar probeer het maar eens. Sluit al die andere schermen op je computer, zet de TV uit. Wees eens 100% bij de taak voor handen.

7. Wees flexibel. Vanochtend werd mijn routine bruut verstoord door de bezorging van onze tuinset. Leuk natuurlijk, maar dat zorgt er wel voor dat deze blog pas na 10 uur gepubliceerd werd. Dat is dan niet anders, en zo moet je ook met je routine omgaan. Wees voorbereid op onderbreking. Maar zorg er wel voor dat je dat bij jezelf niet doet. Geen twitter, facebook of andere afleidingen dus. En doe je deur dicht als je echt niet afgeleid wil worden. Of hang een sticky note op je cubicle. Een koptelefoon werkt ook goed.

8. Neem voldoende rust. De computer en informatiewereld zorgen er nog wel eens voor dat je hoofd letterlijk vol voelt. De enige oplossing daarvoor is rust. Iets doen wat niet teveel vergt van je hersenen. Een boek lezen, een tijdschrift, even voor de TV hangen, of gewoon een klein uurtje slapen. Dat zorgt er voor dat je gedurende de dag je energie kunt houden.

9. Leef gezond. De houding en de manier waarop we leven achter het beeldscherm blijkt erg ongezond. Vaak wordt er ook verwezen naar de mogelijkheden van staand werken. Sowieso denk ik al beter lopend, maar staand werken overweeg ik ook nog eens te proberen. Daarnaast is goed, gevarieerd en regelmatig eten én goed bewegen nodig om je energie goed te kunnen doseren en de hele dag normaal te kunnen werken.

10. Heb een beetje lol in je leven. We vergeten nog wel eens te genieten van wat we doen. Ik heb de luxe veel vrijheid te hebben als zelfstandig ondernemer, ik kan dus zelf bepalen waar en wanneer ik werk. Vorige week nog op Texel bijvoorbeeld, en een dag vrij met mijn verjaardag aanstaande maandag is ook geen probleem. Ik weet alleen wel dat ik al mijn taken op mijn lijstje af moet werken, dus plan ik elke dag opnieuw. Maar ik probeer wel elke dag lol te hebben. Al is het maar genoeg rust om te lunchen, of even een film te kijken. Ook Youtube is daar een prima medium voor.

Zo zijn er nog genoeg tips te bedenken, maar ik ben vooral benieuwd naar hoe jij omgaat met informatie, tijdsindeling en jezelf.

Photo: Creative Commons / Flickr; Katsrcool