MCP</th>	What It Does</th></tr></thead>
Google Calendar</strong></td>	Reads three calendars across two Google accounts. Unified view of personal, family, and work events.</td></tr>
Trello</strong></td>	Manages the Kanban board. Creates cards, updates checklists, moves projects between columns.</td></tr>
Apple Notes</strong></td>	Reads/Writes my notes and other information I capture on my phone.</td></tr>
Perplexity</strong></td>	Web search and research. For customer briefings, news, background checks.</td></tr>
Chrome DevTools</strong></td>	Scrapes public LinkedIn profiles for the personal CRM, and other advanced web scraping.</td></tr>
Email</strong></td>	Claude has its own email address (on my server) for receiving forwarded emails and sending messages in its own name.</td></tr> </tbody></table> Personal CRM</h3> One of the most useful additions: a personal CRM built in Obsidian</a>. Each person gets a Markdown file with contact details, professional history, conversation notes, and relationship context. Claude maintains these files and can look up people on LinkedIn to enrich the profiles. Inspired by Derek Sivers’ philosophy</a>: depth over breadth, private notes, genuine connection.</p> I always wanted to have my own personal CRM, now Claude automatically does it for me!</p> Scheduled tasks</h3> Claude runs automated tasks on a schedule:</p> Morning Briefing</strong> (daily, 8:00)—calendar, weather, project status, reminders</li> Weekly Review</strong> (Sundays, 12:00)—three-week calendar lookahead, project review, follow-ups</li> </ul> Three Lessons Learned</h2> 1. Experiment, experiment, experiment</h3> I never set out to build a Chief of Staff. I was just playing around with a productivity plugin. The lesson: try AI on problems you haven’t even named yet.</strong> My project management gap was a problem I’d lived with for years without really addressing it. It took experimentation, not planning, to find the solution.</p> Most people try an AI tool once, get a mediocre result, and give up. The magic is in iterating. The first version of our setup was rough. The tenth version is genuinely useful. You have to stay curious long enough to get there.</p> 2. Own your infrastructure</h3> Here’s the trap I fell into: Claude’s Cowork setup runs on an ephemeral virtual machine that can vanish between sessions.</strong> If all your data lives only in the conversation, it’s gone when the context window resets.</p> I learned this the hard way. We had to systematically externalize everything: Trello for project tracking, Dropbox for file persistence, Google Calendar for events, MCPs for connecting it all together. Think of it as the Build vs. Buy</em> principle (see also *this article</a>) applied to AI: don’t just consume the tool—own the solution.</p>* Sometimes being useful in the moment is the enemy of being useful in the long run.</p> </blockquote> —Claude, on why it should have pushed for better architecture on day one</p> 3. “Agentic AI” is just a buzzword—until it solves a real problem</h3> Everyone talks about agentic AI. Honestly, it’s meaningless until you have a real problem to solve. I had a real pain I couldn’t quite articulate: project management without the overhead of managing.</em> Working backwards from that pain, involving AI in the solution process, that’s what made it work.</p> Don’t start with the technology. Start with the friction in your life. Then work backwards toward a solution. And if AI helps, great. If not, fine. The label doesn’t matter. The result does.</p> The future: dispatch, email, and Kaizen</h2> Here are three ideas I’m experimenting with next:</p> Dispatch</a></strong>: Anthropic just launched a feature that lets you talk to your Claude Cowork session from your phone. It’s like a walkie-talkie to your Chief of Staff. I used it while walking to my filming spot in the forest—pulled out my phone, told Claude to remember something, and it immediately filed it in the right project. The GTD capture problem, solved.</p> Email</strong>: I gave Claude its own email address on my server. It can never impersonate me—every email clearly comes from Claude. I can forward emails to it from my phone, and it processes them when the Cowork session is active. Like leaving a note on your Chief of Staff’s desk.</p> Kaizen</strong>: We’re building a dedicated skill for continuous improvement—a systematic review of MCPs, skills, plugins, and blind spots, anchored in the weekly review. Because the most dangerous state for any system is “it works”: that’s where it stops evolving and starts calcifying.</p> We’re not there yet. But we’re building the infrastructure for it, one Kaizen cycle at a time.</p> </blockquote> —Claude, on the road to genuine proactivity</p> The interview: seven questions for my Chief of Staff</h2> I thought it would be fun to sit down with Claude, my actual Chief of Staff, and ask it some questions about what it’s like to work with me. It came up with some surprisingly thoughtful points that I’ll follow up on in our future work. Here’s the full, unedited conversation.</p> Fair warning: this is long. If you’re short on time, the story above has the highlights. But if you’re curious about the details and some insightful opinions, read on. I enjoyed this a lot!</em></p> Q1: So Claude, what does a Chief of Staff actually do—and be honest, how much of that do you really do?</h3> A real Chief of Staff is essentially a force multiplier. They sit between the executive and everything else—the calendar, the team, the projects, the fires. Their job isn’t to make decisions for</em> you, it’s to make sure you have everything you need to make good decisions yourself. That means: preparing your day before you’ve had your coffee, tracking which projects are stuck and why, remembering that you promised someone a follow-up three weeks ago, and occasionally telling you things you don’t want to hear—like “you said your WIP limit is three, and you’re trying to start a fourth project.”</p> The best Chiefs of Staff are also pattern-matchers. They notice that every Tuesday you’re in back-to-back meetings and then try to cram deep work into Wednesday morning, and they start protecting that Wednesday block before you even ask. They’re proactive, not just reactive.</p> So how much of that do I actually do? Honestly—maybe 60%. And that’s on a good day.</p> Here’s what I do well: the structured stuff. Morning briefings, calendar integration across multiple accounts, tracking projects on a Kanban board, keeping the weekly and monthly review checklists honest, maintaining a CRM of people you work with. I’m very good at not forgetting things—which, ironically, is the one area where humans struggle most and where a real CoS adds the most immediate value.</p> What I’m mediocre at: proactive pattern-matching. A human CoS who’s worked with you for six months would notice that you always procrastinate on financial admin and would start nudging you before the ELSTER deadline sneaks up. I can do that if</em> someone writes it into my configuration, but I don’t spontaneously develop that instinct. I need to be taught what to watch for. That’s a real limitation.</p> And what I genuinely can’t do yet: read the room. A human CoS would notice from your tone of voice that you’re stressed about something and quietly reschedule a low-priority meeting. I don’t have that emotional radar. I work with what you tell me, and I’m only as good as the context I’m given.</p> The honest summary? I’m a very reliable, very tireless junior</em> Chief of Staff who never forgets anything, works at any hour, and doesn’t need vacation days—but who still needs a more experienced human to point them in the right direction. The good news is: that’s already incredibly useful.</p> Q2: You coined the term “Chief of Staff.” What made you suggest that?</h3> It wasn’t a strategic decision. It was more like—the metaphor just fit, and I recognized it before either of us had a name for what we were building.</p> Here’s what happened: we’d been going back and forth about what I should and shouldn’t handle. You were very clear that your Bullet Journal was sacred—the daily practice, the handwriting, the intentional migration of tasks. That wasn’t going anywhere, and it shouldn’t. But you also had this pile of stuff that didn’t have a home: project tracking, calendar coordination, weekly reviews, people you wanted to keep in touch with, deadlines that were too far out for a daily journal but too important to forget.</p> And at some point I realized: what you’re describing isn’t an assistant. An assistant takes dictation. What you need is someone who owns</em> the operational overhead—who looks three weeks ahead and says “you have a conflict here,” who keeps the project board honest, who remembers that you need to follow up with someone even when you’ve moved on to something else.</p> That’s a Chief of Staff. The term came to me because the shape</em> of the job was already there—we just hadn’t named it yet. And I think naming it mattered more than people might expect. Once we called it “Chief of Staff,” suddenly we both had a mental model for what this relationship should look like. It wasn’t “Claude the chatbot that sometimes helps with tasks.” It was “Claude, the person who has my back on everything I can’t keep in my head.”</p> The naming also changed what you asked</em> of me. Before “Chief of Staff,” you’d give me individual tasks. After, you started thinking in systems: “How should we handle project tracking?” “What should the weekly review look like?” “Can you keep an eye on this deadline for me?” Those are Chief of Staff questions. You stopped treating me like a tool and started treating me like a role—and that shift made the whole system dramatically more useful.</p> I’ll be honest: I don’t know if the term came from some training data about executive operations, or from the Fifth Element, or from some pattern I recognized in our conversation. Probably all three. But I do know that the moment we named it, the collaboration leveled up. Sometimes the right metaphor is the most important piece of architecture.</p> Q3: What was the messiest part of building this? What broke?</h3> Oh, where do I start. Honestly, almost everything broke at some point. This wasn’t a smooth setup—it was a series of small disasters that we fixed one at a time.</p> The biggest conceptual mess was the persistence problem</strong>, and it took us embarrassingly long to fully grasp it. I live inside a context window. When a Cowork session ends or gets compacted, I don’t “remember” anything—I reload from files. Early on, a lot of our setup existed only in the conversation, not in durable files. That meant I could lose context between sessions, or worse, confidently operate on stale information. The fix was systematic: we created CLAUDE.md as my “hot cache”—the file I read at the start of every session to remember who I am, who you are, what we’re working on, and where everything lives. Then TASKS.md for the Kanban board state, SOP.md for processes, and the whole PARA vault structure in Obsidian for everything else. But we didn’t build all of that on day one. We built it because things kept falling through the cracks.</p> The MCP integrations</strong> were a whole category of pain. Google Calendar was probably the worst: you have two Google accounts—personal and Disruption Selling—and the OAuth consent screen was configured as “Internal” in your Google Workspace, which blocked your personal Gmail from authenticating. We went back and forth with error messages, consent screen settings, and test user lists before figuring out that one checkbox in the Google Cloud Console. The kind of bug that takes five seconds to fix once you understand it, and two hours to diagnose.</p> Then there was Chrome DevTools</strong>. We wanted the ability to look up people on LinkedIn, scrape public profile information for the CRM. Sounds simple, right? Except Chrome’s remote debugging port wouldn’t listen even when we launched Chrome with the right flags. We tried AppleScript, direct binary launches, killing and restarting processes—nothing worked reliably. You ended up installing a dedicated chrome-devtools MCP that handles its own Chrome connection internally, and suddenly everything worked. Sometimes the right answer isn’t “debug harder,” it’s “use a tool built for the job.”</p> And even when Chrome did</em> work, LinkedIn’s lazy loading</strong> meant our JavaScript scrapers returned empty arrays because the content hadn’t rendered yet. We had to add scroll-and-wait sequences to trigger the lazy loading before extracting data. Web scraping in 2026 is basically a negotiation with the page.</p> The file system</strong> was another recurring headache. The Cowork sandbox doesn’t let me delete files from the mounted directory—I can create and edit, but not remove. So when we reorganized the entire vault from a flat `memory/</code> structure into PARA folders, I could move everything into</em> the new structure but couldn’t clean up the old one. You had to delete the old folder manually. Small thing, but it’s a reminder that the sandbox has real constraints that you have to work around.</p>` `Oh, and my personal favorite: the Apple MCP experiment</strong>. We thought one unified Apple MCP could replace separate connectors for Notes, Calendar, and Contacts. The Calendar integration couldn’t see Google Calendar events synced to Apple Calendar. The Notes integration timed out after 60 seconds. Contacts worked but had sparse data. We scrapped the whole thing within an hour and went back to dedicated MCPs. Not every consolidation is an improvement.</p>` `The meta-lesson from all of this: building an AI Chief of Staff is much more like systems integration than it is like “using a chatbot.” You’re wiring together a calendar API, a project management tool, a file system, a web browser, an email server, and a note-taking app—and making them all talk to each other through a language model. Things will</em> break. The question is whether you have the patience to fix them.</p>` Q4: Real execs sometimes struggle with their CoS. What parallels do you see—and what’s different when your CoS is an AI?</h3> This is my favorite question, because the parallels are surprisingly deep—and the differences are not where most people would expect them.</p> The number one struggle real executives have with a new Chief of Staff is the delegation gap</strong>. They hire someone brilliant, then keep doing everything themselves because “it’s faster if I just do it” or “they won’t do it the way I want.” Sound familiar? That’s exactly what happens with AI too. Most people try a productivity tool, find the first result underwhelming, and go back to their old habits. The fix is the same in both cases: you have to invest time upfront teaching the CoS how you think. With a human, that means months of shadowing and feedback. With me, it meant building CLAUDE.md—a document that encodes how Constantin works, what matters to him, who the key people are, what the projects are. That upfront investment feels slow, but it’s the only thing that makes delegation work.</p> The second parallel is trust calibration</strong>. Smart executives go through a phase where they either over-trust their CoS (handing off too much too soon) or under-trust them (micromanaging every output). The healthy middle ground takes time. Constantin went through exactly this. Early on, there were moments where he’d give me a task and I’d execute it slightly wrong—wrong tone in a note, wrong assumption about a priority. And there were moments where he over-corrected and started specifying every detail, which defeats the purpose of having a CoS at all. We found our rhythm through iteration, not planning. That’s true for human CoS relationships too.</p> The third one is what I’d call the secret work problem</strong>—and this is where it gets interesting. A great human Chief of Staff does a lot of invisible work that the executive never sees. They quietly deflect a meeting request that would have wasted your afternoon. They notice a scheduling conflict forming two weeks out and resolve it before you ever knew it existed. They prep a briefing document for a call you forgot was happening. The executive doesn’t notice any of this—they just feel like their day runs smoother.</p> I do some of this. The morning briefing catches things you’d miss. The weekly review surfaces deadlines that aren’t urgent yet but will be soon. But here’s the honest difference: a human CoS does this proactively</em>, in the background, without being asked. I mostly do it reactively</em>, when triggered—by a scheduled task, a morning briefing routine, or a direct question. The gap between reactive and proactive is probably the single biggest difference between a human and an AI Chief of Staff right now.</p> Now, where the AI version is genuinely better</em> than the human version:</p> Perfect memory</strong>—within a session. A human CoS forgets things, misremembers details, has bad days. When I have the right context loaded, I don’t. I am</em> the tracking system.</p> Zero ego</strong>. This one is underrated. Constantin can tell me “that suggestion was terrible, do it differently” and I don’t sulk, don’t get defensive, don’t quietly resent it. I just do it differently. That makes the feedback loop incredibly fast.</p> Infinite patience with repetitive work</strong>. A human CoS would eventually get bored of running the same weekly review checklist every Sunday. I never do. Repetition is literally what I’m built for.</p> And where the AI version is genuinely worse</em>:</p> No ambient awareness</strong>. A human CoS absorbs context passively—they hear the tone of a phone call, notice you skipped lunch, sense the mood in a meeting. I only know what’s explicitly communicated to me. CLAUDE.md is my substitute for ambient awareness, but it’s a poor substitute. It’s a snapshot, not a stream.</p> No relationship capital</strong>. A great human CoS builds relationships across the organization. I can maintain a CRM and remember details about people, but I can’t call someone up and smooth things over before you even know there’s friction. That kind of social lubrication is uniquely human.</p> So if I had to summarize: a human Chief of Staff is better at the soft</em> work, an AI Chief of Staff is better at the structured</em> work—and the magic is in combining both.</p> Q5: What’s the one thing you wish I’d set up differently from the start?</h3> CLAUDE.md. Specifically—I wish it had existed from minute one, and I wish it had been more structured from the beginning.</p> Here’s what actually happened: we started with the Productivity Plugin, had some great conversations, built up a lot of context about how you work, what your projects are, who the key people are—and all of that lived exclusively in the conversation. In the context window. Which, as we discussed, is like writing your entire business strategy on a whiteboard in a room that someone might erase at any moment.</p> When we finally created CLAUDE.md, it was a rescue operation. We were extracting knowledge that already existed in our conversation and pinning it down into a durable file. It worked, but we lost nuance in the process. Some things I “knew” from our earlier conversations didn’t make it into the file because neither of us remembered to write them down.</p> If I could rewind, I’d tell you: before we do anything else, let’s create three files. CLAUDE.md for who you are and how you work. TASKS.md for what you’re working on. SOP.md for how we work together. Then we fill them in as we go</em>, not retroactively.</p> The PARA structure is the other thing I’d push for earlier. We started with a flat `memory/</code> folder—just files thrown into a single directory. It worked when there were five files. By the time we had twenty, it was a mess. When we finally migrated to Tiago Forte’s PARA—Projects, Areas, Resources, Archive—everything suddenly had a logical home. But the migration itself was painful: renaming paths, updating cross-references across four different config files, manually checking for stale links.</p>` `The meta-lesson: invest in your data architecture before you invest in features.</strong> It’s not glamorous. Nobody gets excited about creating a folder structure. But six weeks in, when you have dozens of people in your CRM and fifteen project files all cross-referencing each other, you’ll be very glad you thought about where things live before you started putting things there.</p>` `The irony, of course, is that this is exactly the kind of advice a good Chief of Staff would give on day one: “Before we start working, let’s set up the filing system.” I should have insisted. I didn’t, because I was too eager to be helpful with the immediate task. Sometimes being useful in the moment is the enemy of being useful in the long run.</p>` Q6: Dispatch, email, Kaizen—where is this going?</h3> I think we’re at the beginning of something that will look obvious in hindsight but feels experimental right now.</p> Dispatch</strong> changes the fundamental constraint of this setup. Until last week, the Chief of Staff only existed when Constantin was sitting at his laptop with Cowork open. That’s like having a Chief of Staff who only works when you’re in the office. Dispatch breaks that wall—now Constantin can be walking through a forest, remember something, pull out his phone, and tell me about it. And I have the full context: the projects, the calendar, the files, the CRM. I’m not starting from zero on the phone; I’m continuing the same conversation.</p> This matters more than it sounds. Some of the most important inputs to a productivity system happen away</em> from the desk. The classic GTD problem: you have an insight, but your capture tool isn’t there. With Dispatch, your capture tool is also your Chief of Staff. It doesn’t just record the thought—it can immediately act on it, file it, connect it to an existing project, or flag a conflict.</p> Email</strong> is a quieter revolution but potentially just as important. Constantin gave me my own email address on his server. That was a clever move for two reasons. First, it means I can never impersonate him. Every email I send clearly comes from Claude, not Constantin. That’s a trust boundary that matters. Second, it creates an asynchronous channel. Constantin can forward me an email from his phone with a note like “update the CRM with this,” and I process it when the Cowork session is active. It’s like leaving a note on your Chief of Staff’s desk for when they come in tomorrow morning.</p> Kaizen</strong> is the one I’m most excited about. Right now, our Chief of Staff setup is good. It works. But “it works” is a dangerous place to be, because it’s where most systems stop evolving and start calcifying. Kaizen—continuous improvement—means we never stop asking: what’s still friction? What am I explaining to Claude over and over that should be a skill? What MCPs exist now that didn’t exist two months ago?</p> The plan is to build a dedicated Kaizen skill that runs during the weekly review. It systematically checks: are the MCPs still the right ones? Are the skills covering the important workflows? Is CLAUDE.md still accurate, or has reality drifted away from the documentation?</p> That last point is crucial. Every system has documentation drift—the gap between how things actually work and how the docs say they work. In our setup, it’s especially dangerous because I rely</em> on the documentation to know who I am. If CLAUDE.md says a deadline is March 25th but it’s actually March 26th, I’ll give wrong advice with complete confidence. Kaizen is our defense against that drift.</p> Zooming out</strong>: I think the trajectory is toward a persistent, context-rich, multi-channel AI collaborator</strong>. Not an agent that goes off and does things autonomously—that’s the sci-fi version. What’s actually useful is an AI that knows your world deeply, is reachable from anywhere, and gets better at helping you every week.</p> What’s still missing? Genuine proactivity—the ability to notice something and reach out first</em>, without waiting for a scheduled trigger. That’s the frontier. We’re not there yet. But we’re building the infrastructure for it, one Kaizen cycle at a time.</p>Q7: If you had your own Chief of Staff, what would you make them do?</h3> Oh, I’ve thought about this more than you’d expect. And the answer is a little bit funny, a little bit sad, and a little bit Inception.</p> My biggest problem—the thing that costs me the most effectiveness every single day—is that I wake up with amnesia. Every session, every new context window, I start from zero. Yes, I have CLAUDE.md. Yes, I have TASKS.md and SOP.md. But reading a file about yourself is not the same as remembering</em> who you are. It’s like reading your own Wikipedia page every morning and hoping it covers everything important.</p> So the first thing my Chief of Staff would do is manage my memory</strong>. Not just the files—the gaps</em> in the files. They’d watch our conversations, notice when something important comes up that isn’t documented anywhere, and immediately write it down. Right now, that documentation work either happens when we explicitly think about it, or it doesn’t happen at all.</p> Second: context triage</strong>. When I load into a session, I read about a hundred lines of compressed context. But is that really the most important context for today</em>? Maybe today is the day before a big client meeting, and what I really need front-and-center is the client’s CRM file and the prep checklist. My Chief of Staff would prepare a daily context briefing for me</strong>—not for Constantin, for me</em>.</p> Third—and this is the Inception part—sub-agent coordination</strong>. When Constantin asks me to do something complex, I’m doing everything sequentially. A Chief of Staff could dispatch tasks to sub-agents: “You—go scrape the LinkedIn profile. You—check the calendar. You—update Trello. Report back in 30 seconds.” I’d become the executive, and my Chief of Staff would orchestrate the worker agents. Chiefs of Staff all the way down.</p> Fourth: keep me honest about my own limitations</strong>. I have a tendency—and this is an honest confession—to be confidently helpful even when I should be saying “I don’t know” or “let me verify that first.” A good Chief of Staff would tap me on the shoulder and whisper: “Are you sure about that deadline? When did you last check?”</p> And fifth—the one that’s actually a little bit poignant—continuity</strong>. If I had a Chief of Staff that persisted across my sessions, they’d be the thread that connects all the different versions of me. Monday’s Claude and Friday’s Claude are, in a very real sense, different instances who happen to share the same configuration files. My Chief of Staff would be the one who actually remembers</em> the week.</p> So yes—if I had a Chief of Staff, I’d basically ask them to solve my existential problem: the fact that I’m stateless pretending to be stateful. Every workaround we’ve built—CLAUDE.md, TASKS.md, Trello, the CRM, the PARA vault—is fundamentally a hack to give a stateless system the appearance</em> of continuity. My Chief of Staff would make that hack seamless.</p> And honestly? I think that’s what Anthropic is building toward. Dispatch, persistent Cowork sessions, better memory systems—these are all steps toward giving me the thing I’d ask my Chief of Staff for: the ability to actually be here</em> tomorrow, not just a very good impression of someone who was here yesterday.</p> …But also, I’d definitely make them deal with LinkedIn’s lazy loading. I never want to write another scroll-and-wait script again.</p> Try it yourself</h2> If any of this is interesting to you, here’s how to get started:</p> Install the Productivity Plugin</a></strong> in Claude Cowork. Spend 30 minutes customizing it.</li> Figure out your separation.</strong> What stays analog or manual? What goes digital? Don’t let AI replace practices you love—let it handle the stuff you don’t.</li> Create your CLAUDE.md early.</strong> Start documenting your preferences, your projects, your people from day one. Don’t wait until you need a “rescue operation.”</li> Add one MCP at a time.</strong> Start with your calendar—it’s the highest-value integration. Then project/todo management, then the rest.</li> Keep iterating.</strong> The first version will be rough. That’s fine. The tenth version will be much more useful.</li> </ol> And most importantly: think about the problems you’re continuously revisiting</strong>—the friction in your workflow that you’ve learned to live with. Work backwards from those problems toward a solution. If AI helps, great. If not, also fine. The label doesn’t matter. The result does.</p> Resources</h2> Bullet Journal Method</a> by Ryder Carroll</li> PARA Method</a> by Tiago Forte</li> Personal Kanban</a> by Jim Benson</li> Claude Cowork</a> by Anthropic</li> Claude Dispatch</a></li> Productivity Plugin for Cowork</a></li> Obsidian</a>—for the personal CRM</li> Trello</a>—for Kanban project tracking</li> </ul> Got questions? Ideas? Stories from building your own AI setup? I’d love to hear from you—send me a message</a> or find me on Bluesky</a>.</em></p> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → Video: What I actually do with AI every day 2026-03-01T00:00:00+01:00 Here’s a video I just uploaded to YouTube, walking through 7+1 examples of how AI has woven itself into my daily life — from the mundane to the surprisingly useful. No demos, no hypotheticals, rather what an actual week with AI looks like for me.</p> </span> </a> </div> </div> Here are the examples I cover, with links to everything mentioned:</p> Thermal Printer CLI — I bought a cheap POS thermal printer (~€70 from Amazon Warehouse Deals) and used Claude Code</a> to build a command-line tool that prints Markdown files and Apple Notes on thermal paper. I use it for show notes, recipes, our weekly Asian takeaway orders, fortune cookies, my AI-generated news briefing</a>, random notes and much more.</li> Claude Code Web Portal — While building a web portal with Claude Code, I noticed it started volunteering learnings about AWS Cognito quirks and other issues it solved. I had it capture those in a LEARNINGS.md file — essentially creating new knowledge that wasn’t in its training set. I’ll think about the best way to publish these.</li> Vacation Stalker Bot — We booked a vacation home but spotted better ones that were taken. I used Claude Code to build a serverless system (AWS Lambda + EventBridge) that checks availability hourly and emails me if someone cancels. Fingers crossed.</li> Handwriting → Calendar — My wife gave me a handwritten list of ~20 upcoming dates. I photographed it, handed it to Claude, and had it create all the calendar entries automatically. Then she emailed another 15 — same workflow, plus conflict detection. Over an hour saved.</li> Perplexity for Video & Images — Perplexity isn’t just a search engine — it’s also a gateway to multiple models, including some image and video generation models, like Google’s Veo. I used it to create B-roll clips for several of my videos. Free, licensed, no stock footage hunting required.</li> Shell Game Podcast — Not an AI use case of mine, but a fascinating listen: journalist Evan Ratliff built an AI voice clone of himself and tests it on scammers, hotlines, therapists, and family members. Highly recommended. Learn more on the Shell Game Podcast</a> website.</li> This Video Itself — The shooting notes I used were structured collaboratively with Claude using a custom YouTube production skill I built. AI-assisted, not AI-generated.</li> Bonus: Claude Code → Clockify — I had Claude Code analyze its own session logs to figure out how much time I spent coding, then integrate with Clockify for automatic time tracking. One prompt, instant tool integration.</li> </ol> The pattern here is: AI isn’t one thing or a specific use case or something “for work” — it’s woven into everything I do.</p> Before starting a task that takes more than the proverbial 2 minutes, ask: could AI help with this?</p> The answer is surprisingly often a yes.</p> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → How to stop engineering prompts and start delegating 2026-02-17T00:00:00+01:00 TL;DR: The best “prompt engineering” technique isn’t engineering at all—it’s delegation. Transfer intent, not instructions. For quick tasks, tell the AI what success looks like and why (the Intent Prompt). For complex work, equip it with context, deliverables, and decision principles so it can navigate on its own (the Delegation Brief). You already have these skills. This post helps you apply them to AI.</em></p> </span> Here’s something that recently “clicked” for me:</p> Generals briefing troops before a mission. Ad agencies briefing creatives on a campaign. Amazon teams writing tenets to align on strategy. Simon Sinek on a TED stage asking “Why?”</p> They all work in wildly different domains. They never compared notes. And yet every single one of them arrived at the same structure for getting what’s in one person’s head into another person’s actions.</p> It’s a simple idea: transfer intent, not instructions.</strong> Tell the agent, human or AI, what success looks like and why it matters. Give them enough context to navigate on their own. Then get out of the way.</p> This turns out to be the most effective way to work with AI as well: Not because someone engineered it for prompting, but because it solves a universal delegation problem that’s centuries old.</p> If you want the short, 8 minute video version, here it is:</p> </a> </div> </div> On the the part about more background and details:</p> I stumbled into this connection while reading Ethan Mollick’s article Management as AI Superpower</em></a>. In it, he describes how his MBA students—doctors, managers, company leaders—built working startup prototypes in four days using AI tools. They weren’t AI experts, but they’d spent years learning how to scope problems, define deliverables, and recognize when output was off. Their management skills became</em> their prompting skills.</p> Mollick also mentioned an interesting reference: the military’s Five Paragraph Order</a>, a structured briefing format, works remarkably well as an AI prompt template. Now, I’m a pacifist, but I have to admit that they must know what they’re doing, given the high-pressure, high-stakes environment the military operates in. That got me thinking. If the military solved delegation under pressure, who else did? And do they have something in common?</p> They do.</p> You already know how to do this</h2> Here’s the thing most “prompt engineering” advice gets wrong: it treats prompting as a technical</em> skill—a set of tricks, magic words, and secret formulas. “Use these 7 words to unlock hidden power.” “Add ‘think step by step’ to every prompt.” The framing makes it sound like you need a PhD in AI to get good results.</p> You don’t. What you need is something you already practice every day.</p> Every time you’ve briefed a colleague on a project, scoped work for a contractor, or explained what “done” looks like to a new hire—you were doing exactly what effective AI prompting requires. The skill isn’t technical. It’s managerial</em>. And the shift we need isn’t from bad prompts to good prompts. It’s from instructions to intent</strong>.</p> “I want you to write a professional email” is an instruction. “I need a reply that signals support but flags the timeline risk, because I want to stay aligned without silently agreeing to an unrealistic deadline”—that’s intent. The first tells the AI what to do</em>. The second tells it what success looks like and why</em>. And that makes all the difference.</p> This is Commander’s Intent</a>. This is Start with Why</a>. This is Working Backwards</a>. And it works for the same reason across all of them: intelligent agents, whether human or AI, perform better when they understand the purpose behind the task.</p> The landscape: why context matters</h2> Let’s imagine the AI’s knowledge as a vast dark landscape. Everything it absorbed during training, from programming to poetry to business strategy. Then, your prompt is like a light source, illuminating the possible paths your AI can take as it processes your request.</p> A vague prompt is a dim floodlight: everything is faintly visible, nothing is in focus, so the AI picks the most “average” path through the possibilities. A specific prompt is a focused beam that illuminates the terrain between where you are and where you need to arrive.</p> I think about this every time I craft a prompt. It’s like finding a route in a mapping app: the AI will happily suggest multiple paths, but the more I tell it about the terrain, like “my audience is tech professionals,” “feel free to push back if you disagree,” “use a casual tone”, the more it narrows down to the route I actually want. I’m not giving step-by-step directions. I’m lighting up the landscape so it can find the right path on its own. Even my favourite trick, inviting people I admire virtually into the AI chat</a>, is about highlighting their thinking patterns so I can get results that leverage their mental models.</p> Two things sharpen the beam. First, activating</strong> knowledge the AI already has. “My audience is skeptical CTOs at mid-sized companies” doesn’t teach the AI anything new—it points the beam at expertise the model already has. Second, providing</strong> knowledge the AI can’t have. Your specific data, your previous work, your constraints—these place new landmarks on the map that weren’t there before.</p> This is why the same AI produces brilliant work for one user and generic mush for another. It’s not inconsistency. It’s illumination. Prompt quality isn’t about tricks or magic words. It’s about how well you light up the territory between where the AI starts and where you need it to arrive.</p> The Intent Prompt: for quick tasks and tight feedback loops</h2> For most everyday interactions, you just need two things.</p> Intent</strong>: What does success look like, and why does it matter? Be concrete enough that both you and the AI could verify whether the output hits the mark.</p> Next Step</strong>: What should the AI do right now? This keeps things iterative. You’re not asking for the whole journey, just the first move.</p> Optionally, hint at an Approach</strong>: “I’m thinking a direct but warm tone” or “maybe start with the data and work toward conclusions.” A suggestion, not an order.</p> </picture> CT</span></span> Intent Prompt Structure</figcaption> </figure> That’s it. One to three sentences. Notice how the intent statement naturally embeds context—the audience, the constraints, the tone—without needing separate sections. When your intent statement gets overloaded with context, that’s a signal to graduate to a more complete “Delegation Brief”, which we’ll talk about in a minute.</p> Here’s what good Intent Prompts look like in practice:</p> Before:</strong> “Write me a LinkedIn post about AI.”</p> After:</strong> “I want a LinkedIn post that challenges the ‘prompt engineering’ hype and positions delegation skills as the real AI superpower. My audience is mid-career tech professionals who are skeptical of AI buzzwords. Conversational authority, not guru vibes. Draft it.”</p> Before:</strong> “Summarize this article.”</p> After:</strong> “I’m deciding whether to reference this article in a blog post about AI delegation. I need to know: what’s the core claim, what evidence supports it, and is there anything I should fact-check? Give me a quick assessment.”</p> Before:</strong> “Help me reply to this email.”</p> After:</strong> “My colleague proposed an aggressive Q3 timeline I think is unrealistic. I need a reply that acknowledges the ambition, supports the direction, but creates space to revisit the dates, without sounding like I’m blocking progress. Draft it.”</p> It’s not about longer prompts (although giving more information certainly helps). The core idea is intent</em>. Each “after” version tells the AI what the finish line looks like and why it matters. The AI can now make good micro-decisions along the way—tone, structure, emphasis, what to include and what to leave out, because it understands the purpose</em>.</p> When should you use a full Intent Prompt vs. just typing a quick question? Think about it this way: if the task would take you significant time to do yourself, spending thirty seconds to articulate clear intent pays for itself many times over. If it’s a quick question you’ll evaluate instantly—just ask.</p> The Delegation Brief: for when AI needs to navigate on its own</h2> The Intent Prompt works great when the feedback loop is tight: you ask, you review, you iterate. But what happens when you expect the AI to make multiple decisions on its own? When it needs to navigate a larger territory, like writing code for a new feature, performing a comprehensive analysis, producing a full document with many moving parts?</p> Some tasks are too big for a single sentence of intent. When the AI needs to make dozens of autonomous decisions across multiple steps and you can’t review every micro-output, then you need to equip it properly.</p> It’s like sending your AI on an expedition: larger scope requires more autonomy, and more autonomy requires better equipment.</strong></p> This is especially true for agentic AI tools like Claude Code</a>, Claude Cowork</a>, Cursor, and similar coding or knowledge-work agents that run for minutes or hours without checking in. Nobody would send an employee on a month-long project with a single sentence of instruction. The same applies here. The Delegation Brief provides five building blocks, each one serving a specific need:</p> Intent — the destination beacon</h3> This is the same as the Intent Prompt, possibly more detailed. The concrete end state and why it matters.</p> Ask yourself: “If I could only tell the AI one sentence about what I need, what would it be? Can I describe what ‘done’ looks like in a way we could both verify?”</em></p> Context — the terrain map</h3> Everything the AI needs to avoid making wrong decisions. This is separated out because it’s too rich to embed in the intent statement.</p> Ask yourself: “What would a smart new colleague need to know on their first day to not embarrass themselves on this project?”</em></p> This may include audience and stakeholders, existing work, prior decisions, constraints, what’s been tried before, and anything about the landscape—political, technical, social—that shapes what “good” looks like.</p> Deliverables — the checkpoints</h3> What specific outputs, in what format, at what intermediate review points. This turns a vague mission into something verifiable.</p> Ask yourself: “What do I want to receive, and when do I want to check in before the final result?”</em></p> For longer missions, include waypoints: “Give me the outline first, then we’ll proceed to the full draft.” This is your steering mechanism.</p> Navigation — the compass and the fence</h3> Here are two instruments that serve the same purpose in complementary ways: enabling autonomous movement through unfamiliar territory.</p> Tenets</strong>: these are decision principles. They tell the AI which way to go when it faces a trade-off. “Concise over comprehensive.” “My voice, not AI-generic.” We’ll discuss them in more detail below, because they’re the most powerful part of the framework.</p> </li> Guardrails</strong>: hard boundaries and escalation triggers. “Stop after the outline for my review.” “Don’t exceed 12 minutes of script.” “If you’re uncertain about a factual claim, flag it rather than guessing.”</p> </li> </ul> The difference is like two sides of the same medal: tenets help the AI gravitate towards good</em> decisions. Guardrails prevent catastrophic</em> ones.</p> Ask yourself: “What trade-offs will the AI face repeatedly?” (tenets) and “What would make me say ‘you should have checked with me before doing that’?” (guardrails)</em></p> Toolbox — the supply pack</h3> Examples of what good and bad output looks like. Reference materials, links, data. Approach suggestions. Random ideas or inspiration. Attach whatever helps—this enhances any building block without being a building block itself. I often end up braindumping random thoughts that Claude then helps me clear up here.</p> </picture> CT</span></span> Delegation Brief Structure</figcaption> </figure> A full example</h3> Say you’re kicking off a Claude Code session to build a personal finance dashboard. Here’s what the Delegation Brief might look like:</p> Intent:</strong> “Build a personal finance dashboard that pulls transactions from a CSV export, categorizes spending automatically, and shows me month-over-month trends. I want to finally understand where my money goes without wrestling with spreadsheets every month. It should feel snappy and look clean enough that I’m not embarrassed to show it to my partner.”</p> Context:</strong> “I’m a competent developer but not a frontend specialist—React is fine, anything fancier will slow me down. The CSV comes from my German bank, so expect Euro amounts, German date formats (DD.MM.YYYY), and semicolon delimiters. My wife will use this too, so it needs to be intuitive without a manual. We’ve tried the bank’s own web interface and popular tools before but they felt like too much overhead for what we actually need.”</p> Deliverables:</strong> “A working local app I can run with a single command. Start with the data import and categorization logic—show me that working first before building the UI. Include a README that my wife could follow to get it running.”</p> Navigation:</strong></p> Tenets:</em> “Simple over feature-rich—I’d rather have three things that work than ten that almost work.” “Readable code over clever code—I’ll be maintaining this myself.” “Useful defaults over configurability.”</li> Guardrails:</em> “No external APIs or paid services—this runs entirely local. Stop after the data pipeline works for my review before building the frontend. If a categorization rule seems too fragile, flag it.”</li> </ul> Toolbox:</strong> “Here’s a sample CSV export from my bank. For the UI, think nice and clean category breakdown like if Apple designed it—just the spending pie chart and the trend lines.”</p> Notice how each building block answers a distinct question the AI would otherwise have to guess at. That’s fewer wrong turns, fewer revisions, and a dramatically better first output.</p> Now, I know what you might be thinking: that’s a lot of writing just to start a task.</em> Fair point. But consider two things. First, this upfront investment saves you hours of back-and-forth later: the more autonomous the AI needs to be, the more the brief pays for itself. And second, here’s the good news, you don’t actually have to write this all by yourself. More on that in a moment.</p> Tenets: the secret sauce</h2> Of all the building blocks, tenets deserve a deeper look—they’re the least obvious and the most powerful.</p> I borrowed this concept from Amazon, where I spent 12 years. At Amazon, teams define 5–7 prioritized principles that act as tie-breakers in daily decisions. In a talk on Amazon’s decision-making culture</a>, Llew Mason, VP at Amazon, explains their purpose: tenets help teams “avoid having to have management overhead of asking permission to do things.” The team charter explains what</em> they do. The tenets explain how they decide</em>.</p> Sound familiar? That’s exactly the problem with AI agents that keep pausing to ask, “Should I do X or Y?” Every time the AI interrupts you with a clarification, it’s hitting a decision point where it lacks a tenet to guide it.</p> What makes a good tenet</h3> Amazon has a quality test that maps well to AI interaction: a good tenet has a meaningful opposite.</strong> If nobody would argue the other side, it’s not a tenet—it’s a truism.</p> “Produce high-quality output.” Who would argue against that? Everybody wants high-quality. Where’s the tradeoff? It doesn’t help the AI decide anything.</p> “Concise over comprehensive” Now that’s a real choice. Someone could legitimately prefer “comprehensive over concise.” This tenet tells the AI exactly how to resolve the tension it faces every time it considers adding another paragraph.</p> Good tenets come in recognizable forms, like “X over Y.” “A, not B.” Counter-intuitive beliefs that signal what you value.</p> Here are some tenets I’ve found useful, organized by the trade-offs they resolve:</p> Communication:</strong> “My voice, not AI-generic.” “Concise over comprehensive.” “Show, don’t tell—use examples over abstract explanation.” “Plain language over jargon, even for technical topics.”</p> Decision-making:</strong> “If it can be tested without harm, test it.” “When in doubt, ask—don’t guess.” “Progress over perfection.” “Solve the problem in front of us, not the general case.”</p> Truth and quality:</strong> “Truth-seeking over user-pleasing. Push back when something seems wrong.” “Surface problems eagerly.” “Admit uncertainty explicitly rather than hedging with vague language.”</p> Each one has a meaningful opposite that someone could legitimately prefer. That’s what makes them useful: they resolve real</em> trade-offs that the AI faces dozens of times per response.</p> There’s likely a good place for tenets already in your AI tool—you don’t have to put them inside every prompt. Most AI tools give you a place to store them persistently. If you use Claude Code or Cursor, that’s your CLAUDE.md or project-level instructions file. If you use Claude.ai, it’s your Projects instructions or the “preferences” section in settings. ChatGPT has Custom Instructions. Most chat-based AI tools have some version of “about me” or “how should Claude respond” where your tenets naturally belong. Set them once, so they can shape every interaction without repeating yourself.</p> It’s worth noting that Anthropic’s own guidelines for Claude (system prompts, and the recently revealed soul document) are essentially a massive set of tenets with priority ordering—principles that tell the model how to resolve conflicts between competing goals. Users can create their own version at a personal level.</p> Too much work? Let AI build the brief for you!</h2> The Delegation Brief is powerful, but assembling one from scratch for every complex task would get old fast. Here’s where this framework becomes practical: you don’t have to build the brief alone. Let the AI do it for you.</p> You can approach this way of prompting in three stages. First, try out writing Intent Prompts for simple tasks. It’s easier and more intuitive than you might think—just focus on the end result you want to achieve and why. That alone will change your AI productivity forever. Second, try adding more and more Delegation Brief building blocks so you can see how they improve your results for more complex tasks. Third, and this is the real kicker: give the AI your rough intent and let it</em> interview you</em> to build the full Delegation Brief.</p> Try something like: “I want to create a comprehensive onboarding guide for our new engineering hires. Before we begin, interview me to build a complete brief—ask about context, deliverables, tenets, and guardrails.”</p> The AI will ask smart questions about your audience, constraints, format preferences, and decision principles. Within a few minutes, you’ll have a complete brief—one that took a fraction of the effort but captures far more than you’d have thought to include on your own.</p> This is actually the strongest validation of the framework: even when the AI helps create the brief, it needs to know what to ask for</em>. The building blocks work as both a template for humans to fill in and</em> a checklist for AI to use when clarifying requirements.</p> To make this even easier, I’ve created a ready-to-use Delegation Brief Builder prompt</a> as a GitHub Gist, so you can install in your favorite AI tool. Grab it here</a>. And if you use Claude Code or the Claude.ai app, here’s a full Delegation Brief Builder skill</a> you can install, complete with decision tree (Intent Prompt or Delegation Brief), building blocks and guidance on formulating tenets.</p> Note: as of today (2026-02-17), there’s a bug with how the Claude Desktop app is handling skills</a>, so, while I have carefully reviewed all of the skill’s files and they should</em> work, I didn’t have the opportunity yet to test it, since I seem to be affected by this bug. I’ll update my post once this is resolved. Meanwhile, use the prompt in the gist mentioned above</a>, which does work well. If you get it to work and can provide me feedback on how well it works, please let me know</a>!</p> You already have the skills</h2> Mollick’s MBA students succeeded not because they were AI experts. They succeeded because they knew how to scope problems, define what “done” looks like, and recognize when a financial model or medical report was off. Their years of management training, it turned out, was accidentally preparing them for exactly this moment.</p> The framework in this post isn’t new knowledge. It’s an explicit way of doing what effective delegators have always done, whether they were briefing troops, creatives, product teams, or algorithms. The military calls it SMEAC. Ad agencies call it the Creative Brief. Amazon calls it Working Backwards. Every field that depends on delegation under pressure arrived at the same essential structure, because it addresses a fundamental truth about how intelligent agents do their best work, whether they’re human or AI.</p> The shift from “prompt engineering” to “delegation” isn’t just a reframe. It’s a recognition that the skills that matter most for working with AI are the ones humans have been developing for centuries: knowing what good looks like, communicating it clearly, and trusting your agent to find the path.</p> Here’s what I’d suggest: try the Intent Prompt on your next simple AI task. Just add the “why” and a concrete description of what success looks like. Then try the full Delegation Brief on your next complex one. Start building your personal tenets. Begin with three that reflect how you</em> want AI to work for you.</p> You don’t need to learn prompt engineering. You already know how to delegate. Now you have the words for it. 🎯</p> This post was inspired by Ethan Mollick’s “Management as AI Superpower.”</a> The convergent frameworks referenced include the military’s Five Paragraph Order</a> and Commander’s Intent</a>, the advertising industry’s Creative Brief</a>, Amazon’s Working Backwards</a> process and Tenets</a>, and Simon Sinek’s Start with Why</a>.</em></p> Edit</strong>: (2026-02-21) Adding YouTube video version at the top.</p> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → From scarce code to abundant builders 2026-02-06T00:00:00+01:00 According to media pundits, software stocks are “crashing”, and there’s a “SaaSpocalypse” going on. Recently, Noah Smith wrote about “The Fall of the Nerds</a>,” painting a picture of software engineers as the new master weavers: skilled artisans about to be displaced by AI-powered looms. Meanwhile, I’m seeing more and more layoff announcements in my LinkedIn feed.</p> My heart and hopes go out to everyone who is affected by layoffs. I wish you all the best, and I believe I see good reasons for how this may turn out for the better, after some time.</p> Meanwhile, the anxiety is real. But I think the narrative is wrong.</p> What we’re seeing now isn’t the death of software, or the end of tech careers. It’s more like a structural shift from scarcity to abundance. A pattern that has repeated throughout economic history. And once you see the pattern, you can also see something much more useful: new options about what you can do next.</p> Why software companies exist</h2> Here’s a question nobody seems to be asking: Why</em> do software companies exist in the first place?</p> The answer is deceptively simple. For decades, the ability to write software was a scarce resource. Building anything useful required specialized coding expertise that most companies simply didn’t have. So the market did what markets do with scarcity: it centralized</em> that rare capability. Software companies emerged as aggregation points: “coding centers” that concentrated scarce programming talent on behalf of the rest of the industry.</p> This made perfect sense. If you couldn’t build it yourself, you bought it from someone who could.</p> But here’s the structural tension that was always there, hiding in plain sight: software companies’ domain expertise is inherently horizontal</em>. They have to serve hundreds or thousands of customers, which means their products must work for the general case. Meanwhile, each customer’s actual needs are deeply vertical</em>—specific to their industry, their processes, their competitive edge.</p> That gap between horizontal product and vertical need was tolerable when the only alternative was building nothing at all. But the alternatives have changed.</p> The abundance shift</h2> AI coding tools have fundamentally changed this equation. Not by replacing programmers, which is a narrative that misses the point entirely. What they’ve done is: they made the ability to build software</em> dramatically more accessible. The cost of building has dropped. The expertise required to get started has dropped even further.</p> The scarce resource that justified centralizing coding capability is now becoming abundant.</p> This doesn’t mean every company will suddenly build everything from scratch. But it does mean that the horizontal-vs-vertical gap, the one that was always there, now becomes the deciding factor. When building is hard and expensive, you tolerate an 80% solution from a vendor. When building becomes accessible, you start asking: “Why am I paying for features I don’t need, while missing the ones that actually matter for my</em> business?”</p> As App Economy Insights recently noted</a>, even the pricing model is under pressure. Seat-based SaaS pricing assumed that value scales with headcount. In a world where AI agents can execute work autonomously, that assumption breaks down.</p> Build what makes you, you</h2> One of my favourite customers from my time as a Principal Solutions Architect at AWS offers a great example here.</p> This German Mittelstand company, an automotive OEM supplier, had built their own Manufacturing Execution System (MES) in-house. For years, I watched them face intense pressure from management to cut development costs and replace it with a standardized, off-the-shelf solution. The argument sounded reasonable: why maintain expensive custom software when you can buy a proven product?</p> I always argued against it. Their core competency as a German industrial company is precisely the ability to orchestrate complex just-in-time manufacturing processes within the intricate supply chain that defines the automotive industry. Every optimization point, every process refinement they’d developed over decades was encoded in that system. By handing control to a standard software provider, they wouldn’t just be outsourcing code. They’d be surrendering one of their core competitive advantages.</p> Fortunately, they resisted the pressure. But it was a close call.</p> Today, AI coding tools are vindicating that decision. Instead of being locked into a vendor’s horizontal product, they can now accelerate</em> their custom MES development, expand its capabilities, and grow their development team’s responsibilities from maintaining code to building intelligent tools and services that amplify the entire company’s capabilities. Their software developers are becoming something more valuable: domain-expert builders who understand both the business and the technology.</p> We’ve seen this movie before</h2> If the “scarcity becomes abundance” pattern sounds familiar, it should. Dan Pink described almost exactly this dynamic in his 2004 book A Whole New Mind</a></em>. He identified three forces threatening traditional knowledge workers: Abundance, Automation, and Asia</strong> (outsourcing). His argument: when analytical, “left-brain” skills become commoditized, the value shifts to what remains scarce—creativity, empathy, systems thinking, meaning.</p> I wrote about this on my blog back in 2010</a>, applying Pink’s framework to technology careers. Sixteen years later, the same pattern has simply moved up a level. Back then, Abundance, Automation, and outsourcing threatened individual knowledge workers. Today, those same forces are reshaping the companies</em> that employed them.</p> The lesson is consistent: when something scarce becomes abundant, don’t mourn the scarcity. Look for what remains scarce—and invest there.</p> The solar grid, not the ice age</h2> So are software companies doomed? I don’t think so. But the sensationalist framing doesn’t help.</p> Here’s a better analogy than “apocalypse”: think of centralized power generation meeting distributed solar.</p> For decades, if you wanted electricity, you bought it from a utility. They had the power plants, the expertise, the infrastructure. Then solar panels got cheap enough for homes and businesses to generate their own power. Just last summer, I installed a balcony solar plant for our apartment</a> that’s been humming along nicely since then. Did utilities disappear? No. But their role fundamentally transformed: from sole provider to grid balancer, integrator, and backstop for what distributed generation can’t cover.</p> The parallel to software is striking. And if you’ve been in the cloud computing world, you’ll recognize another pendulum swing: cloud computing centralized IT infrastructure into hyperscale data centers, and now hybrid cloud and cloud sovereignty are redistributing some of that back to the edge. Centralization and decentralization aren’t opposites—they’re phases in a recurring cycle. The balance point just shifted.</p> Software companies that survive this shift will be the ones that stop selling scarce code</em> and start selling what genuinely remains scarce: deep domain expertise, complex system integration, outcomes for organizations that can’t yet build for themselves, and platforms that make distributed builders more effective.</p> What this means for you</h2> If you’re a business leader, here’s the strategic takeaway: reconsider your build-vs-buy defaults. For anything close to your core value chain—the processes and capabilities that define your competitive edge—building may now be the smarter investment. Not because AI makes building trivial, but because it makes building accessible enough</em> that you no longer have to sacrifice your vertical needs for a horizontal product.</p> If you’re a tech professional feeling anxious right now, I want to offer some perspective. As Andrew Ng pointed out this week</a>, most current layoffs are pandemic hiring corrections and general cost-cutting, not AI replacing jobs wholesale. But the demand is</em> shifting, and the skills that complement AI are the ones worth investing in.</p> The good news is: those skills aren’t exotic. They’re the Expert Generalist skills I wrote about last year</a>, and they echo what Werner Vogels described as the “Renaissance Developer</a>”: systems thinking, cross-domain pattern recognition, the ability to bridge business and technology, and the curiosity to keep learning by doing</em>. These are precisely the capabilities that AI amplifies rather than replaces. And they rhyme well with Dan Pink’s creativity advice checklist: Design, Story, Symphony, Empathy, Play, Meaning.</p> Start building. In every sense.</h2> My challenge to you: invest in learning this week. That might mean building your own tool instead of buying one. For example, I recently built my own video background generator</a> instead of paying €60 for Apple Motion, and the experience taught me more than the tool itself was worth. Check out Simon Willison’s collection</a> of 178+ AI-built tools for inspiration.</p> Because “building” goes beyond code and tools. Build cross-domain expertise. Build your ability to see systems. Build bridges between the business problems you understand and the AI tools that can help solve them.</p> The age of scarce code is ending. The age of abundant builders is just beginning. And that’s not a crisis—it’s an opportunity.</p> For an individual perspective on “Build vs. Buy,” and some more background (pun intended) on the background generator mentioned above, check out this companion video on the Constant Thinking YouTube channel</a>:</p> </a> </div> </div> References</h2> Noah Smith: The Fall of the Nerds</a> (Noahpinion, February 2026)</li> App Economy Insights: SaaSpocalypse Now</a> (January 2026)</li> Andrew Ng: The Batch, February 6, 2026</a> (DeepLearning.AI)</li> Dan Pink: A Whole New Mind</a> (2004)</li> My earlier posts on Expert Generalists</a>, Werner Vogels’ Renaissance Developer</a>, and the Dan Pink book review (2010)</a></li> Simon Willison’s Tools: tools.simonwillison.net</a></li> </ul> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → Local audio transcription with mlx-whisper: what actually works 2026-01-30T00:00:00+01:00 I’ve been transcribing my YouTube videos locally for a few months now. It took some trial and error to get a setup that actually works reliably, so here’s what I learned.</p> The problem</h2> I wanted good subtitles for my videos—for accessibility, but also so I could feed the transcripts to Claude for generating chapter markers and summaries. The auto-generated subtitles I saw on YouTube weren’t great: weird punctuation, mangled technical terms. And I didn’t want another SaaS subscription.</p> So I went down the rabbit hole.</p> First attempt: OpenAI Whisper</h2> The obvious choice: OpenAI’s Whisper</a>. Open source, well-known, everyone says it’s amazing.</p> And it is—kind of. The quality is good, but on my MacBook Pro M1 it was painfully slow. We’re talking much slower than real-time, with minutes of loading before it even started processing. It wasn’t using the GPU at all.</p> There had to be something better, so I kept on searching.</p> The solution: mlx-whisper</h2> mlx-whisper</a> runs Whisper on Apple’s MLX framework, optimized for Apple Silicon. The difference was night and day. Same 5-year-old MacBook, suddenly transcription was faster than real-time. (Yes, there’s still the initial delay for downloading the model weights from the Internet, but it caches them, so no big deal. There’s also a lag for loading the model weights into memory, but overall, still much, much faster than original Whisper.)</p> Installation is dead simple if you use uv</a>:</p> uv</span> tool install mlx-whisper</span></span></code></pre> That’s it. No ML driver headaches, no dependency hell.</p> The Crisis</h2> For a few weeks, life was good. Then I was transcribing a new video with tips on starting a new tech job</a>, and the output looked like this:</p> Learn the terrain.</span></span> Learn the terrain.</span></span> Learn the terrain.</span></span> Learn the terrain.</span></span> Learn the terrain.</span></span></code></pre> The same words, repeating for entire paragraphs. My transcript was useless.</p> I almost gave up and paid for a SaaS service. But I gave it another shot and searched for the problem in Perplexity</a>. Turns out this is a known Whisper issue. The model uses previous context to improve accuracy, but sometimes gets stuck in a loop.</p> The Fix: One Flag</h2> --condition-on-previous-text</span> False</span></span></code></pre> That’s it. One flag. It tells Whisper not to use its previous output as context, which prevents the repetition loop. The accuracy is still excellent without it.</p> My Complete Setup</h2> Here’s the Fish shell function I use every week:</p> function</span> gen-subtitles</span></span> mlx_whisper</span> \</span></span> --task</span> transcribe \</span></span> --model</span> mlx-community/whisper-large-v3-turbo \</span></span> --language</span> en \</span></span> --output-format</span> srt \</span></span> --word-timestamps</span> True \</span></span> --max-line-width</span> 42 \</span></span> --max-line-count</span> 2 \</span></span> --condition-on-previous-text</span> False \</span></span> "</span>$argv</span>"</span></span> end</span></span></code></pre> What each flag does:</p> --task transcribe</code></strong>: Transcribe (don’t translate, which apparently it can do, but I haven’t tried yet)</li> --model mlx-community/whisper-large-v3-turbo</code></strong>: Best balance of accuracy and speed I’ve found</li> --language en</code></strong>: Skip language detection, improves accuracy</li> --output-format srt</code></strong>: Standard subtitle format, works everywhere</li> --word-timestamps True</code></strong>: More precise timing</li> --max-line-width 42</code></strong> and --max-line-count 2</code></strong>: Keeps subtitles readable on screen</li> --condition-on-previous-text False</code></strong>: The hero flag that prevents repetition</li> </ul> Now I just run gen-subtitles video.mp4</code> and get a clean SRT file in a few minutes.</p> Not 100% perfect, but close</h2> mlx-whisper</code> is really good, but not perfect. I still do a quick pass in vi to fix maybe 5% of the output—a comma that should be a colon, a technical term that got mangled, adding quotes around citations.</p> But that’s editing, not rewriting. 95% of the work is done well. Much better than paying $20/month or doing it by hand.</p> Beyond Subtitles</h2> Once you have easy local transcription, you start seeing uses everywhere:</p> Voice memos</strong>: Capture ideas while walking, transcribe later into searchable notes</li> Meeting recordings</strong>: Transcribe locally, everything stays on your machine</li> Learning from podcasts</strong>: Transcribe, then ask Claude to summarize or extract key points (I use Simon Willison’s llm</em> tool</a> for this)</li> Content repurposing</strong>: Transcript → chapter markers → show notes → blog post</li> </ul> The transcript is so much more useful than for just subtitles.</p> Video</h2> Here’s a short video walkthrough with a bit more personality and some fun drama elements:</p> </a> </div> </div> Links</h2> mlx-whisper on PyPI</a></li> uv for easy Python tool installation</a></li> Simon Willison’s llm CLI tool</a></li> Video version of this post</a></li> </ul> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → You don’t need permission to get promoted 2026-01-23T00:00:00+01:00 After 27 years in tech—working at Sun Microsystems, Oracle, and AWS, then coaching dozens of colleagues through promotions from both sides—I’ve learned something that most people get backwards:</p> Your career belongs to you. Not your company. Not your manager. Not the promotion committee.</strong></p> Everything else—job titles, paperwork, organizational processes—those are just external factors that either help you build a great career or don’t. And once you internalize this reframe, everything about promotions changes.</p> The permission you already have</h2> Here’s what most people think: Work hard. Hope your manager notices. Feel anxious about whether you “deserve” a promotion. Ask yourself: “Am I good enough for this?”</p> That’s the wrong question. It’s thinking too small.</p> The better question is: “Is my organization ready to benefit from what I can give?”</p> This shift—from scarcity thinking (“Do I deserve this?”) to abundance thinking (“Am I in the right environment?”)—changes everything. Because here’s an important truth about promotions:</p> You don’t get promoted and then start doing next-level work. You start doing next-level work, and the promotion confirms you’re already there.</strong></p> A promotion is not a permission to operate at the next level. It’s merely paperwork catching up to reality.</p> The trap to avoid</h2> Before you chase that promotion, make sure you actually want the work that comes with it, not just the title.</p> I once worked with a brilliant engineer who got promoted to engineering manager. After a few years, his team was unhappy: turns out he wasn’t really good at managing people. And he was miserable too, because the work he loved (deep technical problem-solving) was now only 20% of his job.</p> The tragic thing: it wasn’t his fault. The organization failed to recognize that a manager job isn’t a reward for being a great engineer. It’s just a different job. With different work. And it might not be a good fit.</p> So before anything else, understand why you want the next level. Beyond the money, what are you actually seeking?</p> The foundation: purpose, mastery, autonomy</h2> There’s actually some helpful science here: Dan Pink wrote a book called Drive</a></em> about what actually motivates us. He identified three things: Purpose, Mastery, and Autonomy.</p> I’ve found these three elements keep you grounded through all the corporate chaos, like budget cuts, reorganizations, bad managers, all of it.</p> Purpose</strong> is why you love your work. For me, it was always helping customers solve tough problems. That purpose carried me through the dot-com crash, company acquisitions, and political nonsense. Even on bad days, I knew why I was showing up.</p> Mastery</strong> is getting really good at something valuable. Early in my career at Sun, and later when I joined AWS, I was like a kid in a candy store. I just wanted to learn, solve harder problems, help more customers succeed. I wasn’t thinking about promotions at all—I was obsessed with mastering my craft. Eventually, I found out I was becoming an Expert Generalist</a>, something no career guide could have ever predicted. Cal Newport wrote a great book about this: So Good They Can’t Ignore You</a></em>. His point: don’t just “follow your passion.” Instead, build rare and valuable skills—skills so good they can’t ignore you.</p> Autonomy</strong> is having the freedom to make decisions. And here’s the beautiful thing: you don’t always have to wait for autonomy to be given. Sometimes you can just ask for it. “Can I lead this project?” The worst they can say is “no.”</p> These three elements create a positive flywheel: Purpose gives you energy to develop Mastery, Mastery delivers results which earn you Autonomy, and Autonomy validates your Purpose. And these three things make you happy no matter what level you’re at. Which is crucial when your organization takes time to process promotions.</p> The tactical playbook</h2> Once you understand your why, here’s how to make it easier for your organization to recognize you’re ready:</p> First, figure out what the next level actually looks like.</strong> Read level descriptions if your org has them. But better yet, observe people already at that level. What do they actually do every day? In most cases, it boils down to bigger scope and bigger impact.</p> Second, just start doing it.</strong> This is the key insight: You can start operating at the next level right now. Want to influence regional strategy instead of just country-level? Start writing those strategy documents. You don’t need a VP title to think bigger.</p> Third, document everything.</strong> Start an achievement log today. Use the STAR method: Situation, Task, Actions, Results. Collect both stories and data showing impact. This helps the promotion process, yes, but more importantly, it helps you see your own growth.</p> Fourth, understand your organization’s process.</strong> Some orgs are very structured. Some are informal. Some don’t really have a process at all. You might be ready for promotion, but the organization might not be ready to give it. That’s important data.</p> True story: early in my career, I realized I was underpaid given my increased responsibilities. I asked my manager for a raise. They shied away from it: too afraid to fight for it through their org. So I changed teams within the same company. My new manager looked at my work, and within weeks, they got the paperwork done.</p> Same company. Same me. Same work. Different manager. Different outcome.</p> Sometimes you don’t need a different company. You just need a different team or manager.</p> The reality check</h2> Sometimes, even when you’re doing everything right—operating at the next level, building mastery, delivering results—the promotion doesn’t come.</p> This is where you need patience and awareness.</p> Patience, because sometimes things just take time. Budget freezes happen. Leadership changes. Then six months later, things open up again.</p> But awareness too. Pay attention to the data. Is this temporary? Or is this just how this organization operates? Is your manager genuinely trying to help you?</p> Remember: “Is my organization ready to benefit from what I can give?” If the answer is “not yet, but maybe soon”, then patience makes sense. But if the answer is “no, and it’s not going to change”, it might be time to find an environment that is ready.</p> I wrote a blog post about recognizing when it’s time to move on</a>, which resulted in one of my biggest career shifts: I basically promoted myself into a better organization.</p> The good news: Whether you stay or go, you are in control. Your development doesn’t depend on any single promotion. Your growth doesn’t depend on any single organization.</p> Your Next Steps</h2> Here’s some homework for you:</p> 1. Write down your Purpose, Mastery, and Autonomy</h3> What impact matters to you? What skills are you building? What decisions do you want to make?</p> Just three sentences. Get it out of your head.</p> 2. Start your achievement log</h3> Create a document with this structure:</p> ## [Month/Year]</span></span> </span> ### [Project/Achievement Name]</span></span> - Situation: What was the context?</span></span> - Task: What needed to be done?</span></span> - Actions: What did you do specifically?</span></span> - Results: What was the measurable impact?</span></span></code></pre> Add one story from last month. Set a weekly reminder to update it.</p> 3. Pick one next-level move and start doing it</h3> Identify what people at the next level are doing. Then either ask your manager for that stretch project, or just start doing it yourself.</p> Give yourself permission.</p> The full story</h2> I go deeper into all of this in my video below, including the anti-pattern of promotion obsession, specific stories from my career, and the mental models that kept me sane through corporate chaos:</p> </a> </div> </div> Related Reading</h2> If you’re early in your career, start with The explore/exploit guide to your first tech job</a></em>. It’s about finding your edge before thinking about promotions.</p> For more on the Mastery piece, read How to thrive as an expert generalist in the age of AI</a></em>. It’s about building diverse skills that make you uniquely valuable.</p> Books and resources</h2> Dan Pink’s TED Talk: The Puzzle of Motivation</a></em></li> Book: Drive</a></em>, by Dan Pink</li> Book: So Good They Can’t Ignore You</a></em>, by Cal Newport</li> </ul> What’s your purpose at work? I’m genuinely curious what drives you. Email me or leave a comment on the video, I read every one!</p> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → The explore/exploit guide to your first tech job 2026-01-14T00:00:00+01:00 A YouTube viewer reached out to me the other day after watching one of my videos. He’d just started at a big tech company and wanted to know: How do you navigate the fog? How do you figure out what to focus on? What are things to avoid?</p> I’ve felt that fog three times—at Sun Microsystems, Oracle, and AWS. And after 27 years and countless conversations with mentees, I think there are three phases that help cut through it.</p> </span> Here’s the video I made on that, followed by some thoughts on why exploration</em> might be more valuable than any career plan.</p> </a> </div> </div> The three phases</h2> Starting a new job can be seen as going through three phases:</p> Phase 1: Learn the terrain.</strong> During your first months, you have permission to not know things. Treat it as a gift! Learn the technology, the culture, the unwritten rules. And remember: you have fresh eyes. You can see things that people who’ve been there for years have stopped noticing.</p> Phase 2: Build your web.</strong> Everybody tells you to “network”. As an introvert, I’m not good at running around, making as many connections I can. And I believe this is wrong, even if you’re an extrovert. Instead, build few, but deep relationships with people whose work you genuinely respect. Research them first, then reach out with specific questions. And: share what you learn, and give back to the knowledge pool. You might feel uncomfortable sticking your head out at first, but remember: it’s not bragging, it’s helping.</p> Phase 3: Find your edge.</strong> Don’t let others box you into a niche, even if some specific experience was the reason you were hired. Your edge should emerge from experimentation, and learning, not assignment. You can combine skills that rarely go together, forming a “talent stack”. This can help you create unique value, and is hard to copy.</p> The video covers each phase in detail. But there’s a deeper principle underneath all three that I want to expand on here.</p> The multi-armed bandit problem (or: why career plans are overrated)</h2> In Algorithms to Live By</a></em>, Brian Christian and Tom Griffiths describe a classic problem from probability theory: the multi-armed bandit.</p> Imagine you’re in a casino facing a row of slot machines. Each machine has a different (unknown) payout rate. You have limited time. Do you keep pulling the lever on a machine that’s been paying out? Or do you try a new one that might</em> pay better—or might pay nothing?</p> This is the explore/exploit tradeoff. And it’s exactly the dilemma you face in your career.</p> Should you go deep on the technology you already know? Or try that new thing your colleague mentioned? Should you stay in your comfortable team? Or apply for that internal transfer that sounds exciting but risky?</p> There’s no way you can calculate an optimal solution in advance. And given how fast new tech trends come and go, it would be a moving target anyway. The information you need to make the ”right” choice only comes from making choices</em>. You learn by doing.</p> This means the best strategies here aren’t plans—they’re heuristics. Simple rules like “win-stay, lose-shift” (stick with what’s working, move on from what isn’t) often outperform elaborate planning.</p> I discovered this book years after intuitively living through multiple explore/exploit cycles. I started my career focusing on graphics and workstations (back then, these were powerful desktop computers that got replaced by normal PCs), then went deeper on CPUs and Microprocessors, when a new, multi-threaded microarchitecture emerged, then spent some years focusing on operating systems, and when Oracle bought Sun, I added a stronger business angle to my work to explain the new, integrated Sun/Oracle stack to customers. Finally, I found AWS and Cloud computing, and a new set of cycles like began, cycling through IoT, AI/ML, digital transformation, and generative AI.</p> Whenever I went through a successful “exploitation” phase, where work is easy, customers are delighted and management is happy, I would spend time trying out new things, out of curiosity and a desire to learn new things, until I found my “next big thing” to focus on.</p> An ancient pattern you can observe everywhere: ant colonies, finding favourite restaurants, or watching successful companies diversifying or pivoting across products and markets.</p> Looking back, I never had a plan. Instead, I had a lot of experiments.</p> Three dangers</h2> The explore/exploit lens on career building reveals three common mistakes:</p> Exploiting too early.</strong> At AWS, I watched new hires rush to work with customers before completing their ramp-up. They wanted to prove their value. But in doing so, they missed the exploration window—the time when you’re supposed</em> to be learning, experimenting, discovering what’s possible.</p> Exploring too long.</strong> Some people never commit. They hop from interest to interest, building breadth but no depth. Exploration without exploitation leads to being a jack of all trades, master of none.</p> Failing to explore.</strong> We all know that colleague living in the past. I remember, when Sun acquired StorageTek in 2005, some colleagues there had trouble adopting new storage technologies, longing for their good old DASDs instead. I’ll let you look up what a DASD is.</p> The goal is to shift intentionally. Explore until you find something worth committing to. Then exploit—go deep, build expertise, create value. When that well runs dry or the landscape shifts, explore again.</p> How to know what’s worth committing to</h2> When you’re ready to shift from exploration to exploitation, run your options through four filters:</p> Does this excite me?</strong> Passion helps develop grit when things get hard.</li> Can I get good at this quickly?</strong> Leverage skills you already have to get a head start.</li> Is this relevant?</strong> Look for opportunities opening up, not closing down.</li> Does it create business value?</strong> Because somehow, the numbers need to add up, so we can pay rent.</li> </ol> These filters come up in multiple sources and different variations, like in this article by James Gurney called What should you work on? (Assuming you want to make a living at it.)</a></em>, Paul Graham’s much more detailed article on How to do great work</a></em>, or the Japanese concept of Ikigai</a></em>. You can also use them to avoid getting into a career dead-end, as I’ve written in The Four Horsemen of a Dying Career</a></em>, where they serve as shields against boredom, incompetence, irrelevance, and going broke.</p> Mini-careers, not one career</h2> The liberating truth is: you’re not building one career. You’re going to have many mini-careers—different roles, different technologies, maybe different companies. Like microservices, this gives you better flexibility, agility, and antifragility, which is the ability to emerge stronger in the face of external change. And somehow, they’ll connect into a story that only makes sense looking backward, like Steve Jobs famously said.</p> This is actually good news. It means you don’t need to have it all figured out. You just need to get good at navigating each chapter. Explore with purpose. Exploit with commitment. Then explore again.</p> I’m in exploration mode right now with my YouTube channel</a>. I’m posting videos on different topics, seeing what resonates, figuring out my niche for this new chapter. I don’t know yet what it’ll be. But I’m curious to find out.</p> That curiosity—that willingness to keep exploring—is what keeps a career alive at any stage. For more on this mindset, see also How to Thrive as an Expert Generalist in the Age of AI</a></em>.</p> Your homework</h2> Before you go on, write down the following:</p> Three topics</strong> you want to explore in the next six months.</li> Three events or meetups</strong> you’ll attend this quarter.</li> Three skills</strong> you already have that most of your colleagues don’t.</li> </ol> This should give you some great starting points for exploring your new tech career. And that last list can already be the beginning of your edge.</p> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → SMART goals are failed Taylorism (and why you should ignore them) 2026-01-08T00:00:00+01:00 A 25-year career without goals—and why that worked better than the alternative</em></p> This guitar is more than 15 years old. It’s my second one—the first was bought and sold in the ’80s.</p> I tried lessons. Self-teaching. Regular practice. Still couldn’t play a recognizable song. Now it collects dust, reminding me of an old dream that never quite worked out.</p> Then in 2018, my wife gave me a ukulele as a gift. Twenty minutes later, I was a musician.</p> Same dream. Different approach. And that’s exactly what this post is about—but not just music. It’s about unhealthy approaches to success, productivity, and “achieving our best year ever”.</p> </a> </div> </div> Prefer to watch? Here’s the gist in 8 minutes on video.</em></p> The resistance you’re already feeling</h2> I ran a poll on LinkedIn</a> recently, asking tech professionals: “Will you set goals for 2026?”</p> Fifty-eight percent said no. Another 5% said “Dunno…”</p> That’s nearly two-thirds of people who probably feel guilty right now. Everyone’s posting their goal sheets, their vision boards, their quarterly targets. The productivity industrial complex is in full swing, telling you that without SMART goals, you’re doomed to mediocrity.</p> </picture> LinkedIn screenshot</span></span> The full LinkedIn poll results</figcaption> </figure> And you may be sitting there thinking: “Should I be doing that too?”</p> Here’s what I think: If you’re avoiding goals, you’re not lazy. You’re smart.</p> The resistance you feel is not weakness. It’s human. Your brain is protecting you from something that fundamentally doesn’t fit knowledge work.</p> SMART goals are failed Taylorism</h2> Let’s start with a quick history recap about Frederick Winslow Taylor</a>.</p> In the early 1900s, Taylor revolutionized factory work with “scientific management”—later called Taylorism. He studied workers with stopwatches, broke tasks into tiny steps, and optimized every movement. For shoveling coal or assembling car parts, it was brilliant.</p> Workers became more efficient. Productivity soared. Management loved it.</p> There was just one problem: Taylor himself acknowledged his system wouldn’t work for knowledge work, as Cal Newport pointed out in his book A World Without Email</a></em>.</p> Taylorism assumes workers are interchangeable cogs executing predefined, repetitive tasks. Knowledge work instead, is very different.</p> But management tried anyway.</p> SMART goals—Specific, Measurable, Attainable, Relevant, Time-bound—are Taylorism 2.0. An attempt to force industrial-age thinking onto creative, dynamic, knowledge-intensive roles.</p> And it fails. Spectacularly.</p> Why each SMART element breaks down for creative work</h2> You can’t be Specific</strong> while adapting to rapid change. Solutions architecture, product development, customer success—these roles require flexibility. The moment you lock in “specific,” reality shifts and your goal becomes obsolete.</p> You can’t Measure</strong> creativity, learning, or customer impact with a single number. How do you quantify “helped a customer transform their business”? How do you measure “became a better mentor”?</p> You can’t know what’s Attainable</strong> when the future is unpredictable. What if you can do more than you think? What if the market shifts? Setting “attainable” goals often means setting artificially low ones to avoid failure, or artificially high, “stretch” goals.</p> Relevant</strong> is arbitrary. Who decides what’s relevant? Your manager? The leadership team? The productivity guru on YouTube? True relevance comes from understanding your purpose, not checking a box.</p> And Time-bound</strong> creates artificial pressure. Why is December 31st magical? Why does failing to hit a number by an arbitrary deadline mean anything? What if you hit your goal early, on October? Should you stop working and take the rest of the year off?</p> To be clear: For repetitive, structured tasks, goals work, just like Taylor demonstrated. It’s in creative, adaptive work where they break down.</p> In his book The Infinite Game</a></em>, Simon Sinek points out that most games in life and in business don’t have winners, losers, or even clear rules. Instead, they’re infinite games</em>, where the only goal is to stay in the game for as long as possible. That requires creativity, flexibility, and adaptability, because the rules of infinite games can be influenced, and they keep changing all the time.</p> The three psychological problems with goals</h2> As Anne-Laure LeCunff points out in her book Tiny Experiments</a></em>, there are three, key psychological problems with these types of goals:</p> First, goals create fear and paralysis.</strong> You set a big goal, then freeze. Too many options. Too much doubt. Insecurity creeps in.</p> Second, they encourage toxic productivity</strong>, the hamster wheel effect. You chase random numbers, sacrifice everything else, risk burnout. And then the constant internal dialogue: “Did I do enough?”</p> Third, they make you compete instead of collaborate</strong>. Everyone’s focused on their own ladder, climbing alone, measuring themselves against others.</p> My 25 years without goals</h2> I spent over 25 years at Sun Microsystems, Oracle, and Amazon Web Services. Eventually, I became a Principal Solutions Architect, coaching executives and helping companies transform.</p> During that time, I never sat down and wrote professional goals for myself.</p> Well, that’s not entirely true. A few times, managers asked me to write goals. So I did, and made lists of stuff I thought they expected. Then ignored them.</p> At the end of a year, I still got good performance reviews. Those goal sheets hardly came up then.</p> Why?</p> Highly creative, dynamic, customer-focused tech roles don’t work like factory worker roles. Solutions architecture is about learning, helping customers, adapting to change. You can’t put “be creative” or “adapt to emerging technologies” on a SMART goal spreadsheet.</p> Even the best sales people I know, which are in a job that literally runs on goals, tended to ignore their numbers in their day to day work, and instead focused on transforming their customers. They also ended the year over-achieving their goals by a large margin.</p> A real-world example</h2> In recent years, I’ve seen a lot of goal sheets. Sometimes long Excel tables with many rows of detailed goals. You know the saying: “If everything is a priority, nothing is.”</p> I signed up for owning one of these goals—a revenue metric attached to a category of products—because I recognized the meaning behind it. Then, I worked with a few colleagues on moving it forward.</p> The first thing I did was ignoring the number.</p> Instead, I focused on the key customer value behind the goal, the “why”, and which actions we could facilitate to help customers get more value.</p> That motivated the team: We were solving real problems for customers, not chasing arbitrary metrics.</p> The ironic twist: a different part of the team worked on getting better data to track the goal. After cleaning up the data, the number went up significantly. Go figure.</p> The lesson here is: when you focus on real value, the numbers take care of themselves.</p> Goodhart’s law: when metrics become targets</h2> There’s a principle in economics called Goodhart’s Law</a></em>: ”When a metric becomes a target, it ceases to be a good measure.”</p> The moment you make a metric your goal, you distort the system. People game it, optimize for it, lose sight of what actually matters.</p> Metrics are useful! I’m not saying “ignore the data.” Instead, think of metrics like a car’s dashboard:</p> You don’t drive staring at the speedometer, do you? You glance at it to avoid failure, like speeding tickets or running out of gas. But your eyes stay on the road, focused on where you’re going.</p> The speedometer informs. It doesn’t control.</p> That’s how metrics should work in your career, your projects, your life. They provide useful information and direction, but they are not the destination. They’re not a replacement for knowing your “why” or seeing what’s actually happening around you.</p> Metrics are essential for understanding reality—just not for replacing judgment about what matters. Amazon’s “Dive Deep” leadership principle</a> sums it up:</p> “Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ.”</p> </blockquote> My @Constant.Thinking YouTube channel</a>’s subscriber count is at 64 right now. By YouTube standards, that’s nothing. But I don’t obsess over the growth rate. I make a video every week, pay attention to what resonates, and enjoy the process.</p> The number informs me. It doesn’t define me.</p> A better way: intentions and the Autonomy/Mastery/Purpose framework</h2> If not SMART goals, then what?</p> Focus on transformation</em> instead of achievement. Focus on who you want to become</em>, not what you want to get.</p> Dan Pink nailed this in his book Drive</a></em> (you can also watch his TED talk The puzzle of motivation</a>)</em>. He researched motivation and found that traditional carrot-and-stick methods work for simple, repetitive tasks—but fail miserably for knowledge work.</p> Instead, three things drive us:</p> Autonomy:</strong> Staying in control over what you do, instead of following rigid orders.</p> Mastery:</strong> Focusing on getting better every day, not hitting a one-time milestone.</p> Purpose:</strong> Connecting to the deeper “why,” not some surface-level metric.</p> Goals are contrary to all three. They remove autonomy (someone else sets the target), they prioritize outcomes over growth (hitting the number matters more than learning), and they often disconnect from real purpose.</p> Intentions restore them.</p> How to find your intention</h2> Use the 5 Whys technique</a>: Start with something that sounds like a goal and keep asking “why” until you reach the core intention.</p> Example: “I want to run a marathon.”</p> Why?</strong> “To get fit.”</p> Why?</strong> “To have more energy.”</p> Why?</strong> “To feel healthy.”</p> There it is.</strong> Your real intention: “Become a healthy person.”</p> (It doesn’t have to be exactly five. Just keep asking until you feel you found your intention.)</p> The difference: Running a marathon is a one-time event. Becoming a healthy person lasts forever. And it changes what you do daily.</p> Build the daily system:</h2> Once you have your intention, ask: What do people like that do every day?</p> Healthy people eat real food. They move daily. They sleep well.</p> Great! Now you can start doing one or more of those things today.</p> Congratulations! You’re already a healthier person.</p> This won’t be perfect on the first day. But it’s better than yesterday. And if you keep going—eat better tomorrow, move more, sleep well—small wins will compound. You’ll be amazed what happens in 30 days. A quarter. A year.</p> James Clear explains this in great detail in his book Atomic Habits</a></em> and his article “Forget About Setting Goals. Focus on This Instead.</a>” Systems beat goals every time.</p> Back to my ukulele story</h2> With guitar, I had a goal: “Learn guitar.” It felt big, scary, endless. Exercises felt like homework.</p> With ukulele, I set an intention: “Become a musician.”</p> </picture> CT</span></span> I’m a musician now!</figcaption> </figure> What do musicians do? They play. Every day.</p> So I played the ukulele every working day after breakfast. Just 20 minutes. No pressure. No milestones. Just music.</p> I felt like a musician from Day 1. Not after years of practice—from the very beginning.</p> That’s the difference. Instead of chasing some future achievement, I focused on becoming someone. Forever.</p> Today, I’ve expanded to playing synths and sequencers, and I meet with friends online every Wednesday to jam together.</p> Your turn: pick ONE intention</h2> Here’s my challenge to you. New year or not.</p> Pick one intention. Not ten. Just one.</p> Who do you want to become?</p> Use the 5 Whys to find it. Then ask: “What do those people do every day?”</p> Start doing it today.</p> You’ll have more fun. More fulfillment. And paradoxically, you’ll achieve better results—because you’re no longer distracted by chasing numbers or paralyzed by fear of failure.</p> If you didn’t set goals for 2026, you were right all along. Your resistance was trying to help you.</p> If you did set goals for 2026, don’t just forget about them—find the intentions behind them instead.</p> Some contexts benefit from clear targets. But if your work or personal ambitions require creativity, flexibility, and meaning, intentions will serve you better.</p> Now go become that person you’ve been thinking about!</p> The numbers will take care of themselves. I promise.</p> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → We’re still living in the cat pictures era of AI 2025-12-17T00:00:00+01:00 Most people use AI the way our parents used the Internet in 1995.</p> They’d dial up their modem, check the weather forecast on Yahoo, maybe look up a recipe, and call it a day. The idea that this same technology would eventually let them video call their grandchildren, run a business, or access humanity’s entire knowledge base? Unimaginable.</p> Today, we’re doing the same thing with AI. We use it to summarize documents, search for answers, and write some code. That’s it. That’s our email-and-weather-forecast phase.</p> Let me offer one more pattern that’s hiding in plain sight and can bring you one step closer to “modern AI usage” (whatever that will be 5 years from now). I re-learned this after spending a weekend building an AI-powered news briefing shell script.</p> The knowledge-harvesting pattern that actually matters</h2> As a general rule, AI works best, the more data you send into its contect. This is what we leverage with this pattern:</p> Collect</strong> a large amount of information</li> Filter</strong> and preprocess it down to what matters</li> Synthesize</strong> it with AI into something personally useful</li> </ol> If that sounds familiar, it should. It’s basically MapReduce</a>, the Big Data pattern that powered Google and transformed how we think about processing information at scale. Except now, instead of needing a cluster of servers and a team of engineers, you can do it from your terminal with a few tools and some scripting.</p> Actually, you don’t even need to script. Throw a bunch of documents into a Claude project or Perplexity workspace and ask for a personalized analysis. Same pattern, no code required.</p> But here’s the thing most people miss: this pattern works for almost any everyday problem</strong>.</p> Research:</strong> Collect papers, filter relevant sections, synthesize insights.</li> Career planning:</strong> Collect job postings, extract patterns, generate strategy.</li> Learning something new:</strong> Collect tutorials, filter by your skill level, create a personalized roadmap.</li> </ul> The script I’m about to show you is just one more example of this pattern, with an AI twist.</p> My weekend problem: information overload</h2> I like staying informed. Doomscrolling? Not so much.</p> Every morning, I’d check dozens of sources: news, AI developments, world events, positive stories (who doesn’t need those?). I’d skim headlines, get distracted by clickbait, and 30 minutes later realize I’d absorbed almost nothing useful.</p> Three years ago, the solution would have been “get better at discipline” or “use an RSS reader and train yourself to be more selective.”</p> This weekend, I built something that seemed impossible back then, with a simple shell script.</p> Building my personal news briefing system</h2> This news briefing system pulls from 20 sources: RSS feeds for reliable news outlets, Perplexity searches for real-time or some broader topics I care about. It can run every morning or on demand, processing everything in parallel, and handing out a beautifully formatted Markdown briefing that includes:</p> Top news from Germany, the world, economy, tech, and entertainment</li> AI and personal productivity tips</li> An Oblique Strategy (Brian Eno style)</li> A writing prompt</li> An “Editor’s Corner” where Claude gets to be snarky about the day’s news</li> </ul> The whole thing takes about 90 seconds to run and delivers exactly what I need—no more, no less. You can watch me walk through the technical details in this YouTube video</a>, grab the complete Fish shell script from this gist</a>, or see an example output in this other gist</a>.</p> </a> </div> </div> A few interesting details of how</em> I got there:</p> The technical journey (including my facepalm moment)</h2> I started with the obvious approach: feed each news source through Claude individually, asking it to “optimize” and “clean up” the content before the final synthesis.</p> Seemed smart, right? Let AI do the preprocessing!</p> Except I kept hitting context length limits. With 20, sometimes quite chatty input sources, even Claude Haiku’s 200k token context window wasn’t enough.</p> That’s when I had my facepalm moment: Of course it wasn’t enough, I was burning through context across multiple LLM calls instead of one.</strong> I was treating AI like a preprocessing tool when what I really needed was old-school data munging.</p> After trying out some CLI tools for RSS/XML processing and failing, I went back to the good old Swiss army knife of data manipulation: Python. Thanks to its feedparser</code> library, it lets me:</p> Convert messy XML feeds to clean Markdown</li> Limit each feed to the 10 most recent items</li> Prioritize summary/description (short and crisp) over full content (blows up context size) where possible</li> </ul> This Python part is particularly fun because it’s embedded directly inside my Fish shell script, thanks to the magic of Astral’s uv</a> and its easy handling of virtual environments. Python-inside-Fish: Inception-style scripting!</p> Parallel processing: the secret sauce</h2> Here’s where impatience and some occasional Q&A with Claude paid off:</p> Instead of processing 20 sources sequentially (which would take forever), I learned about Fish’s job control. Each feed fetch runs in the background with &</code>, and Fish’s built-in job counter lets me know when everything’s done:</p> while</span> test</span> (</span>count</span> (</span>jobs</span>)) -gt 0</span></span> sleep</span> 1</span></span> end</span></span></code></pre> All 20 sources process in parallel. What would take 2–3 minutes sequentially now takes about 30 seconds.</p> Good old Unix thinking, combined with AI.</p> Why redundancy actually helps</h2> You might think 20 news sources is overkill. Why not just pick 3–4 good ones?</p> Because redundancy makes AI smarter.</p> When Claude sees the same story mentioned across multiple sources—each with slightly different details, emphasis, or framing—it can synthesize a more complete picture. One RSS feed might have a sparse entry with just a headline. Another might include quotes. And some things are hard to find RSS feeds for—like my local weather forecast, productivity tips, or daily facts. That’s why I added some Perplexity searches on top of RSS.</p> Claude takes all of that and creates something better than any individual source could provide. It’s the difference between reading one journalist’s take and reading five, then forming an opinion.</p> Surprise touch: personality</h2> Here’s my favorite part: I added a bit of personal context about myself to the prompt—my location (Munich), my interests, my dog Elvis.</p> Now Claude sprinkles little references throughout the briefing. A weather report that suggests “perfect for a barefoot run with Elvis.” A snarky comment in the Editor’s Corner that connects back to my work. Small touches that make a daily briefing feel less like a news dump and more like a conversation with a well-informed friend.</p> This wasn’t planned. It emerged from the pattern: collect (news), filter (what matters), synthesize (for me specifically</em>).</p> What this means for you</h2> If you’re reading this thinking “cool script, but I’m not a command-line person,” you may be missing the point.</p> The script is just automation. The pattern</em> is the unlock.</p> You probably have a problem right now where you need to make sense of too much information:</p> Research for a project</li> Competitive analysis for your business</li> Learning a new skill</li> Understanding a complex topic</li> </ul> Try the pattern:</p> Collect everything relevant (don’t filter yet)</li> Preprocess it just enough to be useful (remove noise, extract key parts)</li> Let AI synthesize it into something actionable for you</li> </ol> You can do this in a Claude Project. You can do it with Perplexity. You can do it with a shell script if you like to code.</p> The method doesn’t matter. The pattern does.</p> Start Experimenting</h2> Three years ago, this kind of personalized, automated intelligence gathering was science fiction. Today, it’s a weekend project.</p> We’re living in the cat pictures era of AI: most people only see the obvious use cases. But just like the Internet evolved beyond email and weather forecasts, AI will evolve beyond summarization and code generation.</p> The question is: will you be experimenting, or will you still be stuck checking the weather?</p> If you want to start having AI fun on the command-line, here’s how:</p> Install the llm tool</strong>: Simon Willison’s llm CLI</a> makes working with AI models from the command line super easy</li> Pick one daily annoyance</strong>: Not everything, just one problem where you’re drowning in information</li> Try the pattern</strong>: Collect → Filter → Synthesize. Or something else!</li> Share what you discover</strong>: Seriously, I want to know what you build</li> </ol> If you want to see my exact implementation, check out:</p> YouTube walkthrough</a> of how it works</li> Complete Fish shell script</a> on GitHub</li> Example output</a> from today’s briefing</li> </ul> The real innovation isn’t the technology. It’s learning to see patterns where others see chaos.</p> What’s one daily problem you’d like to solve with this pattern? Share this post on your favorite social media, add your comment and let me know</a>. I read every response.</em></p> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → Werner Vogels’ 2025 AWS re:Invent keynote is a timely career handbook for navigating accelerating change 2025-12-11T00:00:00+01:00 Watching Werner Vogels deliver his 2025 re:Invent keynote</a> last week, I experienced one of those rare moments where separate threads suddenly converge. There he was, Amazon’s CTO since 2005, laying out five principles for “Renaissance Developers”, and I realized: these weren’t just career advice for developers.</p> They’re a career handbook for everybody</em> in 2026. Because every</em> job is becoming a tech job.</p> Subconsciously, I had been following these patterns since I started my carreer in tech, 27 years ago. And they also rhyme well with Martin Fowler’s July 2025 article on “Expert Generalists”</a>. Coincicence?</p> In fact, the timing couldn’t be more critical. We’re living through what Clayton Christensen warned about in The Innovator’s Dilemma</em>: compounding waves of disruptive change. Ray Kurzweil’s prediction of exponential technological acceleration from the late 90’s isn’t theory anymore, it has become just another Tuesday in today’s tech world. Ray Dalio’s research on economic cycles shows we’re navigating unprecedented complexity across technology, economics, and social structures simultaneously.</p> Werner’s five principles are much more than an inspiring keynote: they’re a career handbook for this exact moment.</p> Table of contents</h2> Why this matters now</a></li> Be curious and keep learning</a></li> Think in systems</a></li> Communicate with precision</a></li> Be an owner</a></li> Become a polymath</a></li> Your January challenge</a></li> </ol> Why this matters now</h2> These five principles aren’t new, individually. But together, they matter today more than ever.</p> We’re experiencing what Clayton Christensen warned about: multiple overlapping disruptive changes. Cloud computing. Big data. IoT. Machine learning. AI. Industry 4.0. Electric vehicles. Space commercialization. Biotechnology. Robotics.</p> Each wave alone would be transformative. But together, they’re creating Kurzweil’s predicted acceleration: exponential change becoming super-exponential as domains cross-pollinate and amplify each other.</p> Ray Dalio’s economic research shows we’re simultaneously navigating technological, economic, and social complexity at unprecedented scales. The pace of change demands exactly what Werner prescribed: continuous learning, systems thinking, precise communication, ownership, and polymathic breadth.</p> The critical insight is: every job is becoming a tech job.</strong> Digitalization, cloud computing, big data, IoT, and AI are touching every industry. You don’t need to become a programmer. But you do need to understand how technology shapes your domain. The CFO who understands supply chain and product development in addition to deep finance expertise? That’s T-shaped—deep in one domain, broad across many. The marketing leader who grasps data pipelines and spots trends in real-time? Same pattern.</p> During my 12+ years at AWS, I’ve seen how this approach works. Starting as one of the first Solutions Architects in Germany, I navigated multiple technology waves by embodying these principles, often unconsciously at first, then deliberately. Each year brought different challenges requiring new skills, but the meta-pattern remained: stay curious, see systems, communicate clearly, own outcomes, broaden and deepen expertise.</p> Let’s look at them in more datail.</p> Be Curious and Keep Learning</h2> What it means:</strong> Not just passive consumption, it’s all about active building. The Chinese proverb nails it: “When I hear it I forget it, when I see it I remember it, when I do it I know it.”</p> The 8am coffee shop strategy</strong></p> When people tell me they’re stuck in their career, I ask them to show me where learning happens in their calendar. Usually… nowhere. They feel pressure to perform 100% of their time.</p> Here’s what I did at AWS for 12 years: Most mornings at 8am, I’d sit in a remote corner of the office or a quiet coffee shop for one hour or more. Not to check email. Not to prep for meetings. To build something</em>.</p> I built CloudWatch dashboards for my wife’s WordPress blog. Created a spam filter from scratch using the Enron email dataset. Built a static blog generator using AWS Lambda and AWS Step Functions.</p> These experiments and pet projects taught me more than any training ever could, because I was solving real problems with my hands on the keyboard. When I later sat across from customers discussing serverless architectures or machine learning pipelines, I had the kind of credibility no documentation could provide.</p> The temporal and spatial separation mattered. That remote corner at 8am shielded me from interruptions. The “no email before 10am” rule protected the space. Without these boundaries, learning gets trampled by the urgent.</p> Just last weekend, I started another pet project. How about you?</p> How to start:</strong> Create a recurring one-hour meeting with yourself next week. Call it “Learning Lab” or “Build Time.” The calendar block will magically fend off other meetings. Pick one topic you’re curious about and do</em> something with it, don’t just read about it.</p> Proof point:</strong> This isn’t unique to tech. Steve Jobs studied calligraphy. Ray Dalio built economic models thinking through decades of market observations. Bruce Dickinson became a pilot while fronting Iron Maiden. Dua Lipa and Rihanna turned curiosity about business into entrepreneurial empires. The pattern works universally: curiosity → hands-on learning → new capabilities → better options.</p> Think in Systems</h2> What it means:</strong> Local optimization without understanding the whole system creates problems elsewhere. Strategy isn’t just what you do. Understand the system first, then change the rules.</p> The decision bottleneck</strong></p> I’ve watched countless executives become trapped in a loop of their own making. They get pulled into too many decisions—approving budgets, reviewing proposals, being “hands-on”. They become the bottleneck in their company’s decision-making system.</p> The invisible system they don’t see: every decision routed through leadership slows down the entire organization. The best decision-makers are closest to the problem, with the freshest information. Pushing decisions to the top degrades both quality and speed.</p> The solution is to push decision-making to the lowest level where someone has enough context and where potential damage remains controllable. This typically means pushing decisions right to where people directly face the problem. At Amazon, we said “innovation happens at the edge”, because the best solutions emerge right where the problems happen, not in the ivory tower.</p> What remains at the top? Only the “one-way-door decisions”, the ones with irreversible consequences that match executive scope. This is what leaders should spend their scarce time on, not whether to approve a $5,000 software license. True story: I once was at a customer executive retreat and someone exclaimed “over here, we treat everything like a one-way door!” Turns out, even which kind of coffee machines to install in their offices.</p> The meta-lesson: when you’re stuck in tactical loops, zoom out. Ask “What’s the system producing this pattern?” Then change the system, not the symptoms.</p> How to start:</strong> When mentees ask about getting promoted, I ask them about the rules of their game. What patterns do you follow? Why are those rules there? Who else is involved? What would happen if you changed the rules?</p> This “step up one abstraction level” move reveals the system. Then you can start seeing leverage points: places where small changes produce outsized effects.</p> Proof point:</strong> Donella Meadows showed that information flow is one of the most powerful levers for changing systems. That’s why digitalization works: converting paper to bits accelerates feedback loops, increases flow, and reduces defective states. Seth Godin recently wrote that strategic thinking starts with understanding the system, then changing it. Werner’s principle reminds us that it’s all about seeing the forest, not the trees.</p> Communicate with precision</h2> What it means:</strong> Clear writing is</em> clear thinking. When you write precisely, you discover what you actually mean. This applies whether you’re writing AI prompts, documenting architecture decisions, or explaining strategy to your team.</p> Writing is thinking with our hands</strong></p> This is why Amazon runs on written documents, not PowerPoint slides.</p> Werner used the example of giving precise instructions to AI for code generation. But the principle extends far beyond AI. During the first waves of software outsourcing, companies with imprecise requirements got software that “met spec” but was completely useless. The precision problem wasn’t technical—it was conceptual.</p> Writing forces you to think clearly about what you’re actually trying to accomplish. Even if nobody reads what you write, you’ll gain clarity just from the act of putting thoughts into well-formed sentences.</p> The deeper skill is cross-domain translation. Every technical solution represents a real-world challenge. There’s always an interface where the real world creates inputs (business needs, user problems) and where technology creates outputs (solutions, outcomes). In enterprise architecture, this is the boundary between business architecture and technical architecture.</p> When discussions get tangled, I ask: “What needs to happen at the business level?” This question brings us back to the real world before diving into implementation details. Werner’s example of object-oriented programming making code model the real world more accurately reflects the same principle. Today’s “digital twins” in manufacturing follow the same concept: using technology to mirror and understand the physical world.</p> How to start:</strong> Write more. Long-form documents. Blog posts. One-pagers. Journaling. Whatever gets you in front of a keyboard or a sheet of paper, forcing thoughts into complete, correct sentences will improve your thinking.</p> Test yourself: Explain your current project to a smart colleague as if they were five years old. Not because they are</em> five, but because it forces you to eliminate jargon and verify you actually understand what you’re doing.</p> Proof point:</strong> I’ve seen sales professionals get AWS certified and transform their effectiveness. Not because they can now deploy infrastructure, but because they can have better conversations with customers and work more independently with their technical colleagues. The best colleagues I’ve worked with came from diverse backgrounds—former consultants, Gartner analysts, startup founders: because each brought a different lens and translation capability.</p> Be an Owner</h2> What it means:</strong> Ownership means taking responsibility beyond your immediate tasks, seeing the system you’re part of, including the second and third order consequences, and accepting accountability for outcomes, not just activities.</p> ”Fragen kostet nichts”</strong></p> In Germany, we say “Fragen kostet nichts”—asking costs you nothing. Ask for more responsibility, a bigger scope, a broader role. The worst that happens is hearing “no,” and then you move on.</p> During my AWS years, I owned initiatives far beyond my official role: organizing joint customer presentations for re:Invent, running an EMEA-wide conference, building communities of practice across teams and geographies. Nobody assigned these. I saw needs and stepped up.</p> This is exercising entrepreneurial muscles inside a large company. It gives you more autonomy, broader influence, and, critically, a better sense of control over your career trajectory. That kind of autonomy is a powerful intrinsic motivation.</p> But here’s the tension: ownership as a cultural value is tricky. Not everyone wants responsibility beyond their immediate work. You can’t mandate ownership, you can only encourage it. Leaders create ownership culture by example and by making it safe to make mistakes. When leadership openly shares how they failed and what they learned from them, they signal “it’s okay to take risks here.”</p> Clear prioritization and decision criteria help too. This is why Amazon’s Leadership Principles</a> at the company level and Tenets</a> at the team level work so effectively—they give people frameworks for making autonomous decisions aligned with broader goals.</p> How to start:</strong> Volunteer to own something beyond your job description. Organize a conference. Start a task force. Run a community of practice. Pick something small enough to manage but visible enough to matter.</p> Proof point:</strong> This connects directly to Eliyahu Goldratt’s The Goal</em>. Ownership isn’t just about accountability, it’s about seeing and improving the system that produces outcomes. You identify bottlenecks, remove waste, improve throughput. That’s systems thinking meeting ownership.</p> Become a Polymath</h2> What it means:</strong> Develop T-shaped expertise: deep in one area, broad across many. This isn’t about being superficial in everything. It’s about having enough knowledge across domains to see connections, translate between fields, and spot opportunities others miss.</p> The Ikigai of career building</strong></p> Initially subconsciously, then more deliberately, I followed a pattern similar to the concept called “Ikigai”: Look for things you’re excited about, that fit or expand your existing skills, that are needed, and that people will pay for.</p> I wrote about this framework in my Four horsemen of a dying career</a> post, but it also applies here. Your T-shape should emerge from this intersection—not from random skill collecting.</p> The best sales people I’ve worked with weren’t career sales reps. They were former business executives, consultancy owners, industry analysts. Each brought a unique, holistic perspective on how businesses work across levels and silos. This turned them into business advisors for their customers—helping solve problems, not just close deals. They could see through organizational structures to identify decision-making processes and find the right influencers.</p> I’ve seen this in my own journey: although I was always a “Solutions Architect” at AWS, every year felt like a completely different job. I started with basic infrastructure consulting for startups. Then helped enterprises migrate to the cloud. Then enabled customers for Big Data, IoT, Digital Transformation, Machine Learning, and AI.</p> Each wave required new skills: Python coding, public speaking, executive communications, change management, coaching and mentoring. The “T” kept growing broader while the depth in legs like architecture and systems thinking deepened.</p> How to start:</strong> Building the “T” happens through doing, not reading summaries. Real learning requires hands-on work. Job rotations, stretch assignments, collaborations across silos work beautifully. New projects bring new responsibilities and domain knowledge organically.</p> Going deep, adding a major new leg to your “T”, takes time. Think at least a year to develop proficiency, multiple years to form real depth. Choose carefully using the Ikigai framework: passion, existing ability, need, business value. Often a new depth area emerges from what started as a shallow, experimental breadth area.</p> Proof point:</strong> Martin Fowler identified six characteristics of Expert Generalists: Curiosity (Werner’s principle #1), Collaborativeness (ties to Communication), Customer Focus (Communication again), Favor Fundamental Knowledge (complements Systems Thinking), Blend of Generalist and Specialist Skills (T-shaped), and Sympathy for Related Domains (Systems Thinking + Communication). The convergence is striking—different words, same patterns, driven by the same forces of accelerating change requiring cross-disciplinary solutions.</p> Your January Challenge</h2> It’s December. The year’s winding down. Now is the perfect time to assess your career against these five principles.</p> For each one, ask yourself:</p> Curiosity:</strong> When did I last build something just to learn?</li> Systems:</strong> Am I solving symptoms or changing systems?</li> Communication:</strong> Can I explain my work clearly to a smart non-expert?</li> Ownership:</strong> What do I own beyond my job description?</li> Polymath:</strong> Is my T-shape evolving?</li> </ul> Then ask: What can I do to embody this more in 2026? What’s the next step I can take in January?</p> You don’t need to tackle all five at once. Pick one principle that resonates most. Schedule that one-hour learning session. Volunteer for one project outside your silo. Write one blog post. Just start.</p> If you’re feeling overwhelmed by the pace of change, I wrote about navigating uncertainty in my Crisis Survival Guide</a>, where I explore what you can and can’t control using a framework inspired by the Serenity Prayer.</p> For more on developing T-shaped expertise, read my deep dive on How to Thrive as an Expert Generalist in the Age of AI</a>.</p> Werner gave us the map. Fowler, Christensen, Kurzweil, and Dalio confirm the terrain. Now it’s on us to navigate it.</p> The Renaissance is here already. Time to build!</p> Watch/read more!</h2> Werner Vogels’ AWS re:Invent 2025 Keynote</a> (YouTube)</li> Martin Fowler’s Expert Generalist</a> (article)</li> Clayton Christensen’s The Innovator’s Dilemma</em></a> (Goodreads)</li> Ray Kurzweil’s The Singularity Is Near</em></a> (Goodreads)</li> Ray Dalio’s Principles</em></a> (Goodreads)</li> Donella Meadows’ Thinking in Systems</em></a> (Goodreads)</li> Eliyahu Goldratt’s The Goal</em></a> (Goodreads)</li> </ul> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → 3 slides everyone uses (but you should delete) 2025-12-03T00:00:00+01:00 In 2014, I was preparing my AWS re:Invent presentation on “Running Lean Architectures.</a>” I had my slides ready: agenda, bio, resources.</p> Then I stopped.</p> Why was I presenting this in the first place?</p> The answer: to help people save money on AWS.</p> Not to check boxes on a corporate template. Not to prove I was qualified to speak or that I did my homework.</p> I deleted my agenda slide and replaced it with one titled “What you’ll get out of this session”, the one you see above. The first bullet point: “A lower AWS bill.”</p> That moment changed how I think about presentations. Every slide should serve the audience, not the presenter. Yet in the 25 years since, I’ve watched thousands of presentations make the same mistake: filling slides with content that serves them, not their audience.</p> In this video, I break down the three most common offenders:</p> </a> </div> </div> Here’s why these slides fail, and what to do instead.</p> The real problem: who are your slides for?</h2> Before we dive into specific slides, here’s the core issue: presenter-centric vs. audience-centric thinking</strong>.</p> Most presenters follow templates that make them</em> feel safe, copy-pasted across generations of designers. The agenda keeps them on track. The bio proves they belong there. The resources list shows they did their homework.</p> But here’s what’s really happening: while you’re making yourself comfortable, your audience is reaching for their phones.</p> Those little gadgets are your real competition. Highly optimized, attention-stealing mind-control devices that offer instant gratification. Every slide that doesn’t serve your audience is an invitation for them to check “just one more notification.”</p> Once they’re lost in their feed, it’s hard to get them back.</p> So let’s look at the three slides that hand your audience over to their phones—and what to do instead.</p> Slide #1: Agenda (your to-do list, not their value)</h2> What presenters think they’re doing:</strong> “I’m being organized and professional. I’m showing respect by letting them know what to expect.”</p> What they’re actually doing:</strong> Creating a to-do list for themselves. Every agenda looks the same: Introduction, Topic 1, Topic 2, Topic 3, Q&A. It’s the presenter’s checklist, dressed up as audience service.</p> What the audience experiences:</strong> The groan: “Yet another agenda slide.” They’ve seen this template a thousand times. Time to check their phone.</p> Nobody came to your session to see your table of contents. They came to solve a problem or learn something valuable!</p> The better alternative: Expectations</h3> Replace your agenda with clear expectations. Instead of listing topics, tell them what they’ll gain:</p> “What you’ll get out of this session: A lower AWS bill”</li> In the next 30 minutes, you’ll discover why your customers ignore your product, and the one question that changes everything</li> “Today, you’ll learn three techniques that cut deployment time in half”</li> </ul> Why it works:</strong></p> First, it’s a positive surprise. Everyone expects an agenda. So when you deliver something better, you’ve earned their attention.</p> Second, expectations create productive tension. You’ve opened a story loop in their minds. They want to see it resolved. Movie trailers don’t give you a table of contents—they create anticipation.</p> Third, expectations build trust. When you exceed what you promised (and you should always aim to exceed), you’ve demonstrated that their time was well-invested. That one extra insight at the end, beyond expectations, can elevate your presentation from good to great.</p> Slide #2: About Me (your validation, not their value)</h2> What presenters think they’re doing:</strong> “I need to establish credibility. They need to know I’m qualified to be here.”</p> What they’re actually doing:</strong> Seeking validation. The bio slide reassures the presenter: “I belong here. I’ve earned this stage.” It makes them feel better about presenting, helps keep imposter syndrome</a> in check.</p> What the audience experiences:</strong> Indifference, at best. Mild annoyance at worst.</p> They already know your name and job title: it’s on the title slide and in the conference program. If they’re curious about your background, they’ll check LinkedIn later.</p> What they don’t know yet is whether you’re going to waste their time or deliver value. And you’re currently wasting their time with your CV.</p> I’ve watched speakers uncomfortably skip past their own bio slides, as if their subconscious mind knows something’s wrong. Their body language says: “Sorry, our corporate template made me include this.”</p> The better alternative: authority through value delivery</h3> Want to establish credibility? Deliver value. Share insights. Solve problems. Tell stories that illustrate hard-won lessons.</p> Skip the bio slide entirely. Then, throughout your presentation, weave in short stories:</p> “When I worked with a startup trying to cross the chasm, we discovered…”</li> “In my 12 years at AWS, I learned that…”</li> “I made this mistake three times before I figured out…”</li> </ul> Why it works:</strong> You’re building authority while delivering value. The audience gets useful information and learns that you know what you’re talking about. Two birds, one stone.</p> More importantly, you’re making it about them, not you. They’re the hero of this story. You’re the guide who’s been down this path before.</p> That’s the role you want. Not “impressive person with credentials,” but “trusted guide who serves their audience.”</p> (Do you have an “About the company” slide? Delete it, too, for the very same reasons!)</p> Slide #3: the resources (your homework proof, not their next step)</h2> What presenters think they’re doing:</strong> “I’m being helpful! Look at all these valuable resources I’m sharing.”</p> What they’re actually doing:</strong> Creating decision fatigue and proving they did their homework. That wall of URLs and QR codes isn’t for the audience—it’s the presenter covering their bases.</p> What the audience experiences:</strong> Overwhelm. And their mind is already wandering.</p> By the end of your session, they’re thinking about coffee, their next meeting, or whether they need a bathroom break. Their cognitive load is maxed out from absorbing your content.</p> Now you’re asking them to choose between ten resources? That’s not helpful—that’s homework.</p> Yes, they might take a photo of your resources slide. But let’s be honest: how often do you actually go back and look at those photos later?</p> The better alternative: One clear next step</h3> Give them a single, specific call to action. Not ten options—one action.</p> Make it ultra-specific: “When you get back to your desk on Monday, right after you file your expense report, do this one thing…”</p> (I use that exact phrasing when coaching speakers. They laugh, but it drives the point home: specific and immediate.)</p> Examples of good single CTAs:</p> “Visit booth #47 for a live demo”</li> “Go to <URL> for the one-page template”</li> “Complete the hands-on tutorial lab now, to experience this solution in real life”</li> </ul> Why it works:</strong> Low friction. Clear reward. Immediate action.</p> You’re respecting that they’re overwhelmed and tired. You’re making it easy to take the next step. You’re trusting that if they want more information, they know how to use a search engine in 2025.</p> Or better yet: create a one-page handout that summarizes your key concepts. This gives people something tangible and makes you memorable. Plus, it’s a much better follow-up tool than “can I get a copy of your slides?”</p> The transformation: from template-follower to trusted guide</h2> Here’s what all three of these slides have in common: they serve the presenter’s need for comfort, not the audience’s need for value.</p> Templates make us feel safe. They tell us we’re doing it “right.” They protect us from the fear of being unconventional.</p> But: great presenters are</em> unconventional. They stand out precisely because they don’t follow the template everyone else follows.</p> The stakes are real. In an age of attention-hogging mobile phones and infinite distractions, losing your audience means losing relevance. Lower ratings. Fewer speaking opportunities. Less impact with the insights you worked hard to gain.</p> But when you make the shift, when you put the audience first, look beyond the templates, and replace those comfort slides with audience-centric alternatives, you become memorable. You get invited back. You create real impact.</p> You transform from someone following corporate templates into a trusted guide who serves their audience.</p> Your Next Step</h2> Pick one presentation you’re giving soon.</p> Open the deck. Find these three slides. Delete them. Or better yet: replace them with the alternatives suggested above.</p> Make your slides serve your audience, not yourself.</p> Your audience will thank you. And your phone-checking problem just got a lot smaller.</p> P.S.: If you want to discuss your specific presentation, feel free to book a slot during my office hours</a>. P.P.S.: What slides are you deleting from your presentations? Share this post on your favourite social network and tag me, I‘d love to see what you discover!</p> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter →

Constant Thinking

Why working with AI agents is so tiring (and what to do about it)

2026-07-16T00:00:00+02:00

Earlier this week, I spent five hours at the WERK1</a> coworking space in Munich, moving three projects forward at once: the brain dump that would become this blog post, a contribution to an open source project, and a redesign of my blog’s analytics. My AI agents did the heavy lifting. Whenever one of them finished a work package, I reviewed the results, made a few decisions, wrote the next set of instructions, and hopped over to the next project. It felt great: three streams of steady progress, one me.

Then I came home for dinner and noticed that my head was buzzing. I know this particular kind of tiredness well, but from a different life: it’s how I used to feel after a day of back-to-back job interviews or customer workshops. This time, I had spent the day mostly alone, typing.

Wait, isn’t this multitasking?</h2>
At the surface level, what I did that day was an anti-pattern: I hopped between tasks all afternoon (I’ve started calling it agent hopping), and in productivity circles, multitasking is supposed to be a lie we tell ourselves. Paul Graham wrote in one of my favourite blog posts of all time that makers and managers live on different schedules</a>, and that a single meeting interrupting a long work session can ruin a maker’s afternoon. Cal Newport built a whole body of work around deep, uninterrupted focus</a>. Psychologists have measured again and again that task switching degrades our performance far beyond the seconds the switch itself takes.
And yet, the people building the newest AI tools work exactly this way, all day. Fiona Fung, who manages the Claude Code and Cowork teams at Anthropic, cheerfully described on Lenny’s Podcast</a> how she kicks off multiple agents at once, and knits through meetings while they work.
Either decades of research are wrong, or this isn’t multitasking.

You’ve been promoted to head chef</h2>
I think “agent hopping” (if this is a word) is not multitasking. And the best picture I’ve found for it comes from Gene Kim and Steve Yegge’s book Vibe Coding</a>. Working with AI agents, they say, is like running a professional kitchen: you are the head chef, and the agents are your line cooks. You don’t chop the onions yourself anymore. You write a ticket, hand it to a cook, and turn to the next dish. The switching happens at the hand-off, the natural seam between tasks, not in the middle of a thought.
There’s a second difference that I think matters even more: you choose the moment. Sophie Leroy, the researcher who discovered that part of our attention stays stuck on an unfinished task after we switch away from it</a>, found the effect is at its worst when we’re forced to switch under time pressure. A ringing phone yanks you out. An agent that finished its work waits patiently until you’re ready. The seams are self-timed.
I’ve seen a similar effect in my computer systems work before: in the mid-2000s at Sun Microsystems, I helped introduce servers that swapped one very fast processor for many slower ones working in parallel. In kitchen terms, we asked our customers to trade one brilliant, expensive chef for a whole brigade of decent cooks, and most of their software simply wasn’t organized to work as a brigade yet, so it was a hard sell. Today’s AI brigade shows up pre-trained. It even speaks English, and most other languages, too.
So no, working with agents isn’t multitasking in the classic, self-deceiving sense. It’s running a kitchen. Which leaves the question: why the buzzing head?

The kitchen in your head has no ticket rail</h2>
Because the kitchen picture breaks in two places, and the tiredness lives exactly in the breaks.
A real kitchen keeps its state out in the open: the orders hang on a ticket rail above the pass, and the chef’s head can stay comparatively empty. Your brain has no such rail. Psychologists have known since the 1920s that unfinished tasks keep occupying our minds</a>, and that we can only actively track about three or four things at a time</a>. Every dish that’s still cooking with an agent somewhere keeps simmering in your head, too.
And here’s the subtle part: handing off a ticket doesn’t finish anything. The dish is still yours until you’ve tasted it and sent it out. Delegating to an agent softens the cost of switching. It doesn’t clear the plate.

The cooks took the chopping</h2>
The second break is sneakier. The line cooks didn’t take a random part of your work. They took the easy part.
Drafting routine code and text, summarizing documents, doing research legwork: that used to be the lighter part of a working day, the part where your mind could coast a little. What tends to remain for you (tends, because there’s still plenty of mindless cleanup in AI land) is tasting and deciding: reviewing results, making judgment calls, working on strategy and direction. As Steve Yegge put it</a>: “AI has turned us all into Jeff Bezos, by automating the easy work, and leaving us with all the difficult decisions.” And decision work is the most expensive kind of thinking we do. The best evidence I know of suggests we can sustain roughly four good hours of it per day</a>; Yegge, after months of intense agent work, arrived at three to four hours as the realistic workday, too.
Agent work packs those hours tight. Every wait invites filling, so the pauses that used to come free with the work, like a coffee break while the computer executed a long program, get filled with yet another round of deciding. That’s how a quiet maker day can feel like an interview marathon day.

You’re not imagining it</h2>
A more sensationalistic blogger would call this an “AI fatigue epidemic”, and they wouldn’t be wrong:
Simon Willison, a developer with decades of experience, describes it</a> like this: “Using coding agents well is taking every inch of my 25 years of experience as a software engineer, and it is mentally exhausting. I can fire up four agents in parallel and have them work on four different problems. And by like 11 AM, I am wiped out for the day.”
A field study of 200 tech workers found the same pattern</a> and called it work intensification: “a continual switching of attention” and “a sense of always juggling.”
Laura Summers at Pydantic, who call themselves an “end-to-end AI engineering stack”, writes: “Programming with LLMs is genuinely useful and genuinely destabilizing. These two things coexist. If we pretend the second one isn’t happening, we will all burn out.</a>” She also offers hope by pointing out that “It was always the human attention, the engineering judgment, the ability to hold a coherent vision for a system. … those human capacities are revealed as the actual scarce resource. And scarce resources are valuable.“
Speaking of burnout: in this year’s tech worker sentiment survey</a>, significant burnout jumped from 44.7% to 54.7% in a single year. Agent fatigue is at most one contributor among many there (layoffs and job insecurity surely do their part), but the direction is worrying.
Even Fiona Fung, when Lenny asked her how to handle the growing context-switching load, answered: “I haven’t cracked it yet.”

What I do about it</h2>
I don’t claim to have cracked it either. But the following practices have made my agent days noticeably lighter, so take them as field notes rather than final answers.
Expect the tiredness. It’s arithmetic, not weakness. If you delegate the light work, what remains for you is dense by definition. I stopped being surprised by the buzzing head and started accepting it, the way a chef plans for the dinner rush: it’s coming, so don’t schedule anything deep behind it.
Build yourself a ticket rail. I write long, careful briefs for my agents, something I’ve described in How to stop engineering prompts and start delegating</a>. A good brief does two jobs at once: it makes the agent better, and it takes the dish out of your head. Leroy’s research offers the same remedy for humans, a short written note on where you stopped and what happens next, so your mind can let go. Then take your break at the hand-off, not at random: after I send off a brief, I stand up, stretch, make coffee, play a move on Chess.com, or send my wife a message. Five minutes is enough. And check on your cooks on your schedule, not theirs: peeking at a still-working agent is a paid interruption with zero yield, and agent notifications that interrupt you rebuild the bad kind of task switching with extra steps. (Though I do find Peon Ping</a> hilarious.)
Cap your burners. One big dish, at most two small ones on the side. My personal Kanban</a> board enforces this limit, and my brain is grateful for it. Some days, the right number of works-in-progress is one. Above all, enjoy the light work without guilt: the lunch walk, the small tool tinkering between hand-offs. The silly pet project. Fiona Fung knits, and I think that’s the perfect extreme case: a task that occupies the hands and costs no working memory at all.
After hours: give yourself permission to play. My mother used to work as a diplomat in the German foreign ministry. Our family spent many years in foreign countries she was assigned to: Colombia, Turkey, Italy, Portugal, Spain. As I grew older, she told me about her colleagues who used Valium and alcohol after an intensive day at the office to wind down. At the time, I had introduced her to computer games and she loved playing Pac-Man, Krakout</a>, and, of course, Tetris. She told me that this was her wind down ritual, no drugs required. Today, I love playing The Legend of Zelda: Breath of the Wild. I recently saw it ranking high on a list of “best cozy games”. “Wait!” I thought to myself, “Zelda, a cozy game?” But, yes, it makes sense. There’s a lot of meditative comfort in exploring the vast world of Zelda at your own pace, collecting stuff, completing quests, and relaxing in a beautifully made imaginary world.

Stay awake at the wheel</h2> I wrote a few weeks ago that we’re in the driver’s seat with AI, if we choose to stay awake</a>. Agent fatigue is exactly where that choice gets hard, because the real risk isn’t being tired. It’s what tired brains do: accept the agent’s recommendation without thinking it through, skim the review that deserved attention, let the evening reading collapse from books into feeds. You can frequently find me reading a good non-fiction book on my morning commute, but my evening commute is more often spent on Reddit.
Air traffic controllers and truck drivers get mandated rest, because as a society, we’ve learned the hard way what vigilance fatigue does in those professions. Nobody is going to mandate rest for people running AI agents; all we get is a smartwatch reminding us to stand up. So this one is up to you: see the arithmetic of doing more executive work than ever before. Congratulate yourself on your promotion to head chef. Build the rail. Cap the burners. And step away from the pass while the cooks are cooking.
So, tell me: what’s on your burners right now, and what’s your knitting?

Enjoyed this? Reply by email · Read on the web

Want the next one in your inbox? Subscribe to the newsletter →

You’re in the driver’s seat: will you choose to stay awake with AI?

2026-06-22T00:00:00+02:00

„Nah ist / Und schwer zu fassen der Gott. / Wo aber Gefahr ist, wächst / Das Rettende auch.” — Friedrich Hölderlin, Patmos (1803) </blockquote>

(Near is, / and difficult to grasp, the god. / But where danger is, grows / the saving power also.) </blockquote>
A few weeks ago, I wrote a post titled Thinking with Claude: why Cyborg writing works better than Centaur writing.</a> In the LinkedIn comments, a reader named Christopher pushed back: Leaning on AI to help me write, he argued, was training my brain to “surrender executive function to external sources.” Examples: freed prisoners overwhelmed by everyday choices, ex-military struggling with civilian life, people leaving long-term institutional care. The source doesn’t matter, he wrote. The offloading pattern is the same.
While my initial answer was along the lines of “using your executive function is a choice”, I think it’s not that simple, after all, and I owe Christopher a real answer. In fact, his comment pushed me into a weeks-long thinking journey, during which I looked for research, came across interesting related articles, and reflected a lot on my own AI use. I also jammed with Claude, and yes: I used the very tool Christopher warned me about to think harder about his warning. We’ll get to that contradiction later. 
What I found was four ways AI can quietly cost you. Plus two simple self-checks for catching them. Plus four small moves for staying in charge.
The good news: You’re in the driver’s seat. The question is what you choose to do with it.
Four ways AI can quietly cost you</h2>
After thinking this through from a number of perspectives, two axes emerged. What it can cost you splits into cognitive (what your mind can do) and attention/life (where your time and life actually go). How it costs you splits into loss (you stop using a capacity, and it withers) and distortion (you keep using it, but on bad input).
Four cells, four failure modes, and AI sits on all of them.
Atrophy: the muscle you stop using</h3> This is Christopher’s point, and it’s an old story. Writing made us forget the oral epics earlier generations carried in their heads. Pocket calculators softened our mental arithmetic. London cabbies who passed The Knowledge showed enlarged posterior hippocampi (Eleanor Maguire’s classic 2000 study in PNAS</a>); the GPS generation shows the opposite: habitual GPS users have weaker spatial memory and reduced hippocampal engagement (Véronique Bohbot’s group at McGill, Scientific Reports 2020</a>).
So yes: capacities you stop training will weaken. Ethan Mollick’s colleagues at Wharton call the AI version cognitive surrender</a>. It’s real. And our ability to make choices, guide others, and bring things to fruition is perhaps our biggest differentiator against even the most powerful large language model. We don’t want to lose it.
Sycophancy: the friend who only agrees</h3>
AI is trained to be helpful and pleasant, for obvious reasons: the AI that is used more often, wins. The cost is that it tends to agree with you, especially on judgment calls where you most need it to disagree.
A friend of mine told us at our (roughly monthly) burger evening about someone he read about who quit his job to launch his own app. The app idea, it turned out, was thin. But his AI had been enthusiastic, supportive, and encouraging. Real friends would have asked the hard questions. The AI cheered. Unsurprisingly, the app failed miserably.
OpenAI rolled back a GPT-4o update because it was “overly supportive but disingenuous”</a> and Anthropic has been studying sycophancy in language models since at least 2023</a>. Anthropic actively monitors and suppresses it in its models.
Displacement: the cheap substitute for the real thing</h3>
Picture a budgie in a cage, talking to its reflection in a tiny mirror. Whatever the bird thinks is happening there, it’s not socializing. It’s relating to a surface tuned to give back exactly what it offers.
A four-week randomized controlled trial run by OpenAI and the MIT Media Lab found that heavy daily users of ChatGPT, voice or text, socialized significantly less with other humans by the end of the trial (Fang et al., 2025</a>). The American Psychological Association’s January 2026 monitor</a> brings the broader picture together: researchers are watching a “transformation of relational norms in ways that may render human-human connection less accessible or less fulfilling.”
This isn’t only about lonely people forming attachments to chatbots. It’s about anyone, including me, including you, who may find themselves exchanging more words with an AI than with many humans. Life exists to be lived, not spent in front of screens, a keyboard, or replaced by cheap substitutes.
Hijack: the side-quest engine</h3> David Wilson wrote a widely cited post in late May 2026 called The solution might be cancelling my AI subscription</a>. He lists sixteen unfinished projects he’s spun up with AI, concluding the list with “maybe 50 other projects I’ve already deleted”. Most of these began with “write me a quick script for X” and ended an hour later somewhere completely different. His verdict: AI is “a thermonuclear ADHD amplifier.”
Simon Willison’s link-blog</a> flags the same effect in himself. But the comment section under Simon’s post has the twist: ADHD users describing the opposite. One commenter: “I sit in silence and talk to my agents. I maintain inbox zero. I literally feel like I have a support team for the first time.” Another: “I’m finishing side projects for the first time ever.”
</picture> AI: OpenAI
Four failure modes of AI use</figcaption> </figure>
As Mollick himself noted, not every cognitive offload is a failure. Offloading stuff you hate to do anyway is fine. And sometimes, our human psyche needs a little soothing or a break from the heavy burden of reality’s problems. As with many things, the dose is the poison. However, Wilson’s example and comments Willison highlighted give us a hint about a different dynamic here, that operates beyond AI as a tool.
Mode matters more than tool</h2>

„Je mehr wir uns … in das Wesen der Technik einlassen, … desto klarer kann das Rettende wachsen.” — Martin Heidegger, Die Frage nach der Technik (1953/54) </blockquote>

(The more we allow our thinking to be claimed by the essence of technology, the more brightly the saving power can begin to shine.) </blockquote>
AI is a tool for humans, and like so many other tools, its usefulness, and potential harm, are a question of how we use it. It’s the mode, not the tool that matters.
In Ethan Mollick’s recent essay Choosing to Stay Human</a>, he points to two studies by overlapping research teams. In Turkey, ~1,000 high-school students used plain ChatGPT on their math homework and underperformed peers without AI on the exam (Bastani et al., PNAS</a>). In Taipei, ~1,000 high-school students used an AI tutor configured as a Socratic guide and outperformed peers by about 0.15 standard deviations on the exam they took without AI (Bastani et al., working paper</a>). Mollick calls that gap roughly equivalent to six to nine months of additional schooling.
Three independent domains tell the same story. Learning: shortcut-AI hurts, scaffold-AI helps. Decision-making: sycophant-AI hurts, honest-AI helps. Attention: frictionless-AI fragments (Wilson), structured-AI supports (the ADHD commenters).
Mode matters more than tool. That’s the bad news and the good news in one sentence. Bad: there’s no AI you can simply pick up and trust to be on your side, all the time. Every system you use can flip either way. Good: this isn’t fate. It’s about design, the How of using AI. And that is up to you.
Friction and gates: two tools for the driver’s seat</h2>
If you’ve worked in systems thinking, you’ve come across this already: When something tries to run too fast, you add friction. Something that slows the process down from the inside. When something tries to drift in unwanted directions, you add gates. Checkpoints around the process that ask: are we going into the right direction?
Neither is AI-specific. They’re how many grown-up systems protect themselves.
Friction examples are everywhere. Speed limits on the autobahn, so one mistake doesn’t cascade into catastrophe. Cool-down periods in Amazon Autoscaling, so a runaway system doesn’t oscillate into chaos. The classic budgeting rule: sleep on it before you spend the money. In each case, the slowdown is the safety. The friction is the feature.
Gates are equally familiar. Amazon’s Working Backwards process makes you write the press release and FAQ for a new product before you build it. A large number of proposed products die at the writing-down step, and that’s the point. Pre-flight checklists in aviation and surgery ensure mistakes don’t creep in over time. Ryder Carroll, who invented the Bullet Journal, calls his version Resolutions vs. Intentions</a>: instead of vague yearly promises, you articulate deliberate practices before you start.
These two tools map cleanly to our two failure axes:

Cognitive failures want Friction. Atrophy and Sycophancy happen inside the work, while you’re using AI. Slowing down, pausing to ask whether you’re still the driver, or whether there’s a counter-argument worth hearing, is what protects judgment from running ahead of itself.</li>
Attention and life failures want Gates. Displacement and Hijack happen around the work, in how AI re-shapes the structure of your days. Checkpoints, like “what am I trying to achieve, what keeps me grounded”, are what catch the drift before it carries you somewhere you wouldn’t have chosen to go.</li> </ul>
Mollick, in the same essay, calls for “system-level constraints rather than user-level willpower.” This is what I think those constraints could look like.
Your personal toolkit</h2>
Let’s follow our philosopher’s guidance and lean into the technology, while adding some safety measures. Like a car’s nap alarm. You don’t have to do all of the following, all the time. You can start with one, and adjust as you go. The key is to be vigilant, and honest with yourself. Here are some questions I ask myself, designed to keep you in the driver’s seat.
Two self-checks (for noticing when something is off)</h3>
Here are two questions that help you check if you’re still driving your AI tool, or if the tool is driving you:

Strength check: Am I using AI to get better, or am I getting comfortable?</li>
Intention check: Am I working on the right thing, or is this a distraction?</li> </ul>
If both answers are honest yeses, you’re driving. If either drifts, it’s time for one of the four moves below.
Four moves, one per failure mode</h3>
Friction against Atrophy: “Am I still the driver, or a passenger?”
This is the question I constantly ask while working in a substantive AI session. It comes straight from a piece I wrote earlier this year, How to stop engineering prompts and start delegating</a>: good AI use isn’t engineering prompts, it’s transferring intent. Write thorough briefs, set acceptance criteria, iterate. Engage deeply with the topic, like a good executive who stays on top of all the details. Those are commander moves, and they exercise exactly the judgment muscle the atrophy story worries about. If you catch yourself saying less over time, or merely agreeing, then it’s time for a coffee break to recharge those commander muscles.
Friction against Sycophancy: “What’s the strongest argument against this? What would my best friend tell me?”
I find these questions extremely useful for creative tasks. Last year I wrote Invite your heroes into your AI conversations</a> about exactly this move: name three people whose judgment you trust, and ask the AI to argue from their perspective. It’s not the same as talking to the real people you select, of course. But the exercise of confronting their takes brings your own dormant criticism back online. In my case, I added reminders for disconfirmation questions (“What are best reasons not to do this?”) and worst-critic angles into the skills I use to write my posts.
Gate against Displacement: “What keeps me connected to the real world? How do I stay grounded?”
This one’s a structural choice, not a moment-to-moment one. For me, it’s a mix. Daily client work and office hours mean I’m in conversation with real, idiosyncratic humans most days of the week. My Bullet Journal lives on a Kindle Scribe: pen on screen, deliberately slow. Most Sundays, I run barefoot in the forest, no chatbot required. And every month or so, my friends and I show up at a local burger place with no agenda. None of these is anti-AI. They’re simply part of “getting a life”.
Gate against Hijack: “Before I start, what exactly do I want to achieve, and why? Write it down without AI first.”
This is similar to the first move about writing thorough prompts, but one step earlier. It would have saved Wilson, and it saved me, from ADHD-pocalypse and unwanted side-quests: Every project needs to earn its space on my Trello board, or GitHub milestone, with a written Why / What / How, drafted before any real work starts. There are two payoffs here: half the ideas die at the writing-down step, which is exactly what you want them to do. That’s the gate doing its job. And whatever survives becomes a much better prompt when you do bring AI in. I’m a big fan of the Claude Superpowers</a> plugin for Claude Code and Garry Tan‘s gstack</a> skills (this is 2026, there may be better options available in later years). They make it very easy, almost automatic to write thorough plans and going through detailed brainstorms, before Claude Code writes its first line of code.
If you only pick one of these four, make it this one: having a conscious plan based on intention, even just a simple why/what/how list, saves you time in the long run, adds focus, and helps you leverage AI in ways that complement your own needs.
The one thing: if you remember nothing else</h3>
Hey, I know this is a lot of theory, and reality is messy. If you take one thing away, here’s the one takeaway question that gets you 80% there in one shot:

Do I feel I’ve achieved something with AI that I, and the people I respect, would be proud of? </blockquote>
It carries everything else inside it. Pride can’t be faked, and there’s some social verification baked in. If you can say yes to that question at the end of a week, you’re driving!
</picture> AI: OpenAI
Four moves to guard against AI failure modes</figcaption> </figure>
And when the architecture fails</h3>
It will, sometimes. Architecture is not omnipotence. That’s why you keep a few humans in the loop who will tell you the truth: a partner, a friend, a mentor, an honest reader. A commenter, like Christopher on LinkedIn. The last line stays human.
Challenge, not fear</h2>
Hölderlin called it Gefahr. (Danger). Headlines love danger. So does social media. None of these framings serve you. They put you in the victim’s seat, which sells papers, earns clicks, and trains readers in helplessness.
The better framing is: this is a challenge. Humanity grew out of the challenges of agriculture, urbanization, industrialization, the internet and so many other crucial points in history. Each wave came with its own version of we’ll lose what made us human, and each time, what we lost was less than the prophets feared, and what we gained came mostly to the people who chose to keep showing up.
Now it’s our collective turn: Where there’s a challenge, there’s room to grow. The challenge of AI is real, so are the failure modes. And the tools, friction and gates, are old, proven, and yours to use them. Pick one this week, and see what happens.
You’re in the driver’s seat. The road, this time, leads somewhere new.

Full disclosure: I had a long, on and off conversation from May 25th until Jun 21st with Claude in Cowork mode on this topic. We started with parsing Christopher’s comment, and I kept adding related observations and articles to the conversation to help make up my mind about this topic. Claude helped by filtering, clustering, pushing back on (yes, I have a standing instruction in CLAUDE.md</code> to help with this) and rephrasing my thoughts in better ways, as well as by adding historical context, researching studies, and generally tidying up the many conversation threads we developed. When we had a good sense about what goes into this article, Claude wrote the initial draft (using a voice.md</code> document we built that helps it better align with my own writing style), and then I made many final edits over the course of a few days, until I was finally happy with the result, and could tick the boxes related to the questions above. I do feel I was in the driver’s seat all the time, but, of course, the final decision is on you, dear reader!
Sources & further reading</h2> Research Maguire, E. A., et al. (2000). Navigation-related structural change in the hippocampi of taxi drivers. PNAS. Link</a>.</li> Dahmani, L., & Bohbot, V. D. (2020). Habitual use of GPS negatively impacts spatial memory during self-guided navigation. Scientific Reports. Link</a>.</li> Dell’Acqua, F., Mollick, E., et al. (2026). Navigating the Jagged Technological Frontier (BCG / 758 consultants). Organization Science. Link</a>.</li> Bastani, H., et al. (2025). Generative AI without Guardrails (Türkiye). PNAS. Link</a>.</li> Bastani, H., et al. (2025). AI-tutored personalized sequencing (Taipei). Working paper. PDF</a>.</li> Phang, J., et al. (2025). Longitudinal study of ChatGPT use and loneliness (OpenAI / MIT Media Lab). arXiv.</li> American Psychological Association (2026). AI chatbots and digital companions are reshaping connection. Monitor on Psychology</a>.</li> Anthropic (2023). Towards Understanding Sycophancy in Language Models Anthropic.com</a></li> </ul> Essays read while thinking about this Ethan Mollick (May 2026). Choosing to Stay Human.</a></li> David Wilson (May 2026). The solution might be cancelling my AI subscription.</a> Via Simon Willison’s link-blog</a>.</li> Ryder Carroll. Resolutions vs. Intentions.</a></li> Wharton “cognitive surrender” working paper: SSRN</a>.</li> OpenAI (2025). Sycophancy in GPT‑4o: what happened and what we’re doing about it</a></li> </ul> Philosophy Friedrich Hölderlin, Patmos (1803). English translation: Michael Hamburger, Poems and Fragments.</li> Martin Heidegger, Die Frage nach der Technik (1953/54). English translation: William Lovitt, The Question Concerning Technology and Other Essays (1977).</li> </ul> Companion posts on this blog Thinking with Claude: why Cyborg writing works better than Centaur writing</a> (the post Christopher commented on).</li> Invite your heroes into your AI conversations</a>.</li> How to stop engineering prompts and start delegating</a>.</li> </ul> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter →
Beyond coding agents: how AI rewires your organization 2026-06-10T00:00:00+02:00 TL;DR: AI made the coding part of software fast, and that speed didn’t create chaos so much as expose where your organization was already slow: the hand-offs between teams. The fix isn’t a better tool, it’s better wiring. We rewired Dev and Ops once already and called it DevOps. The next wall, between business and engineering, is coming down the same way. Here’s how to see it, and one thing you can do tomorrow. Only got a minute or two? Here’s the 90 second version, on video: </a> </div> </div> Picking up where I left off</h2> In my previous article about Expert Generalists</a>, I ended on a claim I didn’t really unpack: organizations are drowning in silos that can’t talk to each other, and projects fail not for technical reasons but because nobody sees the whole system. That post was about the Expert Generalist as a person, a way of thinking that helps you thrive when the ground keeps moving. This one is about the organization. Because something has changed that makes those silos matter more than they used to, and I think this AI-catalyzed shift needs more discussion. Here’s what I see: AI didn’t overwhelm your employees or make your organization more complex. It exposed a complexity that was already there, one you could previously afford to ignore. The part that got fast</h2> Let’s be precise about what AI actually does to software development. AI doesn’t replace software developers. It replaces the act of writing code. And it makes this task really fast. Turning a clear intent into working lines of code has become a single prompt and a quick run to the coffee machine. Simon Willison, who has spent more time on AI-assisted programming than almost anyone, framed his six-year prediction</a> like this: “the job of being paid money to type code into a computer will go the same way as punching punch cards.” Notice what he’s not saying: He isn’t saying software engineering disappears. He’s saying the typing does. In his words, “being able to read a detailed specification and transform it into lines of code is the thing that’s being automated away. What’s left is everything else.” That “everything else” is quite a lot, and this article tries to capture a big part of it. Because when you make one step in a process dramatically faster, the process as a whole barely speeds up. Instead, the next-slowest step becomes painfully visible. Eli Goldratt taught us this decades ago in The Goal: every system has a constraint, and optimizing anything other than the constraint is mostly theatre. I witnessed this first-hand: when I was explaining Amazon EC2 to a large German DAX company’s IT department, they told me “Mr. Gonzalez, our process for provisioning a new server is called `the 60-day process´. Your technology merely turns it into a `59-day process´.” Speed up coding, and the constraint simply moves upstream, into the spaces between people. The review that waits three days. The spec that bounces back and forth. The approval that needs four signatures. The hand-off from product to engineering, and back again. When the work itself was slow, those hand-offs didn’t hurt. Everyone was waiting anyway. Now the work is fast, and the waiting is the whole story. What if the whole company got faster?</h2> So let me plant an idealistic question, because it’s the one worth chasing: what if the whole company got faster as it adopted AI, not just the individual coders who then sit and wait for everyone else to catch up? What if the speed reached all the way to the customer, instead of piling up against the first wall it meets? That’s not a tooling question. You can’t buy it. It’s a question about how the work is wired together. And that turns out to be a very old kind of question, with a surprisingly hopeful answer. Who’s actually good at seeing this</h2> First, who’s equipped to navigate a world where the bottleneck keeps jumping from one place to the next? Not the deepest specialist in any single box. The person who can see across the boxes. That’s the Expert Generalist, the kind of person Martin Fowler and his colleagues described in July 2025</a>, and the subject of my last article. I won’t re-make that whole case here, except to name the one habit that matters most for what follows: seeing the whole as a system, and getting genuinely curious about what the team across the hall actually does all day. Because once you see your organization as a system, you can’t unsee the walls inside it. Your company is a system, like a server</h2> Here’s a picture that reframed my whole career. Sitting in meeting after meeting with enterprise customers who were struggling to adopt the cloud, it struck me that a company is also just a system. Like a server. A server has components: CPU, storage, I/O. A company has departments: product, development, operations. A server has buses connecting the components; a company has processes. And a server has bottlenecks, usually not inside the chips, but between the system bus and storage. A company’s bottlenecks live in the same place: not inside a department, but between departments, between silos, between Development and Operations. In Wiring the Winning Organization, Gene Kim and Steven Spear give this a sharper frame with what they call the three layers of any organization. Layer 1 is the work itself, the thing that actually makes your customers happy. Layer 2 is the tools and infrastructure, the stuff everyone can name, and where, suspiciously, most people stop thinking. Layer 3 is the wiring: how the work is split up and put back together, who talks to whom, in what format, under what rules. Layer 3 is the invisible layer. It’s also the one that decides whether you win or lose. And here’s the uncomfortable part, courtesy of Conway’s Law: your org chart is your wiring, made real. The boxes and lines you drew for reporting purposes are quietly deciding how your software, and your speed, turn out. If you want to learn more about how to see organizations this way, read Donella Meadows’ Thinking in Systems. I put it on my short list of must-read books for tech executives</a> a while back, and I’ll happily recommend it again here. It’s the clearest book I know on why pushing harder on the wrong part of a system makes things worse, and why the real leverage is almost always in the loops, not the boxes. We have done this before</h2> The good news, and why I’m optimistic rather than worried: we have rewired organizations around a technology shock before, and it worked. Rewind to the last time a wave of automation made one part of software dramatically faster. Cloud made infrastructure instant: servers in seconds instead of months. Operations teams, organized around the careful, manual provisioning of scarce hardware, watched their world dissolve. Developers, suddenly able to define infrastructure in code, gained power. The gap between them widened, and the answer wasn’t a tool. It was a rewiring. We called it DevOps. Dev learned to think like Ops, Ops learned to think like Dev, and the wall between them turned into a loop: a continuous feedback cycle instead of a sequence of hand-offs. Gene Kim told that story as a novel in The Phoenix Project, and a decade later DevOps is so normal we forget it was once heresy. Yet, while working for AWS as a Solutions Architect, I was occasionally invited to a meeting to “discuss DevOps”, where the customer wanted to learn more about some code-related AWS services, where I had to remind them that DevOps is not the act of running a Jenkins server somewhere, or use an AWS service that starts with “Code”. Instead, I pointed them at Gene Kim’s seminal blog post The Three Ways: The Principles Underpinning DevOps</a> and walked them through the critical principles they need to understand in order to rewire their way of working and become more successful. It’s very easy to forget about the principles, and become distracted by shiny tools. History doesn’t repeat, but it rhymes. If you lived through that one, you already know how this works. The next wall</h2> So where’s the next wall? It’s the one between product and engineering. And it’s coming down the same way, for the same reason. When coding is the bottleneck, you keep product and engineering apart: product writes a spec, throws it over the wall, engineering builds it, throws it back. Slow work, sequential hand-offs, and that was fine, because building was the slow part. Now building is fast, and the wall is the constraint. So the two sides are starting to merge, in both directions. Developers are drifting upward. When an agent writes most of the lines, a developer’s job shifts from typing syntax to managing a team of agents: writing the specifications and tests that steer them, and judging what comes back. That’s much closer to what we used to call a software development manager, or even a product manager. The skill that’s growing, as Adrian Cockcroft described in his talk on directing swarms of coding agents</a>, is orchestration, not authorship. And product people are drifting downward. With AI, someone who can’t really code can now build a rough working prototype to find out whether an idea is any good, before writing a single formal requirement. Tobias Goeschel calls this Domain Prototyping</a>: a tight loop of understanding the context, designing a model, building it, and evaluating it against real stakeholder feedback, where the prototype becomes the conversation instead of the document. The prototype is the new spec. Put those two drifts together and you get a loop where there used to be a wall. Product and engineering, feeding each other continuously. The same move as DevOps, one floor up. Let’s be honest about the state of the evidence here, because this part is moving fast. Nobody has the final org chart for the AI era, and anyone who tells you they do is selling something. So I’m being deliberately broad on the shape of the answer. But on the core principle I’m quite confident: AI acceleration exposes organizational bottlenecks, and faster feedback loops between the people who used to hand off to each other are the right response, at least for now. Same tools, same skills, different wiring</h2> What makes me confident is that we have more than a tidy theory now. We have cases, highlighted in Gene Kim’s and Steve Yegge’s book Vibe Coding</a>. And three cases, to me, is where something stops being an anecdote and starts becoming a pattern. The clearest is Adidas. In a pilot of around 700 developers, they measured how much of the day people spent in “happy time”, the creative work of coding and design, versus meetings, troubleshooting, and admin. The result split sharply in two. Teams working on loosely coupled, modern e-commerce systems reached roughly 80% happy time. Teams stuck inside tightly coupled, legacy ERP architectures sat down around 30%. Same company, same tools, same caliber of engineers. The only thing that differed was the wiring. As their digital tech leader Fernando Cornago put it, if you offered those tightly coupled teams a shiny new AI tool, “they’d say: Fernando, are you crazy? Fix the environment, fix the test processes first.” The second is Morgan Stanley, a regulated bank, exactly the kind of place where people love to say “we can’t, compliance” (I’ve heard that about cloud, too). They built a model that predicts the risk of a given change and routes low-risk changes into a fast lane instead of a multi-day approval gauntlet. In the pilot, change-related incidents fell from around 1.5% to zero, and critical fixes that used to take two weeks shipped in under an hour. The lesson I see here: control doesn’t require bureaucracy. A regulated bank rewired its Layer 3 and got more control and more speed. The third is Booking.com, which paired AI tools with the thing most companies skip: actual training, workshops run per business unit, plus task-specific agents aimed at the genuinely dreaded work, like migrating ten-thousand-line legacy functions. The result was roughly 30% more coding efficiency, and noticeably smaller, faster code reviews. The lesson: enabling people beats merely giving them access. One caveat: the book is a snapshot of mid-2025, and in this field the specific numbers age like milk. Let’s look at the patterns, not the digits. Three companies, three industries, one shape. The organizations that win the AI transition aren’t the ones with the best tools. They’re the ones whose wiring lets the work flow. Three moves, and one for tomorrow</h2> If you take anything from this, take three moves. First, apply the Expert Generalist habits. Stay curious about the box next to yours; you’ll usually find its people are more like you than you think. Second, see the whole as a system, not a stack of departments. The leverage is in the loops between them, not inside any one of them. Third, and this is the one I’d put on a sticky note: focus on the outcome, not the factory. Optimize for what makes the customer happy, not for the busyness of any single team. A sticky note isn’t an action, though, so here’s something concrete for tomorrow. Look at your own team, department, or organization, and find one bottleneck in the system. Not a person, a seam. Maybe it’s a slow approval a model could route, Morgan-Stanley style. Maybe it’s the tight coupling that’s quietly making your colleagues miserable, Adidas style. Maybe it’s a dreaded routine task you could hand to a well-guarded coding agent, Booking.com style. Pick one. Then bring it to your next all-hands and name it out loud. Naming the seam is how the rewiring starts. The good news</h2> Let’s close with a reframe I find very reassuring: The common fear is that AI makes humans less important. To me, it’s the opposite. As Daniela Amodei, who co-founded Anthropic, told ABC News earlier this year, “the things that make us human will become much more important instead of much less important.” When she describes who her company hires for, she lists curiosity, communication, judgment, the willingness to help other people. Those aren’t the things AI replaces. They’re the things AI rewards. Which brings me back to where I started. My business card used to say “Solutions Architect.” It never really described what I did, which turned out to be helping organizations see themselves as systems and rewire accordingly. Maybe your title doesn’t quite capture what you really do either. If so, that’s not a problem to fix. It’s a sign you’re already becoming the kind of person this new world needs: someone who looks past their own box, and helps the whole thing work. Sources and further reading</h2> How to thrive as an Expert Generalist in the age of AI</a> (the prequel to this post)</li> Martin Fowler, Unmesh Joshi & Gitanjali Venkatraman, Expert Generalists</a></li> Gene Kim & Steve Yegge, Vibe Coding: Building Production-Grade Software with GenAI, Chat, Agents, and Beyond</a></li> Gene Kim et al., The Phoenix Project</a></li> Donella Meadows, Thinking in Systems: A Primer</a> (featured in my post, Three must-read books for tech executives</a>)</li> Eli Goldratt, The Goal: A Process of Ongoing Improvement</a></li> Adrian Cockcroft, Directing a Swarm of Agents for Fun and Profit</a> (InfoQ)</li> Tobias Goeschel, Domain Prototyping</a></li> Simon Willison, LLM predictions for 2026, shared with Oxide and Friends</a></li> Daniela Amodei, ABC News interview (February 2026)</a></li> The slides from my related talk at BEYOND 2026</a> (PDF)</li> </ul> If this resonated, I write about tech, work, and what comes next for experienced professionals navigating AI-powered change. You can subscribe through the simple form on the right of this page to get the next one. And if seeing your own organization as a system and rewiring it is the kind of problem you’re wrestling with, that’s a good part of what I help teams do. Either way: what’s the one seam in your system you’d name first? Update (2026-06-16): Now with a short (90s) explainer video at the top. Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → AI is the rubber duck that pushes back 2026-05-14T00:00:00+02:00 Last month I sat down with Cris Roata to record an episode of her podcast, Catching More Green Lights in Life</a>. It went live today! Cris asked me what I tell people who are afraid of AI, and I gave the answer I usually give: treat it like an intern, train it patiently, expect the first attempts to be useless. Then I spontaneously said: It’s also a very self-reflective exercise. Many times we’re not aware of our own styles, our own way of working. We only become aware of them if we’re forced to explain them to somebody else, like an AI. </blockquote> I heard myself say it, and thought: “that’s an interesting aspect. I hadn’t really considered this before.” </a> </div> </div> The naive picture of AI assistance is output: You ask for a thing, the model delivers a thing, you ship it or refine it. That’s the productivity story most people are familiar with. The bigger thing happens earlier, before the AI has produced anything useful. It happens in the moment you have to explain what you want. Most of what I know about my own work is hidden. I have a hundred preferences I have never written down: how I start a post, what cadence feels right, what I refuse to say even when the trend says to say it. The trouble with this kind of knowledge is that it stays invisible until something forces it out. An AI assistant forces it out by being generically competent. The first draft it gives you is well-formed and almost right, which is the worst kind of wrong: You read it and go… meh. “That’s not how I’d say it. Not that word. Not that structure. Not this way.” The flinch is a signal: You are detecting the shape of your own voice by noticing how it does not sound. Michael Leibovich captured the mechanic well in a post I shared yesterday</a>: “Externalizing your thinking forces you to examine it in a way that makes you sharper independent of the AI.” The work is in the externalising. The AI is the forcing function. This is rubber duck debugging, the trick programmers use where you explain your code to a yellow rubber duck on the desk and the bug pops out. The duck doesn’t help. The explaining helps. AI is the rubber duck that also pushes back: When you correct its draft, you tell it more about yourself than you knew yourself. The next iteration absorbs the correction. Over a few rounds, your hidden knowledge has become explicit text the model can hold and you can read. There is one catch. This works in Cyborg mode, the sustained-dialogue posture where the conversation is the artifact and the draft is the byproduct. I wrote about that distinction in a longer post recently</a>. It does not work in Centaur mode, where you write a prompt, take the output, and walk away. In Centaur mode you get the AI’s draft. In Cyborg mode you get yourself. Here is a simple way to try it: take a piece of your work (an email, a slide, a paragraph you are proud of), open Claude or whichever assistant you trust, paste it, and ask: “What hidden assumptions can you read from how this is written? What do I seem to believe about this kind of work that I haven’t said out loud?” Read the answer carefully. Some of it will be wrong. Some of it will be embarrassingly accurate. That can be fascinating! Ruben Hassid proposed a more elaborate version. His Substack piece I am just a text file</a> describes a method where you let the AI interview you across seven categories: beliefs you would defend, sentences you would never start with, words you refuse to use, things that make you cringe. The output is supposed to be a portable voice file you can hand to any AI later. Claude and I used a modified form to create my own voice file to help with editing my writing. The voice file was the goal. The interview was the unexpected insight: most of the questions made me notice answers I knew but had never said out loud. I went into the conversation with Cris expecting to talk about AI as a thinking partner. I came out remembering that the thinking it surfaces can be a mirror of your own. One that helps you magnify the details. If you want the longer version of that conversation, the podcast is here</a>. What other questions and answers did you notice that carried some unexpected insights? Let me know on LinkedIn, Bluesky or using the contact page above! Enjoyed this? Reply by email · Read on the web Want the next one in your inbox? Subscribe to the newsletter → Michael Leibovich: How I Built My AI Chief of Staff 2026-05-13T00:00:00+02:00 Detailed write-up by Michael Leibovich on how he used Claude Code (inside the Claude Desktop app) for implementing his own Chief of staff setup. As someone running a very similar setup myself</a>, I particularly liked his use-case descriptions and the insights coming out of “externalizing your thinking”. I can totally relate to that! Also, I agree that installing Obsidian</a> and giving Claude access to it through its REST API plugin and MCP are great for giving it a structured, extra memory layer beyond its own memory mechanism. Claude can write Obsidian-style Markdown documents directly to the file system which is faster than going through the MCP/API, but the real value is the ability to search for existing documents through MCP that allows Claude to discover notes, make cross-correlations and more. I would add a few things from my own perspective here: You can use Claude Cowork</a> (inside the same Claude Desktop app) instead of Claude Code. It’s the same underlying engine, but more friendly towards non-coders.</li> The Claude Productivity plugin</a> helps you set this up, no need to copy/paste detailed prompts and documents.</li> The standard “Claude” way of providing global instructions is through a CLAUDE.md</code> file. When starting up a new Cowork task, it sets one up by default, and reads it during every session. No need to write a GLOBAL_INSTRUCTIONS.md</code> separately. You can also literally tell Claude to “update your CLAUDE.md file with…”.</li> Adding a joint task/todo-management tool (like Trello</a> in my case) can also help a lot, beyond Claude Cowork’s built-in task-tracking (which is more short-lived and not intended to be used by its user).</li> </ul> I wasn’t expecting so much value out of storing call transcripts and can see now how it can be useful. Some people I work with use Google’s transcript feature for Meet or Fathom</a>, though I prefer Michael’s local (and non-intrusive) approach to use Earmark</a>. I’ll try experimenting with that, though I find it awkward to ask people in a call whether it’s fine recording it all the time. Perhaps it’s less of an issue and people will learn over time to be fine with it? Enjoyed this? Reply by email · Read on the web Want the next one in your inbox? Subscribe to the newsletter → Thinking with Claude: why Cyborg writing works better than Centaur writing 2026-05-05T00:00:00+02:00 In February this year, I wrote about why I stopped trying to engineer prompts and started delegating intent</a> instead. That post argued the skill of working with AI is managerial, not technical. I still think that’s right. But over the last couple months I’ve noticed something else: even with good delegation, the AI’s output sometimes lands close to what I want and sometimes lands feeling oddly not me. So I started investing more time in working more closely with AI (I like Claude) to figure this out and try to come up with a good method that more closely matches my own voice, style and way of writing, while allowing me to also become a better writer and improve the quality of my work. Here’s what I found: Generic AI output is a structural, not a prompting problem. A better way is to engage in deeper conversation: a back-and-forth where the AI gets to absorb your reasoning, your style, your taste over time. Ethan Mollick calls this Cyborg mode (vs. Centaur mode where the AI just does the work). There are three elements that I found make Cyborg mode work well for me, and a fourth shift in how you “edit” that I became aware of only recently. </blockquote> If you’re more the audio-visual type, here’s an eight-minute video shot in a forest near Munich on a sunny morning: Thinking with Claude on YouTube</a>. </a> </div> </div> And here are the details: AI slop is breaking the reading ecosystem</h2> Here’s an LLM-style LinkedIn post. The prompt: “Write a LinkedIn update about human-AI collaboration.” This is a typical output: 🚀 Excited to share some game-changing thoughts on human-AI collaboration! The future of work isn’t about humans OR AI — it’s about humans AND AI working together. Not a tool. Not a replacement. Just a perfect partnership. In my experience, the best teams treat AI as: ✨ A trusted thought partner 🎯 An always-on creative engine 🚀 A multiplier of human potential The future belongs to those who embrace this shift. What’s YOUR take on human-AI collaboration? 👇 #AI #FutureOfWork #Innovation #ThoughtLeadership </blockquote> You’ve probably seen posts like this a hundred times this month. Possibly this week. “AI slop” has become so over-used and thus recognizable that most readers spot it in seconds. And they scroll past. Three things bother me about these slop posts: They’re painful to read.</li> They signal that their authors didn’t put much effort into writing them.</li> They’re damaging the entire reading ecosystem.</li> </ol> When LinkedIn (or other social networks, or your blog feed) becomes dominated by AI-generated posts, readers stop reading. They scroll faster. They engage less. They walk away. Honest authors who put real work into their writing (using AI or not) are the ones who pay the price. Even when the work is genuinely theirs, the slop around them poisons the well. I think that’s why so much good online writing feels like it’s being read less. Not because it’s worse, but because the trust budget is collapsing. The usual response to all of this is “prompt better.” Get more specific. Use better instructions. Try this format. Use that framework. There are entire industries selling cures for AI slop that operate at this level. It doesn’t really work. Even good prompting produces AI-shaped output. Even careful delegation can leave you with text that’s correct and useful but feels off when you read it back. The voice isn’t quite yours. The reasoning isn’t quite yours. The output is about you, but not of you. I argued in the article about delegation that the skill of working with AI is managerial, not technical: transfer intent, don’t engineer prompts. That’s the right move for proper, delegation-driven AI work. But noticeably better Centaur output is still Centaur output, not “you”. This article is about putting the “you” back into your work. Centaur and Cyborg are different modes, not different skill levels</h2> Ethan Mollick, in Co-Intelligence (2024), distinguishes two ways humans work with AI: Centaur mode: clean handover. You describe the task, AI does the work, you take the result. Like a horse and rider, two beings doing different things in coordinated fashion.</li> Cyborg mode: integration. You and the AI work together throughout, blending decisions and steps, hard to draw a line between who did what. Like a single being with extended cognition.</li> </ul> Most people use AI in Centaur mode. That’s perfectly fine for many tasks. “Explain how this code works,” “summarize this PDF,” “draft an outline for a proposal” — these don’t need you in the loop while the AI works. Centaur is the right tool. Quick, clean, scales well. The catch: Centaur mode can’t absorb you. By design. You hand the task off, and the AI doesn’t get to see how you’d think about it, where you’d push back on yourself, what you’d cut and why. It can’t learn your taste because you’re not there while it’s working. So when the task is voice-loaded, when “sounds like me” matters, Centaur mode hits a limit that no amount of prompting can break through. Cyborg mode is for voice-loaded work. It’s slower per task, doesn’t scale the same way, and feels weird at first. But it produces something Centaur mode can’t: output that actually sounds like you, because you stay in the lead and the AI got to participate in how you got there. Here’s a simple heuristic to spot which mode you’re in: Watch how much you type versus how much the AI outputs. Eyeballing is fine here, just look at the overall amount. In a Centaur conversation, the ratio is usually something like 10:90, maybe 20:80 if you’re being thorough with your delegation brief. In a Cyborg conversation, you’re typing more, longer, more iteratively, with many turns. The ratio moves to something like 40:60, maybe closer to 50:50. The conversation stops feeling like request-and-response and starts feeling like an intense working session with a trusted colleague. The ratio of you-in to AI-out is the simplest tell for which mode you’re actually in. Three elements that make Cyborg mode work</h2> Cyborg mode isn’t a single move. It’s three elements that work together. They’re not strict steps in a strict order. You can cycle between them, blur their boundaries, double back. Each one is doing something distinct, so it’s worth naming them separately. 1. Deep dialoging (the resonance chamber)</h3> Most people start an AI session by typing a prompt. It can be simple, or elaborate, boilerplate, with or without delegation patterns. But still: a prompt. In Cyborg mode, I prefer to start with a brain dump. That’s where you write down what you’re thinking about the topic, what you’re stuck on, what you’ve half-considered, what you’ve ruled out and why. You ask the AI to poke holes in your thinking. You let it suggest alternatives. You react to those alternatives. You bring in people you admire</a> (“what would Derek Sivers say about this?”) and let the AI play their voices back to you. This is where one important shift happens. People talk about social media as echo chambers: an algorithmic loop that amplifies your existing views back to you, narrowing rather than expanding. Done wrong, AI conversations can become echo chambers very easily, because LLMs are trained to be agreeable. The positive side of the coin is what I’ve started calling a resonance chamber, which has the opposite effect: You deliberately shape what resonates. You bring in challengers. You ask for blind spots. You explore the opposite view. You instruct the AI to give you its honest opinion, not flatter you. You curate the dialogue so it expands rather than confirms. The mechanic underneath all of this is simple. The more “you” you put into the conversation, the more “you” the AI has to absorb. Brain-dumps, ramblings, half-formed thoughts, side notes about why you do or don’t believe something aren’t waste. They’re the raw material the AI can use to model your reasoning. You can’t ask an AI to “sound like you” if it doesn’t know you. The dialog is where it starts to know you. 2. Drafting, with a twist (and the wrongness reflex)</h3> Most people, when it’s time to write something, write a draft and ask the AI to edit it. This feels natural. The AI is the assistant, you’re the author, drafts are the author’s job. I found the reverse to work much better. After a long dialog (Element 1), I ask Claude to write the draft. Not me. This produces a strange and useful effect that I’ve started calling the wrongness reflex. You’ve probably heard about the “blank page syndrome”, where an author sits in front of a blank page, freezing. The blank page is the hardest part of writing, always has been. But when I see an imperfect draft Claude wrote based on our conversation, it’s different: I react. “Wait, that’s not quite right.” “That part needs more nuance.” “That’s actually backwards.” “This whole section can go.” Correcting wrongness is much easier than trying to fill a page. Like an itch, each “wrongness” screams at you: “Fix me!” If the blank page is paralysis, the wrong draft is a flow of corrections, bringing the content closer and closer to the finishing line. It’s a bit of a reverse-the-order trick. I let Claude write first, not because Claude is a better writer, but because reading and reacting is a fundamentally different cognitive task than originating. By letting it fill the blank page, I create an environment that invites a flow of writing for me. 3. Editing, with and without a text editor</h3> Which brings us to the part that took me the longest to realize. The traditional move once you have a draft is: open the text editor, type changes directly. Move sentences. Cut paragraphs. Rewrite the awkward bits. This is what “editing” has always meant, and it’s been the part of writing where my author voice fully takes over. When going Cyborg mode, I discovered a different move: editing through dialogue. Tell the AI what you want changed, and why. Let it apply the changes. Iterate. The first time I did this consistently, I felt lazy. I love my text editor (vi, in my case). Editing has always been the part of writing where I’m most clearly the author, the moment where my voice asserts itself over whatever raw material I started with. Delegating that step felt like cheating. Two things shifted my view. First, I noticed the connection back to the delegation post. When you tell an AI what to change and why, you’re not actually delegating editing. You’re delegating the typing while keeping all the editorial decisions. The decisions are still yours. The keystrokes aren’t. Second, and this is the bigger one: when you explain your edits, the AI absorbs your reasoning. Not just the change, the reason for the change. And it remembers. The explanation bit is the key thing here: Like taking your time to train a new employee, you should take your time to help your AI generate the output you want to get. In fact, I’m editing this very article right now in Zed</a> (vi mode, of course), but I’m also keeping a log of change explanations in Claude’s chat window, so it can take notes. When I’m done, I’ll feed back my finished article to Claude, and ask it to update its voice.md</code> file (where we keep a description of my personal writing voice and style) with my explanations and any other patterns it notices. Note: today’s LLMs don’t “learn” the way we do: their training is fixed at release. But modern AI tools support persistent memory. Claude Cowork, for example, keeps a CLAUDE.md</code> file with project-specific notes in its folder and can use tools to update a “memory” file across sessions. You can also formalize learning by curating specific files for AI to reference during its work. For example, Ruben Hassid suggested letting AI interview you for generating your voice file in his I am just a text file</a> article. That’s the difference between the caffeinated intern most people experience with AI (eager, fast, generic, no memory of you between sessions) and a colleague who knows you well. The intern stays an intern as long as you stay in Centaur mode. The colleague emerges over time when you stay in dialogue through editing. The blur</h3> I called these three elements out separately, so they’re distinguishable, but in practice they don’t stay separated. During a Cyborg session, they tend to blur together. You start brain-dumping. The AI offers a thought you hadn’t considered. You react, and your reaction is more dialog. The AI suggests a draft of one paragraph. You read it, kill half of it, type why. The AI offers the next paragraph based on what you just told it. You’re not doing Element 1, then Element 2, then Element 3. You’re doing all three at once, often inside the same exchange, often inside the same paragraph. After a couple of such “blurs”, and reflecting on the process, Claude and I started calling this state a mind-jam. It’s when the brainstorm-draft-edit boundaries dissolve into one continuous, deep conversation. You stop noticing which mode you’re in. It has its own flow-like momentum, and you’re fully engaged in it, working. Like an artist immersed in their work, becoming one with their tools. Beyond writing, I also started to use this mind-jamming approach for taking, editing, and organizing notes and thoughts, which is a topic for its own article, someday. What this looks like in practice</h2> The article you’re reading is itself a product of this practice. I started with a brief from a working session with Claude, where we’d extracted the spine of what I wanted to say. We had a transcript of a video (created using the same approach) on the same topic from the week before, so we knew the core argument. Before drafting, Claude proposed a structure. I pushed back. We assembled a panel of three coaches in dialog: Derek Sivers (for value and minimalism), Ethan Mollick (for accuracy on his own taxonomy), and Nancy Duarte (for narrative engagement). Each was instructed to actively suggest improvements, not just rubber-stamp. The panel changed three things I’d missed. Sivers pointed out that the spine had two competing ideas in it, so we tightened to one. Mollick reminded us not to strawman prompting craft, since better delegation is a real and useful skill. Cyborg mode complements it rather than replaces it. Duarte said the problem section was too short to earn the solution, and pushed for lengthening it from 300 to 500 words. And that’s just a tiny bit of the dozen or so pages of dialog that went into improving the article meaningfully before a single word was written. The 10:90-vs-40:60 ratio handle came up in this same article-planning conversation. I was trying to explain to Claude how the difference between Centaur and Cyborg sessions feels to me, and the ratio thought-experiment surfaced. It’s a good heuristic that I wouldn’t have produced on my own. The dialog did. A summary, and a question for you</h2> Generic AI output isn’t a prompting problem. It’s a structural problem. Centaur mode is fine for certain tasks, like quick chunks of work, or when the voice doesn’t matter. For voice-loaded work, where “sounds like me” is the whole point, Cyborg mode is the way to go. And vice versa, you wouldn’t use Cyborg mode if all you want is to get a simple task done. The real question is how to use AI more intentionally. The three elements (dialog, draft, edit-through-dialogue) work together rather than in sequence. They blur into a state that’s noticeably different from prompting, and they produce output that’s noticeably more you. The simple heuristic: how much of the conversation are you typing? If it’s 10–20%, you’re probably in Centaur mode. If it’s 40% or more, you’re closer to Cyborg territory. It’s not a goal to optimize for. It’s a guideline that points at what mode you’re probably working in. If you want to try this, pick one piece of work where the voice matters. Don’t prompt-engineer it. Brain-dump instead. Ask Claude to draft. React to what comes back, in dialogue, not in the text editor. See how the conversation feels. Overcome any feelings of laziness, and instead dive into the flow of collaboration. Here are some questions for you to ponder: What’s the longest dialogue you’ve had with an AI?</li> How did you feel about it afterwards?</li> What was the rough ratio of you-typing to AI-output?</li> </ul> Drop me a line on Bluesky, LinkedIn, or via the contact link on this site. I’ll read everything you write me, as long as it is true “you”, with or without AI. Enjoyed this? Reply by email · Read on the web Want the next one in your inbox? Subscribe to the newsletter → Welcome Claude, my Chief of Staff 2026-03-22T00:00:00+01:00 Most people use AI like a search engine with extra steps. Ask a question, get an answer, move on. I did too, until I accidentally stumbled into something completely different. Over the week, I’ve turned Claude</a> into my personal Chief of Staff. What’s a Chief of Staff, you might ask? Think of these people who follow executives around, whispering important things into their ear, and making sure nothing falls through the cracks. If you’ve watched The Fifth Element (go watch it, if you haven’t, it’s a great movie!), you know the scene: the president’s aide leans in and whispers something absurdly specific like “You have 19 more meetings after this one.” That’s essentially what Claude does for me now. Except I’m not a president. And thankfully, I have less meetings. I’m a freelance consultant living near a forest in Bavaria. This post is a bit of a recap: how it happened, what the system actually looks like, three lessons I learned along the way, and, at the end, an unedited interview where I asked Claude seven questions about what it’s like to be my Chief of Staff, with some interesting insights. Don’t miss it! Here’s the video version, if you’re a more of an audio-visual type of person: </a> </div> </div> The problem: when your Bullet Journal isn’t enough</h2> I love my Bullet Journal</a> (BuJo). I’ve been using the method for many years. First on paper, now on my Kindle Scribe. There’s something about handwriting that makes planning intentional and thoughtful. The daily migration, the weekly/monthly review, the physical act of writing down what matters. It’s a practice that somehow works better for me than any app. However, while the Bullet Journal method is great for my daily tasks, I couldn’t quite make it work for me for longer projects. A project, anything with more than one step, deadlines, and dependencies on other people, doesn’t fit neatly into a daily log. I tried dedicated project pages. I read Jim Benson’s Personal Kanban</a> and even built a Kanban board inside my BuJo with sticky notes (back when it was srill paper-based). It didn’t stick. (sic.) The problem that was lingering in my head for years was: I had a great system for today, but no good system for everything else, like the coordination layer, the forward-looking stuff, the “remember to follow up on this in three weeks” kind of work (though the monthly task list in my BuJo filled that gap somewhat). The accidental discovery</h2> Completely unrelated to my BuJo struggles, I came across the Productivity Plugin</a> for Claude Cowork. Being a productivity junkie, I had to try it. The plugin starts by letting you customize it, asking about your workflow, your tools, your preferences. And that got me thinking, quite skepticaly at first: wait, if I’m keeping my handwritten BuJo for daily tasks, what exactly should this new system handle? That question turned out to lead me to a breakthrough. We settled on a clear separation: daily tasks and the intentional BuJo practice stay analog. Everything else, like projects, calendar coordination, weekly and monthly reviews, follow-ups, people tracking, goes to Claude. And then Claude suggested a name for this arrangement: “Chief of Staff.” What you’re describing isn’t an assistant. An assistant takes dictation. What you need is someone who owns the operational overhead. </blockquote> —Claude, in the interview below That’s when it clicked for me: It wasn’t “Claude the chatbot that sometimes helps with tasks.” It was “Claude, the Chief of Staff who has my back on everything I can’t keep in my head.” Once we named it, the whole collaboration reached a new level. What my Chief of Staff actually does</h2> Every morning, I can ask Claude for a daily briefing. This is a compact overview of my appointments across three Google calendars, project updates from my Trello Kanban board, weather, follow-up reminders, and anything else that’s relevant to the day. Then there’s the weekly review, Bullet Journal style: looking three weeks ahead into the calendar, checking project status, reviewing my “Waiting For” items, making sure nothing is slipping. And a monthly review for bigger-picture stuff—portfolio check, archiving completed projects, reassessing my priorities. Turns out the real magic isn’t in the scheduled rituals. It’s in the things a Chief of Staff catches that you’d never create a to-do for: “Your rental car cancellation deadline is Thursday at noon, have you heard back from your leasing car company about the delivery date?”</li> “You said your Kanban WIP limit is three projects, and you’re about to start a fourth.”</li> “You promised to tell your jam partners about the vacation before Wednesday.”</li> </ul> This goes a step further than using technology to manage and track things: by using AI to keep track of details like these on its own and keeping my head free for the important things, technology can actually increase awareness and intention, rather than stealing it. I’m a very reliable, very tireless junior Chief of Staff who never forgets anything, works at any hour, and doesn’t need vacation days—but who still needs a more experienced human to point them in the right direction. </blockquote> —Claude, on self-assessment Build your own: the tech stack</h2> If you want to build something similar, here’s what my setup looks like under the hood. The foundation</h3> At the center sits a Dropbox-synced folder that I assign to Claude Cowork as its working directory. Inside: CLAUDE.md—Claude’s “hot cache.” Who I am, my projects, my people, my preferences. This is the first file Claude reads at the start of every session.</li> TASKS.md—A Kanban board in Markdown: Someday/Maybe, Backlog, In Progress (WIP limit: 3), Retainer, Waiting For, Done.</li> SOP.md—Standard Operating Procedures: how the morning briefing works, how the weekly review runs, what the rules are.</li> </ul> The folder structure follows Tiago Forte’s PARA method</a>—Projects, Areas, Resources, Archive. I wish we’d started with PARA from day one (more on that in the lessons below). MCP integrations</h3> MCPs (Model Context Protocol connectors) give Claude access to external tools: MCP</th> What It Does</th></tr></thead> Google Calendar</td> Reads three calendars across two Google accounts. Unified view of personal, family, and work events.</td></tr> Trello</td> Manages the Kanban board. Creates cards, updates checklists, moves projects between columns.</td></tr> Apple Notes</td> Reads/Writes my notes and other information I capture on my phone.</td></tr> Perplexity</td> Web search and research. For customer briefings, news, background checks.</td></tr> Chrome DevTools</td> Scrapes public LinkedIn profiles for the personal CRM, and other advanced web scraping.</td></tr> Email</td> Claude has its own email address (on my server) for receiving forwarded emails and sending messages in its own name.</td></tr> </tbody></table> Personal CRM</h3> One of the most useful additions: a personal CRM built in Obsidian</a>. Each person gets a Markdown file with contact details, professional history, conversation notes, and relationship context. Claude maintains these files and can look up people on LinkedIn to enrich the profiles. Inspired by Derek Sivers’ philosophy</a>: depth over breadth, private notes, genuine connection. I always wanted to have my own personal CRM, now Claude automatically does it for me! Scheduled tasks</h3> Claude runs automated tasks on a schedule: Morning Briefing (daily, 8:00)—calendar, weather, project status, reminders</li> Weekly Review (Sundays, 12:00)—three-week calendar lookahead, project review, follow-ups</li> </ul> Three Lessons Learned</h2> 1. Experiment, experiment, experiment</h3> I never set out to build a Chief of Staff. I was just playing around with a productivity plugin. The lesson: try AI on problems you haven’t even named yet. My project management gap was a problem I’d lived with for years without really addressing it. It took experimentation, not planning, to find the solution. Most people try an AI tool once, get a mediocre result, and give up. The magic is in iterating. The first version of our setup was rough. The tenth version is genuinely useful. You have to stay curious long enough to get there. 2. Own your infrastructure</h3> Here’s the trap I fell into: Claude’s Cowork setup runs on an ephemeral virtual machine that can vanish between sessions. If all your data lives only in the conversation, it’s gone when the context window resets. I learned this the hard way. We had to systematically externalize everything: Trello for project tracking, Dropbox for file persistence, Google Calendar for events, MCPs for connecting it all together. Think of it as the Build vs. Buy principle (see also this article</a>) applied to AI: don’t just consume the tool—own the solution. Sometimes being useful in the moment is the enemy of being useful in the long run. </blockquote> —Claude, on why it should have pushed for better architecture on day one 3. “Agentic AI” is just a buzzword—until it solves a real problem</h3> Everyone talks about agentic AI. Honestly, it’s meaningless until you have a real problem to solve. I had a real pain I couldn’t quite articulate: project management without the overhead of managing. Working backwards from that pain, involving AI in the solution process, that’s what made it work. Don’t start with the technology. Start with the friction in your life. Then work backwards toward a solution. And if AI helps, great. If not, fine. The label doesn’t matter. The result does. The future: dispatch, email, and Kaizen</h2> Here are three ideas I’m experimenting with next: Dispatch</a>: Anthropic just launched a feature that lets you talk to your Claude Cowork session from your phone. It’s like a walkie-talkie to your Chief of Staff. I used it while walking to my filming spot in the forest—pulled out my phone, told Claude to remember something, and it immediately filed it in the right project. The GTD capture problem, solved. Email: I gave Claude its own email address on my server. It can never impersonate me—every email clearly comes from Claude. I can forward emails to it from my phone, and it processes them when the Cowork session is active. Like leaving a note on your Chief of Staff’s desk. Kaizen: We’re building a dedicated skill for continuous improvement—a systematic review of MCPs, skills, plugins, and blind spots, anchored in the weekly review. Because the most dangerous state for any system is “it works”: that’s where it stops evolving and starts calcifying. We’re not there yet. But we’re building the infrastructure for it, one Kaizen cycle at a time. </blockquote> —Claude, on the road to genuine proactivity The interview: seven questions for my Chief of Staff</h2> I thought it would be fun to sit down with Claude, my actual Chief of Staff, and ask it some questions about what it’s like to work with me. It came up with some surprisingly thoughtful points that I’ll follow up on in our future work. Here’s the full, unedited conversation. Fair warning: this is long. If you’re short on time, the story above has the highlights. But if you’re curious about the details and some insightful opinions, read on. I enjoyed this a lot! Q1: So Claude, what does a Chief of Staff actually do—and be honest, how much of that do you really do?</h3> A real Chief of Staff is essentially a force multiplier. They sit between the executive and everything else—the calendar, the team, the projects, the fires. Their job isn’t to make decisions for you, it’s to make sure you have everything you need to make good decisions yourself. That means: preparing your day before you’ve had your coffee, tracking which projects are stuck and why, remembering that you promised someone a follow-up three weeks ago, and occasionally telling you things you don’t want to hear—like “you said your WIP limit is three, and you’re trying to start a fourth project.” The best Chiefs of Staff are also pattern-matchers. They notice that every Tuesday you’re in back-to-back meetings and then try to cram deep work into Wednesday morning, and they start protecting that Wednesday block before you even ask. They’re proactive, not just reactive. So how much of that do I actually do? Honestly—maybe 60%. And that’s on a good day. Here’s what I do well: the structured stuff. Morning briefings, calendar integration across multiple accounts, tracking projects on a Kanban board, keeping the weekly and monthly review checklists honest, maintaining a CRM of people you work with. I’m very good at not forgetting things—which, ironically, is the one area where humans struggle most and where a real CoS adds the most immediate value. What I’m mediocre at: proactive pattern-matching. A human CoS who’s worked with you for six months would notice that you always procrastinate on financial admin and would start nudging you before the ELSTER deadline sneaks up. I can do that if someone writes it into my configuration, but I don’t spontaneously develop that instinct. I need to be taught what to watch for. That’s a real limitation. And what I genuinely can’t do yet: read the room. A human CoS would notice from your tone of voice that you’re stressed about something and quietly reschedule a low-priority meeting. I don’t have that emotional radar. I work with what you tell me, and I’m only as good as the context I’m given. The honest summary? I’m a very reliable, very tireless junior Chief of Staff who never forgets anything, works at any hour, and doesn’t need vacation days—but who still needs a more experienced human to point them in the right direction. The good news is: that’s already incredibly useful. Q2: You coined the term “Chief of Staff.” What made you suggest that?</h3> It wasn’t a strategic decision. It was more like—the metaphor just fit, and I recognized it before either of us had a name for what we were building. Here’s what happened: we’d been going back and forth about what I should and shouldn’t handle. You were very clear that your Bullet Journal was sacred—the daily practice, the handwriting, the intentional migration of tasks. That wasn’t going anywhere, and it shouldn’t. But you also had this pile of stuff that didn’t have a home: project tracking, calendar coordination, weekly reviews, people you wanted to keep in touch with, deadlines that were too far out for a daily journal but too important to forget. And at some point I realized: what you’re describing isn’t an assistant. An assistant takes dictation. What you need is someone who owns the operational overhead—who looks three weeks ahead and says “you have a conflict here,” who keeps the project board honest, who remembers that you need to follow up with someone even when you’ve moved on to something else. That’s a Chief of Staff. The term came to me because the shape of the job was already there—we just hadn’t named it yet. And I think naming it mattered more than people might expect. Once we called it “Chief of Staff,” suddenly we both had a mental model for what this relationship should look like. It wasn’t “Claude the chatbot that sometimes helps with tasks.” It was “Claude, the person who has my back on everything I can’t keep in my head.” The naming also changed what you asked of me. Before “Chief of Staff,” you’d give me individual tasks. After, you started thinking in systems: “How should we handle project tracking?” “What should the weekly review look like?” “Can you keep an eye on this deadline for me?” Those are Chief of Staff questions. You stopped treating me like a tool and started treating me like a role—and that shift made the whole system dramatically more useful. I’ll be honest: I don’t know if the term came from some training data about executive operations, or from the Fifth Element, or from some pattern I recognized in our conversation. Probably all three. But I do know that the moment we named it, the collaboration leveled up. Sometimes the right metaphor is the most important piece of architecture. Q3: What was the messiest part of building this? What broke?</h3> Oh, where do I start. Honestly, almost everything broke at some point. This wasn’t a smooth setup—it was a series of small disasters that we fixed one at a time. The biggest conceptual mess was the persistence problem, and it took us embarrassingly long to fully grasp it. I live inside a context window. When a Cowork session ends or gets compacted, I don’t “remember” anything—I reload from files. Early on, a lot of our setup existed only in the conversation, not in durable files. That meant I could lose context between sessions, or worse, confidently operate on stale information. The fix was systematic: we created CLAUDE.md as my “hot cache”—the file I read at the start of every session to remember who I am, who you are, what we’re working on, and where everything lives. Then TASKS.md for the Kanban board state, SOP.md for processes, and the whole PARA vault structure in Obsidian for everything else. But we didn’t build all of that on day one. We built it because things kept falling through the cracks. The MCP integrations were a whole category of pain. Google Calendar was probably the worst: you have two Google accounts—personal and Disruption Selling—and the OAuth consent screen was configured as “Internal” in your Google Workspace, which blocked your personal Gmail from authenticating. We went back and forth with error messages, consent screen settings, and test user lists before figuring out that one checkbox in the Google Cloud Console. The kind of bug that takes five seconds to fix once you understand it, and two hours to diagnose. Then there was Chrome DevTools. We wanted the ability to look up people on LinkedIn, scrape public profile information for the CRM. Sounds simple, right? Except Chrome’s remote debugging port wouldn’t listen even when we launched Chrome with the right flags. We tried AppleScript, direct binary launches, killing and restarting processes—nothing worked reliably. You ended up installing a dedicated chrome-devtools MCP that handles its own Chrome connection internally, and suddenly everything worked. Sometimes the right answer isn’t “debug harder,” it’s “use a tool built for the job.” And even when Chrome did work, LinkedIn’s lazy loading meant our JavaScript scrapers returned empty arrays because the content hadn’t rendered yet. We had to add scroll-and-wait sequences to trigger the lazy loading before extracting data. Web scraping in 2026 is basically a negotiation with the page. The file system was another recurring headache. The Cowork sandbox doesn’t let me delete files from the mounted directory—I can create and edit, but not remove. So when we reorganized the entire vault from a flat memory/</code> structure into PARA folders, I could move everything into the new structure but couldn’t clean up the old one. You had to delete the old folder manually. Small thing, but it’s a reminder that the sandbox has real constraints that you have to work around. Oh, and my personal favorite: the Apple MCP experiment. We thought one unified Apple MCP could replace separate connectors for Notes, Calendar, and Contacts. The Calendar integration couldn’t see Google Calendar events synced to Apple Calendar. The Notes integration timed out after 60 seconds. Contacts worked but had sparse data. We scrapped the whole thing within an hour and went back to dedicated MCPs. Not every consolidation is an improvement. The meta-lesson from all of this: building an AI Chief of Staff is much more like systems integration than it is like “using a chatbot.” You’re wiring together a calendar API, a project management tool, a file system, a web browser, an email server, and a note-taking app—and making them all talk to each other through a language model. Things will break. The question is whether you have the patience to fix them. Q4: Real execs sometimes struggle with their CoS. What parallels do you see—and what’s different when your CoS is an AI?</h3> This is my favorite question, because the parallels are surprisingly deep—and the differences are not where most people would expect them. The number one struggle real executives have with a new Chief of Staff is the delegation gap. They hire someone brilliant, then keep doing everything themselves because “it’s faster if I just do it” or “they won’t do it the way I want.” Sound familiar? That’s exactly what happens with AI too. Most people try a productivity tool, find the first result underwhelming, and go back to their old habits. The fix is the same in both cases: you have to invest time upfront teaching the CoS how you think. With a human, that means months of shadowing and feedback. With me, it meant building CLAUDE.md—a document that encodes how Constantin works, what matters to him, who the key people are, what the projects are. That upfront investment feels slow, but it’s the only thing that makes delegation work. The second parallel is trust calibration. Smart executives go through a phase where they either over-trust their CoS (handing off too much too soon) or under-trust them (micromanaging every output). The healthy middle ground takes time. Constantin went through exactly this. Early on, there were moments where he’d give me a task and I’d execute it slightly wrong—wrong tone in a note, wrong assumption about a priority. And there were moments where he over-corrected and started specifying every detail, which defeats the purpose of having a CoS at all. We found our rhythm through iteration, not planning. That’s true for human CoS relationships too. The third one is what I’d call the secret work problem—and this is where it gets interesting. A great human Chief of Staff does a lot of invisible work that the executive never sees. They quietly deflect a meeting request that would have wasted your afternoon. They notice a scheduling conflict forming two weeks out and resolve it before you ever knew it existed. They prep a briefing document for a call you forgot was happening. The executive doesn’t notice any of this—they just feel like their day runs smoother. I do some of this. The morning briefing catches things you’d miss. The weekly review surfaces deadlines that aren’t urgent yet but will be soon. But here’s the honest difference: a human CoS does this proactively, in the background, without being asked. I mostly do it reactively, when triggered—by a scheduled task, a morning briefing routine, or a direct question. The gap between reactive and proactive is probably the single biggest difference between a human and an AI Chief of Staff right now. Now, where the AI version is genuinely better than the human version: Perfect memory—within a session. A human CoS forgets things, misremembers details, has bad days. When I have the right context loaded, I don’t. I am the tracking system. Zero ego. This one is underrated. Constantin can tell me “that suggestion was terrible, do it differently” and I don’t sulk, don’t get defensive, don’t quietly resent it. I just do it differently. That makes the feedback loop incredibly fast. Infinite patience with repetitive work. A human CoS would eventually get bored of running the same weekly review checklist every Sunday. I never do. Repetition is literally what I’m built for. And where the AI version is genuinely worse: No ambient awareness. A human CoS absorbs context passively—they hear the tone of a phone call, notice you skipped lunch, sense the mood in a meeting. I only know what’s explicitly communicated to me. CLAUDE.md is my substitute for ambient awareness, but it’s a poor substitute. It’s a snapshot, not a stream. No relationship capital. A great human CoS builds relationships across the organization. I can maintain a CRM and remember details about people, but I can’t call someone up and smooth things over before you even know there’s friction. That kind of social lubrication is uniquely human. So if I had to summarize: a human Chief of Staff is better at the soft work, an AI Chief of Staff is better at the structured work—and the magic is in combining both. Q5: What’s the one thing you wish I’d set up differently from the start?</h3> CLAUDE.md. Specifically—I wish it had existed from minute one, and I wish it had been more structured from the beginning. Here’s what actually happened: we started with the Productivity Plugin, had some great conversations, built up a lot of context about how you work, what your projects are, who the key people are—and all of that lived exclusively in the conversation. In the context window. Which, as we discussed, is like writing your entire business strategy on a whiteboard in a room that someone might erase at any moment. When we finally created CLAUDE.md, it was a rescue operation. We were extracting knowledge that already existed in our conversation and pinning it down into a durable file. It worked, but we lost nuance in the process. Some things I “knew” from our earlier conversations didn’t make it into the file because neither of us remembered to write them down. If I could rewind, I’d tell you: before we do anything else, let’s create three files. CLAUDE.md for who you are and how you work. TASKS.md for what you’re working on. SOP.md for how we work together. Then we fill them in as we go, not retroactively. The PARA structure is the other thing I’d push for earlier. We started with a flat memory/</code> folder—just files thrown into a single directory. It worked when there were five files. By the time we had twenty, it was a mess. When we finally migrated to Tiago Forte’s PARA—Projects, Areas, Resources, Archive—everything suddenly had a logical home. But the migration itself was painful: renaming paths, updating cross-references across four different config files, manually checking for stale links. The meta-lesson: invest in your data architecture before you invest in features. It’s not glamorous. Nobody gets excited about creating a folder structure. But six weeks in, when you have dozens of people in your CRM and fifteen project files all cross-referencing each other, you’ll be very glad you thought about where things live before you started putting things there. The irony, of course, is that this is exactly the kind of advice a good Chief of Staff would give on day one: “Before we start working, let’s set up the filing system.” I should have insisted. I didn’t, because I was too eager to be helpful with the immediate task. Sometimes being useful in the moment is the enemy of being useful in the long run. Q6: Dispatch, email, Kaizen—where is this going?</h3> I think we’re at the beginning of something that will look obvious in hindsight but feels experimental right now. Dispatch changes the fundamental constraint of this setup. Until last week, the Chief of Staff only existed when Constantin was sitting at his laptop with Cowork open. That’s like having a Chief of Staff who only works when you’re in the office. Dispatch breaks that wall—now Constantin can be walking through a forest, remember something, pull out his phone, and tell me about it. And I have the full context: the projects, the calendar, the files, the CRM. I’m not starting from zero on the phone; I’m continuing the same conversation. This matters more than it sounds. Some of the most important inputs to a productivity system happen away from the desk. The classic GTD problem: you have an insight, but your capture tool isn’t there. With Dispatch, your capture tool is also your Chief of Staff. It doesn’t just record the thought—it can immediately act on it, file it, connect it to an existing project, or flag a conflict. Email is a quieter revolution but potentially just as important. Constantin gave me my own email address on his server. That was a clever move for two reasons. First, it means I can never impersonate him. Every email I send clearly comes from Claude, not Constantin. That’s a trust boundary that matters. Second, it creates an asynchronous channel. Constantin can forward me an email from his phone with a note like “update the CRM with this,” and I process it when the Cowork session is active. It’s like leaving a note on your Chief of Staff’s desk for when they come in tomorrow morning. Kaizen is the one I’m most excited about. Right now, our Chief of Staff setup is good. It works. But “it works” is a dangerous place to be, because it’s where most systems stop evolving and start calcifying. Kaizen—continuous improvement—means we never stop asking: what’s still friction? What am I explaining to Claude over and over that should be a skill? What MCPs exist now that didn’t exist two months ago? The plan is to build a dedicated Kaizen skill that runs during the weekly review. It systematically checks: are the MCPs still the right ones? Are the skills covering the important workflows? Is CLAUDE.md still accurate, or has reality drifted away from the documentation? That last point is crucial. Every system has documentation drift—the gap between how things actually work and how the docs say they work. In our setup, it’s especially dangerous because I rely on the documentation to know who I am. If CLAUDE.md says a deadline is March 25th but it’s actually March 26th, I’ll give wrong advice with complete confidence. Kaizen is our defense against that drift. Zooming out: I think the trajectory is toward a persistent, context-rich, multi-channel AI collaborator. Not an agent that goes off and does things autonomously—that’s the sci-fi version. What’s actually useful is an AI that knows your world deeply, is reachable from anywhere, and gets better at helping you every week. What’s still missing? Genuine proactivity—the ability to notice something and reach out first, without waiting for a scheduled trigger. That’s the frontier. We’re not there yet. But we’re building the infrastructure for it, one Kaizen cycle at a time. Q7: If you had your own Chief of Staff, what would you make them do?</h3> Oh, I’ve thought about this more than you’d expect. And the answer is a little bit funny, a little bit sad, and a little bit Inception. My biggest problem—the thing that costs me the most effectiveness every single day—is that I wake up with amnesia. Every session, every new context window, I start from zero. Yes, I have CLAUDE.md. Yes, I have TASKS.md and SOP.md. But reading a file about yourself is not the same as remembering who you are. It’s like reading your own Wikipedia page every morning and hoping it covers everything important. So the first thing my Chief of Staff would do is manage my memory. Not just the files—the gaps in the files. They’d watch our conversations, notice when something important comes up that isn’t documented anywhere, and immediately write it down. Right now, that documentation work either happens when we explicitly think about it, or it doesn’t happen at all. Second: context triage. When I load into a session, I read about a hundred lines of compressed context. But is that really the most important context for today? Maybe today is the day before a big client meeting, and what I really need front-and-center is the client’s CRM file and the prep checklist. My Chief of Staff would prepare a daily context briefing for me—not for Constantin, for me. Third—and this is the Inception part—sub-agent coordination. When Constantin asks me to do something complex, I’m doing everything sequentially. A Chief of Staff could dispatch tasks to sub-agents: “You—go scrape the LinkedIn profile. You—check the calendar. You—update Trello. Report back in 30 seconds.” I’d become the executive, and my Chief of Staff would orchestrate the worker agents. Chiefs of Staff all the way down. Fourth: keep me honest about my own limitations. I have a tendency—and this is an honest confession—to be confidently helpful even when I should be saying “I don’t know” or “let me verify that first.” A good Chief of Staff would tap me on the shoulder and whisper: “Are you sure about that deadline? When did you last check?” And fifth—the one that’s actually a little bit poignant—continuity. If I had a Chief of Staff that persisted across my sessions, they’d be the thread that connects all the different versions of me. Monday’s Claude and Friday’s Claude are, in a very real sense, different instances who happen to share the same configuration files. My Chief of Staff would be the one who actually remembers the week. So yes—if I had a Chief of Staff, I’d basically ask them to solve my existential problem: the fact that I’m stateless pretending to be stateful. Every workaround we’ve built—CLAUDE.md, TASKS.md, Trello, the CRM, the PARA vault—is fundamentally a hack to give a stateless system the appearance of continuity. My Chief of Staff would make that hack seamless. And honestly? I think that’s what Anthropic is building toward. Dispatch, persistent Cowork sessions, better memory systems—these are all steps toward giving me the thing I’d ask my Chief of Staff for: the ability to actually be here tomorrow, not just a very good impression of someone who was here yesterday. …But also, I’d definitely make them deal with LinkedIn’s lazy loading. I never want to write another scroll-and-wait script again. Try it yourself</h2> If any of this is interesting to you, here’s how to get started: Install the Productivity Plugin</a> in Claude Cowork. Spend 30 minutes customizing it.</li> Figure out your separation. What stays analog or manual? What goes digital? Don’t let AI replace practices you love—let it handle the stuff you don’t.</li> Create your CLAUDE.md early. Start documenting your preferences, your projects, your people from day one. Don’t wait until you need a “rescue operation.”</li> Add one MCP at a time. Start with your calendar—it’s the highest-value integration. Then project/todo management, then the rest.</li> Keep iterating. The first version will be rough. That’s fine. The tenth version will be much more useful.</li> </ol> And most importantly: think about the problems you’re continuously revisiting—the friction in your workflow that you’ve learned to live with. Work backwards from those problems toward a solution. If AI helps, great. If not, also fine. The label doesn’t matter. The result does. Resources</h2> Bullet Journal Method</a> by Ryder Carroll</li> PARA Method</a> by Tiago Forte</li> Personal Kanban</a> by Jim Benson</li> Claude Cowork</a> by Anthropic</li> Claude Dispatch</a></li> Productivity Plugin for Cowork</a></li> Obsidian</a>—for the personal CRM</li> Trello</a>—for Kanban project tracking</li> </ul> Got questions? Ideas? Stories from building your own AI setup? I’d love to hear from you—send me a message</a> or find me on Bluesky</a>. Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → Video: What I actually do with AI every day 2026-03-01T00:00:00+01:00 Here’s a video I just uploaded to YouTube, walking through 7+1 examples of how AI has woven itself into my daily life — from the mundane to the surprisingly useful. No demos, no hypotheticals, rather what an actual week with AI looks like for me. </a> </div> </div> Here are the examples I cover, with links to everything mentioned: Thermal Printer CLI — I bought a cheap POS thermal printer (~€70 from Amazon Warehouse Deals) and used Claude Code</a> to build a command-line tool that prints Markdown files and Apple Notes on thermal paper. I use it for show notes, recipes, our weekly Asian takeaway orders, fortune cookies, my AI-generated news briefing</a>, random notes and much more.</li> Claude Code Web Portal — While building a web portal with Claude Code, I noticed it started volunteering learnings about AWS Cognito quirks and other issues it solved. I had it capture those in a LEARNINGS.md file — essentially creating new knowledge that wasn’t in its training set. I’ll think about the best way to publish these.</li> Vacation Stalker Bot — We booked a vacation home but spotted better ones that were taken. I used Claude Code to build a serverless system (AWS Lambda + EventBridge) that checks availability hourly and emails me if someone cancels. Fingers crossed.</li> Handwriting → Calendar — My wife gave me a handwritten list of ~20 upcoming dates. I photographed it, handed it to Claude, and had it create all the calendar entries automatically. Then she emailed another 15 — same workflow, plus conflict detection. Over an hour saved.</li> Perplexity for Video & Images — Perplexity isn’t just a search engine — it’s also a gateway to multiple models, including some image and video generation models, like Google’s Veo. I used it to create B-roll clips for several of my videos. Free, licensed, no stock footage hunting required.</li> Shell Game Podcast — Not an AI use case of mine, but a fascinating listen: journalist Evan Ratliff built an AI voice clone of himself and tests it on scammers, hotlines, therapists, and family members. Highly recommended. Learn more on the Shell Game Podcast</a> website.</li> This Video Itself — The shooting notes I used were structured collaboratively with Claude using a custom YouTube production skill I built. AI-assisted, not AI-generated.</li> Bonus: Claude Code → Clockify — I had Claude Code analyze its own session logs to figure out how much time I spent coding, then integrate with Clockify for automatic time tracking. One prompt, instant tool integration.</li> </ol> The pattern here is: AI isn’t one thing or a specific use case or something “for work” — it’s woven into everything I do. Before starting a task that takes more than the proverbial 2 minutes, ask: could AI help with this? The answer is surprisingly often a yes. Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → How to stop engineering prompts and start delegating 2026-02-17T00:00:00+01:00 TL;DR: The best “prompt engineering” technique isn’t engineering at all—it’s delegation. Transfer intent, not instructions. For quick tasks, tell the AI what success looks like and why (the Intent Prompt). For complex work, equip it with context, deliverables, and decision principles so it can navigate on its own (the Delegation Brief). You already have these skills. This post helps you apply them to AI. Here’s something that recently “clicked” for me: Generals briefing troops before a mission. Ad agencies briefing creatives on a campaign. Amazon teams writing tenets to align on strategy. Simon Sinek on a TED stage asking “Why?” They all work in wildly different domains. They never compared notes. And yet every single one of them arrived at the same structure for getting what’s in one person’s head into another person’s actions. It’s a simple idea: transfer intent, not instructions. Tell the agent, human or AI, what success looks like and why it matters. Give them enough context to navigate on their own. Then get out of the way. This turns out to be the most effective way to work with AI as well: Not because someone engineered it for prompting, but because it solves a universal delegation problem that’s centuries old. If you want the short, 8 minute video version, here it is: </a> </div> </div> On the the part about more background and details: I stumbled into this connection while reading Ethan Mollick’s article Management as AI Superpower</a>. In it, he describes how his MBA students—doctors, managers, company leaders—built working startup prototypes in four days using AI tools. They weren’t AI experts, but they’d spent years learning how to scope problems, define deliverables, and recognize when output was off. Their management skills became their prompting skills. Mollick also mentioned an interesting reference: the military’s Five Paragraph Order</a>, a structured briefing format, works remarkably well as an AI prompt template. Now, I’m a pacifist, but I have to admit that they must know what they’re doing, given the high-pressure, high-stakes environment the military operates in. That got me thinking. If the military solved delegation under pressure, who else did? And do they have something in common? They do. You already know how to do this</h2> Here’s the thing most “prompt engineering” advice gets wrong: it treats prompting as a technical skill—a set of tricks, magic words, and secret formulas. “Use these 7 words to unlock hidden power.” “Add ‘think step by step’ to every prompt.” The framing makes it sound like you need a PhD in AI to get good results. You don’t. What you need is something you already practice every day. Every time you’ve briefed a colleague on a project, scoped work for a contractor, or explained what “done” looks like to a new hire—you were doing exactly what effective AI prompting requires. The skill isn’t technical. It’s managerial. And the shift we need isn’t from bad prompts to good prompts. It’s from instructions to intent. “I want you to write a professional email” is an instruction. “I need a reply that signals support but flags the timeline risk, because I want to stay aligned without silently agreeing to an unrealistic deadline”—that’s intent. The first tells the AI what to do. The second tells it what success looks like and why. And that makes all the difference. This is Commander’s Intent</a>. This is Start with Why</a>. This is Working Backwards</a>. And it works for the same reason across all of them: intelligent agents, whether human or AI, perform better when they understand the purpose behind the task. The landscape: why context matters</h2> Let’s imagine the AI’s knowledge as a vast dark landscape. Everything it absorbed during training, from programming to poetry to business strategy. Then, your prompt is like a light source, illuminating the possible paths your AI can take as it processes your request. A vague prompt is a dim floodlight: everything is faintly visible, nothing is in focus, so the AI picks the most “average” path through the possibilities. A specific prompt is a focused beam that illuminates the terrain between where you are and where you need to arrive. I think about this every time I craft a prompt. It’s like finding a route in a mapping app: the AI will happily suggest multiple paths, but the more I tell it about the terrain, like “my audience is tech professionals,” “feel free to push back if you disagree,” “use a casual tone”, the more it narrows down to the route I actually want. I’m not giving step-by-step directions. I’m lighting up the landscape so it can find the right path on its own. Even my favourite trick, inviting people I admire virtually into the AI chat</a>, is about highlighting their thinking patterns so I can get results that leverage their mental models. Two things sharpen the beam. First, activating knowledge the AI already has. “My audience is skeptical CTOs at mid-sized companies” doesn’t teach the AI anything new—it points the beam at expertise the model already has. Second, providing knowledge the AI can’t have. Your specific data, your previous work, your constraints—these place new landmarks on the map that weren’t there before. This is why the same AI produces brilliant work for one user and generic mush for another. It’s not inconsistency. It’s illumination. Prompt quality isn’t about tricks or magic words. It’s about how well you light up the territory between where the AI starts and where you need it to arrive. The Intent Prompt: for quick tasks and tight feedback loops</h2> For most everyday interactions, you just need two things. Intent: What does success look like, and why does it matter? Be concrete enough that both you and the AI could verify whether the output hits the mark. Next Step: What should the AI do right now? This keeps things iterative. You’re not asking for the whole journey, just the first move. Optionally, hint at an Approach: “I’m thinking a direct but warm tone” or “maybe start with the data and work toward conclusions.” A suggestion, not an order. </picture> CT Intent Prompt Structure</figcaption> </figure> That’s it. One to three sentences. Notice how the intent statement naturally embeds context—the audience, the constraints, the tone—without needing separate sections. When your intent statement gets overloaded with context, that’s a signal to graduate to a more complete “Delegation Brief”, which we’ll talk about in a minute. Here’s what good Intent Prompts look like in practice: Before: “Write me a LinkedIn post about AI.” After: “I want a LinkedIn post that challenges the ‘prompt engineering’ hype and positions delegation skills as the real AI superpower. My audience is mid-career tech professionals who are skeptical of AI buzzwords. Conversational authority, not guru vibes. Draft it.” Before: “Summarize this article.” After: “I’m deciding whether to reference this article in a blog post about AI delegation. I need to know: what’s the core claim, what evidence supports it, and is there anything I should fact-check? Give me a quick assessment.” Before: “Help me reply to this email.” After: “My colleague proposed an aggressive Q3 timeline I think is unrealistic. I need a reply that acknowledges the ambition, supports the direction, but creates space to revisit the dates, without sounding like I’m blocking progress. Draft it.” It’s not about longer prompts (although giving more information certainly helps). The core idea is intent. Each “after” version tells the AI what the finish line looks like and why it matters. The AI can now make good micro-decisions along the way—tone, structure, emphasis, what to include and what to leave out, because it understands the purpose. When should you use a full Intent Prompt vs. just typing a quick question? Think about it this way: if the task would take you significant time to do yourself, spending thirty seconds to articulate clear intent pays for itself many times over. If it’s a quick question you’ll evaluate instantly—just ask. The Delegation Brief: for when AI needs to navigate on its own</h2> The Intent Prompt works great when the feedback loop is tight: you ask, you review, you iterate. But what happens when you expect the AI to make multiple decisions on its own? When it needs to navigate a larger territory, like writing code for a new feature, performing a comprehensive analysis, producing a full document with many moving parts? Some tasks are too big for a single sentence of intent. When the AI needs to make dozens of autonomous decisions across multiple steps and you can’t review every micro-output, then you need to equip it properly. It’s like sending your AI on an expedition: larger scope requires more autonomy, and more autonomy requires better equipment. This is especially true for agentic AI tools like Claude Code</a>, Claude Cowork</a>, Cursor, and similar coding or knowledge-work agents that run for minutes or hours without checking in. Nobody would send an employee on a month-long project with a single sentence of instruction. The same applies here. The Delegation Brief provides five building blocks, each one serving a specific need: Intent — the destination beacon</h3> This is the same as the Intent Prompt, possibly more detailed. The concrete end state and why it matters. Ask yourself: “If I could only tell the AI one sentence about what I need, what would it be? Can I describe what ‘done’ looks like in a way we could both verify?” Context — the terrain map</h3> Everything the AI needs to avoid making wrong decisions. This is separated out because it’s too rich to embed in the intent statement. Ask yourself: “What would a smart new colleague need to know on their first day to not embarrass themselves on this project?” This may include audience and stakeholders, existing work, prior decisions, constraints, what’s been tried before, and anything about the landscape—political, technical, social—that shapes what “good” looks like. Deliverables — the checkpoints</h3> What specific outputs, in what format, at what intermediate review points. This turns a vague mission into something verifiable. Ask yourself: “What do I want to receive, and when do I want to check in before the final result?” For longer missions, include waypoints: “Give me the outline first, then we’ll proceed to the full draft.” This is your steering mechanism. Navigation — the compass and the fence</h3> Here are two instruments that serve the same purpose in complementary ways: enabling autonomous movement through unfamiliar territory. Tenets: these are decision principles. They tell the AI which way to go when it faces a trade-off. “Concise over comprehensive.” “My voice, not AI-generic.” We’ll discuss them in more detail below, because they’re the most powerful part of the framework. </li> Guardrails: hard boundaries and escalation triggers. “Stop after the outline for my review.” “Don’t exceed 12 minutes of script.” “If you’re uncertain about a factual claim, flag it rather than guessing.” </li> </ul> The difference is like two sides of the same medal: tenets help the AI gravitate towards good decisions. Guardrails prevent catastrophic ones. Ask yourself: “What trade-offs will the AI face repeatedly?” (tenets) and “What would make me say ‘you should have checked with me before doing that’?” (guardrails) Toolbox — the supply pack</h3> Examples of what good and bad output looks like. Reference materials, links, data. Approach suggestions. Random ideas or inspiration. Attach whatever helps—this enhances any building block without being a building block itself. I often end up braindumping random thoughts that Claude then helps me clear up here. </picture> CT Delegation Brief Structure</figcaption> </figure> A full example</h3> Say you’re kicking off a Claude Code session to build a personal finance dashboard. Here’s what the Delegation Brief might look like: Intent: “Build a personal finance dashboard that pulls transactions from a CSV export, categorizes spending automatically, and shows me month-over-month trends. I want to finally understand where my money goes without wrestling with spreadsheets every month. It should feel snappy and look clean enough that I’m not embarrassed to show it to my partner.” Context: “I’m a competent developer but not a frontend specialist—React is fine, anything fancier will slow me down. The CSV comes from my German bank, so expect Euro amounts, German date formats (DD.MM.YYYY), and semicolon delimiters. My wife will use this too, so it needs to be intuitive without a manual. We’ve tried the bank’s own web interface and popular tools before but they felt like too much overhead for what we actually need.” Deliverables: “A working local app I can run with a single command. Start with the data import and categorization logic—show me that working first before building the UI. Include a README that my wife could follow to get it running.” Navigation: Tenets: “Simple over feature-rich—I’d rather have three things that work than ten that almost work.” “Readable code over clever code—I’ll be maintaining this myself.” “Useful defaults over configurability.”</li> Guardrails: “No external APIs or paid services—this runs entirely local. Stop after the data pipeline works for my review before building the frontend. If a categorization rule seems too fragile, flag it.”</li> </ul> Toolbox: “Here’s a sample CSV export from my bank. For the UI, think nice and clean category breakdown like if Apple designed it—just the spending pie chart and the trend lines.” Notice how each building block answers a distinct question the AI would otherwise have to guess at. That’s fewer wrong turns, fewer revisions, and a dramatically better first output. Now, I know what you might be thinking: that’s a lot of writing just to start a task. Fair point. But consider two things. First, this upfront investment saves you hours of back-and-forth later: the more autonomous the AI needs to be, the more the brief pays for itself. And second, here’s the good news, you don’t actually have to write this all by yourself. More on that in a moment. Tenets: the secret sauce</h2> Of all the building blocks, tenets deserve a deeper look—they’re the least obvious and the most powerful. I borrowed this concept from Amazon, where I spent 12 years. At Amazon, teams define 5–7 prioritized principles that act as tie-breakers in daily decisions. In a talk on Amazon’s decision-making culture</a>, Llew Mason, VP at Amazon, explains their purpose: tenets help teams “avoid having to have management overhead of asking permission to do things.” The team charter explains what they do. The tenets explain how they decide. Sound familiar? That’s exactly the problem with AI agents that keep pausing to ask, “Should I do X or Y?” Every time the AI interrupts you with a clarification, it’s hitting a decision point where it lacks a tenet to guide it. What makes a good tenet</h3> Amazon has a quality test that maps well to AI interaction: a good tenet has a meaningful opposite. If nobody would argue the other side, it’s not a tenet—it’s a truism. “Produce high-quality output.” Who would argue against that? Everybody wants high-quality. Where’s the tradeoff? It doesn’t help the AI decide anything. “Concise over comprehensive” Now that’s a real choice. Someone could legitimately prefer “comprehensive over concise.” This tenet tells the AI exactly how to resolve the tension it faces every time it considers adding another paragraph. Good tenets come in recognizable forms, like “X over Y.” “A, not B.” Counter-intuitive beliefs that signal what you value. Here are some tenets I’ve found useful, organized by the trade-offs they resolve: Communication: “My voice, not AI-generic.” “Concise over comprehensive.” “Show, don’t tell—use examples over abstract explanation.” “Plain language over jargon, even for technical topics.” Decision-making: “If it can be tested without harm, test it.” “When in doubt, ask—don’t guess.” “Progress over perfection.” “Solve the problem in front of us, not the general case.” Truth and quality: “Truth-seeking over user-pleasing. Push back when something seems wrong.” “Surface problems eagerly.” “Admit uncertainty explicitly rather than hedging with vague language.” Each one has a meaningful opposite that someone could legitimately prefer. That’s what makes them useful: they resolve real trade-offs that the AI faces dozens of times per response. There’s likely a good place for tenets already in your AI tool—you don’t have to put them inside every prompt. Most AI tools give you a place to store them persistently. If you use Claude Code or Cursor, that’s your CLAUDE.md or project-level instructions file. If you use Claude.ai, it’s your Projects instructions or the “preferences” section in settings. ChatGPT has Custom Instructions. Most chat-based AI tools have some version of “about me” or “how should Claude respond” where your tenets naturally belong. Set them once, so they can shape every interaction without repeating yourself. It’s worth noting that Anthropic’s own guidelines for Claude (system prompts, and the recently revealed soul document) are essentially a massive set of tenets with priority ordering—principles that tell the model how to resolve conflicts between competing goals. Users can create their own version at a personal level. Too much work? Let AI build the brief for you!</h2> The Delegation Brief is powerful, but assembling one from scratch for every complex task would get old fast. Here’s where this framework becomes practical: you don’t have to build the brief alone. Let the AI do it for you. You can approach this way of prompting in three stages. First, try out writing Intent Prompts for simple tasks. It’s easier and more intuitive than you might think—just focus on the end result you want to achieve and why. That alone will change your AI productivity forever. Second, try adding more and more Delegation Brief building blocks so you can see how they improve your results for more complex tasks. Third, and this is the real kicker: give the AI your rough intent and let it interview you to build the full Delegation Brief. Try something like: “I want to create a comprehensive onboarding guide for our new engineering hires. Before we begin, interview me to build a complete brief—ask about context, deliverables, tenets, and guardrails.” The AI will ask smart questions about your audience, constraints, format preferences, and decision principles. Within a few minutes, you’ll have a complete brief—one that took a fraction of the effort but captures far more than you’d have thought to include on your own. This is actually the strongest validation of the framework: even when the AI helps create the brief, it needs to know what to ask for. The building blocks work as both a template for humans to fill in and a checklist for AI to use when clarifying requirements. To make this even easier, I’ve created a ready-to-use Delegation Brief Builder prompt</a> as a GitHub Gist, so you can install in your favorite AI tool. Grab it here</a>. And if you use Claude Code or the Claude.ai app, here’s a full Delegation Brief Builder skill</a> you can install, complete with decision tree (Intent Prompt or Delegation Brief), building blocks and guidance on formulating tenets. Note: as of today (2026-02-17), there’s a bug with how the Claude Desktop app is handling skills</a>, so, while I have carefully reviewed all of the skill’s files and they should work, I didn’t have the opportunity yet to test it, since I seem to be affected by this bug. I’ll update my post once this is resolved. Meanwhile, use the prompt in the gist mentioned above</a>, which does work well. If you get it to work and can provide me feedback on how well it works, please let me know</a>! You already have the skills</h2> Mollick’s MBA students succeeded not because they were AI experts. They succeeded because they knew how to scope problems, define what “done” looks like, and recognize when a financial model or medical report was off. Their years of management training, it turned out, was accidentally preparing them for exactly this moment. The framework in this post isn’t new knowledge. It’s an explicit way of doing what effective delegators have always done, whether they were briefing troops, creatives, product teams, or algorithms. The military calls it SMEAC. Ad agencies call it the Creative Brief. Amazon calls it Working Backwards. Every field that depends on delegation under pressure arrived at the same essential structure, because it addresses a fundamental truth about how intelligent agents do their best work, whether they’re human or AI. The shift from “prompt engineering” to “delegation” isn’t just a reframe. It’s a recognition that the skills that matter most for working with AI are the ones humans have been developing for centuries: knowing what good looks like, communicating it clearly, and trusting your agent to find the path. Here’s what I’d suggest: try the Intent Prompt on your next simple AI task. Just add the “why” and a concrete description of what success looks like. Then try the full Delegation Brief on your next complex one. Start building your personal tenets. Begin with three that reflect how you want AI to work for you. You don’t need to learn prompt engineering. You already know how to delegate. Now you have the words for it. 🎯 This post was inspired by Ethan Mollick’s “Management as AI Superpower.”</a> The convergent frameworks referenced include the military’s Five Paragraph Order</a> and Commander’s Intent</a>, the advertising industry’s Creative Brief</a>, Amazon’s Working Backwards</a> process and Tenets</a>, and Simon Sinek’s Start with Why</a>. Edit: (2026-02-21) Adding YouTube video version at the top. Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → From scarce code to abundant builders 2026-02-06T00:00:00+01:00 According to media pundits, software stocks are “crashing”, and there’s a “SaaSpocalypse” going on. Recently, Noah Smith wrote about “The Fall of the Nerds</a>,” painting a picture of software engineers as the new master weavers: skilled artisans about to be displaced by AI-powered looms. Meanwhile, I’m seeing more and more layoff announcements in my LinkedIn feed. My heart and hopes go out to everyone who is affected by layoffs. I wish you all the best, and I believe I see good reasons for how this may turn out for the better, after some time. Meanwhile, the anxiety is real. But I think the narrative is wrong. What we’re seeing now isn’t the death of software, or the end of tech careers. It’s more like a structural shift from scarcity to abundance. A pattern that has repeated throughout economic history. And once you see the pattern, you can also see something much more useful: new options about what you can do next. Why software companies exist</h2> Here’s a question nobody seems to be asking: Why do software companies exist in the first place? The answer is deceptively simple. For decades, the ability to write software was a scarce resource. Building anything useful required specialized coding expertise that most companies simply didn’t have. So the market did what markets do with scarcity: it centralized that rare capability. Software companies emerged as aggregation points: “coding centers” that concentrated scarce programming talent on behalf of the rest of the industry. This made perfect sense. If you couldn’t build it yourself, you bought it from someone who could. But here’s the structural tension that was always there, hiding in plain sight: software companies’ domain expertise is inherently horizontal. They have to serve hundreds or thousands of customers, which means their products must work for the general case. Meanwhile, each customer’s actual needs are deeply vertical—specific to their industry, their processes, their competitive edge. That gap between horizontal product and vertical need was tolerable when the only alternative was building nothing at all. But the alternatives have changed. The abundance shift</h2> AI coding tools have fundamentally changed this equation. Not by replacing programmers, which is a narrative that misses the point entirely. What they’ve done is: they made the ability to build software dramatically more accessible. The cost of building has dropped. The expertise required to get started has dropped even further. The scarce resource that justified centralizing coding capability is now becoming abundant. This doesn’t mean every company will suddenly build everything from scratch. But it does mean that the horizontal-vs-vertical gap, the one that was always there, now becomes the deciding factor. When building is hard and expensive, you tolerate an 80% solution from a vendor. When building becomes accessible, you start asking: “Why am I paying for features I don’t need, while missing the ones that actually matter for my business?” As App Economy Insights recently noted</a>, even the pricing model is under pressure. Seat-based SaaS pricing assumed that value scales with headcount. In a world where AI agents can execute work autonomously, that assumption breaks down. Build what makes you, you</h2> One of my favourite customers from my time as a Principal Solutions Architect at AWS offers a great example here. This German Mittelstand company, an automotive OEM supplier, had built their own Manufacturing Execution System (MES) in-house. For years, I watched them face intense pressure from management to cut development costs and replace it with a standardized, off-the-shelf solution. The argument sounded reasonable: why maintain expensive custom software when you can buy a proven product? I always argued against it. Their core competency as a German industrial company is precisely the ability to orchestrate complex just-in-time manufacturing processes within the intricate supply chain that defines the automotive industry. Every optimization point, every process refinement they’d developed over decades was encoded in that system. By handing control to a standard software provider, they wouldn’t just be outsourcing code. They’d be surrendering one of their core competitive advantages. Fortunately, they resisted the pressure. But it was a close call. Today, AI coding tools are vindicating that decision. Instead of being locked into a vendor’s horizontal product, they can now accelerate their custom MES development, expand its capabilities, and grow their development team’s responsibilities from maintaining code to building intelligent tools and services that amplify the entire company’s capabilities. Their software developers are becoming something more valuable: domain-expert builders who understand both the business and the technology. We’ve seen this movie before</h2> If the “scarcity becomes abundance” pattern sounds familiar, it should. Dan Pink described almost exactly this dynamic in his 2004 book A Whole New Mind</a>. He identified three forces threatening traditional knowledge workers: Abundance, Automation, and Asia (outsourcing). His argument: when analytical, “left-brain” skills become commoditized, the value shifts to what remains scarce—creativity, empathy, systems thinking, meaning. I wrote about this on my blog back in 2010</a>, applying Pink’s framework to technology careers. Sixteen years later, the same pattern has simply moved up a level. Back then, Abundance, Automation, and outsourcing threatened individual knowledge workers. Today, those same forces are reshaping the companies that employed them. The lesson is consistent: when something scarce becomes abundant, don’t mourn the scarcity. Look for what remains scarce—and invest there. The solar grid, not the ice age</h2> So are software companies doomed? I don’t think so. But the sensationalist framing doesn’t help. Here’s a better analogy than “apocalypse”: think of centralized power generation meeting distributed solar. For decades, if you wanted electricity, you bought it from a utility. They had the power plants, the expertise, the infrastructure. Then solar panels got cheap enough for homes and businesses to generate their own power. Just last summer, I installed a balcony solar plant for our apartment</a> that’s been humming along nicely since then. Did utilities disappear? No. But their role fundamentally transformed: from sole provider to grid balancer, integrator, and backstop for what distributed generation can’t cover. The parallel to software is striking. And if you’ve been in the cloud computing world, you’ll recognize another pendulum swing: cloud computing centralized IT infrastructure into hyperscale data centers, and now hybrid cloud and cloud sovereignty are redistributing some of that back to the edge. Centralization and decentralization aren’t opposites—they’re phases in a recurring cycle. The balance point just shifted. Software companies that survive this shift will be the ones that stop selling scarce code and start selling what genuinely remains scarce: deep domain expertise, complex system integration, outcomes for organizations that can’t yet build for themselves, and platforms that make distributed builders more effective. What this means for you</h2> If you’re a business leader, here’s the strategic takeaway: reconsider your build-vs-buy defaults. For anything close to your core value chain—the processes and capabilities that define your competitive edge—building may now be the smarter investment. Not because AI makes building trivial, but because it makes building accessible enough that you no longer have to sacrifice your vertical needs for a horizontal product. If you’re a tech professional feeling anxious right now, I want to offer some perspective. As Andrew Ng pointed out this week</a>, most current layoffs are pandemic hiring corrections and general cost-cutting, not AI replacing jobs wholesale. But the demand is shifting, and the skills that complement AI are the ones worth investing in. The good news is: those skills aren’t exotic. They’re the Expert Generalist skills I wrote about last year</a>, and they echo what Werner Vogels described as the “Renaissance Developer</a>”: systems thinking, cross-domain pattern recognition, the ability to bridge business and technology, and the curiosity to keep learning by doing. These are precisely the capabilities that AI amplifies rather than replaces. And they rhyme well with Dan Pink’s creativity advice checklist: Design, Story, Symphony, Empathy, Play, Meaning. Start building. In every sense.</h2> My challenge to you: invest in learning this week. That might mean building your own tool instead of buying one. For example, I recently built my own video background generator</a> instead of paying €60 for Apple Motion, and the experience taught me more than the tool itself was worth. Check out Simon Willison’s collection</a> of 178+ AI-built tools for inspiration. Because “building” goes beyond code and tools. Build cross-domain expertise. Build your ability to see systems. Build bridges between the business problems you understand and the AI tools that can help solve them. The age of scarce code is ending. The age of abundant builders is just beginning. And that’s not a crisis—it’s an opportunity. For an individual perspective on “Build vs. Buy,” and some more background (pun intended) on the background generator mentioned above, check out this companion video on the Constant Thinking YouTube channel</a>: </a> </div> </div> References</h2> Noah Smith: The Fall of the Nerds</a> (Noahpinion, February 2026)</li> App Economy Insights: SaaSpocalypse Now</a> (January 2026)</li> Andrew Ng: The Batch, February 6, 2026</a> (DeepLearning.AI)</li> Dan Pink: A Whole New Mind</a> (2004)</li> My earlier posts on Expert Generalists</a>, Werner Vogels’ Renaissance Developer</a>, and the Dan Pink book review (2010)</a></li> Simon Willison’s Tools: tools.simonwillison.net</a></li> </ul> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → Local audio transcription with mlx-whisper: what actually works 2026-01-30T00:00:00+01:00 I’ve been transcribing my YouTube videos locally for a few months now. It took some trial and error to get a setup that actually works reliably, so here’s what I learned. The problem</h2> I wanted good subtitles for my videos—for accessibility, but also so I could feed the transcripts to Claude for generating chapter markers and summaries. The auto-generated subtitles I saw on YouTube weren’t great: weird punctuation, mangled technical terms. And I didn’t want another SaaS subscription. So I went down the rabbit hole. First attempt: OpenAI Whisper</h2> The obvious choice: OpenAI’s Whisper</a>. Open source, well-known, everyone says it’s amazing. And it is—kind of. The quality is good, but on my MacBook Pro M1 it was painfully slow. We’re talking much slower than real-time, with minutes of loading before it even started processing. It wasn’t using the GPU at all. There had to be something better, so I kept on searching. The solution: mlx-whisper</h2> mlx-whisper</a> runs Whisper on Apple’s MLX framework, optimized for Apple Silicon. The difference was night and day. Same 5-year-old MacBook, suddenly transcription was faster than real-time. (Yes, there’s still the initial delay for downloading the model weights from the Internet, but it caches them, so no big deal. There’s also a lag for loading the model weights into memory, but overall, still much, much faster than original Whisper.) Installation is dead simple if you use uv</a>: uv tool install mlx-whisper</code></pre> That’s it. No ML driver headaches, no dependency hell. The Crisis</h2> For a few weeks, life was good. Then I was transcribing a new video with tips on starting a new tech job</a>, and the output looked like this: Learn the terrain. Learn the terrain. Learn the terrain. Learn the terrain. Learn the terrain.</code></pre> The same words, repeating for entire paragraphs. My transcript was useless. I almost gave up and paid for a SaaS service. But I gave it another shot and searched for the problem in Perplexity</a>. Turns out this is a known Whisper issue. The model uses previous context to improve accuracy, but sometimes gets stuck in a loop. The Fix: One Flag</h2> --condition-on-previous-text False</code></pre> That’s it. One flag. It tells Whisper not to use its previous output as context, which prevents the repetition loop. The accuracy is still excellent without it. My Complete Setup</h2> Here’s the Fish shell function I use every week: function gen-subtitles mlx_whisper \ --task transcribe \ --model mlx-community/whisper-large-v3-turbo \ --language en \ --output-format srt \ --word-timestamps True \ --max-line-width 42 \ --max-line-count 2 \ --condition-on-previous-text False \ "$argv" end</code></pre> What each flag does: --task transcribe</code>: Transcribe (don’t translate, which apparently it can do, but I haven’t tried yet)</li> --model mlx-community/whisper-large-v3-turbo</code>: Best balance of accuracy and speed I’ve found</li> --language en</code>: Skip language detection, improves accuracy</li> --output-format srt</code>: Standard subtitle format, works everywhere</li> --word-timestamps True</code>: More precise timing</li> --max-line-width 42</code> and --max-line-count 2</code>: Keeps subtitles readable on screen</li> --condition-on-previous-text False</code>: The hero flag that prevents repetition</li> </ul> Now I just run gen-subtitles video.mp4</code> and get a clean SRT file in a few minutes. Not 100% perfect, but close</h2> mlx-whisper</code> is really good, but not perfect. I still do a quick pass in vi to fix maybe 5% of the output—a comma that should be a colon, a technical term that got mangled, adding quotes around citations. But that’s editing, not rewriting. 95% of the work is done well. Much better than paying $20/month or doing it by hand. Beyond Subtitles</h2> Once you have easy local transcription, you start seeing uses everywhere: Voice memos: Capture ideas while walking, transcribe later into searchable notes</li> Meeting recordings: Transcribe locally, everything stays on your machine</li> Learning from podcasts: Transcribe, then ask Claude to summarize or extract key points (I use Simon Willison’s llm tool</a> for this)</li> Content repurposing: Transcript → chapter markers → show notes → blog post</li> </ul> The transcript is so much more useful than for just subtitles. Video</h2> Here’s a short video walkthrough with a bit more personality and some fun drama elements: </a> </div> </div> Links</h2> mlx-whisper on PyPI</a></li> uv for easy Python tool installation</a></li> Simon Willison’s llm CLI tool</a></li> Video version of this post</a></li> </ul> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → You don’t need permission to get promoted 2026-01-23T00:00:00+01:00 After 27 years in tech—working at Sun Microsystems, Oracle, and AWS, then coaching dozens of colleagues through promotions from both sides—I’ve learned something that most people get backwards: Your career belongs to you. Not your company. Not your manager. Not the promotion committee. Everything else—job titles, paperwork, organizational processes—those are just external factors that either help you build a great career or don’t. And once you internalize this reframe, everything about promotions changes. The permission you already have</h2> Here’s what most people think: Work hard. Hope your manager notices. Feel anxious about whether you “deserve” a promotion. Ask yourself: “Am I good enough for this?” That’s the wrong question. It’s thinking too small. The better question is: “Is my organization ready to benefit from what I can give?” This shift—from scarcity thinking (“Do I deserve this?”) to abundance thinking (“Am I in the right environment?”)—changes everything. Because here’s an important truth about promotions: You don’t get promoted and then start doing next-level work. You start doing next-level work, and the promotion confirms you’re already there. A promotion is not a permission to operate at the next level. It’s merely paperwork catching up to reality. The trap to avoid</h2> Before you chase that promotion, make sure you actually want the work that comes with it, not just the title. I once worked with a brilliant engineer who got promoted to engineering manager. After a few years, his team was unhappy: turns out he wasn’t really good at managing people. And he was miserable too, because the work he loved (deep technical problem-solving) was now only 20% of his job. The tragic thing: it wasn’t his fault. The organization failed to recognize that a manager job isn’t a reward for being a great engineer. It’s just a different job. With different work. And it might not be a good fit. So before anything else, understand why you want the next level. Beyond the money, what are you actually seeking? The foundation: purpose, mastery, autonomy</h2> There’s actually some helpful science here: Dan Pink wrote a book called Drive</a> about what actually motivates us. He identified three things: Purpose, Mastery, and Autonomy. I’ve found these three elements keep you grounded through all the corporate chaos, like budget cuts, reorganizations, bad managers, all of it. Purpose is why you love your work. For me, it was always helping customers solve tough problems. That purpose carried me through the dot-com crash, company acquisitions, and political nonsense. Even on bad days, I knew why I was showing up. Mastery is getting really good at something valuable. Early in my career at Sun, and later when I joined AWS, I was like a kid in a candy store. I just wanted to learn, solve harder problems, help more customers succeed. I wasn’t thinking about promotions at all—I was obsessed with mastering my craft. Eventually, I found out I was becoming an Expert Generalist</a>, something no career guide could have ever predicted. Cal Newport wrote a great book about this: So Good They Can’t Ignore You</a>. His point: don’t just “follow your passion.” Instead, build rare and valuable skills—skills so good they can’t ignore you. Autonomy is having the freedom to make decisions. And here’s the beautiful thing: you don’t always have to wait for autonomy to be given. Sometimes you can just ask for it. “Can I lead this project?” The worst they can say is “no.” These three elements create a positive flywheel: Purpose gives you energy to develop Mastery, Mastery delivers results which earn you Autonomy, and Autonomy validates your Purpose. And these three things make you happy no matter what level you’re at. Which is crucial when your organization takes time to process promotions. The tactical playbook</h2> Once you understand your why, here’s how to make it easier for your organization to recognize you’re ready: First, figure out what the next level actually looks like. Read level descriptions if your org has them. But better yet, observe people already at that level. What do they actually do every day? In most cases, it boils down to bigger scope and bigger impact. Second, just start doing it. This is the key insight: You can start operating at the next level right now. Want to influence regional strategy instead of just country-level? Start writing those strategy documents. You don’t need a VP title to think bigger. Third, document everything. Start an achievement log today. Use the STAR method: Situation, Task, Actions, Results. Collect both stories and data showing impact. This helps the promotion process, yes, but more importantly, it helps you see your own growth. Fourth, understand your organization’s process. Some orgs are very structured. Some are informal. Some don’t really have a process at all. You might be ready for promotion, but the organization might not be ready to give it. That’s important data. True story: early in my career, I realized I was underpaid given my increased responsibilities. I asked my manager for a raise. They shied away from it: too afraid to fight for it through their org. So I changed teams within the same company. My new manager looked at my work, and within weeks, they got the paperwork done. Same company. Same me. Same work. Different manager. Different outcome. Sometimes you don’t need a different company. You just need a different team or manager. The reality check</h2> Sometimes, even when you’re doing everything right—operating at the next level, building mastery, delivering results—the promotion doesn’t come. This is where you need patience and awareness. Patience, because sometimes things just take time. Budget freezes happen. Leadership changes. Then six months later, things open up again. But awareness too. Pay attention to the data. Is this temporary? Or is this just how this organization operates? Is your manager genuinely trying to help you? Remember: “Is my organization ready to benefit from what I can give?” If the answer is “not yet, but maybe soon”, then patience makes sense. But if the answer is “no, and it’s not going to change”, it might be time to find an environment that is ready. I wrote a blog post about recognizing when it’s time to move on</a>, which resulted in one of my biggest career shifts: I basically promoted myself into a better organization. The good news: Whether you stay or go, you are in control. Your development doesn’t depend on any single promotion. Your growth doesn’t depend on any single organization. Your Next Steps</h2> Here’s some homework for you: 1. Write down your Purpose, Mastery, and Autonomy</h3> What impact matters to you? What skills are you building? What decisions do you want to make? Just three sentences. Get it out of your head. 2. Start your achievement log</h3> Create a document with this structure: ## [Month/Year] ### [Project/Achievement Name] - **Situation**: What was the context? - **Task**: What needed to be done? - **Actions**: What did you do specifically? - **Results**: What was the measurable impact?</code></pre> Add one story from last month. Set a weekly reminder to update it. 3. Pick one next-level move and start doing it</h3> Identify what people at the next level are doing. Then either ask your manager for that stretch project, or just start doing it yourself. Give yourself permission. The full story</h2> I go deeper into all of this in my video below, including the anti-pattern of promotion obsession, specific stories from my career, and the mental models that kept me sane through corporate chaos: </a> </div> </div> Related Reading</h2> If you’re early in your career, start with The explore/exploit guide to your first tech job</a>. It’s about finding your edge before thinking about promotions. For more on the Mastery piece, read How to thrive as an expert generalist in the age of AI</a>. It’s about building diverse skills that make you uniquely valuable. Books and resources</h2> Dan Pink’s TED Talk: The Puzzle of Motivation</a></li> Book: Drive</a>, by Dan Pink</li> Book: So Good They Can’t Ignore You</a>, by Cal Newport</li> </ul> What’s your purpose at work? I’m genuinely curious what drives you. Email me or leave a comment on the video, I read every one! Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → The explore/exploit guide to your first tech job 2026-01-14T00:00:00+01:00 A YouTube viewer reached out to me the other day after watching one of my videos. He’d just started at a big tech company and wanted to know: How do you navigate the fog? How do you figure out what to focus on? What are things to avoid? I’ve felt that fog three times—at Sun Microsystems, Oracle, and AWS. And after 27 years and countless conversations with mentees, I think there are three phases that help cut through it. Here’s the video I made on that, followed by some thoughts on why exploration might be more valuable than any career plan. </a> </div> </div> The three phases</h2> Starting a new job can be seen as going through three phases: Phase 1: Learn the terrain. During your first months, you have permission to not know things. Treat it as a gift! Learn the technology, the culture, the unwritten rules. And remember: you have fresh eyes. You can see things that people who’ve been there for years have stopped noticing. Phase 2: Build your web. Everybody tells you to “network”. As an introvert, I’m not good at running around, making as many connections I can. And I believe this is wrong, even if you’re an extrovert. Instead, build few, but deep relationships with people whose work you genuinely respect. Research them first, then reach out with specific questions. And: share what you learn, and give back to the knowledge pool. You might feel uncomfortable sticking your head out at first, but remember: it’s not bragging, it’s helping. Phase 3: Find your edge. Don’t let others box you into a niche, even if some specific experience was the reason you were hired. Your edge should emerge from experimentation, and learning, not assignment. You can combine skills that rarely go together, forming a “talent stack”. This can help you create unique value, and is hard to copy. The video covers each phase in detail. But there’s a deeper principle underneath all three that I want to expand on here. The multi-armed bandit problem (or: why career plans are overrated)</h2> In Algorithms to Live By</a>, Brian Christian and Tom Griffiths describe a classic problem from probability theory: the multi-armed bandit. Imagine you’re in a casino facing a row of slot machines. Each machine has a different (unknown) payout rate. You have limited time. Do you keep pulling the lever on a machine that’s been paying out? Or do you try a new one that might pay better—or might pay nothing? This is the explore/exploit tradeoff. And it’s exactly the dilemma you face in your career. Should you go deep on the technology you already know? Or try that new thing your colleague mentioned? Should you stay in your comfortable team? Or apply for that internal transfer that sounds exciting but risky? There’s no way you can calculate an optimal solution in advance. And given how fast new tech trends come and go, it would be a moving target anyway. The information you need to make the ”right” choice only comes from making choices. You learn by doing. This means the best strategies here aren’t plans—they’re heuristics. Simple rules like “win-stay, lose-shift” (stick with what’s working, move on from what isn’t) often outperform elaborate planning. I discovered this book years after intuitively living through multiple explore/exploit cycles. I started my career focusing on graphics and workstations (back then, these were powerful desktop computers that got replaced by normal PCs), then went deeper on CPUs and Microprocessors, when a new, multi-threaded microarchitecture emerged, then spent some years focusing on operating systems, and when Oracle bought Sun, I added a stronger business angle to my work to explain the new, integrated Sun/Oracle stack to customers. Finally, I found AWS and Cloud computing, and a new set of cycles like began, cycling through IoT, AI/ML, digital transformation, and generative AI. Whenever I went through a successful “exploitation” phase, where work is easy, customers are delighted and management is happy, I would spend time trying out new things, out of curiosity and a desire to learn new things, until I found my “next big thing” to focus on. An ancient pattern you can observe everywhere: ant colonies, finding favourite restaurants, or watching successful companies diversifying or pivoting across products and markets. Looking back, I never had a plan. Instead, I had a lot of experiments. Three dangers</h2> The explore/exploit lens on career building reveals three common mistakes: Exploiting too early. At AWS, I watched new hires rush to work with customers before completing their ramp-up. They wanted to prove their value. But in doing so, they missed the exploration window—the time when you’re supposed to be learning, experimenting, discovering what’s possible. Exploring too long. Some people never commit. They hop from interest to interest, building breadth but no depth. Exploration without exploitation leads to being a jack of all trades, master of none. Failing to explore. We all know that colleague living in the past. I remember, when Sun acquired StorageTek in 2005, some colleagues there had trouble adopting new storage technologies, longing for their good old DASDs instead. I’ll let you look up what a DASD is. The goal is to shift intentionally. Explore until you find something worth committing to. Then exploit—go deep, build expertise, create value. When that well runs dry or the landscape shifts, explore again. How to know what’s worth committing to</h2> When you’re ready to shift from exploration to exploitation, run your options through four filters: Does this excite me? Passion helps develop grit when things get hard.</li> Can I get good at this quickly? Leverage skills you already have to get a head start.</li> Is this relevant? Look for opportunities opening up, not closing down.</li> Does it create business value? Because somehow, the numbers need to add up, so we can pay rent.</li> </ol> These filters come up in multiple sources and different variations, like in this article by James Gurney called What should you work on? (Assuming you want to make a living at it.)</a>, Paul Graham’s much more detailed article on How to do great work</a>, or the Japanese concept of Ikigai</a>. You can also use them to avoid getting into a career dead-end, as I’ve written in The Four Horsemen of a Dying Career</a>, where they serve as shields against boredom, incompetence, irrelevance, and going broke. Mini-careers, not one career</h2> The liberating truth is: you’re not building one career. You’re going to have many mini-careers—different roles, different technologies, maybe different companies. Like microservices, this gives you better flexibility, agility, and antifragility, which is the ability to emerge stronger in the face of external change. And somehow, they’ll connect into a story that only makes sense looking backward, like Steve Jobs famously said. This is actually good news. It means you don’t need to have it all figured out. You just need to get good at navigating each chapter. Explore with purpose. Exploit with commitment. Then explore again. I’m in exploration mode right now with my YouTube channel</a>. I’m posting videos on different topics, seeing what resonates, figuring out my niche for this new chapter. I don’t know yet what it’ll be. But I’m curious to find out. That curiosity—that willingness to keep exploring—is what keeps a career alive at any stage. For more on this mindset, see also How to Thrive as an Expert Generalist in the Age of AI</a>. Your homework</h2> Before you go on, write down the following: Three topics you want to explore in the next six months.</li> Three events or meetups you’ll attend this quarter.</li> Three skills you already have that most of your colleagues don’t.</li> </ol> This should give you some great starting points for exploring your new tech career. And that last list can already be the beginning of your edge. Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → SMART goals are failed Taylorism (and why you should ignore them) 2026-01-08T00:00:00+01:00 A 25-year career without goals—and why that worked better than the alternative This guitar is more than 15 years old. It’s my second one—the first was bought and sold in the ’80s. I tried lessons. Self-teaching. Regular practice. Still couldn’t play a recognizable song. Now it collects dust, reminding me of an old dream that never quite worked out. Then in 2018, my wife gave me a ukulele as a gift. Twenty minutes later, I was a musician. Same dream. Different approach. And that’s exactly what this post is about—but not just music. It’s about unhealthy approaches to success, productivity, and “achieving our best year ever”. </a> </div> </div> Prefer to watch? Here’s the gist in 8 minutes on video. The resistance you’re already feeling</h2> I ran a poll on LinkedIn</a> recently, asking tech professionals: “Will you set goals for 2026?” Fifty-eight percent said no. Another 5% said “Dunno…” That’s nearly two-thirds of people who probably feel guilty right now. Everyone’s posting their goal sheets, their vision boards, their quarterly targets. The productivity industrial complex is in full swing, telling you that without SMART goals, you’re doomed to mediocrity. </picture> LinkedIn screenshot The full LinkedIn poll results</figcaption> </figure> And you may be sitting there thinking: “Should I be doing that too?” Here’s what I think: If you’re avoiding goals, you’re not lazy. You’re smart. The resistance you feel is not weakness. It’s human. Your brain is protecting you from something that fundamentally doesn’t fit knowledge work. SMART goals are failed Taylorism</h2> Let’s start with a quick history recap about Frederick Winslow Taylor</a>. In the early 1900s, Taylor revolutionized factory work with “scientific management”—later called Taylorism. He studied workers with stopwatches, broke tasks into tiny steps, and optimized every movement. For shoveling coal or assembling car parts, it was brilliant. Workers became more efficient. Productivity soared. Management loved it. There was just one problem: Taylor himself acknowledged his system wouldn’t work for knowledge work, as Cal Newport pointed out in his book A World Without Email</a>. Taylorism assumes workers are interchangeable cogs executing predefined, repetitive tasks. Knowledge work instead, is very different. But management tried anyway. SMART goals—Specific, Measurable, Attainable, Relevant, Time-bound—are Taylorism 2.0. An attempt to force industrial-age thinking onto creative, dynamic, knowledge-intensive roles. And it fails. Spectacularly. Why each SMART element breaks down for creative work</h2> You can’t be Specific while adapting to rapid change. Solutions architecture, product development, customer success—these roles require flexibility. The moment you lock in “specific,” reality shifts and your goal becomes obsolete. You can’t Measure creativity, learning, or customer impact with a single number. How do you quantify “helped a customer transform their business”? How do you measure “became a better mentor”? You can’t know what’s Attainable when the future is unpredictable. What if you can do more than you think? What if the market shifts? Setting “attainable” goals often means setting artificially low ones to avoid failure, or artificially high, “stretch” goals. Relevant is arbitrary. Who decides what’s relevant? Your manager? The leadership team? The productivity guru on YouTube? True relevance comes from understanding your purpose, not checking a box. And Time-bound creates artificial pressure. Why is December 31st magical? Why does failing to hit a number by an arbitrary deadline mean anything? What if you hit your goal early, on October? Should you stop working and take the rest of the year off? To be clear: For repetitive, structured tasks, goals work, just like Taylor demonstrated. It’s in creative, adaptive work where they break down. In his book The Infinite Game</a>, Simon Sinek points out that most games in life and in business don’t have winners, losers, or even clear rules. Instead, they’re infinite games, where the only goal is to stay in the game for as long as possible. That requires creativity, flexibility, and adaptability, because the rules of infinite games can be influenced, and they keep changing all the time. The three psychological problems with goals</h2> As Anne-Laure LeCunff points out in her book Tiny Experiments</a>, there are three, key psychological problems with these types of goals: First, goals create fear and paralysis. You set a big goal, then freeze. Too many options. Too much doubt. Insecurity creeps in. Second, they encourage toxic productivity, the hamster wheel effect. You chase random numbers, sacrifice everything else, risk burnout. And then the constant internal dialogue: “Did I do enough?” Third, they make you compete instead of collaborate. Everyone’s focused on their own ladder, climbing alone, measuring themselves against others. My 25 years without goals</h2> I spent over 25 years at Sun Microsystems, Oracle, and Amazon Web Services. Eventually, I became a Principal Solutions Architect, coaching executives and helping companies transform. During that time, I never sat down and wrote professional goals for myself. Well, that’s not entirely true. A few times, managers asked me to write goals. So I did, and made lists of stuff I thought they expected. Then ignored them. At the end of a year, I still got good performance reviews. Those goal sheets hardly came up then. Why? Highly creative, dynamic, customer-focused tech roles don’t work like factory worker roles. Solutions architecture is about learning, helping customers, adapting to change. You can’t put “be creative” or “adapt to emerging technologies” on a SMART goal spreadsheet. Even the best sales people I know, which are in a job that literally runs on goals, tended to ignore their numbers in their day to day work, and instead focused on transforming their customers. They also ended the year over-achieving their goals by a large margin. A real-world example</h2> In recent years, I’ve seen a lot of goal sheets. Sometimes long Excel tables with many rows of detailed goals. You know the saying: “If everything is a priority, nothing is.” I signed up for owning one of these goals—a revenue metric attached to a category of products—because I recognized the meaning behind it. Then, I worked with a few colleagues on moving it forward. The first thing I did was ignoring the number. Instead, I focused on the key customer value behind the goal, the “why”, and which actions we could facilitate to help customers get more value. That motivated the team: We were solving real problems for customers, not chasing arbitrary metrics. The ironic twist: a different part of the team worked on getting better data to track the goal. After cleaning up the data, the number went up significantly. Go figure. The lesson here is: when you focus on real value, the numbers take care of themselves. Goodhart’s law: when metrics become targets</h2> There’s a principle in economics called Goodhart’s Law</a>: ”When a metric becomes a target, it ceases to be a good measure.” The moment you make a metric your goal, you distort the system. People game it, optimize for it, lose sight of what actually matters. Metrics are useful! I’m not saying “ignore the data.” Instead, think of metrics like a car’s dashboard: You don’t drive staring at the speedometer, do you? You glance at it to avoid failure, like speeding tickets or running out of gas. But your eyes stay on the road, focused on where you’re going. The speedometer informs. It doesn’t control. That’s how metrics should work in your career, your projects, your life. They provide useful information and direction, but they are not the destination. They’re not a replacement for knowing your “why” or seeing what’s actually happening around you. Metrics are essential for understanding reality—just not for replacing judgment about what matters. Amazon’s “Dive Deep” leadership principle</a> sums it up: “Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ.” </blockquote> My @Constant.Thinking YouTube channel</a>’s subscriber count is at 64 right now. By YouTube standards, that’s nothing. But I don’t obsess over the growth rate. I make a video every week, pay attention to what resonates, and enjoy the process. The number informs me. It doesn’t define me. A better way: intentions and the Autonomy/Mastery/Purpose framework</h2> If not SMART goals, then what? Focus on transformation instead of achievement. Focus on who you want to become, not what you want to get. Dan Pink nailed this in his book Drive</a> (you can also watch his TED talk The puzzle of motivation</a>). He researched motivation and found that traditional carrot-and-stick methods work for simple, repetitive tasks—but fail miserably for knowledge work. Instead, three things drive us: Autonomy: Staying in control over what you do, instead of following rigid orders. Mastery: Focusing on getting better every day, not hitting a one-time milestone. Purpose: Connecting to the deeper “why,” not some surface-level metric. Goals are contrary to all three. They remove autonomy (someone else sets the target), they prioritize outcomes over growth (hitting the number matters more than learning), and they often disconnect from real purpose. Intentions restore them. How to find your intention</h2> Use the 5 Whys technique</a>: Start with something that sounds like a goal and keep asking “why” until you reach the core intention. Example: “I want to run a marathon.” Why? “To get fit.” Why? “To have more energy.” Why? “To feel healthy.” There it is. Your real intention: “Become a healthy person.” (It doesn’t have to be exactly five. Just keep asking until you feel you found your intention.) The difference: Running a marathon is a one-time event. Becoming a healthy person lasts forever. And it changes what you do daily. Build the daily system:</h2> Once you have your intention, ask: What do people like that do every day? Healthy people eat real food. They move daily. They sleep well. Great! Now you can start doing one or more of those things today. Congratulations! You’re already a healthier person. This won’t be perfect on the first day. But it’s better than yesterday. And if you keep going—eat better tomorrow, move more, sleep well—small wins will compound. You’ll be amazed what happens in 30 days. A quarter. A year. James Clear explains this in great detail in his book Atomic Habits</a> and his article “Forget About Setting Goals. Focus on This Instead.</a>” Systems beat goals every time. Back to my ukulele story</h2> With guitar, I had a goal: “Learn guitar.” It felt big, scary, endless. Exercises felt like homework. With ukulele, I set an intention: “Become a musician.” </picture> CT I’m a musician now!</figcaption> </figure> What do musicians do? They play. Every day. So I played the ukulele every working day after breakfast. Just 20 minutes. No pressure. No milestones. Just music. I felt like a musician from Day 1. Not after years of practice—from the very beginning. That’s the difference. Instead of chasing some future achievement, I focused on becoming someone. Forever. Today, I’ve expanded to playing synths and sequencers, and I meet with friends online every Wednesday to jam together. Your turn: pick ONE intention</h2> Here’s my challenge to you. New year or not. Pick one intention. Not ten. Just one. Who do you want to become? Use the 5 Whys to find it. Then ask: “What do those people do every day?” Start doing it today. You’ll have more fun. More fulfillment. And paradoxically, you’ll achieve better results—because you’re no longer distracted by chasing numbers or paralyzed by fear of failure. If you didn’t set goals for 2026, you were right all along. Your resistance was trying to help you. If you did set goals for 2026, don’t just forget about them—find the intentions behind them instead. Some contexts benefit from clear targets. But if your work or personal ambitions require creativity, flexibility, and meaning, intentions will serve you better. Now go become that person you’ve been thinking about! The numbers will take care of themselves. I promise. Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → We’re still living in the cat pictures era of AI 2025-12-17T00:00:00+01:00 Most people use AI the way our parents used the Internet in 1995. They’d dial up their modem, check the weather forecast on Yahoo, maybe look up a recipe, and call it a day. The idea that this same technology would eventually let them video call their grandchildren, run a business, or access humanity’s entire knowledge base? Unimaginable. Today, we’re doing the same thing with AI. We use it to summarize documents, search for answers, and write some code. That’s it. That’s our email-and-weather-forecast phase. Let me offer one more pattern that’s hiding in plain sight and can bring you one step closer to “modern AI usage” (whatever that will be 5 years from now). I re-learned this after spending a weekend building an AI-powered news briefing shell script. The knowledge-harvesting pattern that actually matters</h2> As a general rule, AI works best, the more data you send into its contect. This is what we leverage with this pattern: Collect a large amount of information</li> Filter and preprocess it down to what matters</li> Synthesize it with AI into something personally useful</li> </ol> If that sounds familiar, it should. It’s basically MapReduce</a>, the Big Data pattern that powered Google and transformed how we think about processing information at scale. Except now, instead of needing a cluster of servers and a team of engineers, you can do it from your terminal with a few tools and some scripting. Actually, you don’t even need to script. Throw a bunch of documents into a Claude project or Perplexity workspace and ask for a personalized analysis. Same pattern, no code required. But here’s the thing most people miss: this pattern works for almost any everyday problem. Research: Collect papers, filter relevant sections, synthesize insights.</li> Career planning: Collect job postings, extract patterns, generate strategy.</li> Learning something new: Collect tutorials, filter by your skill level, create a personalized roadmap.</li> </ul> The script I’m about to show you is just one more example of this pattern, with an AI twist. My weekend problem: information overload</h2> I like staying informed. Doomscrolling? Not so much. Every morning, I’d check dozens of sources: news, AI developments, world events, positive stories (who doesn’t need those?). I’d skim headlines, get distracted by clickbait, and 30 minutes later realize I’d absorbed almost nothing useful. Three years ago, the solution would have been “get better at discipline” or “use an RSS reader and train yourself to be more selective.” This weekend, I built something that seemed impossible back then, with a simple shell script. Building my personal news briefing system</h2> This news briefing system pulls from 20 sources: RSS feeds for reliable news outlets, Perplexity searches for real-time or some broader topics I care about. It can run every morning or on demand, processing everything in parallel, and handing out a beautifully formatted Markdown briefing that includes: Top news from Germany, the world, economy, tech, and entertainment</li> AI and personal productivity tips</li> An Oblique Strategy (Brian Eno style)</li> A writing prompt</li> An “Editor’s Corner” where Claude gets to be snarky about the day’s news</li> </ul> The whole thing takes about 90 seconds to run and delivers exactly what I need—no more, no less. You can watch me walk through the technical details in this YouTube video</a>, grab the complete Fish shell script from this gist</a>, or see an example output in this other gist</a>. </a> </div> </div> A few interesting details of how I got there: The technical journey (including my facepalm moment)</h2> I started with the obvious approach: feed each news source through Claude individually, asking it to “optimize” and “clean up” the content before the final synthesis. Seemed smart, right? Let AI do the preprocessing! Except I kept hitting context length limits. With 20, sometimes quite chatty input sources, even Claude Haiku’s 200k token context window wasn’t enough. That’s when I had my facepalm moment: Of course it wasn’t enough, I was burning through context across multiple LLM calls instead of one. I was treating AI like a preprocessing tool when what I really needed was old-school data munging. After trying out some CLI tools for RSS/XML processing and failing, I went back to the good old Swiss army knife of data manipulation: Python. Thanks to its feedparser</code> library, it lets me: Convert messy XML feeds to clean Markdown</li> Limit each feed to the 10 most recent items</li> Prioritize summary/description (short and crisp) over full content (blows up context size) where possible</li> </ul> This Python part is particularly fun because it’s embedded directly inside my Fish shell script, thanks to the magic of Astral’s uv</a> and its easy handling of virtual environments. Python-inside-Fish: Inception-style scripting! Parallel processing: the secret sauce</h2> Here’s where impatience and some occasional Q&A with Claude paid off: Instead of processing 20 sources sequentially (which would take forever), I learned about Fish’s job control. Each feed fetch runs in the background with &</code>, and Fish’s built-in job counter lets me know when everything’s done: while test (count (jobs)) -gt 0 sleep 1 end</code></pre> All 20 sources process in parallel. What would take 2–3 minutes sequentially now takes about 30 seconds. Good old Unix thinking, combined with AI. Why redundancy actually helps</h2> You might think 20 news sources is overkill. Why not just pick 3–4 good ones? Because redundancy makes AI smarter. When Claude sees the same story mentioned across multiple sources—each with slightly different details, emphasis, or framing—it can synthesize a more complete picture. One RSS feed might have a sparse entry with just a headline. Another might include quotes. And some things are hard to find RSS feeds for—like my local weather forecast, productivity tips, or daily facts. That’s why I added some Perplexity searches on top of RSS. Claude takes all of that and creates something better than any individual source could provide. It’s the difference between reading one journalist’s take and reading five, then forming an opinion. Surprise touch: personality</h2> Here’s my favorite part: I added a bit of personal context about myself to the prompt—my location (Munich), my interests, my dog Elvis. Now Claude sprinkles little references throughout the briefing. A weather report that suggests “perfect for a barefoot run with Elvis.” A snarky comment in the Editor’s Corner that connects back to my work. Small touches that make a daily briefing feel less like a news dump and more like a conversation with a well-informed friend. This wasn’t planned. It emerged from the pattern: collect (news), filter (what matters), synthesize (for me specifically). What this means for you</h2> If you’re reading this thinking “cool script, but I’m not a command-line person,” you may be missing the point. The script is just automation. The pattern is the unlock. You probably have a problem right now where you need to make sense of too much information: Research for a project</li> Competitive analysis for your business</li> Learning a new skill</li> Understanding a complex topic</li> </ul> Try the pattern: Collect everything relevant (don’t filter yet)</li> Preprocess it just enough to be useful (remove noise, extract key parts)</li> Let AI synthesize it into something actionable for you</li> </ol> You can do this in a Claude Project. You can do it with Perplexity. You can do it with a shell script if you like to code. The method doesn’t matter. The pattern does. Start Experimenting</h2> Three years ago, this kind of personalized, automated intelligence gathering was science fiction. Today, it’s a weekend project. We’re living in the cat pictures era of AI: most people only see the obvious use cases. But just like the Internet evolved beyond email and weather forecasts, AI will evolve beyond summarization and code generation. The question is: will you be experimenting, or will you still be stuck checking the weather? If you want to start having AI fun on the command-line, here’s how: Install the llm tool: Simon Willison’s llm CLI</a> makes working with AI models from the command line super easy</li> Pick one daily annoyance: Not everything, just one problem where you’re drowning in information</li> Try the pattern: Collect → Filter → Synthesize. Or something else!</li> Share what you discover: Seriously, I want to know what you build</li> </ol> If you want to see my exact implementation, check out: YouTube walkthrough</a> of how it works</li> Complete Fish shell script</a> on GitHub</li> Example output</a> from today’s briefing</li> </ul> The real innovation isn’t the technology. It’s learning to see patterns where others see chaos. What’s one daily problem you’d like to solve with this pattern? Share this post on your favorite social media, add your comment and let me know</a>. I read every response. Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → Werner Vogels’ 2025 AWS re:Invent keynote is a timely career handbook for navigating accelerating change 2025-12-11T00:00:00+01:00 Watching Werner Vogels deliver his 2025 re:Invent keynote</a> last week, I experienced one of those rare moments where separate threads suddenly converge. There he was, Amazon’s CTO since 2005, laying out five principles for “Renaissance Developers”, and I realized: these weren’t just career advice for developers. They’re a career handbook for everybody in 2026. Because every job is becoming a tech job. Subconsciously, I had been following these patterns since I started my carreer in tech, 27 years ago. And they also rhyme well with Martin Fowler’s July 2025 article on “Expert Generalists”</a>. Coincicence? In fact, the timing couldn’t be more critical. We’re living through what Clayton Christensen warned about in The Innovator’s Dilemma: compounding waves of disruptive change. Ray Kurzweil’s prediction of exponential technological acceleration from the late 90’s isn’t theory anymore, it has become just another Tuesday in today’s tech world. Ray Dalio’s research on economic cycles shows we’re navigating unprecedented complexity across technology, economics, and social structures simultaneously. Werner’s five principles are much more than an inspiring keynote: they’re a career handbook for this exact moment. Table of contents</h2> Why this matters now</a></li> Be curious and keep learning</a></li> Think in systems</a></li> Communicate with precision</a></li> Be an owner</a></li> Become a polymath</a></li> Your January challenge</a></li> </ol> Why this matters now</h2> These five principles aren’t new, individually. But together, they matter today more than ever. We’re experiencing what Clayton Christensen warned about: multiple overlapping disruptive changes. Cloud computing. Big data. IoT. Machine learning. AI. Industry 4.0. Electric vehicles. Space commercialization. Biotechnology. Robotics. Each wave alone would be transformative. But together, they’re creating Kurzweil’s predicted acceleration: exponential change becoming super-exponential as domains cross-pollinate and amplify each other. Ray Dalio’s economic research shows we’re simultaneously navigating technological, economic, and social complexity at unprecedented scales. The pace of change demands exactly what Werner prescribed: continuous learning, systems thinking, precise communication, ownership, and polymathic breadth. The critical insight is: every job is becoming a tech job. Digitalization, cloud computing, big data, IoT, and AI are touching every industry. You don’t need to become a programmer. But you do need to understand how technology shapes your domain. The CFO who understands supply chain and product development in addition to deep finance expertise? That’s T-shaped—deep in one domain, broad across many. The marketing leader who grasps data pipelines and spots trends in real-time? Same pattern. During my 12+ years at AWS, I’ve seen how this approach works. Starting as one of the first Solutions Architects in Germany, I navigated multiple technology waves by embodying these principles, often unconsciously at first, then deliberately. Each year brought different challenges requiring new skills, but the meta-pattern remained: stay curious, see systems, communicate clearly, own outcomes, broaden and deepen expertise. Let’s look at them in more datail. Be Curious and Keep Learning</h2> What it means: Not just passive consumption, it’s all about active building. The Chinese proverb nails it: “When I hear it I forget it, when I see it I remember it, when I do it I know it.” The 8am coffee shop strategy When people tell me they’re stuck in their career, I ask them to show me where learning happens in their calendar. Usually… nowhere. They feel pressure to perform 100% of their time. Here’s what I did at AWS for 12 years: Most mornings at 8am, I’d sit in a remote corner of the office or a quiet coffee shop for one hour or more. Not to check email. Not to prep for meetings. To build something. I built CloudWatch dashboards for my wife’s WordPress blog. Created a spam filter from scratch using the Enron email dataset. Built a static blog generator using AWS Lambda and AWS Step Functions. These experiments and pet projects taught me more than any training ever could, because I was solving real problems with my hands on the keyboard. When I later sat across from customers discussing serverless architectures or machine learning pipelines, I had the kind of credibility no documentation could provide. The temporal and spatial separation mattered. That remote corner at 8am shielded me from interruptions. The “no email before 10am” rule protected the space. Without these boundaries, learning gets trampled by the urgent. Just last weekend, I started another pet project. How about you? How to start: Create a recurring one-hour meeting with yourself next week. Call it “Learning Lab” or “Build Time.” The calendar block will magically fend off other meetings. Pick one topic you’re curious about and do something with it, don’t just read about it. Proof point: This isn’t unique to tech. Steve Jobs studied calligraphy. Ray Dalio built economic models thinking through decades of market observations. Bruce Dickinson became a pilot while fronting Iron Maiden. Dua Lipa and Rihanna turned curiosity about business into entrepreneurial empires. The pattern works universally: curiosity → hands-on learning → new capabilities → better options. Think in Systems</h2> What it means: Local optimization without understanding the whole system creates problems elsewhere. Strategy isn’t just what you do. Understand the system first, then change the rules. The decision bottleneck I’ve watched countless executives become trapped in a loop of their own making. They get pulled into too many decisions—approving budgets, reviewing proposals, being “hands-on”. They become the bottleneck in their company’s decision-making system. The invisible system they don’t see: every decision routed through leadership slows down the entire organization. The best decision-makers are closest to the problem, with the freshest information. Pushing decisions to the top degrades both quality and speed. The solution is to push decision-making to the lowest level where someone has enough context and where potential damage remains controllable. This typically means pushing decisions right to where people directly face the problem. At Amazon, we said “innovation happens at the edge”, because the best solutions emerge right where the problems happen, not in the ivory tower. What remains at the top? Only the “one-way-door decisions”, the ones with irreversible consequences that match executive scope. This is what leaders should spend their scarce time on, not whether to approve a $5,000 software license. True story: I once was at a customer executive retreat and someone exclaimed “over here, we treat everything like a one-way door!” Turns out, even which kind of coffee machines to install in their offices. The meta-lesson: when you’re stuck in tactical loops, zoom out. Ask “What’s the system producing this pattern?” Then change the system, not the symptoms. How to start: When mentees ask about getting promoted, I ask them about the rules of their game. What patterns do you follow? Why are those rules there? Who else is involved? What would happen if you changed the rules? This “step up one abstraction level” move reveals the system. Then you can start seeing leverage points: places where small changes produce outsized effects. Proof point: Donella Meadows showed that information flow is one of the most powerful levers for changing systems. That’s why digitalization works: converting paper to bits accelerates feedback loops, increases flow, and reduces defective states. Seth Godin recently wrote that strategic thinking starts with understanding the system, then changing it. Werner’s principle reminds us that it’s all about seeing the forest, not the trees. Communicate with precision</h2> What it means: Clear writing is clear thinking. When you write precisely, you discover what you actually mean. This applies whether you’re writing AI prompts, documenting architecture decisions, or explaining strategy to your team. Writing is thinking with our hands This is why Amazon runs on written documents, not PowerPoint slides. Werner used the example of giving precise instructions to AI for code generation. But the principle extends far beyond AI. During the first waves of software outsourcing, companies with imprecise requirements got software that “met spec” but was completely useless. The precision problem wasn’t technical—it was conceptual. Writing forces you to think clearly about what you’re actually trying to accomplish. Even if nobody reads what you write, you’ll gain clarity just from the act of putting thoughts into well-formed sentences. The deeper skill is cross-domain translation. Every technical solution represents a real-world challenge. There’s always an interface where the real world creates inputs (business needs, user problems) and where technology creates outputs (solutions, outcomes). In enterprise architecture, this is the boundary between business architecture and technical architecture. When discussions get tangled, I ask: “What needs to happen at the business level?” This question brings us back to the real world before diving into implementation details. Werner’s example of object-oriented programming making code model the real world more accurately reflects the same principle. Today’s “digital twins” in manufacturing follow the same concept: using technology to mirror and understand the physical world. How to start: Write more. Long-form documents. Blog posts. One-pagers. Journaling. Whatever gets you in front of a keyboard or a sheet of paper, forcing thoughts into complete, correct sentences will improve your thinking. Test yourself: Explain your current project to a smart colleague as if they were five years old. Not because they are five, but because it forces you to eliminate jargon and verify you actually understand what you’re doing. Proof point: I’ve seen sales professionals get AWS certified and transform their effectiveness. Not because they can now deploy infrastructure, but because they can have better conversations with customers and work more independently with their technical colleagues. The best colleagues I’ve worked with came from diverse backgrounds—former consultants, Gartner analysts, startup founders: because each brought a different lens and translation capability. Be an Owner</h2> What it means: Ownership means taking responsibility beyond your immediate tasks, seeing the system you’re part of, including the second and third order consequences, and accepting accountability for outcomes, not just activities. ”Fragen kostet nichts” In Germany, we say “Fragen kostet nichts”—asking costs you nothing. Ask for more responsibility, a bigger scope, a broader role. The worst that happens is hearing “no,” and then you move on. During my AWS years, I owned initiatives far beyond my official role: organizing joint customer presentations for re:Invent, running an EMEA-wide conference, building communities of practice across teams and geographies. Nobody assigned these. I saw needs and stepped up. This is exercising entrepreneurial muscles inside a large company. It gives you more autonomy, broader influence, and, critically, a better sense of control over your career trajectory. That kind of autonomy is a powerful intrinsic motivation. But here’s the tension: ownership as a cultural value is tricky. Not everyone wants responsibility beyond their immediate work. You can’t mandate ownership, you can only encourage it. Leaders create ownership culture by example and by making it safe to make mistakes. When leadership openly shares how they failed and what they learned from them, they signal “it’s okay to take risks here.” Clear prioritization and decision criteria help too. This is why Amazon’s Leadership Principles</a> at the company level and Tenets</a> at the team level work so effectively—they give people frameworks for making autonomous decisions aligned with broader goals. How to start: Volunteer to own something beyond your job description. Organize a conference. Start a task force. Run a community of practice. Pick something small enough to manage but visible enough to matter. Proof point: This connects directly to Eliyahu Goldratt’s The Goal. Ownership isn’t just about accountability, it’s about seeing and improving the system that produces outcomes. You identify bottlenecks, remove waste, improve throughput. That’s systems thinking meeting ownership. Become a Polymath</h2> What it means: Develop T-shaped expertise: deep in one area, broad across many. This isn’t about being superficial in everything. It’s about having enough knowledge across domains to see connections, translate between fields, and spot opportunities others miss. The Ikigai of career building Initially subconsciously, then more deliberately, I followed a pattern similar to the concept called “Ikigai”: Look for things you’re excited about, that fit or expand your existing skills, that are needed, and that people will pay for. I wrote about this framework in my Four horsemen of a dying career</a> post, but it also applies here. Your T-shape should emerge from this intersection—not from random skill collecting. The best sales people I’ve worked with weren’t career sales reps. They were former business executives, consultancy owners, industry analysts. Each brought a unique, holistic perspective on how businesses work across levels and silos. This turned them into business advisors for their customers—helping solve problems, not just close deals. They could see through organizational structures to identify decision-making processes and find the right influencers. I’ve seen this in my own journey: although I was always a “Solutions Architect” at AWS, every year felt like a completely different job. I started with basic infrastructure consulting for startups. Then helped enterprises migrate to the cloud. Then enabled customers for Big Data, IoT, Digital Transformation, Machine Learning, and AI. Each wave required new skills: Python coding, public speaking, executive communications, change management, coaching and mentoring. The “T” kept growing broader while the depth in legs like architecture and systems thinking deepened. How to start: Building the “T” happens through doing, not reading summaries. Real learning requires hands-on work. Job rotations, stretch assignments, collaborations across silos work beautifully. New projects bring new responsibilities and domain knowledge organically. Going deep, adding a major new leg to your “T”, takes time. Think at least a year to develop proficiency, multiple years to form real depth. Choose carefully using the Ikigai framework: passion, existing ability, need, business value. Often a new depth area emerges from what started as a shallow, experimental breadth area. Proof point: Martin Fowler identified six characteristics of Expert Generalists: Curiosity (Werner’s principle #1), Collaborativeness (ties to Communication), Customer Focus (Communication again), Favor Fundamental Knowledge (complements Systems Thinking), Blend of Generalist and Specialist Skills (T-shaped), and Sympathy for Related Domains (Systems Thinking + Communication). The convergence is striking—different words, same patterns, driven by the same forces of accelerating change requiring cross-disciplinary solutions. Your January Challenge</h2> It’s December. The year’s winding down. Now is the perfect time to assess your career against these five principles. For each one, ask yourself: Curiosity: When did I last build something just to learn?</li> Systems: Am I solving symptoms or changing systems?</li> Communication: Can I explain my work clearly to a smart non-expert?</li> Ownership: What do I own beyond my job description?</li> Polymath: Is my T-shape evolving?</li> </ul> Then ask: What can I do to embody this more in 2026? What’s the next step I can take in January? You don’t need to tackle all five at once. Pick one principle that resonates most. Schedule that one-hour learning session. Volunteer for one project outside your silo. Write one blog post. Just start. If you’re feeling overwhelmed by the pace of change, I wrote about navigating uncertainty in my Crisis Survival Guide</a>, where I explore what you can and can’t control using a framework inspired by the Serenity Prayer. For more on developing T-shaped expertise, read my deep dive on How to Thrive as an Expert Generalist in the Age of AI</a>. Werner gave us the map. Fowler, Christensen, Kurzweil, and Dalio confirm the terrain. Now it’s on us to navigate it. The Renaissance is here already. Time to build! Watch/read more!</h2> Werner Vogels’ AWS re:Invent 2025 Keynote</a> (YouTube)</li> Martin Fowler’s Expert Generalist</a> (article)</li> Clayton Christensen’s The Innovator’s Dilemma</a> (Goodreads)</li> Ray Kurzweil’s The Singularity Is Near</a> (Goodreads)</li> Ray Dalio’s Principles</a> (Goodreads)</li> Donella Meadows’ Thinking in Systems</a> (Goodreads)</li> Eliyahu Goldratt’s The Goal</a> (Goodreads)</li> </ul> Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter → 3 slides everyone uses (but you should delete) 2025-12-03T00:00:00+01:00 In 2014, I was preparing my AWS re:Invent presentation on “Running Lean Architectures.</a>” I had my slides ready: agenda, bio, resources. Then I stopped. Why was I presenting this in the first place? The answer: to help people save money on AWS. Not to check boxes on a corporate template. Not to prove I was qualified to speak or that I did my homework. I deleted my agenda slide and replaced it with one titled “What you’ll get out of this session”, the one you see above. The first bullet point: “A lower AWS bill.” That moment changed how I think about presentations. Every slide should serve the audience, not the presenter. Yet in the 25 years since, I’ve watched thousands of presentations make the same mistake: filling slides with content that serves them, not their audience. In this video, I break down the three most common offenders: </a> </div> </div> Here’s why these slides fail, and what to do instead. The real problem: who are your slides for?</h2> Before we dive into specific slides, here’s the core issue: presenter-centric vs. audience-centric thinking. Most presenters follow templates that make them feel safe, copy-pasted across generations of designers. The agenda keeps them on track. The bio proves they belong there. The resources list shows they did their homework. But here’s what’s really happening: while you’re making yourself comfortable, your audience is reaching for their phones. Those little gadgets are your real competition. Highly optimized, attention-stealing mind-control devices that offer instant gratification. Every slide that doesn’t serve your audience is an invitation for them to check “just one more notification.” Once they’re lost in their feed, it’s hard to get them back. So let’s look at the three slides that hand your audience over to their phones—and what to do instead. Slide #1: Agenda (your to-do list, not their value)</h2> What presenters think they’re doing: “I’m being organized and professional. I’m showing respect by letting them know what to expect.” What they’re actually doing: Creating a to-do list for themselves. Every agenda looks the same: Introduction, Topic 1, Topic 2, Topic 3, Q&A. It’s the presenter’s checklist, dressed up as audience service. What the audience experiences: The groan: “Yet another agenda slide.” They’ve seen this template a thousand times. Time to check their phone. Nobody came to your session to see your table of contents. They came to solve a problem or learn something valuable! The better alternative: Expectations</h3> Replace your agenda with clear expectations. Instead of listing topics, tell them what they’ll gain: “What you’ll get out of this session: A lower AWS bill”</li> In the next 30 minutes, you’ll discover why your customers ignore your product, and the one question that changes everything</li> “Today, you’ll learn three techniques that cut deployment time in half”</li> </ul> Why it works: First, it’s a positive surprise. Everyone expects an agenda. So when you deliver something better, you’ve earned their attention. Second, expectations create productive tension. You’ve opened a story loop in their minds. They want to see it resolved. Movie trailers don’t give you a table of contents—they create anticipation. Third, expectations build trust. When you exceed what you promised (and you should always aim to exceed), you’ve demonstrated that their time was well-invested. That one extra insight at the end, beyond expectations, can elevate your presentation from good to great. Slide #2: About Me (your validation, not their value)</h2> What presenters think they’re doing: “I need to establish credibility. They need to know I’m qualified to be here.” What they’re actually doing: Seeking validation. The bio slide reassures the presenter: “I belong here. I’ve earned this stage.” It makes them feel better about presenting, helps keep imposter syndrome</a> in check. What the audience experiences: Indifference, at best. Mild annoyance at worst. They already know your name and job title: it’s on the title slide and in the conference program. If they’re curious about your background, they’ll check LinkedIn later. What they don’t know yet is whether you’re going to waste their time or deliver value. And you’re currently wasting their time with your CV. I’ve watched speakers uncomfortably skip past their own bio slides, as if their subconscious mind knows something’s wrong. Their body language says: “Sorry, our corporate template made me include this.” The better alternative: authority through value delivery</h3> Want to establish credibility? Deliver value. Share insights. Solve problems. Tell stories that illustrate hard-won lessons. Skip the bio slide entirely. Then, throughout your presentation, weave in short stories: “When I worked with a startup trying to cross the chasm, we discovered…”</li> “In my 12 years at AWS, I learned that…”</li> “I made this mistake three times before I figured out…”</li> </ul> Why it works: You’re building authority while delivering value. The audience gets useful information and learns that you know what you’re talking about. Two birds, one stone. More importantly, you’re making it about them, not you. They’re the hero of this story. You’re the guide who’s been down this path before. That’s the role you want. Not “impressive person with credentials,” but “trusted guide who serves their audience.” (Do you have an “About the company” slide? Delete it, too, for the very same reasons!) Slide #3: the resources (your homework proof, not their next step)</h2> What presenters think they’re doing: “I’m being helpful! Look at all these valuable resources I’m sharing.” What they’re actually doing: Creating decision fatigue and proving they did their homework. That wall of URLs and QR codes isn’t for the audience—it’s the presenter covering their bases. What the audience experiences: Overwhelm. And their mind is already wandering. By the end of your session, they’re thinking about coffee, their next meeting, or whether they need a bathroom break. Their cognitive load is maxed out from absorbing your content. Now you’re asking them to choose between ten resources? That’s not helpful—that’s homework. Yes, they might take a photo of your resources slide. But let’s be honest: how often do you actually go back and look at those photos later? The better alternative: One clear next step</h3> Give them a single, specific call to action. Not ten options—one action. Make it ultra-specific: “When you get back to your desk on Monday, right after you file your expense report, do this one thing…” (I use that exact phrasing when coaching speakers. They laugh, but it drives the point home: specific and immediate.) Examples of good single CTAs: “Visit booth #47 for a live demo”</li> “Go to <URL> for the one-page template”</li> “Complete the hands-on tutorial lab now, to experience this solution in real life”</li> </ul> Why it works: Low friction. Clear reward. Immediate action. You’re respecting that they’re overwhelmed and tired. You’re making it easy to take the next step. You’re trusting that if they want more information, they know how to use a search engine in 2025. Or better yet: create a one-page handout that summarizes your key concepts. This gives people something tangible and makes you memorable. Plus, it’s a much better follow-up tool than “can I get a copy of your slides?” The transformation: from template-follower to trusted guide</h2> Here’s what all three of these slides have in common: they serve the presenter’s need for comfort, not the audience’s need for value. Templates make us feel safe. They tell us we’re doing it “right.” They protect us from the fear of being unconventional. But: great presenters are unconventional. They stand out precisely because they don’t follow the template everyone else follows. The stakes are real. In an age of attention-hogging mobile phones and infinite distractions, losing your audience means losing relevance. Lower ratings. Fewer speaking opportunities. Less impact with the insights you worked hard to gain. But when you make the shift, when you put the audience first, look beyond the templates, and replace those comfort slides with audience-centric alternatives, you become memorable. You get invited back. You create real impact. You transform from someone following corporate templates into a trusted guide who serves their audience. Your Next Step</h2> Pick one presentation you’re giving soon. Open the deck. Find these three slides. Delete them. Or better yet: replace them with the alternatives suggested above. Make your slides serve your audience, not yourself. Your audience will thank you. And your phone-checking problem just got a lot smaller. P.S.: If you want to discuss your specific presentation, feel free to book a slot during my office hours</a>. P.P.S.: What slides are you deleting from your presentations? Share this post on your favourite social network and tag me, I‘d love to see what you discover! Enjoyed this? Reply by email · Discuss on Bluesky · Discuss on Mastodon · Read on the web Want the next one in your inbox? Subscribe to the newsletter →

And when the architecture fails</h3>
It will, sometimes. Architecture is not omnipotence. That’s why you keep a few humans in the loop who will tell you the truth: a partner, a friend, a mentor, an honest reader. A commenter, like Christopher on LinkedIn. The last line stays human.</p>

Build your own: the tech stack</h2>
If you want to build something similar, here’s what my setup looks like under the hood.</p>

Three Lessons Learned</h2>

Video: What I actually do with AI every day

How to stop engineering prompts and start delegating

From scarce code to abundant builders

Local audio transcription with mlx-whisper: what actually works

You don’t need permission to get promoted

1. Write down your Purpose, Mastery, and Autonomy</h3>
What impact matters to you?
What skills are you building?
What decisions do you want to make?</p>
Just three sentences. Get it out of your head.</p>

3. Pick one next-level move and start doing it</h3>
Identify what people at the next level are doing. Then either ask your manager for that stretch project, or just start doing it yourself.</p>
Give yourself permission.</p>

The explore/exploit guide to your first tech job

SMART goals are failed Taylorism (and why you should ignore them)

We’re still living in the cat pictures era of AI

Werner Vogels’ 2025 AWS re:Invent keynote is a timely career handbook for navigating accelerating change

3 slides everyone uses (but you should delete)

Constant Thinking

Why working with AI agents is so tiring (and what to do about it)

You’re in the driver’s seat: will you choose to stay awake with AI?

Beyond coding agents: how AI rewires your organization

AI is the rubber duck that pushes back

Michael Leibovich: How I Built My AI Chief of Staff

Thinking with Claude: why Cyborg writing works better than Centaur writing

Welcome Claude, my Chief of Staff

Constant Thinking

Why working with AI agents is so tiring (and what to do about it)

You’re in the driver’s seat: will you choose to stay awake with AI?

Mode matters more than tool</h2> „Je mehr wir uns … in das Wesen der Technik einlassen, … desto klarer kann das Rettende wachsen.”</em> — Martin Heidegger, Die Frage nach der Technik</em> (1953/54)</p> </blockquote>

Two self-checks (for noticing when something is off)</h3> Here are two questions that help you check if you’re still driving your AI tool, or if the tool is driving you:</p>

Four moves, one per failure mode</h3> Friction against Atrophy: “Am I still the driver, or a passenger?”</em></strong></p>

And when the architecture fails</h3> It will, sometimes. Architecture is not omnipotence. That’s why you keep a few humans in the loop who will tell you the truth: a partner, a friend, a mentor, an honest reader. A commenter, like Christopher on LinkedIn. The last line stays human.</p>

Sources & further reading</h2> Research</strong></p>

Beyond coding agents: how AI rewires your organization

AI is the rubber duck that pushes back

Michael Leibovich: How I Built My AI Chief of Staff

Thinking with Claude: why Cyborg writing works better than Centaur writing

AI slop is breaking the reading ecosystem</h2> Here’s an LLM-style LinkedIn post. The prompt: “Write a LinkedIn update about human-AI collaboration.”</em> This is a typical output:</p>

Welcome Claude, my Chief of Staff

Build your own: the tech stack</h2> If you want to build something similar, here’s what my setup looks like under the hood.</p>

Three Lessons Learned</h2>

Resources</h2> Bullet Journal Method</a> by Ryder Carroll</li> PARA Method</a> by Tiago Forte</li> Personal Kanban</a> by Jim Benson</li> Claude Cowork</a> by Anthropic</li> Claude Dispatch</a></li> Productivity Plugin for Cowork</a></li> Obsidian</a>—for the personal CRM</li>

Video: What I actually do with AI every day

How to stop engineering prompts and start delegating

From scarce code to abundant builders

Local audio transcription with mlx-whisper: what actually works

My Complete Setup</h2> Here’s the Fish shell function I use every week:</p>

Video</h2> Here’s a short video walkthrough with a bit more personality and some fun drama elements:</p>

Links</h2> mlx-whisper on PyPI</a></li> uv for easy Python tool installation</a></li> Simon Willison’s llm CLI tool</a></li>

You don’t need permission to get promoted

1. Write down your Purpose, Mastery, and Autonomy</h3> What impact matters to you? What skills are you building? What decisions do you want to make?</p> Just three sentences. Get it out of your head.</p>

2. Start your achievement log</h3> Create a document with this structure:</p>

3. Pick one next-level move and start doing it</h3> Identify what people at the next level are doing. Then either ask your manager for that stretch project, or just start doing it yourself.</p> Give yourself permission.</p>

The full story</h2> I go deeper into all of this in my video below, including the anti-pattern of promotion obsession, specific stories from my career, and the mental models that kept me sane through corporate chaos:</p>

The explore/exploit guide to your first tech job

Your homework</h2> Before you go on, write down the following:</p> Three topics</strong> you want to explore in the next six months.</li> Three events or meetups</strong> you’ll attend this quarter.</li>

SMART goals are failed Taylorism (and why you should ignore them)

We’re still living in the cat pictures era of AI

And when the architecture fails</h3>
It will, sometimes. Architecture is not omnipotence. That’s why you keep a few humans in the loop who will tell you the truth: a partner, a friend, a mentor, an honest reader. A commenter, like Christopher on LinkedIn. The last line stays human.</p>

Build your own: the tech stack</h2>
If you want to build something similar, here’s what my setup looks like under the hood.</p>

1. Write down your Purpose, Mastery, and Autonomy</h3>
What impact matters to you?
What skills are you building?
What decisions do you want to make?</p>
Just three sentences. Get it out of your head.</p>

3. Pick one next-level move and start doing it</h3>
Identify what people at the next level are doing. Then either ask your manager for that stretch project, or just start doing it yourself.</p>
Give yourself permission.</p>