Accidentally in Code

Author: Cate

  • Book: Obviously Awesome

    I’ve been trying to learn marketing lately. I would not say it’s going well.

    I started with a Coursera course, and one module in I was so frustrated by the pseudo-scientific framing. Some of it was actually scientific (I recognised Sheena Iyengar‘s work) and some of it only seemed so.

    Claude told me I should read this book instead. I told Claude I had to finish my current book first. I tried to keep going with the Coursera course.

    Then I finished my book, had some downtime, and read the one Claude recommended: Obviously Awesome by April Dunford. Claude was right. This was the book I needed.

    Positioning is the foundational idea of what you’re selling. One chapter in, I was having an aha moment about DRI Your Career and our positioning. By the end of it, I was revved up and ready to fix it.

    So I did. I downloaded the worksheet and built out a prep doc of what we know from user surveys, testimonials and other data. I fed that into Fable and asked it to ask me any questions it needed in order to produce a positioning statement.

    From the positioning statement we produced a messaging doc, and from that, did a copy pass across the entire site, making it more consistent and aligned with our overall positioning. I did a detailed pass on the messaging myself, then fed it back in to update.

    This positioning work moved DRI out of “cheaper 1:1 coaching” into its own category – a course with a coach in it – unified four courses around one buyer: someone facing a changing industry, and led on what’s genuinely differentiated: a coach reads everything you write, and you leave with your own docs. Price and access became quiet commitments (one price, scholarships, no hustle), not the pitch.

    With that, many things became easier. The new security course felt coherent rather than something to explain. I had much less dissonance around 1:1 coaching vs. DRI. And in the same pass, we could tighten up the website generally. Orienting it around being by and for engineers meant a docs theme was more resonant than a standard marketing one-pager.

    This book, plus the generous templates, took me from a problem that felt unbounded to a concrete, step-change improvement that I was able to ship in a few days.

    I still have a lot more to learn about marketing, but this has given me a model for how I want to approach that – good resources, on concrete problems, that I can apply and test on the thing I actually care about. The Coursera course made me feel like I was learning marketing for marketing’s sake, but I’m not; I’m trying to figure out how we make DRI something real, and marketing is about how we tell people about it.

  • What do managers even do now?

    Credit: Paul Hudson / Wikimedia

    I watched an IC have a lightbulb moment: they’re a manager now. Running agents in parallel, giving direction, deciding what’s worth doing. Being responsible for what ships, without doing it all themself. My job is giving them the pieces of management that are useful right now.

    Not how to run a 1:1.

    How to think one level up, and systematically. Not the bug, the bug class. Not the problem directly in front, the one that comes next.

    The ones asking for this help are the ones who still feel responsible for what ships. How do I do this responsibly? I see pro-AI-development and cognitive surrender being conflated as the same position. They aren’t. The work is building systems where you can be responsible for what you shipped without being in the details of it.

    ICs spend – or at least used to – more time focused on the thing immediately ahead and as such are biased to notice that. It made sense when that took a while, but now it can be faster, the timelines are compressed – or they can be, if things are working well.

    Managers encode judgement through process and relationships. Relationships build judgement 1:1 – and that’s valuable – but process is how judgement scales.

    Scaling agents has really tapped into something for me, and it’s all the skills I used to use when I was scaling teams – many of the same ideas showing up at different times. Also things other people used to do and I never got into the depths of – I’m spending a lot of time in CI, lately. I never did that before.

    The human parts of management are important. Of course they were. But the people who thought managers did nothing but go to meetings always seemed to miss the pieces those meetings (and documents, and nudges, and questions) moved forward. Which was finding the things that were lossy – whether partial processes, or missing guardrails or understanding – and causing them to be filled in directly or indirectly.

    If you want to move at speed with these new tools, you can’t have 8 people on the team moving as fast as possible and one person trying to figure that out. You certainly can’t expect that from the person who has so many direct reports they can’t physically meet with them each week. Every IC needs to learn how to do it for themselves, and then collectively, so the team can move faster together.

    Management is learnable. When you scale a team you build a layer of management underneath you. You bring people in, or you lift people up, and you train them. You take the values of the team and encode them into process, because process is how you get multiple people to do the same thing consistently.

    ICs aren’t being asked to do this. They’re being asked – told – to go faster. But this is how teams go faster. This is the work good managers always did. Now they need to scale that work earlier, with people who didn’t sign up for it deliberately.

    If we’d ever really been clear on what a manager does, perhaps this aspect of management would be more defined and it would be easier. Oh well.

  • Announcing: Breaking Into the Security Mindset

    Image credit: Joe Groove

    Application security might seem like a strange thing to build a coaching course about.

    But the thing that makes coaching work is that the person comes out feeling bigger than the problem. That’s useful in many things. It’s especially useful in a field that seems to have been designed to be opaque. We’ve partnered with Halle Winkler to bring you a blend of her security expertise and our coaching mindset, in the DRI async+audio format.

    This is our first partner course, and it gives us an opportunity to bring in another collaborator, with different skills. I’ve learned so much working on this, and I’m so excited to share it with you.

    Halle and I met at an iOS conference years ago. She’s now an offensive security researcher and application security engineer, a Certified Ethical Hacker with twelve Apple security credits. Her CVE proofs of concept include a macOS remote-control camera and a Lock Screen keylogger.

    There’s more talk about application security than there has ever been, which can make it seem more intimidating than ever – but we think it’s an opportunity to get to grips with it. If you’re a product engineer, you probably know more about this than you think you do. You understand systems. You’ve spent years thinking about managing a full range of inputs and all the unexpected states. What’s missing is the vocabulary, a map of the field, and the sense that you’re allowed to do this at all if you didn’t start hacking at thirteen. You are.

    What is Breaking Into the Security Mindset?

    Breaking Into the Security Mindset is an 8-week course for engineers and engineering managers who want to bring security into their engineering and product work. It isn’t magic and it isn’t only for lifelong hackers.

    The course has 4 modules:

    1. Finding Yourself in Security — three personae: you as the defender, adversaries, and who you protect and why. Then threat modelling, the state of the art on both sides, and our ethics and safety practices.
    2. Your Project, Part 1 — build a small offensive research script or agent against a safe synthetic target, using local LLM workflows, and write up a vulnerability report on what you find.
    3. Your Project, Part 2 — research your vulnerability, remediate it, and then how you can adjust your development practices to prevent it being built in the first place.
    4. Bringing It Together — CI/CD and supply chain, secure coding as policy, which shift-left tooling applies to your products, and staying current so you can sleep at night.

    Each module includes:

    • Written content and frameworks, so the jargon is demystified
    • Audio conversations between Halle and me
    • Exercises to apply what you’ve learned to your situation
    • Personal feedback from us on everything you turn in
    • Project work you drive at your own pace

    Plan for around 60 minutes a week. The project is the biggest variable. If it pulls you in, you might blow past that – and your bedtime!

    Why now?

    The agentic era of software development is also the agentic era of vulnerability exploitation. Teams are shipping AI-assisted code at volume, and a lot of people aren’t sure what risk that introduces or how to set guardrails around it. A lot of other people have quietly become the de facto security person on their team without ever deciding to.

    This course is for you if you know security is a gap and it has felt too intimidating to begin. You’ll want to be actively coding, to the extent that building and debugging a small tool is possible for you. It’s not for you if you already work in security and want advanced technique.

    Enrollment is open now.

    Early bird pricing: $599 USD

    Regular pricing: $699 USD

    The course starts October 12th, 2026.

    👉 Learn more

  • Skills for a more leveraged workflow

    Adapted from Mix and Match Robot expressions by anarres (Openclipart, CC0)

    I’ve been skeptical in general about sharing workflow skills. I have a bunch I share with direct collaborators, but there are a lot of “AI skills” repos out there and I’ve only found 2 of them really useful to me (#1, #2). I thought working out what you wanted and making your own was important – but I kept packaging up a similar set of skills to share with specific people, because I underestimated the value of having a starting point. So finally I accepted – I too would make an AI skills repo: ai-dev-starter-kit.

    The conversation I was having is how to go from leveraging AI to leveraged by AI. I think it’s a question of what do you hand off, and what do you keep? AI can do a lot of work, but it can also generate a lot of work for you. You have to figure out how to manage that so you’re not just scattered and getting less done (been there).

    At the core of it is a board configured a certain way, and three terminals. The board is the source of truth, and work is issues moving through a status workflow. Two of the terminals are the skills that generate and validate code: the orchestrator, which fans work out across the board, and the merge queue, which serialises the landings and does final validation before anything goes in – things that can run for hours with periodic checkins. The third terminal is the one that requires thinking and engagement, and the work I do in it is to make work agentable (i.e. push it into the queue the other two terminals run).

    The other thing in it is a sample CLAUDE.md – talking to people in mid-sized orgs, I consistently notice it’s under-leveraged, and it’s much easier to change robot behaviour than human behaviour.

    The others are smaller. One goes through what went in overnight and flags anything I should worry about – review isn’t required before merge, but I still want to know what landed.. fable-audit-prompts is my answer to “what is Fable even for”: I use it to audit things where I have vibes but not concrete ideas, and it generates a report that makes that work agentable by less expensive models.

    If you’re looking for a starting point for a more leveraged workflow, I hope this can be helpful – whether you take some pieces as they are or just as inspiration. Feedback or ideas always welcome.

  • The next weight

    Credit: NeedPix

    Something that comes up regularly in coaching is the idea that you get stronger against the weight you can lift, not against the one you can’t.

    If your goal is to bench 100kg you don’t get there pushing at that weight on a bar you can’t move. You start lower and work up. You build your strength. You manage your fatigue.

    Pushing on the 100kg bar will tire you out. It will feel like you’re working hard. It won’t make you stronger.

    The same is true at work.

    If you struggle to set boundaries and work in an environment where boundaries are discouraged, that might be the 100kg weight. Working somewhere that’s always on, but where people are expected and respected for setting their own? That might be the weight you can lift.

    If you need positive feedback, a manager who only tells you what’s wrong might be the 100kg weight. A manager who is matter of fact – who tells you when something is fine and moves on – might be the weight you can lift.

    If you struggle to rely on others it might feel more comfortable to work for yourself, but it’s not growing your capacity for collaboration. An environment that is super team first might be a very difficult adjustment. That could be the push you want – but know that going in.

    Something we talk about in DRI Your Career is that we’re not – mostly – different people inside and outside of work. The struggles we have show up in multiple areas of our lives. It’s easy to complain about the job being the problem, and I would never deny that there are very toxic situations out there. But more often than not the problem is the person and job in combination.

    It’s amazing to me how much stays the same when we make dramatic change in our lives. It’s been more than six months since I upended my life, started doing something completely different. My partner still says I work a lot. My boss – despite being a different person – would probably still say my tolerance of bullshit is low. I still get anxious, and I still struggle with things that are boring or feel pointless.

    It was overall a really positive change. But it didn’t change everything. I’m not a different person.

    The other idea in coaching is to focus on what you can control. This always starts with your own choices and behaviour. You can’t stop your colleagues messaging you out of hours, but you can stop checking Slack. You can’t change the feedback culture overnight, but you can ask for what you need today. You can’t control whether or not someone will show up, but you can give them the opportunity to live up to some better expectations.

    I love how in the tech industry we have normalised the extended break. But I worry that it’s become an expected cycle of burnout and crash. I think we can learn to self-regulate, even as capitalism will always aim to maximally utilise us.

    A few years ago I switched to the Whoop as my fitness tracker. The appeal was its focus on recovery. It’s been difficult to use something targeted at pro athletes – at times in my life that would have led to some destructive tendencies. But it did help me regulate better, to work out more sustainably, to move away from the sprint and crash cycle.

    There is no equivalent for mental self-regulation. The closest thing I’ve found is PQ, which helps bring awareness to these tendencies and gives you a way to actively work through breaking them. Some other suggestions:

    • Ask for what you need. Make reasonable requests and expect reasonable answers – at least the first time.
    • Get clear about what it would serve you to work on, and make a plan for that.
    • Invest in the quality of your life outside of work. Connect to that, rather than disconnect from it.

  • The Date – Blunt Implement or Forcing Function?

    Credit: Alexas_Fotos / Pixabay

    On some of the worst run projects I’ve seen, leaders trying to get them back on track would set a date.

    Never, ever, in that circumstance, have I seen a date be met. No-one believes in it, no-one is willing to work overtime to meet it. It slips. Another one is set. And another. Maybe six months later something goes out.

    I feel conflicted about this because I do really believe in the power of setting a date as a goal. The thing is, for this to work:

    • It needs to be part of the conversation from the point when the project is defined and real.
    • It needs to push people but they have to be able to reason about and with it – it can’t be a joke.
    • It has to be used as a way to force decisions – what’s in, what’s out.
    • It has to be part of a healthy function where in general bottlenecks get investigated and removed.

    We just shipped a complete replatforming for Twill, and this is how I approached it. I set a date – July 4 – because honestly what better time to ship a big thing than when Americans are OOO and partying. The engineer I work with told me I was wrong – and I was – we shipped a month later, on August 2.

    On the one hand – one month overdue, 33% of the plan. On the other hand – four months. This required us to be brutal – as the CEO puts it, I said no to every request for four months.

    You can only say no to everything for four months when you have credibility and you’ve given people a baseline first. You can only keep that up for so long – you have to ship.

    This might seem basic, like yes, this is the thing we’ve all agreed on for a long time. Maybe you want to cast some shade that I was off by 33%.

    But here’s the thing – whatever we had thought we’d agreed, AI has upended it. More and more the date isn’t a month out. It’s today.

    A week out. A month out. Far enough away to seem possible without knowing what actually needed doing. Reality would arrive. Eventually they’d stop.

    The leader who sets the date today is sometimes right.

    It took me a while to set a date at all. My stance was that so much had changed that my way of estimating was off base. I’m not surprised I was wrong – I know exactly what was faster and what was slower than I had accounted for.

    As I write this, some Claudes are working. One of them is cutting a release. Another is running agents and churning through a list of issues. This is completely different. But I will still need to validate the release before it goes live. And later I’ll come back to yet another Claude and figure out what else is ready to go, what needs human judgement or setup. That bit is less different.

    The discipline of decision-making, of reducing collisions and churn… that continues.

    There’s this dissonance around “go faster” being a strategy. It’s not a strategy. It was never a strategy. But I see engineering pushing back from a stance of, I thought we agreed this was bonkers? We have to come at it by reasoning about what has changed and what has not.

    For years, in engineering, we’ve worked to make the conversation about velocity rational. Now we need to do that again. Even when “go faster” is the strategy, turning engineering – now with additional token spend – into impact is still the job.

  • What would make next week better?

    Credit: Flickr / Christopher Bowley

    Just about everyone gets overwhelmed sometimes, and many of us deal with that by working harder. This is a reasonable response to a single unexpected thing, or a bad week, but it’s not the right response to systematic overwhelm. Then you need to stop asking the question “what do I do next” (or worse: “how am I going to do everything?!?”) and ask a different one:

    What would make next week better for future-me?

    When you’re overwhelmed, current you is SOL. Future you doesn’t have to be. What can you do for them?

    Working harder isn’t the answer, and you know this because if it was going to work, it would have by now. Also you can’t operate at your max capacity week in week out, because something will happen. You’ll get tired. You’ll get sick. The vacation you booked months ago will suddenly be next week. Something will go wrong. Your exec will demand something you hadn’t accounted for.

    When you’re overwhelmed, thinking about future you, and picking one thing, small enough that you can do it while still drowning, is how you dig out of the hole. Maybe the first one won’t feel like it made a big difference. But enough of them, and it will.

    The bonus: this isn’t only a way out of overwhelm. It’s how you build slack, so you have capacity when the opportunity comes, or the unexpected bad thing does.

  • Book: Churn

    Claude Steele’s first book Whistling Vivaldi gave me one of the most useful framings I have for bias. Stereotype threat: in a situation you care about, the worry that you’re about to confirm a negative stereotype about your group degrades how you do. So when I saw he had a new book – Churn: The Tension That Divides Us and How to Overcome It – I bought it immediately. And then it sat on my Kindle unread for months; I finally started it and by chapter one I could see why. It named something I wasn’t ready for before.

    Stereotype threat is the impact. Churn is what happens inside you while it’s happening.

    He opens on a parent-teacher conference. Black parents, white teacher, everyone arrives braced. The parents are wondering whether their son is going to be stereotyped. The teacher is wondering whether her constructive feedback will land as racism. Everyone has good intentions and cares deeply. Churn isn’t manufactured by prejudice; it’s the concern and expectations of it.

    Prove it again

    At a previous job you would get hired for your experience and then have to prove it again. Pretty common, I’ve found, in environments that pride themselves on uniqueness, and it makes sense – it’s well documented that many executives fail because they try to apply the same playbook in a different context. I recognised it quickly and just went with it. A male colleague was really annoyed about it. He left some time before I did.

    The phrase belongs to bias research – Joan C. Williams’ Prove-It-Again, where women and people of colour re-establish credibility that everyone else gets on credit. Whilst my male colleague was mad about it, his anger made me more relaxed – I wasn’t having to prove it again because of who I was, this was the standard applied to everyone.

    Which aligns with an experiment from the book: both Black and white students got critical feedback on an essay from a white evaluator. The white students took it at face value. The Black students had no way of telling, from the inside, whether the notes were about the essay or about assumptions concerning their group. But when evaluators added a line: high standards, and I think you can meet them, those students trusted the feedback and were more likely to action it.

    What it’s like without it

    I’m much less stressed lately and now I’ve got a label for why.

    I work primarily with very competent women, with coaching clients who sought me out, with people who opted in to DRI. There’s no competition, no drama, no behaviour where I have to wonder whether or not it is sexist and as a result – no churn.

    Combined with Claude (a non-judgemental answer to any question I have), it’s been helping so much with learning. So much of that is things I used to be afraid of – financial accounting, SQL, infrastructure… I feel like I can make mistakes because if I do it will not reinforce the stereotype. No one taking a mistake as a reason why I’m actually completely worthless.

    Which sounds dark, like I used to work with horrible people. I didn’t. But there was enough bias and shitty gendered behaviour that I got really in my head about it for a while, and then, to insulate myself, built a set of coping mechanisms that I do still believe were necessary and am not convinced were healthy.

    Coping mechanisms help you cope. Nowhere is perfect. Taken too far they become harmful, the thing, I think, is to realise when it’s heading in that direction and create space to untangle yourself from them.

    A break, not an exit

    I wondered whether it’s unrealistic to opt out of something this inherent to the industry. But honestly I’m inspired by King Richard. Richard Williams didn’t subject Venus and Serena to the junior circuit. Everyone told him that was the way to do it, but he saw the psychological cost, and wasn’t willing for his girls to pay it.

    We don’t get the counter story, the version where they went through it on schedule. Or perhaps we do, given how few Black players there have been in tennis.

    Steele’s own answer isn’t exit, it’s trust built inside the settings you’re already in. Maybe the reason why I’m lower in churn isn’t just because I’ve created my own, more homogeneous environment, but because it’s an environment higher in trust.

    I don’t know that it’s viable forever. I’m probably too ambitious for that. I knew I needed a change and I got one, and the label turned up afterwards to explain why there is such a difference. What I can say is that I needed some respite from what I can now call churn, and it’s made this period of change a lot easier to learn in.

  • Maturing our development process as an AI-first 2 person team

    Credit: Landiva Weber / Pexels

    We’re doing a big release this week for DRI Your Career. Mostly bug fixes and reliability work nobody will notice, but the two things worth mentioning:

    • Audio episodes are now available as a private podcast feed.
    • Made significant progress towards supporting multiple coaches (yes this implies some very exciting announcements – more soon).

    We’ve come a long way since it was just Jean and “Claude the intern”, but mostly very iteratively. We’d come to a point where it seemed worth rethinking. We wanted to ship some bigger things – this release was nearly 100 PRs over about a week, passing back and forth between Ireland and California – and to do that we had to mature our approach.

    1. Release branch and release process (vs pulling from main). I know this goes against conventional wisdom, but for a 2 person team with no on-call SRE, I think it’s better to be able to schedule your problems for a convenient time.
    2. Orchestrator + merge queue. The merge queue tends to be stricter, so everything gets 2 code reviews, follow-ups filed, and so on. It also handles sequencing and rebasing – the things I used to burn CI minutes on when I was chaotically working in 5 tabs.
    3. Board hygiene. P0/P1/P2/P3 issues, aligned with the orchestrator + merge queue setup. Everything related to features slated for the next release gets tagged so it gets prioritised.
    4. Devex and optimisations. Ephemeral DB targets, authenticated E2E tests, env var requirements, a full design system, automated nightly DB backups.

    What I find interesting is that these four pieces map onto four different phases of a team maturing.

    1. Overkill. Slightly anal for two people. But the natural progression for a 2 person team no longer wanting to deploy main on every PR.
    2. The AI-native piece. Only necessary because AI exists – also allows Claude to work overnight whilst we are sleeping (and don’t need the tokens for everything else we are doing).
    3. The setup of a well-organised 6+ person team. What keeps the orchestrator (and us!) focused on impact rather than maxing out token and CI spend. Brought in when I realised we could easily ship >50 PRs but no finished headline feature.
    4. A level I used to watch 20+ person teams struggle to reach. Necessary to support the velocity.

    All of this to say that a sensible setup for a 2-person team has shifted dramatically from even a year ago. If the shift is that big for a small team running a small website on top of other activities, it’s going to be even more dramatic for larger teams. The list above is our specifics, but the categories are transferable: even if your process was right sized for your team before, it isn’t – or shouldn’t be – once each person on your team is running a team of agents.

    1. What is your release process? How do you validate, find issues and monitor?
    2. How do your agents run, what guard rails are in place?
    3. How do you maximize value for token spend?
    4. What’s your DevEx setup and how does it need to evolve?

    Lately I’ve been thinking about the AI shift as upending the standard bottlenecks for team scaling. That’s moved me from “we need a new playbook” to “we need to update the existing one with different priorities”. All but one of these are things I’ve done as part of scaling a team in the before times. I just didn’t used to do them all in a week.

    This is why I stay optimistic about developers even as writing code gets automated. You can’t just “AI it”: getting AI to solve problems faster than it creates them takes judgement. Claude helps enormously in moving things forward, but knowing what to prioritise and what it should be doing is a critical input.

    This is the kind of work good managers do – evolving how the work gets done as the team evolves, to keep things moving. So we’ve decided, again, that we “don’t need managers”, at the exact moment there’s more of that work to do than ever… My hot take from years of experience scaling teams and being deeply immersed in AI-dev for the last 8 months or so? We’ll come back to the same conclusion – managers matter 🍿