We’re doing a big release this week for DRI Your Career. Mostly bug fixes and reliability work nobody will notice, but the two things worth mentioning:
Audio episodes are now available as a private podcast feed.
Made significant progress towards supporting multiple coaches (yes this implies some very exciting announcements – more soon).
We’ve come a long way since it was just Jean and “Claude the intern”, but mostly very iteratively. We’d come to a point where it seemed worth rethinking. We wanted to ship some bigger things – this release was nearly 100 PRs over about a week, passing back and forth between Ireland and California – and to do that we had to mature our approach.
Release branch and release process (vs pulling from main). I know this goes against conventional wisdom, but for a 2 person team with no on-call SRE, I think it’s better to be able to schedule your problems for a convenient time.
Orchestrator + merge queue. The merge queue tends to be stricter, so everything gets 2 code reviews, follow-ups filed, and so on. It also handles sequencing and rebasing – the things I used to burn CI minutes on when I was chaotically working in 5 tabs.
Board hygiene. P0/P1/P2/P3 issues, aligned with the orchestrator + merge queue setup. Everything related to features slated for the next release gets tagged so it gets prioritised.
Devex and optimisations. Ephemeral DB targets, authenticated E2E tests, env var requirements, a full design system, automated nightly DB backups.
What I find interesting is that these four pieces map onto four different phases of a team maturing.
Overkill. Slightly anal for two people. But the natural progression for a 2 person team no longer wanting to deploy main on every PR.
The AI-native piece. Only necessary because AI exists – also allows Claude to work overnight whilst we are sleeping (and don’t need the tokens for everything else we are doing).
The setup of a well-organised 6+ person team. What keeps the orchestrator (and us!) focused on impact rather than maxing out token and CI spend. Brought in when I realised we could easily ship >50 PRs but no finished headline feature.
A level I used to watch 20+ person teams struggle to reach. Necessary to support the velocity.
All of this to say that a sensible setup for a 2-person team has shifted dramatically from even a year ago. If the shift is that big for a small team running a small website on top of other activities, it’s going to be even more dramatic for larger teams. The list above is our specifics, but the categories are transferable: even if your process was right sized for your team before, it isn’t – or shouldn’t be – once each person on your team is running a team of agents.
What is your release process? How do you validate, find issues and monitor?
How do your agents run, what guard rails are in place?
How do you maximize value for token spend?
What’s your DevEx setup and how does it need to evolve?
Lately I’ve been thinking about the AI shift as upending the standard bottlenecks for team scaling. That’s moved me from “we need a new playbook” to “we need to update the existing one with different priorities”. All but one of these are things I’ve done as part of scaling a team in the before times. I just didn’t used to do them all in a week.
This is why I stay optimistic about developers even as writing code gets automated. You can’t just “AI it”: getting AI to solve problems faster than it creates them takes judgement. Claude helps enormously in moving things forward, but knowing what to prioritise and what it should be doing is a critical input.
This is the kind of work good managers do – evolving how the work gets done as the team evolves, to keep things moving. So we’ve decided, again, that we “don’t need managers”, at the exact moment there’s more of that work to do than ever… My hot take from years of experience scaling teams and being deeply immersed in AI-dev for the last 8 months or so? We’ll come back to the same conclusion – managers matter 🍿
The core problem of scaling a team is that not everyone can know everything. Scaling is the work of systematizing that – so that things are understandable, knowable. It’s turning “tribal knowledge” into documentation, automation, and process. It used to be that only the automation was for the machine, but now documentation is machine critical and process is machine readable.
With humans, things bubble up and down. You don’t – in general – make systematic fixes for the first complaint. First you validate, check the scale of the issue. You try the softer interventions – trying to get people to actually talk to their team mates – before you start building process. Maybe you make a change a month to the way a team works. Carefully, thoughtfully. Because no effective person wants to be on a team where the job seems more process than impact.
Automation was always the most effective, but also usually the most expensive. The thing that gets put in when “please follow this checklist” fails frequently and severely enough to be worthwhile. An incident can be the gift that delivers the agreement on priority that always seemed necessary to those close enough to it, by making the cost of not doing it clear.
As we are deep in replatforming Twill, I’m back to being a developer, and as I operated my orchestrator and dispatched agents on the backlog, even though in some ways everything is wildly different, some parts of it that I reached for out of habit felt very familiar: scaling.
+AI
AI feels like speed-running some of the team scaling stuff that previously I orchestrated over months – years even. The economics have shifted to make automation much cheaper, so it’s no longer deferred, but top of the list.
With people, knowledge lives in two places – in the people and in the systems. With AI, only the systems part persists. Every session starts contextless. This is the problem that surfaces all the documentation that wasn’t written, and all the automation that was never built – a core part of why building with AI from scratch is so much easier than retrofitting onto an existing setup.
On DRI, when Jean started building the platform, we talked affectionately about “intern Claude”. Over time, we matured away from that framing. We put the guardrails in. We stopped treating it as a novelty to be supervised and started treating it as a system to be designed. With Twill, I started from a higher level of understanding, and the baseline was higher.
The snark, which I’ve also expressed: people will do for a machine what they were never willing to do for their team. Write the doc. Define the work clearly. Build the guardrail. Forgive the mistake.
I stand by it. But that doesn’t mean those of us who were always trying to do this for humans gain some moral high ground by not doing this for machines.
The rigour was always good practice. The humans operating the machine will have a much better time if those machines are set up to succeed. I think the call for EMs to “get closer to the work” has been poorly expressed and executed, but at the core of it – having got much closer to the work myself – I have come to see the validity of it. The scaling problem that managers used to deal with is now happening at higher speed, and the only way to have fidelity on it is to understand the work being done. Because so far, there is no playbook – we all have to write our own.
The best example of this is CLAUDE.md. For both DRI and Twill, it’s a living team artifact, and the churn on it is a good thing – the way of working should keep evolving, as we evolve our understanding, our work, our effectiveness.
Three terminals
“Dispatch a review agent” was encoded in our process for months. It’s very helpful. But I would still find the odd issue or untracked follow up. Then, tired of Claudes colliding on CI and wasting build minutes, I made a merge queue. It serialises merges across concurrent sessions, files the follow-ups, and sends PRs back when they’re not ready.
The next round of reviews I dispatched came back clean. And the next. And the next.
Turns out merge queue Claude, reviewing work it had no part in, was stricter than the Claudes that had done the work.
The reason is the contextlessness. Which gets talked about like a strength or a weakness as we look for metaphors about working with this thing that is new and we don’t yet fully understand. I’ve given up on metaphors, and think this aspect, like this shift in general, is best treated as a neutral.
The reviewer had no investment in the work. Nothing to rationalise. No “well, I did it that way because.” It knew only what the standard said and whether the code met it.
So many times, after reading a review or finding something that didn’t work as I expected it to, I’ve thought that something should be already prevented by CLAUDE.md and asked why it wasn’t. The answer was always clarity – fair. But turns out, like humans, the answer could also be process.
The common manager refrain on AI is that it separates those who think from those who don’t. Fair. But one of the core skills you have to develop in leadership is knowing what to pay attention to and what can be ignored. The broader your scope, the more you need to be brutal.
How many times have I told someone “that’s not making it onto my list”? Too many to count. Enough that people have been known to text me when they find themselves saying it. Now, having so many things in flight at once, I’m always trying to figure out what to pay attention to and what not.
The mechanical guardrail is encoded in CLAUDE.md: hit the same issue twice, stop. A lesson learned the hard way after burning a bunch of build minutes on something stupid, because it only got intermittent attention and seemed like it should be fine. It’s inclined to keep pushing through, but telling it to stop also tells me to stop, to give that problem some attention, to think.
Before, the discipline was: you found a bug, you wrote a test so it wouldn’t come back. Good practice. Now, I do that, and then I ask: how do we guard against this class of problem?
Competent humans rarely make the same mistake twice. AI will make the same mistake endlessly.
Making a class of issue impossible is not cheap. This is why we didn’t use to do it. A minor bug spawns five-plus follow-ups – graduated solutions of increasing complexity. A null-handling issue that threw 500s; fixed in one PR, but the follow up issues to eliminate the pattern and add a tripwire in CI so it can’t come back got added to the backlog, ready to be picked up, implemented by the orchestrator as a slot becomes free. Done within the week. Because now it’s possible. It’s tractable: it’s bounded, well-defined work, which makes it exactly the kind of thing you can hand to an orchestrator and let run in parallel.
I keep reading all this stuff about “working with AI” and it’s so depressing that most of it seems to be about building things that run AI agents. What’s the point of it? What are you actually shipping? Is this just some game, like The Sims: But Make It Programming (and also really expensive)?
Cranking through a bunch of stuff to launch, I’m running Claude in three tabs. The first is an orchestrator. The second is the merge queue.
The third is the terminal where I actually define, decide, and unblock things. The most important one. In this one sometimes I feel like a product manager, sometimes an engineering manager, sometimes an architect. Sometimes I’m just wiring up secrets and things, feeling like some modern day version of the ENIAC women who used cables and switches. At least I get a manual.
Scaling a team, you keep coming back to the same need: be clearer. Clearer about what’s expected, who owns what, what good looks like. Clarity. Clarity. Clarity.
If you’re reading this on cate.blog, things look different. I’m pleased with how it came out. Getting there was more difficult than I expected.
I came into this confident. I used to work on WordPress (admittedly, the mobile apps – but I did the support rotations and lived in P2 like everyone else). I have been running my own site for years. This was not my first visual update, it was just the biggest. I thought my expertise + Claude design would be a winning combination.
It was not.
I knew what I wanted: a stronger brand, something more visually distinctive, an information architecture that put DRI front and centre, more of a “website” than “just a blog”
What went well
The design. Yes, it has the italicised titles characteristic of Claude design. But overall the look is a nice balance of pops of color but not in the way of reading. The goals have been met, and I’m really pleased with how it looks.
I love Claude Design, high on updating DRI Your Career I was looking for other things that could be prettier. I also used Claude Chrome to validate: visual detail at the level of font sizing and spacing is not a strength of mine, so it was incredibly useful to go through multiple rounds of checks and the entire site to ensure that everything had been applied just so.
What went poorly
TL;DR: WordPress.
I started using Claude Code as an issues manager and lookup engine, but after a day of this, frustrated by how much slower the progress was than I’d expected, I connected Claude Code directly. This was a huge accelerator, although I had to pay attention that it built block components rather than making everything custom – I do want to be able to edit it, after all. But even with that working, CSS edits still had to be copied and pasted.
I made a staging site, which I have never bothered to do before – probably something that had kept the scope of my previous redesigns small, ensuring that I could keep a working and visually acceptable website as I went.
I’d decided against a child theme, on the reasoning that child themes don’t receive updates and those are important. However because all the customisation lives as configuration in the database instead of in theme files, appearance and content are in the same place. Deploying staging to production took two hours, took my site down while it ran, and broke Jetpack on the way. I knew this going in (well not Jetpack breaking, that I had checked a box to prevent), when I set up the staging site, and decided to go with it. But it is still horrifying.
I moved from Twenty Twenty-Three to Twenty Twenty-Five, which is extremely minimal; very little is defined until you define it. As the definitions live in two places, Global Styles and a separate CSS block, any given margin might be set in either. Reconciling that was fiddly and irritating.
I always heard web developers be dismissive of WordPress, and I didn’t fully get it, because what I have always loved about it was that it was easy to write in, and that was my goal of having a website. But having dealt with this I get it. The tooling is just so frustrating.
Now that I have more of a brand, I decided to update What Raccoon to match – it’s more prominent on the site and felt jarring to switch, so wanted them aligned.
Yes, it’s a much smaller site. But it took 10 minutes and had one minor bug: keyboard detection in Chrome. Done.
cate.blog? Four days. Yes doing other things, but I maxed out my Pro plan twice in one day working on it. The last time I did that, I was making a 50 page slide deck (for the first time, inefficiently). My website is not that big. The difference in effort was wildly out of proportion to the difference in complexity. What’s interesting to me is the gap between where AI accelerates and where it doesn’t. WordPress – the speed increase did not match the increase in my ambition. But for a regular website? The speed increase is driving my ambition.
What I’d do differently
I did write GitHub issues, but they were the spec I handed Claude Code to work through, not a tracker I was keeping for myself. As things got more complex, I was missing one source of truth for me, across the three Claudes and all the manual steps in between, that stayed current as the work moved.
So, next time:
Treat it like a project for real: not just a spec to kick things off, but a source of truth I keep current as I go, so the plan and the actual state don’t drift apart.
Content backed up to GitHub so there’s real version control on it.
Still build the staging site to test against, but deploy by connecting Claude to the live site and having it move the changes across, rather than deal with deploying and all the problems that entailed.
A better way to keep Claude Design, Claude Code, and Chrome-for-validation in sync with each other. A validation checklist living in GitHub would go most of the way.
I’m keeping the new look, and I still have a deep love of Claude design. But my WordPress ambitions? Those will be tempered for a while.
The volume is up. More PRs, more pings, more incidents, more asks coming from more directions. I used to have 8 directs that dealt with most things, and organized and routed information to me for what I had to help them with, but since embarking on a new adventure, I’ve been rebuilding a different system that helps me stay on top of things and prioritize it.
Three jobs, in order: 1. route the tedious stuff so it doesn’t waste my time, 2. report usefully so I can orient quickly, and 3. understand what’s actually going on.
These all run on Claude Code as part of a broader chief-of-staff setup. I started with this repo and have expanded extensively. Here, I’ll focus on the set of skills that cover the core of EM operational work.
1. Routing: get the tedious stuff off your desk
Tedious but useful: maintaining a source of truth, and making sure that incoming requests get appropriately routed. Many EMs try, reasonably, to enforce a process here, but let’s be real; that process never applies to the C*O or your boss. They send the request as and how it works for them.
I had a Zap set up for this, but it relied on a narrow trigger. Now, I have a skill that scans the channels where work comes in and reconciles them against the boards where work is supposed to live. It is also instructed to read the thread before flagging anything. If the ask is resolved in the replies (“we already have this”), flagging it anyway just makes noise, which is the thing I’m trying to reduce.
That last rule is important because I don’t want one more thing pinging me. The point of routing isn’t to surface more; it’s to surface usefully and reconcile quickly, so the backlog reflects reality.
2. Reporting: start the day knowing what’s going on
The reports run first thing, and they run ops-first. Strict ordering: anything broken right now beats anything in flight, which beats anything in the backlog, which beats anything in the future. The daily version is deliberately short; a few lines, only the highest-signal items, and if nothing flags it just says “clear.” I don’t want a dashboard I have to interpret; I want one line that tells me whether my initial plan for the day has to go in the bin.
At longer cadence: a weekly view for what’s moving and what’s stuck, a monthly one for the board update. Same sources, different altitude. Daily keeps me from missing fires; weekly keeps me from missing drift; monthly is a quick and useful way to keep other people in the loop.
“I have a morning report” is the most boring possible sentence. But I think of it not as a report, but as an orientation to my day; something that looks through everything in a structured way, so that I know where I am and where I need to go, quickly. The terminal is also the feature: plain text on a yellow background (so I can distinguish that terminal from all the others), and I don’t risk getting distracted by “just this one small thing”, which is a) never just the one, and b) rarely that small.
At a previous job, once I stopped getting pinged on every incident, I stopped knowing they were happening as they were happening; I learned about it when I reached that particular channel in Mattermost, or got through all the explicit demands for my attention in Asana. On some level, that’s fine and expected: if, as a director+, you’re in every incident, that is itself the problem, and incident response being able to run to your standards without you being aware is evidence that it has resolved.
But then I had to look at everything. Now I can have structured, prioritized information without needing to. Cheap operational awareness is a win.
3. Understanding: what’s actually going on, versus what we agreed
Once you’re organized, and oriented, you come to the actual work of an EM: making the team better.
It had been a long time since I consistently looked at PRs, but now it’s ~daily. I have heard that PRs are redundant now, and maybe I’ll come around to that point of view, but currently I see a PR as a queryable unit of work. It’s never been easier to know:
Is this code good? Dispatch a review agent.
Does this architecture make sense? Ask questions or for an architecture document.
Does this conform to our standards of ways and working? Encode those in claude.md and check.
Are the docs up to date? Ask, and then update.
Better understanding of the work used to convert into process changes; tweak the review policy, change how we run standups. That work is still important, more so than ever. But also think about claude.md or equivalent. Did I learn something about how we work more effectively? Propose a change to it. The file is a really useful lever for team effectiveness and consistency.
The bonus: the skills are alive
I’m not sharing these skills publicly because I think the skill.md, tailored to my work situations, is much less useful than the way of thinking. But here’s a snippet I think you should take. All my skills have it, and it ensures they keep evolving as I do, and as the work does.
## Living document
Update this skill when:
- Triage patterns emerge from real audits
- A new source of truth comes online
- The way the work actually happens shifts
Coming back to the start – I used to manage a lot of people, and now I use AI to manage (and do!) a lot of work and far fewer people. The thing I loved, and still love, about managing people is that they would learn and grow. Skills doing that is not as rewarding – but it is necessary to function.
I’m disciplined about scope. Ship the smallest thing that moves you forward. The feature you don’t build is the feature you don’t maintain. When I was running a team, holding the why was the job. Keeping us focused on the things that actually mattered, and away from the things that didn’t.
In Navigating the AI Shift there’s a module where we talk about finding the joy of scope creep, once your core thing is shipped and you can lean into curiosity.
I think this is both the joy and the danger of AI. Everything seems possible, so everything is happening, and you lose sight of the point of it all.
But back to the joy. I wanted to fix our marketing messaging. It had been sitting on my list for… a while, which is a long time for something I’d decided was important.
I hate marketing messaging. But finally, I’d collected all our blog posts, the things we say about running DRI, not the things we write when we’re trying to sell something, and used them to build a point of view that actually sounded like us. It was better. But I wasn’t sure what to do with it.
So I stuck it into Claude design, and entered a few days of absolute madness.
this is what passes for a daily standup in our world
24 hours later, I was rolling out the redesign. New design system, home page, landing page template, all three courses. The messaging that had been stuck was live. A 404 page, just because I could. A “how to expense this” page that Jean rolled out while I was asleep.
24 hours after that, the comparative ugliness of the logged-in views was untenable. So now we have an all new experience, right on schedule for Module 3 of our accelerated cohort.
Objectively, a whole site redesign to unblock one piece of copy is ridiculous.
Practically, it worked.
This isn’t the first time I’ve done this, but it’s the biggest and most visible. I was feeling a bit low and needed a win, and this was my background task that I poked along between a day of too many calls.
The admin portal is just me and Jean. Does it matter? Looking at our previous UX, you would have to conclude: no. But also: don’t we also deserve to have a good experience in what is functionally our workplace? And now the “show cohort progress” item that I wanted but didn’t know how to express, is in.
Jean has the generous read, which is that the creep is productive. Every side quest teaches you where the tools are strong and where they fall apart. The dashboard rebuild went fine. The macOS app I once tried to build for Social Brain, my analytics thing that kept growing until I tried to make it native, did not (yet). I keep learning, I’m getting better at it all.
I’m having a great time.
I had a pause when I realised that Claude design produces very similar sites. I shook it off. Most sites already look the same and it’s clearly better. A designer is not in the budget. Let’s just get it done.
In the course we tell people: find the win, and find the joy. When AI is what everyone else is using and it’s making your work life worse, it sucks. You have to find the thing that makes your work life better. When it’s the stick you have to use otherwise you’ll be laid off, and you might be laid off anyway, there’s no joy there – only fear.
When you shipped the thing you wanted? There’s joy in that.
Lately my wins are getting bigger. I did this in a week when I was feeling low, and I fucking loved it. I learned a ton. The site looks good.
And when the first sale came through on the new look, I thought, oh. Maybe this is why.
We’re really enjoying seeing what people create in our first cohort of Navigating the AI Shift. The next cohort starts June 8, and if you could use help finding the joy of it all, we’d love you to join us.
I have a great memory and a high tolerance for ambiguity, and I evolved to match the era of the internet where searching things by keyword was sufficient. I documented, extensively. But I did not really organize. Not myself, nor – despite my job – other people. I used to joke that I caused people to organise themselves around me: I remembered everything and asked a lot of questions; working with me effectively required those below me to have it together.
In as much as I optimised for anything, I optimised for being able to think.
Big things documented. The weekly list on a sheet of paper. How they fit together, how to reason about things, how to prioritize… that lived in my head.
Like everyone, AI has shifted my workflows, and somehow I have become a person who organises things.
What broke
The first thing that broke is that Jean and I DDoSed each other. We got productive enough that relying on reliability of the other wasn’t enough – we needed a source of truth to know everything that was going on, and who was doing it. We threw out our system (although if I’m being honest, system is a generous description) and built a new one. Nothing that fancy – just a shared system in GitHub and clarity about the state something was in and what it was waiting on.
Then I DDoSed myself. Too many things in flight, flitting between them, nudging them along. So many terminals I needed to color code them in order to be able to find them. There’s an HBR piece on AI brain fry defining it as mental fatigue from oversight of AI tools beyond your cognitive capacity, with measurable effects on errors and decision-making. This was 100% what I had done to myself. The brain fry is the feeling. The result was too many things moving and nothing finishing. I worry in general that the push to “AI driven productivity gains” drives people into this headspace – with all the harm that brings – and misses the point of the productivity, which is the outcomes the productivity is meant to drive.
Jean suggested I look at turning Claude code into a “chief of staff”, and so I forked the repo and started iterating aggressively. My trello board went in the bin – the API that had seemed like a nice to have a week earlier suddenly a fundamental requirement – GitHub became the source of truth. I added in my existing skills for email and social media. I figured out how to version and symlink them.
It was an expensive and chatty todo list. Becoming more like an actual chief of staff required a set of underlying skills – for course operations, inbox triage, analytics, social, the things I do every week – and a way to surface state. Given the starting point, it became the place I looked to put the things I needed, as I realised I needed them.
This is essentially the principles of context engineering, applied to my own effectiveness. As an engineering manager, my role was to notice and remove bottlenecks. To figure out the failure mode and make (or cause to be made) the process that addresses it. To build the structure that makes individual output add up to team output. Now my productivity has gone way beyond what I thought was achievable as one person, and the result was looking a lot less like individual productivity problems used to, and much more like the kind of problems that occur in a team.
The value of organising things became a lot more apparent. In the same way people used to organise themselves in order to manage up to me, now I create organizational systems to build skills that can help me manage myself – help me finish things, rather than starting one more thing, because the green terminal isn’t currently running anything and it could be.
My prompts are short, and laden with typos. But a collection of skills makes me effective. The working-with-cate skill tells Claude how to be effective with me in return. The DRI program manager skill surfaces the things that need attention. The inbox management skill ensures loops get closed and don’t fall through the cracks, the content manager skill keeps me on track on the internet. Some are just for me. Increasingly, they are shared with the people I work with.
The skill alone is not enough, they need to be backed by data. For my non-technical colleagues, that is often notion. For other engineers, it’s often GitHub. Or another API. Combining an API on DRI with the GitHub repo is what makes the DRI PM skill accurate – and as such, useful.
In functional programming, we talk about pure functions, and side effects. AI alone was like a pure function where I – the lossy human – was responsible for the side effects. Increasingly, to be more effective, I want the side effects. I want the skill to write to the source of truth, and flag updates to itself when it realises it is less useful than it is supposed to be.
To manage the side effects, you need guardrails. Now my collection of skills has progressed such that I added a structured rubric to run skills against.
The ever increasing burden of reviewing
Which brings us to the skill of reviewing. When my job was weighted more toward reviewing other people’s work than producing my own, AI looked, frankly, like a productivity tool for everyone except me. It is much more fun to be a creator than a reviewer in this timeline. The skeptics aren’t wrong about slop.
But liberated from other people’s nonsense and trying to grapple with my own, I stopped debugging at one level of indirection, and started getting to the core of it.
The answer is not “stop reviewing.” The answer is to get structurally better at reviewing – which mostly means asking better questions and shaping the work so it’s queryable.
For example, PRs. I know there’s a debate on this, and I get it. I still believe PRs are useful. Firstly because they segment the change – if it breaks something, you know where to look. Secondly because the PR itself is a queryable unit. You can run rules over it, check whether the standards you encoded are being met. Reviewing – for me at least – looks less like looking at the code, and more like thinking through how to validate the work, ensuring that has happened, and figuring out what to learn when it has not.
There’s a good chance my opinion will be different next week. The willingness to put everything I think I know in the bin weekly if not daily is currently the most useful thing I can do to accelerate my own learning. I don’t think anyone really knows what they are doing yet; the constant iteration is necessary to navigate the learning curve.
The metric isn’t output, it’s completion
The trap I fell into is that the cost of generating drops and you can have a lot more things going. Just because you can doesn’t mean you should.
Individual productivity is not a pure function. There are side effects and interdependencies. Hooking up the waiting list to my email and to GitHub is a win – when the thing I’m waiting on comes in, the item moves from waiting to needing my action. Similarly, surfacing the things others are waiting on from me is a reminder that team movement beats individual productivity.
Part of why I wasn’t given to organize things, is that I’m an ADHD-creative type. Executive function is boring, which makes it expensive, which makes me not do it. Building an operational floor for myself helps liberate me from worrying about things, from expensive “did I remember this” panic. I’ve given that work to the robot, so I can work to my actual strengths.
In the first period – before the DDoSing began – I felt the high of AI making me more capable at the things I’m good at. Now I’m leaning into how to be effective at handing off the things I’m bad at. We’re not going to be winning any prizes for organisation, but that’s okay because organization is not the point. The point is the output. The point is finishing the thing. Shipping it.
Everyone is figuring this out
If it is this much work for one person spanning two small teams, of course large organisations are struggling. The learning curve is hard — trying to navigate new tools and a step change in productivity at one time. I’m unconvinced anyone has it figured out, despite some people loudly claiming they do. I’m so grateful I have this time to work through this learning curve working with fewer people, in a more collaborative set up.
I was heads down for a while, but lately I’ve been talking to more people, being more willing to share where I’m at, and offer suggestions. In doing so, I realised I had rewired my brain. Things seemed obvious to me that weren’t obvious before. How to reshape a problem, how to systematise it, how not just to increase the throughput, but drive the overall goal forward, too.
This rewiring happened because I had the space to mess around – to try things, abandon them, try different things, talk it through with someone who was also open they are figuring it out. You cannot build that space by reading a blog post about it. You have to do, and badly, and give yourself permission to learn.
Fundamentally, I’m optimistic about the value of engineers, despite the narrative that we can be replaced by AI. I think learning and adapting is a core skill for us, and we have it to call on, even if the timing is not what we would choose. But sometimes that skill alone feels insufficient, and for that, Jean and I built Navigating the AI Shift. We saw the dissonance and the struggle, and designed a structured space for engineers and EMs to do some rewiring, with the support and accountability of coaching but at a more accessible price point.
The first cohort starts May 11. We’d love you to join us.
For a lot of people, AI started out as a net negative.
You’re reviewing documents someone couldn’t be bothered to write themselves. You’re having your time wasted by PRs generated by someone who never tried to understand the problem. The efficiency gains everyone keeps talking about haven’t really shown up in your week – but the expectation of those efficiency gains has, and somehow your workload is bigger, not smaller.
And then you spend five minutes on the internet and feel hopelessly behind.
The industry is shifting. Competence in this is not optional. But how do you build it amidst so much overwhelm and anxiety?
Jean and I have been thinking a lot about how AI fits into the developer career. We see its impact in DRI Your Career and in the EM Survival Guide courses, and in our 1:1 coaching. And for ourselves — we’ve found a way to make it positive, but along the way we broke things, DDOS’d each other, and threw out our workflows multiple times.
The reality of change is that it’s messy and often also emotional. We wanted to build something that made space for the mess and for the emotions — but takes you through to the other side, where you feel more competent and can apply what you’ve learned to the actual context you work in.
What is Navigating the AI Shift?
Navigating the AI Shift is a 4-module course for engineers and engineering managers who want to move from anxious and reactive to capable. It’s not a technical deep-dive into AI/ML systems, and it’s not a prompt-engineering tip sheet. It’s a course about building fluency through a real project, with the structure and feedback to make it stick.
The course has 4 modules:
Navigating the Identity Threat — What’s actually changing in the job, and where your existing skills are more important than ever.
Your Project, Part 1 — Find an idea that’s yours, scope it to something you can ship, and get moving.
Your Project, Part 2 — Go deeper: constraining problems well, evaluating output, adding guardrails like tests and documentation.
Bringing It Back to Your Team — How to remove bottlenecks, systematise solvable problems, and build a learning culture that supports AI effectiveness across your team.
Each module includes:
Written content and frameworks
Audio conversations between Jean and me — personal stories and reflections you can listen to on a walk
Exercises to apply what you’ve learned to your situation
Personal feedback from us on your submissions
Project work you drive at your own pace
Two ways to take it: standard or accelerated
This is new for this course. Our normal 8-week pacing lets things sink in between modules and accounts for life in between. For people who want to move faster — and have the capacity to block off half a day a week to make that happen, we’re offering an accelerated 4-week version.
Standard pace (8 weeks): A new module every two weeks. Around 60 minutes a week — fits around a busy schedule.
Accelerated pace (4 weeks): A new module every week. Built for people who feel the urgency and can commit to half a day a week of focused time.
Same structure, same content, same personalized feedback from us. The accelerated option is for giving you a container for the focused time you already know you need to carve out, and a level of accountability that holds you to it.
Why now?
It’s an intense time in tech right now, and most jobs are more pressured than ever. The promise of stability from being a good developer is gone. We know we need to learn and adapt, but it’s hard to do that from a place of threat. It can also be hard to do that on the job when workload and pressure to deliver feel higher than ever.
If you’ve been feeling anxious, behind, or quietly resentful about the AI transition — that’s a reasonable response. But it’s not constructive, and it doesn’t serve you.
This course is for you if you want to get clear on which of your skills transfer, build something real, and come out the other side with more confidence in your own judgement (which, it turns out, is the thing that matters most).
It’s not for you if you’re already fluent with AI tools and want advanced techniques, or if you want a technical deep-dive into AI/ML internals.
Enrollment is open now.
Early bird pricing: $449 USD (available until April 30th)
Regular pricing: $499 USD
We start May 11th, 2026, and we’d love for you to join us.
Often, when we talk about automation, we talk about planes. We say they fly themselves, which, sure – and technically the largest planes can even land themselves, if the airport has the equipment (it’s mainly used for bad weather). However most takeoffs and landings remain manual. My pilot friend also points out that many decisions (fuel is a big one) get made on the ground.
The other thing my pilot friend pointed out is that pilots are in for any decisions they make. They are not just flying the plane; they are in the plane. Contrast this with the surgeon, who performs the surgery, and walks out of the operating room afterwards, regardless of the patient outcome.
In this analogy, VCs are surgeons. Developers are pilots. And the hype-men… travel agents selling plane tickets, mainly.
The problem with much of the hype around AI is that it’s not meeting the people who actually do the work where they are at. We’re not being clear about what’s takeoff, what’s landing, and what the ground decisions are.
The cracks are starting to show. I’ve seen various bits and pieces, but nothing captures it better than Luca Rossi’s summary of CircleCI’s State of Software Delivery 2026 data: elite teams nearly doubled throughput YoY, median barely moved. 81% use AI, so the differentiator is not the tooling; it’s infrastructure. Teams with CI pipelines under 15 minutes in 2023 are 5x more likely to be top performers today.
I am fascinated by the software factory model — Dan Shapiro’s Level 4, where programmers are less programmers and more managers of AI agents and tasks — and the challenges of retro-fitting it onto an existing engineering organisation. It’s been a lightbulb moment for me – I feel like I finally get why the layoffs happened first, and why the productivity gains have failed to materialise.
I think the answer lies in the ground decisions, or the open questions from an organisational perspective.
How does the developer tooling calculus change?
With teams of developers, we used to know the things that were useful for a team of 20 but not 2, and the things that made sense at 200 but not 20. That calculus seems to have changed fundamentally for two reasons. First, headcount is not (or shouldn’t be) a good proxy for productivity. Second, tooling itself is easier to build.
Concrete example: every organisation eventually evolves to have a design system. Few start with one. But if you were building a web app today, would it make sense to start with a design system from day one? The answer might be yes.
How do budgets need to evolve?
Historically, dev team budgets are mainly salaries and some tooling. But StrongDM, who built one of the first real software factories, use $1K/engineer/day in token spend as their benchmark for whether you’re doing it seriously.
Firstly, how do you factor that kind of ongoing cost in? Secondly, is managing more complex budgets and ROI going to become a bigger expectation of engineering managers? And what does it take to get good at that?
What does skill definition look like now?
It’s clear that a different skill composition will be more valuable in this model. My predictions are that judgement – understanding what to build and why, what is good to ship (aka takeoff and landing) – and feedback – providing clear direction and iterating well – will be bigger differentiators, and earlier in someone’s career than before. What people call prompt engineering is just problem definition and refinement – skills that have always mattered, now moved to the front.
What does this mean for hiring and onboarding?
Skill definition leads neatly into these two problems: what do you evaluate, and how do you onboard?
In hiring, most of the conversation has been about the ways AI generates noise from candidates and heartless automated rejections from companies. Which is a real problem, but not the most interesting one. Beyond that: once there’s a human in the process, are the skills being evaluated the best predictors of success in this new model?
Similarly with onboarding: having hired many people over the years, I used to have dialled in what good looked like at key intervals — 30, 60, 90 days. But in this model, what does a good trajectory look like when AI can both accelerate and abstract from understanding the systems?
I have my own concerns about AI, I’m not going to pretend otherwise. But I also think the adoption curve is inevitable, and I’d rather help engineering leaders navigate the reality in front of them than relitigate whether we should be here at all.
Coming back to the pilot analogy:
Takeoff – what we build and why
Landing – shipping and the decisions around it – what’s actually good enough to meet the definition of done?
Ground decisions – the open questions above.
What am I missing? What’s your definition of take off and landing, and what are the ground decisions that are changing in real time?
For years, I’ve known intellectually that my best days aren’t my busiest days. That sustainable productivity requires balancing multiple priorities. That beating myself up about not accomplishing “enough” is counterproductive.
But knowing something intellectually and remembering it when you need to are very different things.
So a couple of months ago I started trying something different to help me better understand how I spend my time, what works, and what doesn’t. I wanted to
Capture what I was actually doing across multiple areas
Track not just activities but impact and how I felt
Mine the data for insights about what was actually working
A long time ago, I tried tracking my time in 15 minute increments, which was helpful, but a lot of work. At DuckDuckGo I used to keep a list of what I’d done for the week and then outside of work I mainly used Trello. But then I only got the dopamine hit of the checkbox for finishing things – not all the effort that went into them.
The Solution: A Spreadsheet
I set up a spreadsheet.
One tab per week – easy to review without drowning in data
Columns for categories: Adulting, Human Being, Development, Promotion, Revenue, Twill, DDG (while relevant)
Two assessment columns: Daily impact rating and overall vibe, color coded (green/yellow/red).
Color coding: I also highlighted high-impact activities in green.
Keep it open: I left it in a browser tab and jotted things down as they happened
The key was making it easy. I wasn’t timing anything precisely or categorizing every minute. Just capturing: “What did I do today? Did it matter? How did I feel?”
After a month, I had enough data to start asking bigger questions about what was working overall and what was not.
The AI Analysis
I fed my spreadsheet to Claude and asked it to analyze my patterns over the past month. What came back was a thorough, personalized report that I would never produce myself. First because of the time, and secondly because I’m inclined to be overly harsh on myself for what I accomplish – and what I don’t.
This is one of the core ways I use AI: to give me faster and more detailed feedback loops.
The feedback tends to be very positive, which is why real data matters—it keeps the AI grounded. It also tends to be generic, which is why identifying a process that works for me first, then using AI to give feedback and iterate, works better than asking for generic suggestions.
But when you combine genuine data with AI analysis, something useful happens. Here are some of the insights I got from Claude’s analysis.
The High-Impact Day Formula
Claude identified patterns in my color-coded days. It turns out my best days share these characteristics:
2-3 categories active (not all six—trying to do everything leads to feeling scattered)
1 significant accomplishment I can point to
Mix of strategic + tactical work (both vision and execution)
Human Being time included (exercise, relationship time)
Clear assessment at end of day of what I achieved
This was validating. My instinct to prioritize exercise and quality time with my partner isn’t “nice to have”, it’s foundational.
Wins + Opportunities
Claude validated me as someone who:
✅ Values wellbeing and relationships ✅ Manages multiple work streams effectively ✅ Navigates major transitions with awareness ✅ Balances doing with being
But also (accurately) called out that I would benefit from:
⚠️ More deliberate planning (light vs. focus days) ⚠️ Increased development investment ⚠️ Recovery time after intense periods ⚠️ Clearer daily priorities to reduce “busy but unclear” feeling
The Core Insight
I’m pretty sure I already knew this, I just forget when focused on all the things I haven’t done (yet). I hope that building a structured way to give myself a regular reminder is not just good for my productivity – but also for my mental wellbeing.
My best days aren’t when I work most, but when I have clarity about what matters, make visible progress, and maintain my human being practices.
This felt particularly important to pay attention to as I navigate a transition from a structured and meeting heavy work environment to a more portfolio setup, but honestly most of the same insights probably would have been true 6 or 12 months ago.
Rinse and Repeat
The nice thing about this system, was I could use the insights and feed the data back in a week later. Claude was encouraging about my progress, which was nice – I tend to start the week a little overwhelmed by everything I want to accomplish and it helped me ground myself in what I am capable of.
After taking the feedback, I managed to have a week as a person that:
Works hard without sacrificing relationships
Rests intentionally without guilt
Acknowledges challenges without catastrophizing
Celebrates progress without waiting for perfection
Maintains systems without being rigid
Obviously I still had things I can do better (specifically: spending more time on development). But for one week later – a busy one! – that was pretty great progress. This solidified the Monday morning ritual – run the spreadsheet through and ask “how did I do?” and “what can I learn?”
Failing
I live for the validation, but a few weeks later I took a long weekend and missed the Monday ritual. By Friday, I was toast. I ran the spreadsheet through Claude, and it brought the Real TalkTM. Pointing out that I had:
Sprinted through the week before the long weekend.
Not actually rested – had a hectic (but fun!) weekend away.
Came back and tried to jump back to full capacity whilst noting myself “discombobulated and tired”.
Missed my physical anchors (no yoga or spin).
Claude ordered me to stop and rest, and I obeyed. It was a good call – I managed a nice afternoon reading a novel before spending the entire weekend sick.
I know this is a pattern I have. That I push myself to “earn” a break by getting everything I would have done in that time around it. It’s destructive. But the good thing is that the failing enforced the value of this ritual more than any succeeding would have done.
Try It Yourself
If you’re curious about your own patterns:
Pick 5-7 categories that matter to your life (work projects, learning, relationships, health, etc.)
Create a simple spreadsheet with these as columns.
Add an overall impact and overall vibe columns to capture how you feel about how the day went.
For 2-4 weeks, jot down what you do each day.
Use color for an easy visual emphasis.
Feed it to an AI and ask for patterns – note that in your prompting you’ll likely need to be explicit about the color coding and what it means.
Maybe you’ll learn something new, or maybe – like me – you’ll be reminded of the things you know but forget when you’re stressed. Either way, I hope it’s useful.
If you try this, I’d love to hear what you discover. What patterns emerged? What surprised you?
Cookie Consent
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
