Accidentally in Code

Author: Cate

WordPress + Claude – a new look for cate.blog
Created by Claude Design

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.
June 16, 2026
Useful AI skills for Engineering Leaders
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.
June 9, 2026
Making a New Plan

Credit: Unsplash / beth_k

Once, I got an email. To paraphrase, it said: I ignored your recommendation, but new evidence arrived, and now I see that you were right. I won’t do that again.

A rare enough thing that I can, years later, still quote it.

Part of what made it so meaningful was this person didn’t have to tell me this. I had no way to know he’d ignored my recommendation. I didn’t even mind that he hadn’t gone with my recommendation – the information that was my job to gather was just one piece of the picture.

I was talking to a friend recently, and one of our topics of shared frustration was the inability of people to admit when they are wrong. The mental gymnastics that ensue.

I enjoyed our shared moment of gossip and judgement, of course.

However, the next morning it connected to something else I’d said in that same conversation, about a project I was doing, where I used phrases such as “knowing what I know now”, and “what I’d tell someone trying to do this”…

And realized I was doing the same thing. That I had new information, but I was sticking to the plan I’d made without that information.

So I made a new plan.

Terrifying.

But clarifying.

The old plan wasn’t bad, but it also wasn’t the best plan that could be made with the information available. I debated what to do with it. Then I thought about me three months from now, and asked myself – do I want to regret not making this change then?

I did not. I shared the document with the CEO. After we’d got to an agreement, I told her:

I realized I can just incorporate new information and make a better plan without it threatening my sense of self

She replied:

YES you CAN

I think admitting when your opinion has changed, and why, is an underrated leadership skill. If you’re publicly wrong, not admitting that doesn’t change anything – getting to be less wrong means admitting that you have changed your mind. If you don’t do that, the people around you – particularly under you – feel gaslit. If you do, they trust you more.

We’re all wrong at times. But in an industry being upended, I think we have to accept that we’re all going to be wrong more often than ever.

Terrifying.

But freeing?

I think it can be.

June 2, 2026
The Joy of Scope Creep

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.

May 26, 2026
The New Realities of EM Lyfe

Image credit: Joe Groove

A fascinating thing is happening. EMs are saying it’s better to be an IC. ICs think being an EM is where it’s at.

This is part of the AI shift. The industry seems to be in chaos, and wherever you are, somewhere else seems better. But below that, it’s not just the job that’s changing. It’s the context we’re operating in hitting like a bucket of cold water.

The seller’s market is over

We lived in a seller’s market, and we thought it was because of our own brilliance. Jobs were easy to come by, and with them comp, job titles and perks.

It’s a buyer’s market now and that loss of leverage means we have to justify our impact. If you think you can get a better job, the organization is more likely to say “okay” than give a meaningful counteroffer. It’s always been true you shouldn’t negotiate on a job you don’t mean to take, but now that needs to be a hard line as you’re more likely than ever to be called on it.

It’s a hard thing to accept, being less special and less in demand.

The attrition is the point

When management is an abstraction over people, it only has value when people do.

For example, during ZIRP, being a good hiring manager was a huge part of the job, and a good hiring process was a real differentiator. People were the constraint. Companies competed on how well they identified, attracted and developed talent, because that was what determined what you could build.

That’s gone. Hiring is slow or frozen. The L&D budget has been slashed. I wrote last year that management debt was looking cheap. Now I would say it’s looking actively desired.

Why develop your people if attrition will sort it out for you. Why give hard feedback if the person will burn out and leave. Why fix morale if the ones with options have already gone and the ones who stayed can’t go anywhere. The workforce that’s left is cheaper, quieter, and more grateful.

The risk, of course, is that the people without options aren’t usually the people you most wanted to keep. This is the AI-era debt; we’ll see what it costs down the line.

Mass layoffs are the new RTO

Post-pandemic, return to office looked easier than management fundamentals. Remote work didn’t break those organizations. It made it visible long term deficiencies that were too expensive and structural to fix.

Mass layoffs are the new blunt instrument.

Running a layoff is, bureaucratically, easier than writing a PIP. A PIP requires you have been managing the person. Documentation, expectations, feedback they had a chance to act on. A layoff requires a spreadsheet and a comms plan.

Both punish everyone for problems leadership created. I miss the time when a layoff included an admission of failure. Now they read more like an acceptance speech for visionary of the year.

This is not to say I don’t think AI will restructure the workforce. I do. I’ve been realizing efficiency gains with it. Reflecting on my time running a large org, I don’t honestly know how I’d make those gains real without a layoff. But that’s not an indictment of the workforce, nor one that I would measure in a %. It’s the change-management and people-development bill coming due. What was less than optimal becomes a structural block.

We never agreed what an EM is

We never had a shared definition of what an engineering manager is. Sometimes you could figure it out from the job description, but not always. People-leader, technical-leader, project-runner, career-developer, information-router, scope-holder, vibe-shaper. The profile depended on the values of leadership and the outcome of the latest reorg.

Fundamentally, you didn’t have to be great at all the things to be good enough for the org, and the people stuff was big enough and fuzzy enough that it often became the job.

Now I keep seeing the phrase “player coach” and I don’t know what it means. But the overall shift is, I think, pretty clear: get closer to the work, drive delivery improvements, be able not just to know what is going on but consistently make it better (or at least faster).

Without a good definition, it’s much harder to absorb the chaos of senior leadership litigating in public whether the role should even exist. Trying to “improve productivity” by “doing the work” has ICs describing the output as AI slop. Being told you could be more efficient by having fewer 1:1s, but no one gave that memo to the ICs who still expect their 30+ minutes a week as well as an actual fix for the things they’re complaining about.

It’s hard to fit all this conflicting feedback into an undefined scope.

The force multiplier

A consistent thing I keep seeing from EMs is moral injury. They got into the job because they care about their teams and want to support them, and they feel conflicted between that calling and the organization’s demands.

It’s fair and understandable. The challenge, I think, is moving to more of a collective care than an individual one. And rightsizing your care to the market we’re in. Taking personal responsibility for things where you have little to no power is a recipe for burnout.

Something I have long believed: a manager is a multiplier on the team. The worst ones for bad. In a growth market, you didn’t have to be much more than a 1x to have value. Now, the expectations are higher.

Framing the role this way, a force multiplier for the team, creates clarity. You’re expected to make the team better. It also explains the calculus in a way that makes sense. If being a great hiring manager was a multiplier effect before, now it’s not. Retention is not seen as valuable. I believe retaining your strongest team members still will be, but that’s unlikely to be everyone. You’ll need to pick your battles.

The thing is, there’s a good chance your organization won’t tell you how to do that. You have to figure out how to take in the information you have, and figure it out for yourself.

If that sounds like a lot, the EM Survival Guide cohort 2 starts in June. Join us, we’d love to help you.

May 19, 2026
Force Multipliers

Image credit: Joe Groove

It’s harder than ever to be an engineering manager. Fewer resources, higher expectations, and a public conversation actively questioning whether the role should exist at all. Less support than ever, in a job that already often felt hard and lonely. That’s why Jean and I built the Engineering Manager Survival Guide – and I’m so glad we did, because the first cohort just wrapped, and it confirmed everything we thought was true about the gap, and how rewarding it would be to help people close it.

We spent weeks debating what an EM actually is before we could build the course around it. The definition is both poor and variable. Same job title, completely different jobs. We eventually landed on force multiplier for the team – and then spent the rest of our build time working out, tactically, what that means and how to do it.

We knew going in that the role was variable, but there’s a difference between knowing that intellectually and seeing it up close. The exercises where we asked people to go through every direct report, one by one – what they’re working on, what they need, what’s getting in their way – I love seeing how deeply people understand and care about their teams. I know, as a manager, how often conversations were dominated by the problems. It’s good to create space for all of it.

Recording our wrap up audio, Jean pointed out the frameworks are simple – what you get out is what you put in. But the process of systematically looking through things, identifying the gaps, and figuring out the changes you need to make: it can be hard to do when so much of your job is responding to what people expect from you. Carving out space, support and structure to think is valuable.

In DRI Your Career we’re often encouraging people to widen their frame. With EMs it was the opposite – what they lack most is time and perspective, and our role was more to help them narrow in on which of their many ideas could have the most impact.

I wrote recently about the role middle managers were supposed to be doing, the flawed metric of headcount that defined them, and how unsurprising it is that people feel adrift when that metric collapses. I’m now three months into something new, and what I notice is that the mindset – the orientation toward making everything around me better – hasn’t changed, even as the work has. Process and efficiency, abstracted by skill.md files now instead of people. The work of being a manager, in a different form.

What I want for every EM is the same thing I wanted for myself, when I started being an EM, when I wrote The Engineering Leader, what I now try (with Claude) to create for myself each day, each week: a clear enough definition of the job that you can have a sense of whether you’re doing a good job and be able to call it when the day is done. Something concrete enough that you can still hold onto when the org chart shifts under you.

The course covers what a force multiplier actually does, across four modules: sustaining yourself, leveraging feedback, leading with clear direction, and expanding your range as a leader. We read and comment on every exercise submission.

The next cohort of the Engineering Manager Survival Guide starts in June. You can find out more and sign up at driyourcareer.com/em-survival-guide.

May 12, 2026
High Throughput, Low Completion

Credit: Flickr / MeTaMiND EvoLuTioN MeTaVoLuTioN

I have never been someone who organises things.

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.

May 5, 2026
Book: Burnout – The Secret to Unlocking the Stress Cycle

I first read Burnout – The Secret to Unlocking the Stress Cycle by Emily and Amelia Nagoski in May 2019. I was, at the time, pretty fried. I’d recently written The Cost of Fixing Things about three back-to-back team turnarounds – one of them with a fractured shoulder whilst buying and renovating a house. I’d disappeared in Seoul. I was accidentally stuck in Thailand because my passport was full and I didn’t realize. Everything had been a bit too hard, and honestly? I was hardest on myself. I picked up the book and live-tweeted my way through it.

The engagement on that thread was amazing. The best of Twitter before that dreadful man ruined it. It felt like reading the book in community.

I did buy many copies of it for other people. Also, I guess this is the complete review. A little late 😝

I returned to it recently because I felt like my nervous system needed to be healed again. There’s a bit in the book about a bunny hiding under a bush, not sure the fox is gone yet. That was me. I was in the midst of processing a huge change – leaving my job to do other things, living in the space where even though I was pretty confident I had made the right decision, my feelings were a bit all over the place.

Re-reading it was a different experience. The first time was intellectual revelation, in community. This time despite trying to recruit some friends to a little book club (they need it too) it was a more solo experience, like returning to a friend who gives you the real talk whilst also believing in you. Some things I’d internalized so deeply I barely noticed them as lessons anymore. Some things landed differently because I was in a very different place.

What makes Burnout special is the arc. It doesn’t start with “here’s what’s wrong with society” (which would be overwhelming) or “here’s some self-care tips” (which would be patronizing). It starts with your body. Then it widens the lens to the systems acting on your body. Then it names the enemy. And then – only then, once you are clear on what you’re working with – it tells you how to rebuild. Self care is not the capitalistic con where we have to buy candles and take baths. It’s connection, compassion, rest, meaning.

Complete the Cycle. Stress and stressors are different things. You can solve the problem that stressed you out but your body is still holding the stress response. You have to complete the biological cycle separately – through movement, breathing, crying, connection, creative expression. This is where the book starts: with the physical reality of what stress does to you and what it takes to release it.

In 2019 I needed this desperately. In 2026, I noticed exercise has felt less necessary lately. Not because I’ve gotten lazy, but because I’ve actually removed many of the stressors. My body isn’t holding as much. That’s a good sign – and it ties to the later chapter about rest. I don’t need to complete the cycle faster; I have fewer cycles to complete, and that respite? Amazing.

#Persist. The Monitor – that part of your brain tracking the gap between where you are and where you want to be. It calculates effort vs. progress and decides whether to keep going or give up. When the gap feels unbridgeable, you get stuck in frustration or despair. Sometimes you need to adjust the goal, sometimes you need a different door entirely.

I guess quitting my job was about finding a different door. But The Monitor is still adjusting. It needs me to define manageable, incremental progress to feel like I’m doing enough. Trying to succeed immediately is unhinged. My monitor really can be a despot.

Meaning. The book makes the case that meaning isn’t a luxury you earn after the practical stuff – it’s a core resilience tool. It’s what makes the effort worth it when things are hard. This chapter completes the first section of the book: you’ve got tools for your body, tools for your frustration, and now something to orient toward. You need all three.

My sense of meaning has shifted lately. When I was doing the CoActive coaching training, I was anchored in the meaning I derived from being “the architect of effective organizations”. At the end of last year, I realized that wasn’t resonating anymore. Now it’s about helping people thrive and be human despite capitalism. That needs to include me.

Then we come to the systematic. The book names the systems that are so corrosive and taxing to our well being.

The Game Is Rigged. Human Giver Syndrome – the expectation that women give their time, energy, attention, bodies to others. The distinction between “human givers” and “human beings.” You can’t self-care your way out of a rigged game.

This chapter cut to the core in 2019. It cut to the core again. It named some unreasonable things I want to leave behind. It remains such a good articulation of the structural inequity that results from making women responsible for other people’s feelings.

The Bikini Industrial Complex. The system that profits from women hating their bodies. Diet culture, BMI as junk science, the wellness industry selling solutions to problems it created. The body ideals are unattainable on purpose. That’s the business model.

What I take from this chapter is the question of why you care for your body. Is it about you feeling better, or conforming to the bullshit system? Internalizing unrealistic beauty standards is a form of self harm. Moving your body because it makes you feel good and/or helps complete the stress cycle, and moving your body because you hate how it looks are not the same.

Having acknowledged the structural challenges, that we still need to exist within – now it’s time for the tools that help us do that.

Connect. It starts with connection – the healing power of other people, the danger of isolation, the importance of someone being “the keeper of your story.”

I told a friend recently I was in a very productive hole – so, this one is relevant. I’m grateful for my partner, but I need to seek out more community. I’m in a mode where I’m inclined to hide away and do the work. But that’s not healthy.

What Makes You Stronger. The Mad Woman in the Attic – your inner critic, named so you can recognize her when she’s talking. Self-compassion as a real practice. And rest. Real rest.

And then, on the topic of productivity:

I was a tube of toothpaste being squeezed relentlessly in 2019. In 2026, this chapter was the biggest shift. My inner voice is less cruel now. I deleted it. That was a long undertaking, but one that profoundly improved my well being.

Grow Mighty. Not fixed. Not perfect. Mighty. The final chapter pulls everything together – the body tools, the systemic awareness, the connection, the self-compassion – into something that feels doable day to day. You’ll still be stressed and the game is still rigged, but existing in the system does not have to mean believing the system.

The arc of Burnout puts you at the centre of the hero’s journey, and then it takes you through it, and for me at least, deposited you outside of it at the end, with a little more confidence, substantially less gaslit, and more trusting of myself.

In 2019 I consumed it like someone throwing me a lifeline. In 2026 I read it like a reminder of how to come back to what I know.

If you haven’t read it, read it. If you read it years ago, maybe it’s time to go back. The friend has new things to say. Or maybe you’ve changed enough to hear them differently.

April 28, 2026
Announcing: Navigating the AI Shift
Image credit: Joe Groove

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:
1. Navigating the Identity Threat — What’s actually changing in the job, and where your existing skills are more important than ever.
2. Your Project, Part 1 — Find an idea that’s yours, scope it to something you can ship, and get moving.
3. Your Project, Part 2 — Go deeper: constraining problems well, evaluating output, adding guardrails like tests and documentation.
4. 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.

👉 Learn more

You can also preview the intro module for free to see what the course experience is like.
April 21, 2026