Birdcar

Just build it twice

Tue, 26 May 2026 00:00:00 GMT

I was reading Hacker News the other day, as one does, and a post titled "Using AI to write better code more slowly" had climbed near the top. I read it, and then I just kinda sat there chewing on it while I worked for the afternoon. Ultimately, I think Nolan has named something I'd been turning over for months without quite being able to articulate.

I've been writing about AI tools for a little while now, With the general tone being somewhere between lightly skeptical and inquisitive. Right now I'm basically of the belief that AI leaves the hard problems exactly as hard as they were before. The easy stuff is inarguably easier, and boilerplate is functionally eliminated, but it isn't the society-ending inflection point everyone keeps fretting about.

What Nolan's post did was clear a path through the part of the question I hadn't worked out.

Before I'm branded a hater or in denial, let me be clear about where I'm standing: I'm enthusiastic about these tools. I use them every day, and I've built things in the last year (including a business) that I would not have started, much less finished, without an agent (or several) at my elbow. I regularly teach, encourage, and recommend the use of these tools at work and as a freelancer

Having said that, I also try very hard to think critically about my tools, which is the only way I know how to keep using anything in good conscience. So when I say the skeptics are wrong, I mean it. They're wrong, full stop. And when I say the hype people aren't quite right, I mean something more particular: they're not sure what they're actually right about. Somewhere between those two positions is a much smaller, much weirder claim, and that's the thing I want to talk about.

Speed? Well.. kinda

The dominant narrative says AI makes engineers 10x faster, 30x faster, sometimes 100x faster, depending on which CEO is in front of a camera that day. The numbers vary, but the gospel is the same. Type a prompt, get code, ship feature, repeat. Whoever ships fastest wins, and the agent is the unlock.

I have been doing this long enough to know that the slow part of building software was never typing. It wasn't typing twenty years ago and it isn't typing now. The slow part is figuring out what to build, why to build it, and how to be confident that what you built actually does the thing you thought it would do. The slow part is the part where you sit with a half-working prototype and realize that the real problem isn't the bug you're hunting, it's that the entire framing of the feature was wrong.

An agent does help with that, kind of. Just not in the way that folks are talking about right now.

As many detractors point out, an agent will gleefully accelerate you into a wall. It will generate thousand-line refactors against ({your, its}) flawed premise with admirable confidence. I think anyone who uses an LLM even casually for development has watched this happen.

This is not new criticism, lots of smart people have said it. You know the agent makes you faster at the parts you were already doing thoughtlessly and confidently incorrect about the parts you needed to slow down on.

So I kept pulling at the thread. If the speed framing is wrong, and the agent doesn't help with the hard parts, what is it doing that's worth my time? Because the honest answer, the one I kept landing on, is that there is something. I think critically about my tools. I would not still be reaching for these every day if I couldn't tell you, plainly and in one sentence, what they are actually doing for me. So let me tell you.

Fail faster, but also more completely

The agent has lowered the cost of building the same thing twice.

That is the entire delta. That's where I'm actually faster. Everything I value about working with these tools collapses into that one sentence.

The slow, painful part of building something is not the typing. It's also not, exactly, the thinking. It's that for many problems, you have absolutely no idea what you're doing. The only way to figure out what you actually want is to build the wrong thing first and use it for a while. You don't know what ergonomics you want from a CLI until you've typed the wrong invocation seventeen times. You don't know what shape your data should have until you've written the query that exposes how badly you got it wrong. You don't know what a feature should feel like until you've shipped a version that feels off, and you can finally put a finger on why.

For most of my career, this was a luxury. Building software was expensive enough in terms of both time and money that "build it twice on purpose" was a catastrophic mistake. The kind of story you tell in your job interview about how you failed one time. In reality, most teams build it once, ship it, suffer with it, and then maybe in eighteen months get the budget for a "v2" that's usually still constrained by the bones of v1. The cost of throwing the first one away was high enough that nobody actually threw the first one away.

What agents have actually made faster and cheaper is being wrong and more importantly learning that you're wrong. They have made me willing to throw a draft in the trash that I would have died defending six years ago. That is a different thing, and it is bigger than it sounds.

You only learn what you want by using the wrong thing

I have a problem I haven't solved before. I don't really know what I want. I have a vibe, a constraint, maybe a half-formed sentence about what "good" looks like. In a previous era I would have done one of two things: stared at a blank file for two days writing pseudocode, or built a careful, deliberate v1 that I would then have been emotionally married to by the time I realized it was the wrong v1. (Technically, the third thing would be "preemptively give up and live with the problem sucking").

Now I do something different. I open up Claude or Codex, dump out everything I'm half-thinking, and let it interview me into a spec. The agent then does something I cannot easily do for myself via "rubber duck" talking or white-boarding, which is fill in the gaps in my own thinking. The places where my thinking was fuzzy, where I would have shrugged and waved a hand and said "we'll figure it out as we go," get filled in. Then the agent builds the thing the spec asks for, and I start trying to use it.

Here, finally, is where the work actually happens. I use the thing the agent built, and within an afternoon I can usually tell you in detail what is wrong with it. The code is ok-to-good. Bugs are absolutely present, and fixing them is often a clarifying experience, but what I usually find out is wrong is the shape. Even with the gaps filled in, I was foundationally incorrect about what I wanted to build, and I could not see that until I had the working thing in front of me to use.

That clarity is impossible without the v0. I cannot predict in advance what will feel off about a system I have not yet used. I don't know that anybody can, reliably. The people who say they can are lying, or they're working on problems they have already solved (or mostly solved) before.

So I throw it out. I go back to to my tools with everything I now know that I didn't know yesterday. I write a new spec that is dramatically sharper than the first one, because the first one taught me what was actually load-bearing. I let the agent build the new thing. Two generations, two days, and I have a foundation I trust enough to stand on. That foundation is not a 10x productivity gain. It's something more valuable: a thing I would not have arrived at any other way.

When in doubt

None of this is a productivity claim. I am not telling you agents will make your work twice as fast.

What I am telling you is this: for the class of problem where you don't yet know what you want, the cost of finding out has dropped enough to matter. By enough that I now build throwaway drafts on purpose, on a Tuesday afternoon, as a standard part of how I work. That's the change. That's the whole pitch.

The framing of "AI = speed" has been making me crazy because it sets up a thing to argue about that isn't the interesting thing. The interesting thing is that we now have a tool that makes the second-draft possible at the level of the individual engineer. We used to need a team of ten and an eighteen-month roadmap to rewrite something. Now I can rewrite it on a Tuesday afternoon, knowing what I know on Tuesday, not what I thought I knew on Monday morning.

So when in doubt: just build it twice.

Your AI wrote a bug

Fri, 17 Apr 2026 00:00:00 GMT

I'd been using Claude Code for about a week when I asked it to scaffold a Laravel authentication module. It generated the routes, the controllers, the middleware, the views. Clean code. Well-structured. Proper separation of concerns. I skimmed it, nodded, ran the tests.

Green across the board. I pushed to staging, opened the browser, typed in credentials, and watched it redirect me to a 500 error. The middleware was checking for a session token that the login controller never set. The tests passed because the test helper bypassed middleware entirely.

I fixed it in ten minutes. But the thing that stuck with me wasn't the bug. It was how convinced I'd been, for about thirty seconds, that the AI had just written a flawless auth system. The code looked right. The tests said it was right. The only thing that caught the problem was actually trying to log in.

I want to tell you this was a one-time thing, that I learned my lesson and it never happened again.

It happened 51 more times.

The story we tell ourselves

There's a narrative around AI coding assistants that goes something like this: developer installs AI tool, developer becomes dramatically more productive, developer ships features at speed no human could match, developer is now a 10x engineer. The AI companies tell this story. The tech press tells this story. The LinkedIn thought leaders love this story.

And it's true, in the same way that saying "a car goes 80 miles per hour" is true. It omits the traffic, the fuel stops, the wrong turns, the flat tire in New Mexico, and the hour you spent in a rest stop parking lot arguing with Google Maps. The destination speed is real. The journey speed is different.

I've been tracking my Claude Code usage for six months now. Buried in those almost four thousand prompts are 52 distinct bug-fix loops. Moments where Claude Code generated something, I accepted it, and then reality intervened. That's roughly one bug for every 75 prompts, or about two per week. Some were trivial. Some cost me hours.

Let me stop telling you the productivity story. Let me tell you the bug story instead.

What actually happens

A bug-fix loop, as I've come to think of it, follows a depressingly predictable pattern.

I ask Claude Code to build something. It builds it. The output looks reasonable. If there are tests, they pass. I move on to the next thing. Then something breaks, or I notice an edge case, or a real user hits a path the tests don't cover. I go back. I read the code Claude Code wrote, often for the first time with real attention. I find the problem. I explain it. Claude Code fixes it. Sometimes it introduces a new problem in the fix. Sometimes the fix is perfect. Sometimes I fix it myself because explaining the issue would take longer than changing two lines.

The 52 loops break down roughly like this: about 20 were genuine logic errors where the generated code did the wrong thing. About 15 were integration failures where the code worked in isolation but broke when connected to real systems, databases, APIs, authentication layers. About 10 were subtle specification mismatches where Claude Code built what I asked for instead of what I meant. The rest were edge cases that nobody would catch without production traffic.

Most loops were logic and integration failures, not edge cases.

None of these are surprising. They're the same bugs humans write. The difference is in the feeling. When I write a bug myself, I have a mental model of the code that includes the bug. I know what I was thinking when I wrote it, so I can reason about where the thinking went wrong. When Claude Code writes a bug, I don't have that mental model. I have to build it retroactively, reading code I didn't write to understand decisions I didn't make. That's closer to debugging a colleague's code than debugging your own, and it requires a different set of skills.

The gap in the mental model

This is the part I keep circling back to.

When you write code by hand, the bugs are yours. You understand them because you built the context they live in. When you direct an AI to write code, the bugs are still yours (you shipped them), but you lack the construction context. You're responsible for code you didn't think through, and the debugging requires you to think through it after the fact. You're held to account for decisions you never made.

In practice, this means AI-assisted development isn't faster in the way people think it is. The generation step is faster, yes. The code appears in seconds. But the verification step expands to fill the time the generation step saved. I don't spend less total time per feature. I spend the time differently: less on writing, more on reading. Less on construction, more on inspection. Less on "does this compile" and more on "does this actually do what I need it to do."

My dozens of scope-expansion follow-ups tell the same story from a different angle. These are prompts where I said "also add X" or "can you also handle Y" after Claude Code delivered something that technically met the spec but missed the fuller picture. The AI did what I asked. I hadn't asked for enough. The cost of underspecification is real, and it compounds, because each "also add" builds on a codebase that was designed without the addition in mind.

What the numbers actually show

If I'm honest about what six months of data tells me, it's this: AI coding assistants make the easy parts trivially easy and leave the hard parts exactly as hard as they were.

Scaffolding a project? Trivial. Generating boilerplate? Instant. Writing tests for well-defined functions? Handled. Converting a Python script to TypeScript? Fifteen minutes, and honestly pretty good. These are the tasks that take time but don't take thought, and the AI eats them for breakfast.

Designing an architecture that will hold up under real usage? Exactly as hard. Catching the integration bug that only manifests when two subsystems interact under load? Harder, actually, because you have less intuition about code you didn't write. Knowing when the generated code is subtly wrong in a way the tests won't catch? That's a skill, and it's a new skill, and nobody's teaching it.

The 10x claim measures the easy parts. "Look how fast I generated this CRUD API!" Yes, you did. The CRUD API was never the bottleneck. The bottleneck was understanding the domain well enough to know which CRUD operations your users actually need, and what happens when two of them run concurrently, and where the validation belongs, and which error messages are helpful versus which ones will generate support tickets.

Those questions didn't get easier. They got more important, because the AI removed all the other reasons to slow down and think.

The skill nobody's measuring

I don't have a clean name for the competency that actually matters here. It's the ability to read AI-generated code critically, to spot the structural weaknesses, the false-positive test suites, the integration gaps, the specification mismatches. Before AI assistants, code review was something you did to other people's work. Now it's something you do to your own, constantly, because the "other person" generated your implementation and you need to verify it.

The developers who are genuinely more productive with AI tools aren't the ones who accept the output. They're the ones who've gotten fast at reading the output, knowing where the seams are, and testing the seams before they ship.

I'm still learning this. Fifty-two bugs in six months means I'm catching about two per week after they've gotten past my initial review. The ones I catch before they land, I don't count. I'm getting better at the before-they-land part, but better is relative, and the bugs are real.

What I'd tell someone starting out

Don't trust green tests. Run the thing. Click the buttons. Hit the endpoints. The tests might be testing the wrong assertion, or bypassing the layer where the bug lives, or passing because the test helper sets up state that production never will.

Don't skip reading the code. The thirty seconds you save by not reading the implementation will cost you two hours when the bug surfaces in staging. AI-generated code is not self-documenting. It's plausible-looking, which is more dangerous.

Expect the iteration. Budget for it. Your first prompt will get you 80% of the way there, and the remaining 20% will take 80% of the time. This is just the Pareto principle wearing a new hat, and it applies to AI-assisted development the same way it applies to everything else.

The AI didn't make you a 10x developer. It made you a developer who generates code at 10x speed and verifies it at 1x speed. The bottleneck moved to you, to your ability to read what was generated and know whether it's right. If that sounds less exciting than the LinkedIn version, it's because it is. It's also true, and true is more useful than exciting when you're staring at a 500 error in staging wondering why the test suite is green.

The tools that build the tools

Fri, 10 Apr 2026 00:00:00 GMT

You install an AI coding assistant. You type a prompt. It writes some code. You fix the parts it got wrong. You type another prompt. This is the loop, and for most people it stays the loop forever. Prompt, generate, fix, repeat.

I did this for about three months. It was useful. I built things faster than I would have alone. I explored codebases I didn't know. I generated documentation nobody else was going to write. The tool was good at its job, and I was good at asking it to do that job, and that was the whole story.

Then in December something shifted, and the story stopped being about a tool and started being about a system.

Thirty-three skills and a problem I didn't know I had

I now have a custom skill ecosystem inside Claude Code. Custom slash commands that trigger multi-step workflows. Custom agents that handle specialized tasks. Custom hooks that enforce rules before and after every tool call. If I type /commit, it doesn't just commit. It runs a semantic analysis of the changes, generates a conventional commit message, validates it against the project's style, runs pre-commit hooks, and only then creates the commit. If I type /new-post, it loads my writing voice profile, selects a narrative framework from a catalog of 25, walks through a structured content pipeline, runs a humanization audit against an AI-slop blacklist, and writes a blog post to the right file path with correct frontmatter.

This sounds like overengineering. It probably is overengineering, depending on who's counting. But the economics changed in a way I didn't anticipate.

What is: life without skills

Before the ecosystem, every session with Claude Code started from zero context. I'd open a project, explain what I was working on, remind it of the conventions, specify the file paths, describe the output format I wanted. Every. Single. Time.

For a customer reply at work, this meant: find the relevant codebase, search for the API endpoint, read the implementation, check the public docs, cross-reference with any recent changes, understand the customer's specific configuration, and then draft a response in the right voice for a developer audience. That's forty minutes of context-building before I write a single sentence.

For a blog post, this meant: explain my writing voice, describe the narrative structure I wanted, list the things I didn't want (no em dashes, no "delve", no thesis-at-the-top), specify the frontmatter format, point to example posts. Every time. The same instructions, rephrased slightly, hoping this time it would stick.

The repetition wasn't Claude Code's fault. It's an LLM. It doesn't remember. But the repetition was my problem, and I was spending 20-30% of my working time on it.

What could be: the first skill

The first skill I built was /customer-reply. It's a workflow that researches across the codebase at work, Slack threads, Zendesk tickets, and public docs, then drafts a response in my voice. I spent maybe three hours building it. It runs in under two minutes now, and the output is good enough that I edit rather than rewrite.

Three hours of investment. Two minutes per use. I send maybe 10-15 customer replies per week. The math is trivially obvious in retrospect, but I didn't think of it as math at the time. I built the skill because I was annoyed by the repetition, not because I'd calculated the ROI.

But after that first skill worked, something clicked. The repetition wasn't just annoying. It was a tax on every session, and the tax was compounding because I was using Claude Code more every week.

What is: the hidden cost of unstructured AI work

This is the part most people don't see. The productivity story around AI coding assistants focuses on the generation: how fast it writes code, how many lines per minute, how it compares to a human. Nobody measures the overhead.

I went back through my history and looked at prompts that were pure setup. Context-setting and convention-reminding prompts that didn't produce any artifact. They were 15-20% of my total prompts in October and November. By January, as I used Claude Code for more complex tasks, the percentage was climbing toward 25%. A quarter of my prompts were about telling the tool how to do its job, not about the job itself.

This is the same pattern I've written about in support organizations. The metric that looks good (prompts per day, tickets per hour) hides the metric that matters (what percentage of effort goes to the actual work versus the machinery around it). The volume goes up, and you feel productive, and the overhead goes up too, and you don't notice because you're busy feeling productive.

What could be: the multiplier nobody's measuring

After /customer-reply, I built /commit, /new-post, /review-pr. Then I started building skills for skills: a skill-forge that generates new skills from brain dumps, a skill-validator that checks quality, a skill-optimizer that improves descriptions for better trigger accuracy. Meta-tools. Tools that build tools.

My skill usage went from 1% of prompts in October to 30% at peak in February. That 30% isn't just "I used a shortcut instead of typing a long prompt." Each skill invocation replaces a sequence of 5-15 prompts that would have included the context-setting, the convention-reminding, the format-specifying overhead. The compression ratio is roughly 10:1 when you account for everything a skill encodes.

The part I didn't anticipate: the overhead didn't just shrink. It moved. Instead of spending 25% of my time telling Claude Code how to do things, I spend maybe 5% of my time maintaining and improving the skills that tell it for me. The maintenance is also more pleasant, because it's a design problem (how do I encode my preferences?) rather than a repetition problem (how do I say the same thing again?).

What is: the obstacle nobody talks about

The obstacle is this: building an AI skill ecosystem requires the same kind of systems thinking that most people using AI assistants don't think they need. You have to notice the patterns in your own work. You have to identify which repetitions are worth encoding and which are one-offs. You have to design abstractions over your own workflows, which means understanding your workflows well enough to see their shape. And then you have to sit down and build something, which is slower than just typing the same prompt again.

Most developers can do this. It's the same skill as refactoring code: spot the duplication, extract the pattern, parameterize the variation. But most developers don't think to apply it to their AI interactions because the AI interaction feels like a conversation, not a system. You don't refactor a conversation.

Except you can. And when you do, the conversation stops being a conversation and starts being an interface, a programmable surface that you shape to match how you actually work.

The flywheel

The reason this compounds isn't just time savings. It's that each skill I build teaches Claude Code more about how I work, which makes the next skill easier to build, which means I build more skills, which means Claude Code knows more about how I work. The context I used to provide manually is now encoded permanently. The conventions I used to repeat are now enforced automatically. The workflows I used to manage in my head are now executable.

In February, I built a blog post from brain dump to finished draft in 45 minutes. Not because Claude Code is fast at writing. Because the skill encoded my voice, my narrative preferences, my formatting rules, my quality checks, and my file structure. I wasn't directing a generative model. I was running a pipeline that happened to use a generative model as one of its components.

That's the shift. You go from using an AI tool to building a system that uses an AI tool. The tool gets better because you made it better, not because the model improved. The next model improvement will compound on top of what you've already built, rather than starting from scratch.

I don't think most people using AI coding assistants will build a 33-skill ecosystem. I don't think they need to. But I think the gap between "I use Claude Code" and "I've built workflows on Claude Code" is going to be the gap that separates productive AI-assisted developers from the rest. Not prompt engineering. Not model selection. Whether you're using the tool, or whether you've made the tool yours.

Six months of talking to a machine

Fri, 03 Apr 2026 00:00:00 GMT

I keep a file called history.jsonl on my laptop. I didn't put it there. Claude Code did, logging every prompt I've sent since October. The other day I counted the lines: 3,976. Six months, almost four thousand requests, across a dozen projects and at least five programming languages. That's roughly 23 prompts per day if you average it, though averages lie, and I should know better than to trust them.

Monthly prompt count, October through March.

I wasn't looking for this file. I was looking for something else entirely, the way you find an old journal in a drawer when you're hunting for a screwdriver. But once I started reading, I couldn't stop. Not because the prompts were interesting on their own. Most of them are mundane. But the shape of them, the way they change from October to March, told a story I hadn't noticed while I was living it.

The long-message era

My first prompts average almost 300 characters. That's roughly two solid sentences, sometimes three. They're polite, contextual, and careful. "Given the database schema located in './packages/api/db/data/schema.sql', generate a mermaidjs diagram explaining the database entity structure and all relationships." I'm specifying file paths. I'm explaining what I want and why. I'm framing the task before delegating it.

Reading them now, they sound like emails to a new contractor. Here's the work, here's where to find things, here's what I need back. There's a formality to it, a hedging, that I recognize from every first week at a new job. You over-explain because you haven't calibrated trust yet. You don't know what the other party knows, so you fill the gaps preemptively.

October and November were almost entirely exploration. "Tell me about the service in this directory." "Explain how it gets configured for an end user." I was mapping territory, using Claude Code the way I'd use a senior engineer who happened to have read every file in the codebase. The questions were genuine. The answers were useful. But I was doing the thing people do when they get a new tool: I was testing it, not trusting it.

Something shifts in December

Thirty-three prompts in October. Six in November. Then almost 200 in December and nearly 900 in January. The volume change is dramatic, but the character of the prompts shifts in a way the numbers don't capture. My December prompts start telling Claude Code to build things. Not explain, not describe, not diagram. Build. "Create a plugin that does X." "Generate tests for Y." "Scaffold this project."

I don't remember making a conscious decision to change how I worked. That's what interests me about reading the history. The shift happened gradually, prompt by prompt, as I accumulated evidence that the tool could carry more weight. There wasn't a moment where I thought "okay, I trust this now." There was just a slow erosion of the hedging. I stopped specifying file paths for things it already knew about. I stopped explaining context it could infer. I started writing prompts that assumed a shared understanding we'd built over weeks.

By January I'm building a plugin ecosystem. Custom skills, custom commands, custom hooks. I'm not asking Claude Code to help me do my work. I'm asking it to help me build tools that change how I do my work. That's a different relationship entirely.

Trust encodes as brevity

By March my average prompt is about 150 characters. Half the length of October. A third of my prompts are under 50 characters. "fix the tests." "use the commit skill." "check types." Some of them are just slash commands, five characters invoking a workflow I spent hours designing in January.

The popular narrative is that prompt engineering is a skill you learn, a set of techniques you apply, a craft you refine. And maybe it is, for people using ChatGPT for one-off questions. But in a sustained working relationship with a coding assistant, what actually happens is closer to what happens with any colleague: you develop shared context, and the shared context makes the communication shorter.

I started writing paragraph-length messages to a stranger. I ended sending five-word commands to a collaborator. The compression isn't laziness. It's trust.

The work migrates

Something happened that I didn't expect, and I'm still working through what it means.

In October I was using Claude Code to understand code. In March I was using it to build tools that build tools. The ratio of "explain this to me" to "build this for me" inverted completely. But the skills I'm exercising as a developer haven't atrophied. If anything, they've shifted upward. I spend less time writing boilerplate and more time thinking about system design. Less time debugging syntax and more time debugging architecture.

The work doesn't disappear. It migrates. I used to spend an hour writing a test suite. Now I spend that hour deciding what the test suite needs to prove. I used to spend a morning scaffolding a project. Now I spend that morning designing the project's constraints.

I notice this most in the burst projects. I built a full-stack salary negotiation tool in two and a half days. A working fine-grained authorization demo with role hierarchies, resource policies, and a live permissions playground in two days. These aren't prototypes or proof-of-concepts. They're applications with real data models, real auth flows, real UI. The prompt counts (about 150 and 100, respectively) just show the scale of the conversation, not the thing that mattered. What mattered was that I was thinking at the architectural level the entire time, deciding what the app needed to be rather than wrestling with how to make it work. I'm not faster because Claude Code types for me. I'm faster because I can hold the whole system in my head and direct its construction without the cognitive interruption of implementation details.

What I'm not sure about

I want to be honest about the parts I haven't figured out.

I worry about the exploration I'm not doing. When I wrote code by hand, I stumbled into things. I'd be implementing a feature and notice an edge case, or discover a library function I didn't know existed, or realize the data model was wrong in a way that only became visible when I tried to wire things up. Some of my best architectural insights came from the friction of implementation. When you delegate the friction, do you lose the insights?

I don't know. The history file is full of bug-fix loops, moments where Claude Code did the thing wrong and I had to dig in and course-correct. Those moments are still learning moments. But they're reactive, not exploratory. I'm finding bugs, not finding ideas.

There's also the language question. I've written meaningful code in Laravel, Next.js, Python, and Rust over these six months. That's a breadth I wouldn't have attempted without an AI assistant. But the depth is different. I can direct a Rust implementation. I can read one. Can I think in Rust? I'm not sure I can, and I'm not sure this tool is teaching me to. It's teaching me to think about Rust, which is useful but isn't the same thing.

What the history file actually shows

Counting lines in a file is a productivity story, and on the surface this is one. Four thousand prompts, a dozen projects, measurable compression in communication overhead. The numbers are real.

But that's not what the history file actually shows. What it shows is a relationship forming. The gradual accumulation of shared context. The slow calibration of trust. The shift from formal requests to shorthand. The evolution from "help me understand this" to "help me build this" to "you know what to do." These are the same patterns you see in any productive working relationship. The medium is different. The dynamics are not.

I think about this when people ask me whether AI coding tools are worth adopting. The question assumes the value is in the output, the code produced, the tasks completed. And the output is real. But the more interesting thing is what happens to you over six months of sustained collaboration. How you think changes. What you spend your attention on changes. The boundary between your ideas and your implementation dissolves in a way that is genuinely new, at least to me, in twenty years of writing software.

I don't know what the next six months look like. My March prompts are already so compressed that there's not much room left to shorten them. The skill ecosystem I've built is sophisticated enough that I'm maintaining it more than extending it. Maybe the next phase is something I can't predict from the current trajectory, the way October-me couldn't have predicted the plugin ecosystem of January.

I'll keep counting the lines, though. The file keeps growing, and the shape of it keeps telling me things I didn't know I was learning.

The other side of empathy

Wed, 25 Sep 2024 00:00:00 GMT

I'm not going to tell you empathy is bad.

I want to be clear about that up front because I know what it looks like when a white dude in tech gets up and starts poking at empathy. You're expecting me to recommend Radical Candor or The Hard Thing About Hard Things or one of the other books recommended by people who want to wrap their assholery in a veneer of "tough love" or "misunderstood genius." I am not that guy. I do not think "all these feelings" have ruined the workplace. I'm aware that there are power dynamics at play, almost all of which have been designed to benefit me rather than limit me.

I promise: I am not saying "screw empathy, everyone should toughen up and be jaded like me."

But.

But but but.

I think we need to talk about empathy. Specifically, I want to talk about the other side of it. The costs we sweep under the rug while we grin and bear the emotional labor of being an organization's nervous system.

The neurodivergent pastime of googling "Am I a sociopath?"

Too real? Am I alone there?

I had a really hard time in my early career. I found myself repeatedly running into confusing situations where I was unable to understand what was being asked of me. I really, deeply cared about fixing things for customers. I wanted them to enjoy and be excited about whatever product I was working on, whatever new feature I thought was cool. I wanted to help them get the most out of it. And I was good at it.

But I found myself regularly annoyed at people who, in retrospect, were just having feelings I hadn't been allowed to have growing up. The hypo-sensitivity (and in some cases insensitivity and resentment) I'd been gifted meant that it was genuinely hard for me to understand how emotions came into play for customers, co-workers, bosses, or even myself.

Over and over again I'd get feedback like: "You're killing it! You're thorough, good at explaining things, clearly passionate, easy to listen to... could you be nicer when you talk to customers? I think you need to focus on empathy."

For the record, they were right. I absolutely needed to work on that. But it left this constant question rattling around in my head:

Why do I feel like some kind of exception? Why does it seem like everyone here just naturally feels things for customers, sees that as a core piece of being good at this work, and I don't?

I started to heal a bit. Let go of the resentment, anger, and criticism I was holding onto. Started to connect with people and get even better at my job, to say nothing of my actual relationships. The imposter feelings started to subside. They were replaced by a new thought I couldn't stop chewing on:

Why does it feel like everyone is so deeply exhausted?

We're all trying to find the guy that burnt us out

In trying to answer that question, I've discovered a curious thing: support people, more than most, seem to be angry. At everything. Angry at our tools. Angry at our leadership. Angry at the industry. Angry at the decisions our team is making. Angry at the decisions other teams are making. Angry at each other. Angry at nothing in particular.

And yet, I've found that support people are the least likely to know that what they're feeling is anger.

We're not really allowed to be angry. Some of us might have never been allowed to be angry, even in our personal lives. We're professional empaths. We've built our entire identity on caring really hard about our customers, about the products we support, and about the people we work with. We hire for it, evaluate it constantly, and use "empathy" as a kind of thought-terminating cliche to correct others or ourselves if we ever let the mask slip too far.

The problem is that when anger doesn't have a place to go, when it's pushed down or ignored, it shows up as exhaustion. Deep, crushing, unbelievable exhaustion and hurt.

Think about whether any of these resonate:

You're deeply, deeply tired, in a way that sleep doesn't fix.
You've felt personally victimized by a seemingly innocuous decision at work.
You fantasize about certain coworkers or leaders realizing they were wrong about some decision and apologizing earnestly.
You've been emotionally hijacked, unable to let things go even when you've already voiced your position and been outvoted.
You've found it hard to let go of those arguments even after you've left the company where you were having them.
You swing wildly between feeling numb and feeling overwhelmed.

Everything I've just described are textbook symptoms of empathy burnout, and we've got it bad. Not just as individuals, but as a community and career path.

We've told people they need to be empathetic, but we've given very little support or clarity on how to manage empathy sustainably. We spend almost no time acknowledging how power imbalances and bad-faith actors affect and complicate our centering of empathy.

In over a decade in this space, I've heard no serious discussion of when apathy, distance, boundaries, anger, or other "negatively" coded emotions should be allowed or even encouraged. We implicitly discourage considering those emotions as valid or useful in our work.

We've built our identities, our teams, and in some cases our professional morality on being endlessly empathetic caretakers. And when we find ourselves collectively destroyed by that approach, we find fresh people to take on the role.

"How are you so calm right now?"

So what do we do? We can't keep exhausting ourselves, but we also can't stop caring. Empathy is important to our work. But it's draining us. What do we actually change?

I'm not going to pretend to have all the answers. But over years spent both finding my own niche in this profession and learning from some truly gifted leaders and colleagues, I've arrived at three questions I think are worth using as a starting point.

Who's your focus?

The first thing we do is stop pretending we can focus our empathy indiscriminately on everyone. It's not that you shouldn't be empathetic with everyone at a human level in your day-to-day interactions. It's that the focus of your caring, your empathetic effort, is going to be limited because you're a human. To be effective as a person and an organization for the long haul, you need a shared way of triaging your emotional labor.

One thing I've observed over the years: when you start out, the focus of your empathy is easy. It's the customer in front of you. As you grow in your career, no one comes by to say "your empathy is more effective in this other place now." By default you keep focusing it on "customers," but you kind of implicitly change who "customer" means to be "wherever your work queue comes from."

If you're in ops, it's easy to squint and begin seeing the engineering team as your customers. If you're in management, it's easy to see leadership as your customers. The dynamic this creates is that support cares about everyone else, but that energy, focus, and empathy is never returned. And much like a single parent who finally snaps when a child doesn't refill the ice cube tray, we find ourselves exhausted and resentful.

So write it down. Role by role:

In the queue? Your empathy focuses on the customer.
Working ops? Your empathy focuses on the support people working the queue.
In management? Your empathy focuses on your team.
Senior leadership? Your empathy focuses on your org.

Ask yourself: "Who is the primary group I'm supposed to focus on?" Once you've got that, start filtering the stuff you're doing by whether it's for them. Start figuring out how to stop doing the stuff that isn't.

Who should you be fighting?

Ok, maybe "fight" scares some people. Let's say: who's outside of your area of concern? Who do you advocate to on behalf of your focus group?

We talk endlessly about empathy, but apathy is just as much a skill and a tool. We need it to be effective.

Right now, in burnout, your apathy is probably uncontrolled. You feel it because your nervous system is shutting down, and that means sometimes it's directed at people or problems who actually need your focus.

After you've written down who your focus is, write down the teams you work closely with who are not your focus. Do it for yourself. Do it role by role in your organization. Create specific exclusions where you get to not care.

In the queue: you advocate to anyone and everyone for the customer, and don't care about the noise.
In ops: you advocate to engineering and product for the queue workers.
In management: you advocate to other managers and senior leaders for your team.
In senior leadership: you advocate to the rest of the leadership team on behalf of Support.

Who are you missing?

Those first two questions are things you can do right now, personally and with your teams. But the final thing we have to consider: do we have the right people to actually execute on this?

A side effect of our over-indexing on empathy is that we're pretty conflict-averse as a crowd. We're bent heavily towards "fawn" in our stress and trauma responses, and that means we're not great at direct advocacy. I'd argue that part of the problem with the first two questions isn't that we don't know who we should be focusing on or fighting for. It's that we're not great at doing it. We expect the rest of the org to be as empathetic as we are, and we're not great at pushing back when they're not.

The final thing you need to do is ask yourself: do I have the right people to do this? If the answer is no, start looking at your hiring pipeline and focus on people who are a little more comfortable with conflict and advocacy. I'm not saying hire callous assholes. I'm saying that as a profession we need to swing the pendulum back towards a balance of dispositions, not just empaths.

Get angry

I don't think anything I've said here is groundbreaking. Most of you have probably heard some version of this before, almost certainly from someone smarter. Some of you are actually extremely good at this, and your existence in this space helped me find my own place and figure all of it out.

But let's be honest: we're already burnt out and it's 2024. Some of us have been laid off multiple times. Some of us spent months looking for work. We're scared, we're tired, and the urge to fawn or keep our heads down and keep our jobs by not bothering anyone is strong.

I get it. But I also know we can't keep going like this. We can't keep burning out and then replacing ourselves with fresh people who will burn out in turn. We can't keep pretending that empathy is the only tool in our toolbox, or that it can be used indiscriminately.

We need to do something productive with this anger before it consumes us.

So get angry. Let it out. Fight for yourself, for your team, for support as a profession. Get mad as hell and refuse to take it anymore, then hire reinforcements who can give you the data and tools to do that well.

Your metrics are bullshit

Wed, 01 May 2024 00:00:00 GMT

The companies in this story are not real, but you've worked there. The people in this story are not real, but you know them.

Welcome to the doom cycle

You're in support at Big Tech Company. You got this job after leaving Starbucks five years ago, worked your way up to senior support employee, and you're frustrated. Your leaders just told your team there was no new headcount for this year although you've lost some key folks and followed that up by increasing weekly ticket quotas by five. When you complain, you're told to "do more with less."

You love the product and enjoy your team, but this is intolerable. You start interviewing.

An authentication startup that just graduated Y-Combinator, closed its first round of funding, and is making its first "real" support hire looks promising. You get the gig; it's stressful in the way startups are, but you feel impactful. You're eight equals working on a product you all believe in. When you talk about customer needs, everyone listens. When there's debate over a particular solution, you don't always win, but you feel heard. You build a small team, collecting folks from the diaspora of talent scattered by the company you left, finding new folks who impress you. You're a team of five or six Support folks doing incredible work. The camaraderie is palpable. You communicate well, you solve problems as a unit. You are experts. You accomplish more as a six-person team than the 20-person team at your previous gig. Success!

But the gears of the doom cycle are creaking to life.

Like many catastrophes, it comes in the guise of good news: a $100M A-round! The Engineering and Product teams explode. The user base explodes. And, predictably, so does your support queue. Your response times -- one of the only things you're measuring -- slip a little, but your team rallies. You know it can't hold, but are cautiously optimistic.

The queue continues to explode.

You ask for headcount and your founders, aloof and stressed, tell you to hire whoever you need. Your team balloons to 50, and response times drop. You promote a bunch of your first hires. Many are first-time managers; they're nervous and inexperienced, but want to do a good job.

The queue continues to explode

Your new folks are struggling to learn and keep up. The glowing online reviews about your company's support turn nasty. Sales wants to guarantee enterprise customers four-hour resolutions.

The queue continues to explode.

The founders drag you into a meeting; they're seeing complaints everywhere and they don't understand. They want ambitious goals and marked improvement. They don't say "or else," but you hear it. So you and your managers set the performance metrics you used at your last job: Support Professionals will spend six-ish hours a day in the queue, and two-ish hours on the project work that needs doing in a still-growing organization.

Slack goes silent as people live in DMs, keeping their heads down. Your managers are frustrated, the numbers still aren't looking good. Product updates ship and no one tells Support. Your docs are out of date. Your backlog is in the hundreds and growing. You fire some folks who aren't meeting their ticket quotas, a first for you.

The numbers stabilize, but it's still not great. Everyone is frustrated. Everyone is angry. Your first hire leaves, taking a job at a new AI startup as their first support hire.

As things improve a little, you move a couple of people to focus on docs. You raise the weekly ticket quota by five. Your managers tell you that your team works overtime to keep their numbers looking good. They ask for more headcount.

You tell them they need to "do more with less."

There are rules, but we consistently break them

Was that uncomfortable? A little close to home? I used to think this was how growth works. To get around it, I avoided any company I thought was at the end of the cycle.

But the doom cycle isn't inevitable: it's a known result of misusing metrics.

There are known and pernicious effects that come from misunderstanding numbers, especially when those numbers measure human effort and determine someone's continued employment or salary. They've been studied for decades across professions, cultures, and economies. There are rules that, when you break them, damage your team and turn people against each other.

The ways we measure and motivate Support Professionals violate almost all of these rules.

Goodhart's Law

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.

-- Charles Goodhart (1975. Problems of Monetary Management: The U.K. Experience)

Or more simply:

When a measure becomes a target, it ceases to be a good measure.

-- Marilyn Strathern (1997. Improving ratings': audit in the British university system)

We often approach support with the false assumption that all customers are broadly the same, so their support expectations are the same. Economics has this flawed idea of a "Homo Economicus," a universal stand-in for a person who always acts to maximize their self-interest. This person doesn't exist, and neither does "Homo Customericus."

Based on this false belief, we invent "industry standard" benchmarks and expectations that apply to every support team and customer experience, and then use them to set targets for and measure the success of individual Support Professionals. We measure how many tickets a person answers -- something customers don't know or care about -- as a proxy for their support experience. We measure average handle times, something users don't care about and which is highly variable. We obsess over finding "magic" single numbers that tell us if our support is good or if a Support Professional is good.

Goodhart's law says that when we do that -- when we take some benign observation of how a human-centered system operates and make a specific value of that measurement a target or a goal -- we destroy the usefulness of the observation.

Campbell's Law

The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor.

-- Donald T. Campbell (1979. Assessing the impact of planned social change)

When a number determines whether you keep your job, you'll do anything -- including cheat -- to improve it.

Support leaders focus a lot on Customer Satisfaction (CSAT) ratings. Almost no one really knows what their company's real CSAT rating is. Senior leaders get measured by whether that number goes up or down. Cherry-picking ensures it goes in the right direction:

"Oh, don't send the satisfaction survey to anyone who's gotten a refund."

"Make sure we don't send a survey to anyone from that company, they hate us."

Your ICs cherry-pick to reach their ticket quota. You do it to keep your CSAT up, and it's a rational strategy for inflating a number that's (1) not entirely within your control and (2) arbitrarily used to punish you. You know that the CSAT number doesn't tell the whole story and absolutely isn't within Support's control, so you find ways to minimize the damage. That's cheating. That's data corruption. Ultimately, this corruption pressure hurts both your Support organization and your customers.

Surrogation

The tendency for managers to lose sight of the strategic construct(s) the measures are intended to represent, and subsequently act as though the measures are the constructs.

-- Willie Choi; Gary Hecht; William B. Tayler (2013. Strategy Selection, Surrogation, and Strategic Performance Measurement Systems)

[A] manager charged with 'delighting the customer' who uses customer satisfaction surveys to gauge strategic success may begin to see maximizing survey results as the strategy, and behave accordingly.

-- Willie Choi; Gary Hecht; William B. Tayler (2011. Lost in Translation: The Effects of Incentive Compensation on Strategy Surrogation)

Surrogation equates "Well, the number went up" with "fulfilling our mandate to empathize with and serve customers." We're incentivized to take measures that keep the number up even though they go against our goal of improving customer satisfaction, because we've decided that a good number is customer satisfaction. It's the final boss of the Support game, and it's why we don't question the obvious corruption of our measurements when we should: the measurement itself has become the goal.

How many Support teams have a CSAT rating above 80% but don't tell their company leadership what their customers say about their product on Reddit? We've mistaken our ability to improve that number (the measure) with our customer's actual satisfaction (the actual goal that measure is intended to represent).

We're tired, we're angry, we've seen our organizations decimated for not meeting arbitrary goals written by people who don't understand our work. There has to be a better way.

Service agreements that serve us

I think most of us have heard of an SLA before -- a Service Level Agreement. SLAs are the last piece of a three-piece puzzle. Changing our approaches to all three levels has the potential to transform your Support org and your customer experience.

First come Service Level Indicators (SLIs). Service Level Indicators are the raw numbers that describe how your system is performing. Most Support metrics are SLIs. Second, you have Service Level Objectives (SLOs). This is your "target": a number -- preferably a range -- for a service that is measured by an SLI. If you have an SLI that shows your team is consistently and collectively responding to tickets in eight hours on average, your SLO will say that your 75th percentile response time is eight hours.

Third -- always last and with the involvement of the sales, engineering, and legal teams -- you have SLAs or Service Level Agreements. These are an explicit contract with your users that includes the consequences for missing certain SLOs.

You can define all three in ways that avoid the doom spiral and incentivize team effectiveness.

Start with objectives - human-centered objectives

To design a system for measuring and understanding your service level, start with your objectives. Actively avoid starting with what you can measure; this road leads straight to surrogation land. Start with objectives, based on your users' realities and core needs.

I once did Support for a developer-focused platform. If we had chosen phone support as our main channel, most of our users would have revolted. They want email, and the emails they appreciate are, quite frankly, terse. They want to tell you about an issue, and then they don't want to hear anything at all until the thing is fixed. Many were happy as hell with a simple "heard" or "fixed, thanks."

What we defined as "good" support was hyper-specific to our users. Your customers are yours. Think about them, not about standards or industry trends. How do they want to be talked to? What are their expectations for response times? What channels do they care about, and how much do they care about those channels? (And if you don't know the answers, you have an easy fix: ask your customers.)

How do you define specific, useful objectives? Start here:

Keep it concrete. Don't say "we want every user to feel whole in their soul after contacting us." How would you ever really know? Instead, get specific: "90% of users who write to support for a non-blocking issue should get a response in no more than eight hours." You know what your non-blocking issues are; you can keep a list (ideally publicly, so your users know what to expect from you.)
Avoid absolutes. Notice how precise that example was? That's on purpose. It's tempting to provide absolutes like "everyone gets a response in four hours," but all systems have limits. Your Support team members are not a bunch of interchangeable cogs with the same skills, gifts, and speed. Avoid absolutes to create space for your diverse employees and users.
Don't have too many. You want concrete objectives in that you want to focus on specific things your users care about, but you also want as few of those objectives as possible. Two or three is a good place to start.
Embrace imperfection. You will not get this right the first time. Adjust objectives up or down, or scrap them and start over as you learn more. Last year's numbers mean nothing if your user base grew by 25% this year! Don't aim for perfect, aim for progress.
Build in buffers. Your goal isn't a set of objectives that you have to work overtime to keep. Your goal is an error budget.If you know you can respond to everyone in eight hours, set your SLO as the third quartile of requests in that time. That gives you a buffer to experiment with ways of preventing tomorrow's tickets rather than struggling through today's and constantly straining as you grow.

Make metrics with meaning

You have some objectives now, and now you need to figure out how to know if you've met them. This is where you start thinking about SLIs and metrics.

Track fewer, more meaningful indicators. An objective can have multiple measurements associated with it, but I'm going to humbly suggest that you start associating objectives with specific measurements. And wherever possible, those measures should not be proxies for what you're trying to achieve. In other words, if you take the example of "the third quartile of conversations get a response from Support in eight hours", that has a direct measurement you can use: How long it takes for your team to respond to conversations. This isn't always possible, but it's important that your team can see how they're directly affecting things together and begin thinking as a team.
Use distributions, not averages. Averages are neat and clean, but their abstraction hides important nuance. If Jeff Bezos walks into a room of 100 people and we take an average, they're all billionaires. If we used that average to decide, "Everyone has to give 10 million dollars to charity every day until they die," is that doable? Did the average help you make a smart decision? Or did it lie to you and make things worse? What you want are distributions. "99.9% of people in this room have a net worth of $80k, and 0.01% have a net worth $161b" Distributions group data, show you outliers, and give you more information. Whenever possible, use distributions and avoid averages.
Resist corruption. Nothing changes if you cherry-pick these numbers. You have to count everything; it's the only way you'll know the truth. This should be a less scary proposition now that you're using SLOs and SLIs that describe and measure distributions. Those difficult customers whose CSAT scores you don't want to see? They'll fall into that top 1%, and you've built a buffer for that.

Lose your misleading leaderboards

Apple used to tell Genius Bar employees that if they wanted to, it could replace the entire Genius Bar with a vending machine that spits out replacement devices and reads the warranty off the device. It doesn't, because it's not just paying Geniuses to fix iPhones -— it's paying them to fix the relationship that the customer has with Apple.

Your customers aren't reacting to their experience with the wait time or the individual Support Professional they're talking to. They're reacting to their relationship with your product and your company being broken. They don't care how many tickets each person is answering, or even what your total headcount is. They just want help.

As a Support leader, it's tempting to lose that perspective by obsessing over each individual Support Professional's response numbers, but this is another form of surrogation. It leads you away from all of the levers that could improve your objectives and enable you to help folks and towards the belief that making everyone's response numbers roughly the same is the same thing. This keeps you from recognizing when the most impactful work is work that can't be measured directly.

With that in mind, you should:

Hide individualized data. The only people who should be seeing individualized data are the individual employee and their direct manager. That's it. If you're not the person who the data is about and you are not the one managing that person, you should only be seeing team-level distribution data about the system. You do not have enough context to make judgments about individualized data. Hiding that data will bring teamwork back to your organization.
Prioritize celebrating team success over individual achievement. Your objectives are set at the team level because that's how customers experience your support. So celebrate the team working together to solve a problem: One person answered 400 tickets in a day because someone else hopped out of the queue to do crisis communication and a third person was writing user-facing docs to stop the deluge of tickets. Celebrate them all for communicating and working together to solve the problem and meet the team's objectives. And not just in the moment — remember how they worked together when performance review season comes around.
Focus on team-based, differentiated solutions. Now that objectives aren't individualized and it's not terrifying or career-ending to leave the queue and solve root issues, you have an incentive to work as a team to hit your objectives and maintain your service level. Some people are going to love answering tickets and hate being a liaison to product. Other folks are going to have a knack for writing docs that keep users from opening tickets at all. Let people be good at different things. Focus on hiring, compensating, and enabling team players with differentiated skills.

Breaking the cycle

Nothing I've written here is that radical in practice, but it is a departure from the "best practices" and received wisdom we've been relying on for decades. This is a call to center the Support Professionals, the customers they support, and our end goal of providing the best possible support. The doom cycle is avoidable, but avoiding it takes effort, intention, and care.

At the beginning of the cycle, we're in the queue all day. We're painfully aware of the flaws with this system of individualized objectives. It keeps us from proactively helping customers and doing our best work. When we become leaders, however, we fall back to the systems we know, believing that we can tweak and tame it to produce a different outcome.

The problem is that the system spends all its time measuring a tiny picture of the effort of your individual employees. We have convinced ourselves that this measurement is a perfect surrogate for the objectives and business outcomes that we're trying to achieve, but as we've seen above, that surrogacy leads us away from true understanding.

True understanding is difficult to achieve. It requires us to think deeply about our customers, businesses, and goals. There are few standard metrics or formulas that can help us, and it's possible we aren't currently tracking the information we need. But we can't sidestep that work by focusing on the data that's easy to measure, like how many conversations each person answers in a day. That measurement doesn't actually tell us anything useful about the work of our team.

Your Support Professionals know what they're doing. They know what's wrong with the product, your Support Level, and the customer experience. They know the big-picture fixes that would provide relief if they just had the time to focus on anything other than the constantly ticking clock. They want to do good work, they want to see their business succeed, and they want customers to have a good experience from the moment they begin using your product or service. Listen to them. Trust them.

If you take nothing else from this, I want it to be that Support work is done by teams of people -- not a collection of individual queue crushers -- and it takes diverse skills, dispositions, focuses, and areas of expertise to do well. Make sure that the way you measure the work reflects that.

Yetto values: Joy Matters

Wed, 24 Jan 2024 00:00:00 GMT

I think about death kind of a lot, and I have for most of my life.

I realize that might seem like a weird way to start a blog post about joy -- or any post about company values for that matter -- but it's true, and I think it's relevant. 21% of your total waking hours over a 76 year lifespan will be spent working, with another 33% sleeping. In total, that translates to you spending over half of your life either unconscious or laboring.

Actually, this number also only accounts for time actually spent at work, and that 21% is measured across the whole life, which means your childhood -- whether carefree or traumatic -- doesn't count. This also means that every hour of commuting, every moment of stress you have before and after going into work, every period of alone time you need because you're too exhausted from the day, every minute you spend checking your notifications from bed; adds to that total number of hours you spend between birth and death toiling to survive.

It's an astounding theft. No matter how much you love your job, how much you succeed, or how great your co-workers are; the fact is that -- unless something fundamental changes about the ordering of our society -- you're going to be living your life around your work, and not the other way around.

How much more horrifying is it, then, that our tools, colleagues, and employers often aggravate rather than alleviate this reality?

You're not gonna make the world a better place

Plenty of companies claim they want to take care of employees, customers, and the world writ large -- the ham-fisted insistence that all these startups are going to "make the world a better place" is a recurring jab at these claims from Silicon Valley under a decade ago -- but in practice, when rubber meets the road, that amounts to little more than lip service.

We're not special, we aren't claiming to fix the world or be immune to the pressures of capitalism. Having said that, we believe there are values and structures that can help you order your company in such a way that when compromise must exist, you can at least triage it to ensure consistency with what matters most to you. It's good to be specific about what your values mean in practice -- as mentioned above, we've all seen platitudes be nothing more than propaganda -- but your concrete policies and decisions are a reflection of the company's philosophical beliefs, whether those are explicit (e.g. "Don't be Evil") or implicit (i.e. "we exist to make money, everything else is secondary. Greed is good.").

With that in mind, I present to you the central, animating philosophy of Yetto and its founders: Joy Matters.

But that doesn't mean you can't do good

"Joy" meaning "that which isn't necessary, but makes life better"; "Mattering" meaning "Joy itself is enough of a reason to do something, we don't need another motive." This two-word sentiment is our first-filter for everything everything from product decisions to company policy, and it's remarkably effective.

From a product perspective, it means asking questions like "does it increase or decrease joy and psychological safety for a support professional to be able to easily compare their ticket output to their colleagues?" and then refusing to build dashboards that allow for that comparison when the answer is "No", regardless of how many managers or leaders want it. It means obsessing over details like how many tabs or browser windows a support professional would need to have open to do their job effectively, and trying to reduce that to as close to "one" as possible.

At the company level, it means rejecting the culture of "speed at all costs" that is endemic to startups and choosing to build deliberately and resiliently. It means trying to figure out what the minimum amount of hours everyone at the company can work while still being able to do their jobs. 32 hours? 24 hours? Let's find out. It means asking "Why do we pay people different amounts of money based on where they live?"

None of these decisions or ideas are world-changing, and they're not trying to be. What they are trying to do is make working life a little more joyful for everyone we can. Joy matters, and increasing it is enough of a goal in and of itself.

Are you the fuel? Or the operator?

All three of us have worked on building and supporting developer tooling for the last decade or more, but a better way of understanding this experience is that the problems we like solving involve improving people's daily experience of work; as much as we can, in any way we can. We've been front-line support professionals, documentation engineers, technical writers, platform engineers, support leaders, ops specialists, and internal tooling developers. We will talk about how this experience informs building Yetto ad-nauseam, but the unifying focus we all share as a result is a deep, first-hand understanding that the current slate of tools for support professionals are not built to maximize their joy and productivity; they're built to contain, measure, and control them.

We aim to change that, and we hope you join us in our attempt.

Data is a curse

Wed, 26 Jul 2023 00:00:00 GMT

Customer support teams, like most teams now, rely on data for decision making. We move forward based on what we think the data shows us. Our understanding of our business and our customers is often driven by what our data tells us. We think data can tell us an unbiased story about our products, our businesses, our teams, our employees, and our customers.

We look at first reply times, ticket resolution times, handle times, and wait times to see how well we are helping people. We analyze inbound volumes and outbound volumes to measure the health of a support queue. And with great reverence we collect customer satisfaction scores and net promoter scores to measure the quality of the support we provide. All this data will surely tell us what we need to do to make the customers happy.

It's true that data can be useful for many things. We can use inbound volume and outbound volume to know when we need to hire more staff. It can help us schedule teams to be available when customers are most often opening support requests.

And yet! And yet we view support data in isolation. On its own, it gives us a hazy view of reality at best and a misleading funhouse mirror view of it at worst. The data cannot tell us how well we are doing at the overall job of customer support. Ultimately, it is not support's responsibility to make the customers happy: it is the company's responsibility.

Customers email a company to solve a problem they are having. It might be a bug in an app or a package lost in transit or a refund for product that wasn't what they expected. They aren't emailing support to solve their problem, they want the company to solve the problem. By measuring customer satisfaction with the support experience and fawning over charts of reply times and handle times, we ultimately focus on the wrong things. The data leads us astray. Those reply times and handle times are a small portion of a larger lifecycle. Other teams are involved in the issue - product teams who design the app, engineering teams who developed it, logistics teams who get physical products shipped around the world, finance teams who forecast and track revenue, marketing and sales teams who get the product into people's hands.

It is said that you can only change what you can measure. Or, perhaps more accurately, "If you can't measure it you can't manage it." (This quote ironically misattributed to W. Edwards Deming despite his statement being the opposite.) People take this clever sounding advice and measure the number of hours their employees are working and the speed with which they are answering emails or phone calls or Twitter threads. However, we can only get faster at the things that support teams do in isolation if we only measure those teams in isolation and fixate on driving the numbers towards our weekly/monthly/quarterly/annual goals. These decisions don't necessarily make the product better or improve the customer's experience. They might, though. We don't know! We don't know because the data we most often look at cannot tell us. Some of those decisions, however, definitely make people's lives worse. People are burned out by metrics. People are fired for not meeting a threshold for calls answered or tickets resolved, or they work an extra 10, 15, even 20 hours a week to make up those numbers.

This all sounds like I am against collecting data. Like I'm suggesting that we stop looking at numbers and let people do whatever they want. And while I (Brian) think that might be a good idea and a worthwhile experiment, it is not what I'm suggesting. I am instead suggesting that we look at data within a larger context. We need to look at data as an organization and as a company. Support ticket volume goes down when products have fewer issues that need fixing. Reducing the number of those issues happens fastest when teams work together to find problems, build a roadmap for addressing them, and communicate that to customers. It's a team effort and our data should reflect that.

I say that data is a curse because we look at segments of data and make decisions that "move the needle" but don't make a meaningful impact on the business - revenue, retention, expansion, etc. Looking at support data (what friction customers are encountering) alongside other data from across the company - product data (what are we building and why), engineering data (how are we building it and how quickly), marketing and sales data (who is interested and what they want). It's only by looking at a holistic set of data in context that we can see what makes customers happy or frustrated and what leads them to continue using a product, buying from a vendor, or recommending products or services to other people. Support data in isolation (and really any team's data in isolation) can only give a sliver of an insight and the likelihood of making good decisions based on that is as good as not.

I hear you all nodding your heads while saying, "Yes but..."

But how can we measure the performance of the support team?
But how can we know who is doing a great job and who needs coaching?
But how do we know who would make a good coach?
But how do we know when to promote people?
But how do we know when to fire people?

The answers to these aren't easy. If you are looking for data to tell you how your team is doing in isolation, you need to talk to your team more. Maybe the support agent answering 50% as many tickets per week as the team average is handling more difficult tickets. Or maybe they're just more thorough than other people. And maybe that's totally fine, but you'll only know by talking to the people on the team and working with them, rather than looking at a ream of numbers every day or week.

Maybe the bottleneck to happier customers isn't the speed with which each individual team member answers tickets but in how well the teams work together to solve customer problems. If these are your "Yes but..." issues, then you aren't measuring how well your teams are working together and your don't know with certainty where the bottleneck is. Since you're collecting data on issue handle times and ticket responses per week, that's where you feel you can affect change. The answer is to dig deeper, collect more data from more teams across the company and look at it all together. And acknowledge that some decisions won't be less arbitrary by using whatever data you happen to have available.

To summarize all of this, data is only as useful as the story it tells us. When we look at small bits of it at a time, we only get part of a story. If we want to shift our thinking from "measurable" to "impactful", we have to rethink our data strategy and stop looking at each team's performance in tightly bounded boxes. We also have to acknowledge that the data we collect can only ever tell part of a story. When it comes to people - and especially how we manage people and teams - we need to understand the work and the individuals doing that work. People are not machines and should not be expected to perform within precise tolerances. Every time I see a dashboard showing ticket resolution times for the support team or KPIs and OKRs asking support to reduce handle times or response times, I think of all the support professionals struggling to meet those demands without knowing how or if they are making a positive impact on the business or the customer.

You're already doing all hands support

Wed, 14 Jun 2023 00:00:00 GMT

Back in April, I was walking around Chicago with Brian during Yetto's first in-person meetup, and I said something that started an interrogation. I don't remember what I said and in some ways it doesn't matter -- robust dialogue, jovial hyperbole, and good-natured ribbing are how all three of us enjoy interacting -- but I distinctly remember it being low stakes enough that I found myself asking "Why is this so shocking to you? It seems like a weirdly big deal." Brian's response was "You and I are so deeply similar that when we disagree on stuff it's noticeable and shocking."

I find that quote echoing back in my head as I write my "rebuttal" to Brian's belief that we should stop doing all hands support. I've known his thoughts on this topic for a while now, and in some ways they're deeply persuasive to me. As a support professional who's been doing this work in every kind of role and company imaginable for the last decade, I want to agree with him wholeheartedly. I find myself nodding along and doubting myself as I read it back.

And yet, something felt incorrect and I couldn't put my finger on it. I located my discomfort as I read it for the hundredth time, when I was about to resign myself to writing "I was wholly naive and we should stop doing this":

Several times when a CEO has asked me to implement all hands support at their organization, I have asked how they implement "All Hands Finance" or "All Hands Engineering". We don't do those things because we understand that those roles require unique skills and it takes time to hone those skills for the specific business. Asking someone to do "all hands account payable" for one week a year would seem both preposterous and dangerous. And I think the same applies to customer support. If we believe that support professionals bring a unique skill set and a unique value to the business, as I mentioned in the last section, then we should also believe that not everyone at the company can do that job successfully.

On first glance, this is a persuasive point. In fact, it knocked me on my heels the first time Brian said it to me. But reading this again I realized something: I've never once worked somewhere that didn't do all hands support.

Don't get me wrong, I've worked lots of places that didn't have formal all hands support programs, at least not the kind that Brian is talking about. But unlike accounting, finance, and other specialized roles in your organization, that doesn't stop everyone from doing it anyways; it just stops them from knowing how to do it well.

Support is different

Do I believe that support professionals bring a unique skill set and value to the business? Yes, wholeheartedly and without equivocation. More than that, I believe that the skills required to provide company-changing, customer-salvaging, product-defining support require years of experience, honing, and mentorship to develop. Those kinds of support professionals are worth whatever you have to pay them, and I in no way want to devalue their work.

But supporting customers, as a function of your business and also as an activity, is categorically different than a lot of specialized roles.

I've never seen an engineer hop into an #accounts-payable channel in Slack with an @here demand to drop everything they're doing to help an angry influencer on Twitter. I've never seen Security get ordered by another department to retool their entire workflow for the next three weeks to prioritize an important contract that sales wants to land. Both of those suggestions are daily occurrences in your company's #support channel.

But between events like escalation-via-founder, engineers on Twitter debugging in DMs, marketing folks getting LinkedIn DMs about unreleased products, and lots and lots of "urgent" questions from enterprises throwing their weight around, your whole company is already doing all hands support.

The problem is they suck at it, won't stop sucking at it, and aren't interested in your professional opinion on why they should defer to you. After all, how hard could it be to talk to customers? They do it all the time.

Where I'm coming from

My positive feelings about all hands support come from working at Zapier. Wade, one of the co-founders, made it clear from day one that every employee was required to spend 8 hours per week in the support queue helping customers; no exceptions, founders included.

During onboarding, every employee spent a portion of each day learning how to support users. They paired with incoming support professionals and received training from the company's support trainer. They learned how to use the support tools required to do it well, how to identify which tickets were ok for them to work vs which ones should be escalated to the professionals, and importantly, they learned the "why" of support and the consequences of even small deviations from a system designed to serve millions of people with only 30 professionals.

Were they great at support? Not at first. They were never as good as the full time support professionals, but because it wasn't a "one week a year" thing and we had dedicated people assigned to answer questions and pair with them, they maintained junior-level, tier-1 capabilities at minimum and the benefits far outweighed the costs.

What made it worth it?

Like Brian mentioned, it's a massive investment of both the company and Support's resources to make this kind of all hands support happen. Among other things, you need to:

Staff a dedicated training team.
Fly that team in for onboarding (if you do in-person onboarding) or schedule time during onboarding for each employee to learn from them (if you're fully remote for onboarding).
Have Support account for sub-junior employees in the queue and ensure that they have something to do.
Regularly remind new employees that it's not optional and they have to do this.
Sacrifice 8 hours a week of everyone's focus on their day to day work.

With all those costs, what was the result? Why is it something I still can't let go of?

First, I have never worked somewhere where the Support team was more valued or respected. Far from Brian's concern that this devalues support, at Zapier my time and attention were treated like an intrinsically valuable, limited resource. Other teams routinely praised the Support team with specific encouragements from tickets they came across and learned from. Engineers would catch an edge case that affects some small percentage of users before shipping the feature and would explicitly delay shipping it so they don't overwhelm support. It honestly freaked me out for a while, it felt Stepford-esque.

Second, engineers spent way more time fixing their customers' everyday pain. Wade once said something to the effect of "If you make an engineer answer the same question 50 times, it'll be fixed by Monday"; my experience there bore that out.

Finally, rather than lowering support quality, it aligned the whole company on the right way to talk to customers about the product. Support teaches you the awesome and terrifying power of words. We have decade-long discussions about whether and in what specific contexts saying "Sorry" is appropriate. It's the kind of thing that seems like an overreaction until you get named in a former-customer's lawsuit for "admitting fault" in their costly data loss issue. You want to stop Sales from promising features on Friday that the product doesn't do yet? Make them answer the angry email about it next Wednesday.

How my thinking has changed

It pains me to admit that I think Brian is ultimately right here. At the end of the day, the kind of all hands support I'm describing above is rare to the point being non-existent. Most companies don't have the buy in, culture, will, or desire to do it well. I admit that my resistance to fully agreeing with Brian is that I experienced the platonic ideal implementation.

I can't help but feel that it's still worth fighting for though. I don't agree that expecting everyone to effectively help customers and communicate information clearly inherently devalues trained, career support work anymore than teaching everyone to write inherently devalues the works of Ursula K. Le Guin or Samuel R. Delaney. If you're an organizational leader and you agree with me, the components of successful all hands support are:

Frequency: You have to do it more often than "once a quarter" or "once a month." Ideally it needs to be for some inflexible number of hours every week, scheduled as it makes sense to the individual (e.g. 8 hours a week, scheduled into the week at the discretion of the individual employee). This isn't so much a best practice as a minimum bar, if you're not in the queue every week then you're woefully behind on what customers are experiencing.
Totality: If it's all hands support, than it's all hands. A single exception to this rule will destroy it. No one -- especially not senior leaders -- can opt out and willful failure to comply must face consequences. In my opinion, if you're doing this it should go in the employee contract so folks know that it's an expectation going in. It needs to be a top-level value you not only hold but celebrate.
Deference: Your Support team, from the newest team member to management, will always know more and be better at this than you. Give them power over the program and the resources to do it well. Don't make training the rest of the company someone's "20% time" gig. Make it clear that they are the experts every single chance you get and celebrate specific things they've accomplished and not just "Wait time is down and the queue is being handled."

If you're not a founder, VP, or C-suite executive fully committing to the system I described above? If you're a Support leader or team member who longs for Product and Sales to feel the pain they've caused you and your team?

I get it. I do.

But the bottom line is that in most cases, if you have some influence and want to affect the most change with the fewest resources, it's probably not worth it to start with all hands support. In fact, even if you are doing some form of all hands support you should do what Brian suggests. Your team will thank you.

No matter what you choose to do, for the love of all that is good and the sanity of your team, have a talk with your leadership about how they shouldn't be an escalation point for the public. Make the consequences of careless words and actions visible to the rest of your organization.

Because if your company isn't gonna do all hands support, then they should actually stop.

Stop giving me take homes

Wed, 31 May 2023 00:00:00 GMT

Introduction

As a customer support professional, I'm accustomed to navigating a tricky job-hunting landscape. Avoiding work-from-home scams. Figuring out which companies just want bodies as chum for poorly-treated customers and which companies truly value their customers and the holistic business benefits the Support function provides. Getting through a few interviews before finding out a company wants me to provide those comprehensive Support services for call center pay.

But after a decade of filling out job applications, customizing my resume and cover letter for every unique opportunity, enduring round after round of seemingly endless start-up interviews, there's one thing that I've come to hate about job-hunting more than anything else in the Tech world: take-home projects.

Take-home projects (also sometimes called take-home assignments) are ostensibly meant to weed out unserious and unqualified candidates and highlight the outstanding ones. But in reality, I've found they often fail to measure relevant skills, unnecessarily lengthen already excessively long interview processes, put demands on my time that as a caregiver is difficult (if not impossible) to accommodate for a job I may not get, and are an excuse for employers to extract free labor from vulnerable people with little to no recourse for recovering their work.

Why Take-Homes Are Exploitative Bullshit

I've worked hard to hone my technical problem-solving and emotional intelligence -- vital skills for customer support professionals -- and I'm excellent at both. This isn't hubris; my professional worth and aptitude is demonstrated in my resume, in the references my peers and supervisors provide on my behalf, and in the work samples I provide in my portfolio.

Yet despite these tangible proofs of my ability and experience, almost every interview process I've been a part of during my Support career has involved a take-home project. It's not at all uncommon for the take-home project to ask me to write a help center article or answer help desk tickets, as if I were a new Support worker with no work examples to my name or experience under my belt.

Every time I'm sent a take-home project I think to myself -- did they not read my resume? Do they think I somehow cheated my way through 10 years of verifiable work experience? Did they not look at the sample work they asked for? What's the point of completing the job application if they don't read any of it?

Or worse: the also not-uncommon take-home project that asks me to do actual work the company clearly needs done, like evaluating and correcting weaknesses in a company's support community program or drafting a training program for new Support hires (both real projects requested by potential employers in the past).

Either I'm asked to prove I can do the most basic work of a Support professional, or I'm asked to provide a potential employer free labor in exchange for a chance at a job (not a promise of a job! Just the chance of being considered!), and either option is incredibly insulting to me as a candidate.

It's also become increasingly apparent to me that tech companies are just disrupting wage theft -- innovating new ways to steal labor from vulnerable people who need the work. If you're in a low-wage job, or in a hostile workplace and desperate to get out, or if you've been laid off and unemployment is a ticking time bomb about to go off -- are you going to say no to a take-home project? Even if you suspect it's a company's excuse to get work done on the cheap? Probably not.

I've also been on the hiring side of take-home projects, and it's just as infuriating. I hear my employers claim they want to hire women, people of color, older workers, and other people underrepresented in Tech, and yet still design 2-8 hour take-home projects that only folks who have the privilege of time, of money, and of power could possibly complete with any quality.

When candidates withdraw from the interview process because they understandably can't or won't complete the take-home project, my employers are affronted, as if this is an insult or red flag instead of a candidate's very reasonable exercise of agency. When I point out that perhaps the candidate didn't want to give us free labor, they scoff. They say things like, "we can't compromise our standards," or "how will we know if they're a top performer?"

I bite my tongue until it bleeds, because otherwise I'd reply, "just admit that you want to go the easy route and hire a white dude and be done with it," and then I'd be a job seeker again facing down another take-home project, weighing my need for the job and salary against my sense of self-worth.

For everyone except the most privileged, take-home projects are like playing the lottery -- you know you're probably going to lose and that someone else is going to benefit from your loss. But you can't win if you don't play, and employers know it.

So If Not Take-Homes, Then What?

Ah, I can hear you asking -- if we don't use take-home projects, how will we measure a candidate's empathy, their patience and tenacity, their google-fu, their critical thinking?

My counter-question is this: is your take-home project actually measuring those things? The very nature of take-home assignments means that they tend to ask candidates to give solutions to well-defined problems or provide detailed consultations for finite projects, but in reality, Support work is rarely so concrete or predictable.

And take-home assignments are often not effective at evaluating the candidate's ability to dig into problems they don't know much about, their willingness and aptitude for working with others, their capacity for adapting their approach when necessary -- essentially, their emotional intelligence and intellectual elasticity. We know this is true because take-home projects almost always come with a subsequent review interview, or come in addition to several rounds of face-to-interviews that evaluate for culture and values fit.

In my experience, take-homes are a dysfunctional shortcut for employers who are either too lazy to put in the effort to do things differently and reach more highly-qualified candidates, or they don't have the expertise to really zero-in on what they're looking for in a candidate, especially if it's for a non-technical role as Support roles frequently are. (Although I genuinely believe this is true regardless of the type of role, but that's an argument for another blog.)

This means that in order to replace a take-home project with a more equitable and accurate measure of a candidate's fit for a role, employers need to be thoughtful and deliberate about determining what skills and competencies the role truly needs.

At the risk of providing yet more free labor for companies that surely have the resources to figure this out for themselves, here are some suggestions.

Scenarios, Live Projects, and Writing Samples / Portfolios

Scenario-based questions and live projects are great ways to tease out a candidate's ability to navigate difficult situations with empathy and patience, their critical thinking process, and their ability to provide the right solution at the right time for the right problem.

Scenario-based questions and live projects are especially helpful when you have specific problems in your Support organization that you know a candidate will need to solve. Both scenario-based questions and live projects are time-boxed, which limits the complexity of the candidate's answer (thus limiting the chance their work will be exploited) while giving a candidate the opportunity to demonstrate how their experience allows them to meet the challenges they'll face in the role.

Scenarios and live projects also allow you, the employer, to evaluate the most important skills a Support professional needs in order to excel in any Support role: are they able to learn new things, troubleshoot, and problem-solve on the fly? How do they deal with uncertainty, frustration, and stress? Can they effectively explain what they're doing? How do they communicate with peers and supervisors? Do they know when to admit they're struggling and ask for help?

It's a frustrating waste of everyone's time to ask experienced candidates to prove they know how to do basic support work like answering tickets, but it's perfectly reasonable to want to be sure a candidate's writing and communication skills will match the needs of a Support role.

This is where work samples or writing portfolios come in. Most experienced support professionals are very well-versed in writing help documentation, training material, and even blog posts, and most will be able to provide one or two existing samples upon request. This is a much better option than asking a candidate to write a help center article for your company in a take-home project; it's less exploitative, and it tells the candidate that not only do you respect their time, but you also recognize and value the experience demonstrated in their resume and application.

But If You Must Do Take-Homes, Do Better

If you've gotten this far and you're still thinking that I'll pry take-home assignments from your cold, dead hands -- well, I can't stop you from being wrong. But if you're going to do take-homes, there are ways to not be an asshole about it.

For starters, shorten the take-home as much as possible, and limit it to only the type of work the candidate would be doing if they got the job. For an (unfortunately real) example, if they're going to be managing a team of front-line agents, don't ask them to do market research and make recommendations for how to improve your mobile app to be more competitive with other companies' apps.

Secondly, shorten your overall interview process as much as possible, and only ask a candidate to complete a take-home project if you're otherwise sure the candidate is a good fit for the role. If you're asking a candidate to go through 5-6 rounds of interviews plus a 2-8 hour take-home project, that's 5-13 hours of time you're taking away from that candidate, who you may not hire, and who is likely repeating this process with other companies as well. Aside from making your company more competitive comparatively, it's also just decent and more equitable to reduce the demands you're making on a person's largely uncompensated time.

Lastly, pay candidates for completing the take-home project, regardless of whether the take-home assignment actually contains real work the candidate might do in the role. Again, aside from making your company incredibly competitive, it's also just the right thing to do. If you're asking a candidate -- or anyone -- to do work they wouldn't otherwise do, you should pay them.

How much you should pay will obviously depend on the role and the work involved. My advice is to use the hourly rate on the high-end of the salary range for the role in question and then multiply that by the number of hours the take-home project will take to complete. Having said that, a flat rate is also acceptable, and it never hurts to default to generosity.

Could paying people for their time or eliminating the take-home altogether get expensive? Certainly, if you don't know what you're looking for or haven't properly screened candidates as they move through the hiring process. But hiring the wrong person is also incredibly expensive, both in terms of time and revenue lost, so committing the resources to ethically finding the right person for the right role at the right time?

That's priceless.