I called this newsletter what's my job again, because I think that's the job of leadership - it's not fixed, it's a question we must keep asking every day, as we figure out what is most impactful. That name has felt apt this year. Are we all in tech not asking it more often, and more intensely, given everything that's changing?

Finally I feel like I'm converging on some answers. Not just how to be an IC in this new way of working, but how to explain that.

ICs need to step up one level. It might come in as a bug, but it needs to be thought of as a bug class, and then guarded against. Guardrails are what make the whole class less likely. Whenever a problem surfaces, think not just about the problem itself, but about what it indicates about the guardrails that are missing. That's the kind of work you can feed to a mostly autonomous orchestrator.

For managers, we have to find non-human ways to surface problems so we can proactively coach ICs on this thinking. CI data is a rich source - how long PRs spent open, how many times CI needed to run. Code coverage reports tell us where the gaps are. You could set aside a couple of days, go deep, and come out with a point of view. But better to work in a way that checks in on this regularly, finds the bottlenecks, and figures out how to improve them. The most useful source I've found is running CI cost analysis, finding the unnecessary burn, and improving some combination of process and tooling.

The two hardest things as a manager in this time frame were hiring - a separate topic, but AI creates so much noise there - and the problems where I would ask people "can AI help with this?" and sometimes get yes, and sometimes get no, and it was hard to know what was real and what was not. I didn't have the toolkit to move it forward. Now I have more granular questions to ask, which I think is important. "Just AI it" was never a strategy, it was a forcing function, a blunt implement, to find the limits. The person who gets paged when those limits are breached, or the person who has to clean it up when it's wrong, was never going to be on board.

I'm pulling all of this together for a talk I'm giving. I have data - 1,411 PRs shipped at Twill since April, tagged, so I can see how our guardrails have evolved. Checks per PR went from 2 to 22.

Which assumes that what we're doing is working, which is perhaps a big assumption to rest on. But from the same data I also know our hotfixes and our feature velocity. About ten hotfix releases. The real fires were two days at launch - a 500, an SSR crash, and a currency bug that was dollars in one place and cents in another - and then it held. Was it my smoothest launch? It was never going to be, because of the constraints of moving off a no-code platform. But is it trending in the right direction? Yes.

What started as a way to answer "what percentage of output should be guardrails?" turned out not to have a number as an answer. The share going into tests and infrastructure went 12%, 19%, 15%, 21%, 24%. And that undercounts it, because most PRs carry their tests along with the feature. I had a feeling it was around a third - intuition from years of management, which this doesn't validate but does align with. That's part of it, I think. We need to retune to a new frequency, and figure out which of our intuitions are still directionally correct and which are not.

It's much easier to measure progress than state.

The forcing function of needing to write a talk about this is such a gift. I wasn't sure I could piece it all together yet, but then this came up, and I started working with a new coaching client explicitly on being more effective in an AI-native context. It feels like a milestone. A depth of understanding I set out this year to build. Like I could go back to a bigger organisation and set to work retrofitting this way of working, with a bigger toolkit and a more confident point of view.

It's easy to say "just AI it" isn't a strategy. Replacing that with an actual strategy is much harder. Having realised what I already knew, now I have to write it down, and make it clear.

What I've been doing

We launched our first partner course, with Halle Winkler - Breaking Into the Security Mindset. The first cohort starts on the 12th of October.

Application security might seem like a strange fit for a coaching-shaped course. But the point of coaching is to equip people against the things that intimidate them, and security is genuinely intimidating. I had barely accepted that as a CTO I was the IT department when I discovered I was also the security department, fielding questions about SOC compliance. Working with Halle is what convinced me it's learnable. Not rocket science, and not reserved for people who have been hacking since they were 13. As product engineers we've been doing pieces of it all along - we just called them bugs instead of vulns.

There's also a new raccoon.

A friend said something that's been living in my head ever since: "I'm no longer taking competence feedback as relationship feedback."

Separating the person from the work is one of the most underrated skills in leadership. Engineers learn it through code review, and then forget not everyone else has. It's my favourite of the audiograms I've been making while we prep the next cohorts of DRI Your Career and the EM Survival Guide - both open now at driyourcareer.com.

We continue to build on Twill - the post launch clean up, new features. I'm thinking about how we can make recruiters as AI-leveraged as engineers can be - whilst maintaining candidate and hiring manager experience.

I wrote about skills for a more leveraged workflow, and shipped the starter kit that goes with it. I'd been sceptical about publishing workflow skills - but I kept assembling custom starter kits enough that it was the logical next step.

The DIY MBA continues, as planned on marketing - a Coursera course, currently trying to understand what "positioning" actually is. Questioning how much of this is worth knowing up front, and how much you only understand after having a go. Or whether taking a course about marketing is just procrastinating on doing marketing.

Two talks this autumn. Bug Bash Europe on the 30th of September, at goto; Copenhagen - what we can take from managing large teams and apply to making agents reliable and effective. Then swiftCon at next.app devCon in Berlin, 7th to 9th of October - how ICs can be more like Toronto raccoons, useful skills for the current market.

What I've been reading

• Poisonous People by Leanne ten Brinke - a couple of times I've missed nasty tendencies in someone, and as a result missed the opportunity to stop them getting power. Helpful on the concrete things I missed. Though it left me wondering, in one case, how much was situational rather than inherent.
• Quiet quitting, rage quitting and real quitting - quiet quitting is mostly a myth. It takes about ten months, and people work hard the whole way through. Women spend twice as long getting ready to go. And the right time to quit - three to five years in a role is the sweet spot for a step up, ten or more is the worst place to be.
• Cognitive surrender - when we complain about AI slop we blame the machine, but the problem is that someone put their name on it and wasted our time. We all have to figure out how to apportion our limited cognitive energy when the machine's is by definition closer to infinite.
• Choosing a Claude model and effort level in Claude Code - a clear explainer. It validated how I use Fable and made it obvious I'm underutilising Sonnet 5.
• Big cat energy - obsessed with this story about Michelle - the founder I work with - and how she took her pitch cues from her cat, who expects the reverence of a god. She leaned back, asked the investors what questions they had for her, and got her first yes within ten minutes. More big cat energy, ladies.