Accidentally in Code

Tag: ai

  • WordPress + Claude – a new look for cate.blog

    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.

  • Useful AI skills for Engineering Leaders

    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.

  • The Joy of Scope Creep

    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.

  • High Throughput, Low Completion

    High Throughput, Low Completion

    A dark room dominated by two large monitors displaying green Matrix-style cascading code, surrounded by a chaotic wall of wires, knobs, fairy lights, and tinkered electronics.
    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.

  • Announcing: Navigating the AI Shift

    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.

  • Ground Decisions

    Ground Decisions

    Credit: Unsplash / Bao Menglong

    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?

  • The Spreadsheet: Using AI to Understand How I Spend My Time

    The Spreadsheet: Using AI to Understand How I Spend My Time

    Credit: Google DeepMind / Unsplash

    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:

    1. Pick 5-7 categories that matter to your life (work projects, learning, relationships, health, etc.)
    2. Create a simple spreadsheet with these as columns.
    3. Add an overall impact and overall vibe columns to capture how you feel about how the day went.
    4. For 2-4 weeks, jot down what you do each day.
    5. Use color for an easy visual emphasis.
    6. 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?

  • What Raccoon Are You Quiz (and some thoughts on vibe coding)

    What Raccoon Are You Quiz (and some thoughts on vibe coding)

    Raccoons are very much part of my brand, so many friends (and my boss) sent me the latest adventures of the drunken raccoon in the liquor store. The past couple of years I’ve also been framing my talks about tech as we used to be instagram raccoons – and now we all live in Toronto.

    So I made a personality quiz for tech workers – what raccoon are you right now?

    Take it. Find out if you’re the drunk raccoon passed out in a liquor store, the MPR raccoon stuck 23 floors up, or the unkillable Toronto raccoon that defeated every “raccoon-proof” garbage bin the city designed.

    Creation

    I’m a software engineer by training, but JS is not my friend, so I took this as an opportunity to try some vibe coding using Claude. I set up a repo on GitHub to use GitHub pages, committed changes as we went, reviewed the code, and made my own edits after.

    It was fun! Without AI it would have taken me much longer to turn this concept into something, and probably not something I would have prioritized. I used AI to give me options, generate the things I didn’t care deeply about, accelerate tedious work, and focused my attention on making the quiz fun and interesting. I started with the list of raccoons and about half the question topics, and then refined from there.

    Rather than do it all in one go, I iterated gradually.

    • Starting with the base quiz.
    • Breaking the files up to make them easier for me to work with.
    • Adding extra features like dark mode, runner up reveal, and back buttons one by one (thanks to my partner for the early testing and feature requests).

    Once I had something that I believed I could ship, I reached out to an artist (Joe Groove) I work with so they could create some adorable illustrations to go with it.

    What I Learned

    From idea to working quiz was very quick, and I was able to chip away at it in bits and pieces of time. That’s transformative for small side projects where it’s more about the creative concept than the code quality.

    But some caveats:

    • No-one else will need to edit this, and I don’t anticipate it will change dramatically.
    • It’s a small webpage hosted on GitHub, so no performance considerations.
    • There’s no PII, no metrics, no business dependencies.
    • If it breaks, I can just take it down (or regenerate it again from scratch).

    Back to the Raccoons

    The raccoon archetypes matter because they reflect something real about tech work right now. The drunk raccoon in the liquor store. The stuck raccoon in the sewer grate. The alligator rider surfing capitalism precariously.

    AI didn’t replace my judgment—it let me build something in hours that would have taken days. I still made every creative decision. I still designed the structure. I still wrote the results that matter.

    Go take the quiz. Find out which raccoon you are. And if your result makes you realize thinking more strategically about your career might help, check out my course with Jean at DRI Your Career, or my book The Engineering Leader.

  • How I’ve Been Using AI

    How I’ve Been Using AI

    By Ralf Steinberger from Milan, Berlin + Munich, Italy + Germany – 21st century robots. Seen from the future, they will just look cute., CC BY 2.0, https://commons.wikimedia.org/w/index.php?curid=110354735

    I feel like the whole AI conversation is dominated by two extremes. Those who believe in AGI, and AI skeptics. I’m trying to approach it as a tool that may or may not be useful. Here are some things I’ve found so far.

    Useful as an editing partner. For things where I have a clear point of view, I produce a first draft and then use AI to refine and clarify. It will just go on endlessly though, so I have been telling it “I have limited time to spend on this, please stop once the feedback is chasing diminishing returns”. I think this works for me because I am quick to write and slow to edit.

    ➡️ For similar reasons, I’m enthused about AI feedback on PRs.

    Helpful for generating feedback. If I’m reviewing something, I can use a similar process to refine my feedback. So I will put in the doc, my initial thoughts, and ask it what else – again being judicious about what I include. Or the doc, the additional clarification I wrote, and then use the combination of those to generate a feedback. It means that I can read something once and query it, rather than reading multiple times to check my thoughts – the longer what it is I’m reviewing, the more useful that is.

    ➡️ Like all women in tech, I’m continually walking the tightrope between being a b*tch and being a pushover, so I’m trying to offload any overthinking of “tone” to AI. My current workflow here is to tell it: “You are a busy engineering leader, who wants {team|person|whatever} to get their shit together”, and then “Now soften it a bit so people don’t think you’re mean”.

    Mixed for structuring things. I’ve also been trying to use AI to create structures or plans, typically for things I don’t know much about (if I know about it, the structure is normally very clear to me). Here, I’ve had mixed results.

    • For example, I tried to use it to generate a book promotion plan for me. It was okay, but initially gave me a full time job’s worth of work. After a few rounds I got something that is more doable, but I’m still not sure how good it is (also I have failed to do it, suggesting the lack of plan was not the only problem).
    • Another example, I tried to use it to create a structure for a proposal around professional development. I put in some bits and pieces – a conversation with a colleague about it, some disjointed thoughts, and got something out that I only have the expertise to tell is bad, and I’m not sure how to make it better. (Although telling the AI “this is bad, try again” has been surprisingly effective).

    Both of these examples were places where I have some amount of expertise, but a relatively narrow point of view, deeply anchored in my own experience. As a result, I was struggling to move something forward or know how to prioritize, I wanted AI to help me get from half formed idea -> plan, but perhaps I need to add an interim step of half formed idea -> deeper understanding -> plan.

    All in all, this I think supports a theme of what I’ve been hearing about AI, for example on the impact on senior devs (good for productivity) versus juniors (destroying their learning).

    • For things you know well, it can be a productivity boost.
    • For things you don’t know, it can give the illusion of knowledge. This is dangerous for knowledge workers, as it can result in wasting time and going down the wrong path. Also, if you submit it to someone who does have that knowledge, an excess of nonsense will be judged more harshly than a gap.
    • It tends to be overly comprehensive and includes excessive low value information.

    For my own takeaways:

    • As a writer, it’s a productivity tool not a generator. I am clear on my voice and despise reading obviously AI generated content so I would not do that to others.
    • As an overthinker and procrastinator, it’s good to offload some things that I might spend disproportionate time on or not do.
    • As a leader, who spends more time reviewing other’s work than creating, I need to adjust my approach to filter out noise and validate structure first.