There’s a lot of conversation right now about “context engineering” for dev work; structuring what you feed an LLM so it can do useful things. It’s fantastic, we use this approach for DRI Your Career – to the point where we moved our course development out of Google Docs and into GitHub.

But – Jean and I are engineers. I can’t ask my non-engineering colleagues at Twill to do that. Hiring, sales outreach, project tracking; these processes live in spreadsheets and email and Notion.

Having seen the power of this framing for engineering, and being slightly horrified learning about some workflows to transfer context, I’ve been building operational pipelines that apply the same idea to non-engineering work, using Notion, Claude, Gmail and Slack. The system pattern is the same whether I’m looking at intern hiring or sales outreach. It’s not complicated, but it is a shift in thinking.

The last time I ran hiring myself with no recruiter, it was a nightmare. Took forever, things fell through cracks, I hated every minute. This time it’s bearable. Sometimes it feels like Claude is my admin; it pulls the database, checks what’s due, drafts the emails. Sometimes it feels like I’m Claude’s admin; downloading a resume attachment because it can’t handle that yet, hitting send on an email that I’ve already rewritten twice.

The system pattern

The core idea is: Notion is the source of truth, not the conversation.

Normally people update the task management after the task. This needs to shift. Every update goes to Notion first. Reviewing the candidate against the rubric I specified gets written to Notion before I see it. When my email is pulled in, there’s a round of updates written – before I get a summary of what actually matters to me.

Some key things:

• Every record has a Next Action. This turns a database into a task list. When Claude scans the database at the start of a session, it can tell you what the next steps are and when they are due.
• A startup prompt transfers context between conversations. The same every time, that recognizes the data as the source of truth and works to the system you’ve designed.
• Use handoff docs to make it multiplayer. Similar to how we use “claude.md” in a repo, the way of working has to be encoded in the same way. This is a killer feature for me – it’s annoying to get humans to change process, it’s easy to get Claude to.
• Claude drafts, humans decide. Claude can search email, read threads, create drafts, write to Notion, and score things against criteria. It can’t send emails or make decisions. The human reviews and sends. Over all, I like the clarity: the repetitive work is automated but the judgment stays with me.
• Iteration is cheap. The Notion-as-source-of-truth pattern was foundational; once that’s in place, changing things is easy. Forgot a column? Need to reformat a field? Need to add comms logging? These are rote, repetitive tasks, that Claude excels at and I plan to never do again. Adjust as you learn. This is particularly important when building workflows for other people – encourage them to adapt it to suit their needs.
• Interop is critical. I’ve used Trello personally for years and never once thought about its integrations. Now the fact that it doesn’t connect to Claude is its biggest missing feature. That’s a personal tool and a minor irritation. For an organization, interop is so foundational I wouldn’t consider adding a tool that lacks it.

I can see why people are saying the enterprise software market is in for trouble. Not because any one AI tool replaces Greenhouse or Salesforce, but because for a lot of workflows, “Claude plus the tools you already have” is pretty good. Add in no procurement process and no extra cost – that’s very compelling.

There’s an idea that agents will replace the humans that use these systems – certainly AI will shift jobs around, but I’m also not convinced that is the right framing. Many startup hires fail because their role isn’t understood, and the same issue is true of an agent – you need to know what you actually want them to do. The danger of AI is that being over-confident and wrong in those kind of roles is a brand and credibility risk.

I’m not anti-agent, I use them for coding. But a lot of the agent conversation feels deliberately incomprehensible to normal people, and like some kind of panacea – which makes sense, I guess, when you’re selling something to do a job. But to get an agent to do something well you need to define what it’s doing well enough; which means understanding it well enough yourself first. For a lot of operational work Claude as glue between the tools you already use seems like a better start. Over time it may turn into an agent definition and run without intervention. Or it may not.

Any conversation about how AI changes work makes me think about scaling. I came from an environment with a lot of specialisation; dedicated recruiters, dedicated EMs, dedicated ops people. Now I’m using AI to compensate for roles I don’t have. Whether that’s recruiter or engineering manager or something else, the pattern is the same. I think this will fundamentally change when and what you hire for – it’s certainly reshaped what I think I need. The challenge for existing organizations will be retrofitting this onto an existing org – which is much harder than building with it from scratch. When you have nothing, the reasonable working thing is a great addition. When you have an existing process, the reasonable working thing is a compromise you may not be willing to make.

There’s a concept in computer science called explore vs. exploit. Exploitation means using what you know to get reliable returns; exploration means trying new things at the cost of those returns. Most algorithms skew too hard toward exploit. Humans have also been known to do this – including me. The known path is comfortable.

My last job, I was deep in exploit mode. I had playbooks. I refined them. I ran them. I wrote them up into a book. But often I worried I wasn’t growing. Part of why I left – and chose the particular shape of what came next – was to return to a place of genuine learning. I had enough concreteness that I could exploit, but also space to explore.

So what does that actually look like? A few things I’ve been in the middle of this season:

Formal learning. I’m currently enrolled in LSE’s MBA Essentials Course. I’ve long felt under-equipped on business fundamentals. Every time I was asked for an opinion on an acquisition, I would panic that I didn’t know how to reason about it. Structured training has been helpful for me to prioritize time for learning – I did the Co-Active coaching training a few years ago, but that was immersive; a few days I could slot in when it made sense. MBA essentials is 8-10 hours a week for 10 weeks and that felt like a different ask entirely – not one I felt up for adding onto a more than full time job without organizational support. Prioritizing it for myself, finally filling in a gap I’ve known about for years, feels good. Some combination of learning and building confidence – I’m not sure how much of which yet – but so far, it’s interesting.

Getting back to the work. As you get up the org chart the job stops being the work and starts being the work that makes the work happen. It’s necessary and done right it’s impactful and I do enjoy it, but I missed the feeling of actually building. For the past few months I’ve been back to the code again, building tools, co-building a course platform – I pushed a fix to production this morning! In a time of huge change, being closer to the work feels important. I want to understand this shift deeply because it will be affecting our whole industry for some time to come.

Deep collaboration. The best periods of my career have always featured a great collaboration. But the higher up you go, the lonelier it gets. Coming back to a real, balanced, give and take collaboration feels like a glass of cold water on a hot day. I love it. We negotiate to our strengths, balance getting stuff done with having fun. I also learn a surprising amount just from being close to another person’s workflow.

Fractional CTO work. This is a different kind of leadership than I’ve done before. In some ways it’s like running a large org – you have to be deliberate about your time because it’s limited. The strategic work (my favourite) is more visible when every decision counts and resources are limited. In other ways it’s very different – more hands-on with the actual infrastructure decisions, closer to an IT function than I’ve ever been (not a strength for me, I’m working on it).

Social media. For me, Twitter was everything in one place – community, self-promotion, ambient industry conversation – not that I had to be so clear about that. It worked so well for me and I missed it for a long time, without doing anything about figuring out how to fill the holes it left. I miss the community most, and I’m slowly trying to find it again. Given everything I’m doing, I need to figure out self promotion that doesn’t give me the ick.

AI workflows. Having space to actually play with this – without the constraints and overhead of an organization – has been revelatory. What works, what doesn’t, where it helps and where it’s just noise. The context matters enormously for perceived impact: if you use AI to do a mid version of someone else’s job inside an org, it’s insulting and will cost you in credibility. If you use it to do a mid version of something you otherwise couldn’t do at all, it gets something done and helps you learn. Jean and I are building a course platform, running cohorts, developing new material… with plenty of other things going on for both of us. We’ve used AI to create efficiency and leverage, to build something we couldn’t otherwise have built, while retaining the time and attention to make sure the pieces that should be human are.

I do really love running bigger teams. But you end up constrained – by org structure, by politics, by the cost of starting anything new, the difficulty of changing direction when you’re already moving, the morale hit of killing something even when it’s the right call. In a time of this much change, the number of people becomes its own constraint; change management could easily be the whole job right now, and not an enjoyable one.

It’s good to be free for a while. A hill-climbing algorithm will always find a peak – but it might not be the highest one. Sometimes you have to go down before you can go higher. I don’t think careers have to go up and to the right, and this season is making that clearer every day.

If everything is changing, you may as well choose the change you want.

I have a problem that I suspect others reading this share: my content is spread across too many places, and I have no coherent picture of what’s actually working.

I post on Mastodon, Bluesky and LinkedIn. I write a weekly blog post. I have two newsletters — one monthly, one “when I leave somewhere.” I have been experimenting with posting videos. I try to regularly share other people’s work when I find something interesting. Each platform has its own analytics, its own quirks, its own definition of “engagement.” None of them talk to each other. My interest in being a social media manager is pretty minimal, I care less about “reach” than impact. But also – I’m in a building phase right now and I need to share and talk about it to get traction.

Eventually it occurred to me that I was asking the wrong question. The question isn’t “how should I social media”; it’s: what would be an effective use of ~10 minutes a week + Claude to materially improve this problem.

The trouble with social media analytics

The data exists. LinkedIn will tell you your impressions. Bluesky will tell you your likes. Buttondown will tell you your open rate. But none of it is useful in isolation, and the mental overhead of checking five dashboards and trying to synthesize them in my head means it basically never happens. I’m busy moving onto the next thing, and the things that actually interest me. I also hate most of the social media advice out there – it feels fake and weird. I don’t want to post videos of myself twice a day. I do want to know, of the things I do do, what works best and what I can learn from it.

What I wanted was a weekly ritual where I could look at everything together and ask: what’s actually landing? What’s not? What should I write about next week?

The bottleneck isn’t Claude’s ability to analyse this – it’s amalgamating the data for Claude in the first place.

One caveat: this assumes you’re already publishing regularly. If you’re starting from scratch, there’s no data to analyse — come back when you’ve got a few months of content out in the world.

What I built

social-brain is a Python CLI that:

1. Pulls data from as many services as possible including: Buffer, Mastodon, Bluesky, Buttondown, Jetpack (WordPress stats), Vercel Analytics and Amazon (for book sales), and Google Search Console.
2. For the unfriendly services — LinkedIn and Substack — it reads a CSV export you drop in a folder.
3. Pulls future posts from relevant services (for me: blog, Buttondown and Buffer) so it won’t suggest things you’ve already done.
4. To improve display and suggestions, there is a dashboard that Claude can reuse (no need to regenerate each time), and specific prompts aimed at concrete advice that builds on your existing content, and your specific goal (configurable).
5. Runs locally, so no sending off all your credentials to yet another service that is also more likely to be rate-limited on some of the undocumented requests or scraping.
6. Produces a prompt that you can put into your friendly Claude tab. This generates the dashboard and a markdown report: what worked, what didn’t, cross-platform patterns, and five content suggestions for next week

The idea is that you start with a larger import (~3 months) to give it something to work with, and then it builds on that over time — collecting weekly snapshots and maintaining a spreadsheet of your history.

I built it with Claude Code. The initial tool took a few hours, then high on the power of vibe coding, I spent about 2 days (amidst other things) turning it into something really cool.

On building with Claude Code

Before I started building, I spent time thinking about the problem and what I actually wanted. I used Claude chat to help me refine my thinking and options to be clear about what I wanted. Then I fed that prompt into Claude Code.

The initial build prompt was maybe 600 words. It produced working collectors for four platforms, graceful error handling (if one collector fails the rest continue), CLI flags, a pre-commit hook that checks you haven’t accidentally staged your API keys, and a README with step-by-step setup instructions including curl commands for getting OAuth tokens.

Then came testing and follow ups. Realizing that I needed time-frame options (a big import then incremental additions). Refining the system prompt. Fixing a miss with the LinkedIn Import. Adding attachment types to posts. Adding Vercel Analytics for a second site (DRI Your Career) and the available data from Amazon for my book. Adding future posts, persistence so the history builds over time, and website data from Google Search Console. The report structure solidified into something consistent: What Worked, What Didn’t, Cross-Platform Patterns, Next Week Suggestions, and a Metrics Summary table.

I picked this to create firstly because I wanted something, but secondly because given the way the industry is shifting, AI-assisted development is a competence I need to build. I think it also illustrates what’s straightforward and what’s not – what I have here is a tool that any other developer can set up quickly, but it’s completely unusable for a normal person. But still – it’s a tool I wouldn’t have bothered to build six months ago.

The ten-minute question

Can I get useful information about my content in under ten minutes a week?

Last week: No.

This week: Yes. LinkedIn export is annoying but quick. The script doesn’t take long. Reading the report – and acting on it! – is the main thing.

The suggestions seem reasonable, and what I like is that they are grounded in what I’m actually sharing – not generic advice. Week one was fine but generic. By week three or four, the suggestions were building on patterns Claude had actually observed across months of data rather than guessing from a single snapshot. Once I’d put everything in and iterated, I got it to put together some social media guidelines for me and save them in memory (so it can refer to them across conversations) based on how I actually post combined with what works – and what doesn’t. Here’s its high level takeaway:

You write like a person who has thought carefully about something and has a view. Not a brand. Not a thought leader. A person. The posts that work are the ones where that’s most obvious — and the ones that don’t are almost always the ones where you slipped into promotion mode.

The through-line in your best content: name the system, then explain why it matters. “Performance reviews are capitalism’s scorecard.” “You can’t be the servant of people you have power over.” “The job description has been sent to dev/null.” These land because they’re not tips — they’re a diagnosis.

The gap between your highest and lowest performers isn’t topic — it’s whether you’re writing as yourself or as someone promoting a thing. The servant leadership post and the Buttondown endorsement are both essentially “here is my view and why it’s correct” and they both land. The course promo posts are the same ideas dressed up as sales and they don’t.

Real talk, but honestly – helpful. It also encouraged me on the personal posts which I’ve been more reticent to do lately. Good job, Social Media Manager Claude. Here’s to owning my opinion more, and continuing to learn how to be more effective.

So what does Claude need to be a useful social media manager? The data, a bit of context about what you’re trying to do, and about ten minutes of your time. The insight quality isn’t magic — it’s just what happens when you actually look at everything in one place, which you weren’t doing before. The history spreadsheet means it gets better the longer you use it – without paying more, or giving more of your data away.

The code is at github.com/catehstn/social-brain if you want to run it yourself. You’ll need to add all the connecting info, but I put checks in to ensure that everything stays local. WordPress was by far the most annoying of the legitimate connections, and Vercel was an absolute pain. But if you run into anything Claude can surely help!

For a long time — especially in software engineering — there was an unspoken promise: if you were smart enough, fast enough, or technical enough, the rest would work itself out.

That promise no longer holds.

I had the chance to talk with Amy Yee on her podcast Wired for Change about what’s changed in tech, and what engineering leadership demands now. We covered a lot of ground — identity, AI, leadership, values, career paths — but it all comes back to one thing: we have to let go of what we thought was normal, and understand reality as it is.

When Did Things Change?

For me, it was when the mass layoffs started. Before that, doing a layoff was a sign of failure. Somehow it rapidly became a normal thing to do – at volume and in an inhumane way.

The underlying shift is that org size went from a status symbol to liability. The base assumption used to be a large enough group of developers would generate value. Post-ZIRP, all kinds of debt got more expensive. Organizational debt included.

On a human level, a social contract was broken. You saw people who had worked at an organisation for a decade or more just have their access cut one day. Now I think there’s a split between people who think they can out-work or outmanoeuvre being dispensable, and people who know that a job is just a job and their career – and life – is something outside of that, that they need to pay attention to.

The Identity Problem

I don’t think demand has evaporated, but it has changed. I think most obviously, in hiring, it’s a buyer’s market and that means longer, more arduous processes and less good candidate experience. Within organisations, fewer perks and promotions.

External validation was always a shaky foundation. Picking a CS degree at 18 was often arbitrary, and building an identity on it was never healthy. What matters now is clarity about how you bring value.

The job was never to write code – the job was to solve problems and move metrics. What problems or metrics are you responsible for? Do you know what impact you’re having on them? Can other people – like your manager, their manager – tell the impact you’re having?

The 80/20 Shift

Scaling yourself is about building systems and instilling judgment – how you continue to deliver things of value as more is available to you. It was always the case that at a certain level code was not the limiting factor. But with AI that’s happening earlier in someone’s career.

If it used to be the case that a good developer was say, 80% throughput, and 20% team multiplier, that calculation has now changed. Let’s say in 2026 it’s 60:40 – the result is that figuring out how to be a multiplier is more important than ever.

Engineers often used to put off that shift until staff level, but now they need to adjust their mindset earlier. It’s less about the code or language – more about systems design. Being good at systems design, being able to critique, give feedback, and set standards are even bigger levers than before. These were multiplier skills that used to be 20% for strong ICs – not everyone. Now 20% is the minimum, 40% is expected – a bigger part of the role and greater drivers of impact.

AI as a Multiplier

I think about AI as a multiplier, and that’s part of the dissonance around it. Competent, self-aware people use it to get more done. Less competent people use it to generate noise — it’s easier than ever to produce something superficially polished but lacking depth. That creates work for the people reviewing it, and undermines credibility.

Worth naming: we’re all competent and incompetent depending on the task. I have a workflow that makes me produce better written content. I use it for frontend development because I know enough to get adequate results. But when I tried to use it for a professional development policy — something I have no expertise in — I could tell the output was bad but couldn’t fix it. At least I knew, and didn’t waste anyone else’s time.

What You Can Control

Developers have less control than we had before, but all the more reason to use the power we do have well. Nowhere is that more true than over our own choices and attitude in the face of change.

We need to expect to earn our keep. In the ZIRP era I think a lot of software devs lived in some world where they expected to make a lot of money in a way that was divorced from the realities of the business. Now you need to know what value you drive to the business and stay focused on that.

Embrace the idea that your career is bigger than your current job. A bad job is hard, but it’s survivable. You can come back from it. Start with the things you can control – it’s more than you think.

Listen to the Full Conversation

Amy and I talked for over an hour — self-management, feedback, privacy and values, what leadership looks like without authority or abundance. You can watch the full episode here or listen on [Spotify | Apple podcasts]

If this resonates with you, you might be interested in:

• The Engineering Leader – the book
• DRI Your Career – the courses Jean and I are building to support ICs and managers navigating the post-ZIRP era

This isn’t a doom-and-gloom conversation. It’s a reframing — about judgment, agency, and what it means to lead when the old assumptions no longer hold.

Earlier this year, Jean and I ran the first cohort of DRI Your Career — a course we’d spent the better part of a year building together. We had high hopes. But the first time you do something — you can believe in it, but you can only really hope. I am so happy with how it went, though. Here are some highlights.

Jean and I agonized and iterated over the format. We both find a lot of professional development exhausting — the live sessions you have to show up for at set times, the group dynamics, the performing-engagement-in-a-Zoom-call energy. As a result, we wanted to build something introvert-friendly and timezone-friendly: async, self-paced, with the depth happening in writing rather than on camera. We weren’t sure how that would land. Turns out it resonated — we had participants from APAC, Europe, and the US, and the engagement with the exercises was great. The submissions were genuinely thoughtful. People showed up more honestly, I think, because they had space to.

What I didn’t expect was how much it would feel like coaching. Reading people’s exercises became my morning ritual. You’d watch someone’s thinking shift in real time — letting go of the things that capitalism had installed within them, or getting that light bulb moment from taking the time to think deeply and express it. We went into this with the idea that we wanted to make the impact of 1:1 coaching available to people at a more accessible price point, and it was so exciting to see that play out.

The ideas in this course are in my personal operating system (and also my book). I believe in them deeply, and strive to practice them. But between building the course and launching it, I left the company where I had spent the past five and a half years to have more time for projects like this one and have taken on a fractional CTO role. The same ideas that helped me stay for so long, and get promoted twice, helped me trust and build a plan around my feeling that it was time to do something else.

This is what I want for everyone. Not “you should quit” and not “you should stay.” Having enough clarity that you can tell the difference. Being at choice — making decisions for yourself and owning them.

The course covers four modules: challenging the default narratives capitalism installs in your career, figuring out what you actually want, making feedback work for you, and understanding what you’re moving towards. We read and comment on every exercise submission.

The next DRI Your Career cohort starts in April. If you’ve been thinking about it, the early bird ends very soon. You can find out more and sign up at driyourcareer.com.

If you’re an engineering manager navigating a post-ZIRP world — fewer resources, higher expectations, less margin for error — we also built the Engineering Manager Survival Guide. The course we wished existed when we became EMs and even more when we started managing them! Same format, different focus. First cohort starts March 13th.

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?

As a manager, maybe you start your day looking at your calendar, or the pings that are already piling up. It can be easy to get caught up in what people are asking of you – but your job needs to look beyond the requests and into the causes underlying them.

Here’s what I think the job of an engineering manager actually is:

You’re a force multiplier for a team, and you take responsibility for that team.

There’s a lot to unpack in that. But here I want to talk about three things:

• The timeframe you live on
• The distinction between a learning opportunity and a fuckup
• The Clarify and Shard

The Three Timeframes

As an EM, you don’t just live on one time horizon. You need to live on multiple, and that needs to change over time. Consider your week – how much time have you spent on the immediate, versus the longer term.

This is clearest when you’re ramping up on a new role. Then it roughly looks like:

This week: What is a problem this week? Get it fixed.

This month: What is a problem this month? Systematize it. Delegate it.

Next quarter, next year: What is a problem next quarter or year? Make a plan.

It’s less clear when you’re in the middle of things. Of course you go back and forth. Of course you pitch in when someone’s sick or there’s an incident. A week when you don’t get to the future is okay. Every week is not. A problem you don’t fully root cause is not the end of the world. But some of them are probably connected, and you’ll never get to those connections if you don’t get to stop and think.

The pull of the urgent is strong, and bluntly handling the urgent makes your immediate value clearer. Your real value, though, that shows up over time.

Learning Opportunities vs. Fuckups

As an EM you need to both develop your team, and hold them accountable. When faced with a person + challenge, you need to understand: what’s a learning opportunity and what’s a fuckup?

A learning opportunity is when your teammate missed something. They didn’t know, they didn’t see it, with the best of intentions they made a call that turned out wrong.

A fuckup is when the risk was called – by you or someone else – and they did it anyway.

Your job as a force multiplier is to increase learning opportunities and reduce fuckups. Learning opportunities are how people grow – they’re the place for the blameless postmortem, the non-judgemental deconstruction, and the process update.

Fuckups are unforced errors that erode trust. They are where you need to be clear on accountability, what’s negotiable – and what is not. Was the process ignored? Was something not clear?

When you’re coaching someone through these situations, say what you believe. Ask the question about what you’re curious about.

Delivery overshot by a week? Learning opportunity. A quarter? That’s a fuckup. And it shouldn’t happen again.

New manager didn’t realize the hire needed specific feedback? Learning opportunity. You told them and they didn’t do it? Fuckup.

Incident from factors no one saw coming? Learning opportunity. Same incident twice because the process wasn’t followed? Fuckup.

The learning opportunity, you can get curious about what can be learned from it.

The fuckup? The question is more direct – how did this happen, and why am I finding this out now?

Clarify and Shard

One of the ways to create learning opportunities is what I call the “clarify and shard”. It’s a leader’s job to navigate ambiguity, and create clarity for their team.

In the ambiguity, you make the ~~vibes~~ concrete. That feeling that the thing is slow, or the initiative is not working, or the process is wrong – you go into it and you come out with a point of view.

That clarity can then be sharded (delegated, not necessarily just to one person). It’s the learning opportunity – with some guard rails that prevent it becoming a fuckup.

What does this look like in practice?

For example: the vibes say you’re no longer confident in the hiring process – that’s the ambiguity. Making it concrete looks like figuring out why that is. What parts of it aren’t working, or aren’t giving signal. Once the outcomes needed are clear, you can delegate.

Another: the vibes say DevEx is slowing the team down. Getting concrete is about digging into what is slower and why, and whether or not that’s a problem. Maybe the change is that you have a PM now and they want to spec things? That’s good. But if they are becoming a bottleneck – that’s not. Now you know what you need to fix.

Bringing it Together

Put these together:

• This week’s problem, fix it – then figure out if it’s a learning opportunity or a fuckup.
• This month’s problem, run the clarify and shard.
• Next quarter or year – make space for the ambiguity. You have some thinking to do.

So when you look at your calendar tomorrow, or that pile of pings – remember you’re not just responding to requests. You’re looking for patterns, building systems, and clearing the path ahead. That’s what makes you a force multiplier.

The hardest part? You won’t see the impact of the third timeframe for months. Your calendar will keep filling up with the urgent. But your job is to protect that thinking time anyway – because that’s where your real value as a leader shows up.

If this was helpful, you might also like The Engineering Manager Survival Guide. An 8 week fully async course, to help you survive – and thrive – as an EM in the post-ZIRP era. Start March 13th. Early bird ends Feb 28th.

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:

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 Talk^TM. 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?

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.

One of the biggest issues I saw running remote teams for the past decade+ was the lack of good engineering manager training. With a global team it’s harder (and more expensive) to get everyone in the same place at one time. With a small team, the cost of doing anything custom is infeasible.

To help new managers I was responsible for be successful, I had a set of options. We’d attend LeadDev as a group – but that happens once or twice a year and not everyone could make it. Many people would take Co-Active Fundamentals training, which is great – but general. I had a roster of coaches I recommended for 1:1, but that budget wasn’t always available.

In the post-ZIRP era, being an engineering manager is harder than ever. When headcount was a vanity metric, managers had value simply as an abstraction layer over a number of people. When things were growing fast, there were opportunities to move up just because someone needed to fill the position.

That era is over.

Now it feels more important than ever to have a clear point of view on how an engineering manager actually creates impact – and how to support yourself while doing it.

What is the EM Survival Guide?

Jean Hsu and I designed The Engineering Manager Survival Guide for managers navigating this new reality. Whether you’re a new manager trying to ramp up, or a more experienced one who knows you’d benefit from devoting some time to consider your approach, this course gives you the frameworks and tools to be effective without burning out.

The course runs over 8 weeks with 4 modules. Each module includes:

• Written content and frameworks
• Audio conversations between Jean and me, with personal stories and reflections
• Exercises to apply what you’ve learned to your specific situation
• Personal feedback from us on your submissions

It’s designed to fit into a busy schedule while still creating space for real reflection and change. Around 60-90 minutes a week, in pieces, as you can fit them in.

Why now?

The expectations for engineering managers have fundamentally shifted. The role used to be about coordination and headcount. Now it’s about tangible impact, strategy, and doing more with less.

If you’re feeling squashed between what your team wants from you and what your boss expects, if you’re wondering how to be effective without burning out, if you want to feel intentional instead of reactive – this course is for you.

It can be hard to make time to step back and learn. We get it, and we’ve designed this course to fit your schedule. Plan to spend a minimum of 60-90 minutes a week, and it’s completely asynchronous, so you can listen to our audio conversations on a walk or in the car, read the module content in between meetings, and do each module’s targeted exercises whenever is best for you.

Enrollment is open now.

Early bird pricing: $799 USD (available until February 28th)

Regular pricing: $899 USD

The course starts March 13th, 2026. Enrollment closes March 10th or when we are at capacity.

Learn more