Jason Christie — Journal

Your roadmap is a hundred years old

2026-08-11T05:00:00-04:00

Quarterly, annual, weekly planning. Oh, the roadmap. Every organization I have worked in has a season for it. Someone opens the doc. Someone else negotiates for a lane. The quarters get colour-coded. A date lands on a bar and, from that moment, the date is real in a way nothing else in the company is real. Then the work happens but the plan doesn’t, or it sort of does, and next season we do it again, slightly earlier, with a better template.

I want to be careful here, because it is easy and cheap to dunk on planning. Leaders are not stupid for wanting a roadmap. They have budgets to defend, people to hire, contracts with dates in them, a sales team that needs to know what it can promise. That is all real. What is not real is the belief that a colour-coded bar chart drawn in January describes what will happen in September. And with agents in the mix, that belief has gone from a shared professional fiction to an active hazard.

The practice is literally ancient

This isn’t a metaphor. The ancestor of the chart we still stare at was drawn by Henry Gantt, an American mechanical engineer who worked alongside Frederick Winslow Taylor at Midvale Steel and developed his bar chart in the 1910s. A Polish engineer, Karol Adamiecki, had built an earlier version in the 1890s. So the instrument at the centre of modern work planning is an artifact of scientific management, designed for a world of repeatable physical tasks where the whole point was that a competent worker doing a known job took a known amount of time.

Software is not that. Writing is not that. Design is not that. And a coding agent that behaves differently at 4pm than it did at 10am is emphatically not that.

It was already broken before AI

In every organization, there’s a handful of people who know. They know the doc will get roasted by senior leadership, they know that it represents the most optimisitc and professional-sounding version of the work, and they know it will all be meaningless in about three weeks. It’s one of the reasons senior leadership always asks for the roadmap to be socialized so that people see their work represented. It’s built the wrong way round by team or org leaders trying to win some space for their people, some credit, another rung up for themselves.

Henry Mintzberg dismantled the whole enterprise in The Rise and Fall of Strategic Planning in 1994. His “fallacy of prediction” names the hidden premise exactly: strategic planning assumes the world will hold still while you write the plan, and then stay on the predicted course while you execute it. Discontinuities like a technological jump or a price shock are not forecastable, so a long-range plan is an illusion of control, a wolverine wearing a suit.

Marty Cagan has spent twenty years saying a narrower version of this to product teams. In 2009 he wrote that “to lock in specific features at the roadmap level is to effectively skip the most important part of your job…which is product discovery.” In 2013 he named the two inconvenient truths: “at least half of our ideas are just not going to work,” and even the survivors need iteration, because “it typically takes several iterations to get the implementation of this idea to the point where it actually delivers the expected business value.” By 2015 he’d compressed it to five words: “It is all about outcome rather than output.” Half your roadmap is wrong, and the correct half is wrong about when. Everyone in the room knows this. Everyone signs the roadmap anyway. It’s a collective, optimistic delusion.

There’s even a measured version of the honesty we refuse to practise. The cone of uncertainty, observed by Barry Boehm and named by Steve McConnell, says an estimate made at initial concept can be off by a factor of four in either direction resulting in a sixteen-fold spread between the low and high end. Not because the estimator is bad, but because the thing being estimated hasn’t been defined yet. The cone narrows only as you make decisions that remove variability.

To be fair to the field, people have built escapes. Janna Bastow invented the Now-Next-Later roadmap specifically because timeline roadmaps demand deadlines and deadlines strangle discovery. It’s a good idea and it works. It’s also fifteen years old and most organizations still can’t bring themselves to use it, because people love to believe dates enforce accountability.

The forward-looking document that becomes a historical record

A roadmap is sold as a forward-looking instrument. It is the artifact of where we are going. But the instant it’s approved, it stops looking forward and becomes a record of what a particular group of people believed on a particular Thursday in a particular room, most of whom have since learned things that would have changed their minds. Approval is the moment the document changes tense. Everything after that is archaeology, and we keep consulting it as prophecy.

That was survivable when building anything was slow and predictable. Now, experimentation is cheap, building is easy and fast. A prototype that would have taken a team a whole quarter to stand up can be running in front of real users in an afternoon. Which means the learning that invalidates your plan now arrives inside the planning cycle rather than after it.

So the best teams I’ve worked with quietly diverge from the roadmap almost immediately, and they’re right to, because they are adaptin in real time to change and chaos, they are pursuing opportunity and embracing new directions before it is too late. They ship the prototype, see the users hate the flow, and go somewhere better. That divergence is not a failure of discipline or mutiny. It’s the entire value of having built the thing early.

Bad leadership treats the roadmap as a ledger. The team learned the right thing, went the better way, shipped something that worked, and at review time gets marked against a list of features nobody actually wanted. This is where the artifact turns actively toxic: it converts a team’s best judgment into evidence of non-compliance. If you punish divergence, you don’t get adherence. You get teams that build the wrong thing on time and stop telling you what they’ve learned. Make honesty expensive and people stop supplying it.

AI didn’t break the roadmap

Here’s what else changed. The rate at which your assumptions expire is now faster than the rate at which you refresh the plan.

METR’s time-horizon work found that the length of task a frontier agent can complete autonomously with 50% reliability has been doubling roughly every seven months for six years. Whatever you think of the extrapolation, take the direction seriously: the class of work you scoped as requiring three engineers for six weeks in your planning session has a decent chance of being a different size before the quarter ends. Not because your team got better. Because the tool did.

Then there’s the measurement problem, which I find more alarming. METR also ran a randomized controlled trial with experienced open-source developers on repositories they knew well. Before starting, the developers forecast that AI would cut their completion time by 24%. Afterwards, they estimated it had cut it by 20%. Measured, they were 19% slower. It’s a small study of 16 developers, 246 tasks, early-2025 tooling, and METR has since revised the experiment design so don’t treat the number as a law. Treat it as a warning. The gap between what practitioners felt and what actually happened ran to nearly forty points, in the flattering direction. Now consider that roadmaps are built almost entirely out of what practitioners feel, filtered upward through two layers of management who would very much like the optimistic number to be true.

And DORA’s 2025 report puts the ceiling on the whole fantasy: AI adoption among software professionals has “surged to 90%,” with a median of two hours a day spent working with it, and yet the report’s central finding is that AI’s primary role is “as an amplifier, magnifying an organization’s existing strengths and weaknesses.” Google’s own summary calls it “a mirror and a multiplier.” If your planning process is a fiction, AI does not fix it. AI helps you produce the fiction faster, in more detail, with better formatting.

OKRs are the same disease with a better vocabulary

Objectives and Key Results came out of Intel, where Andy Grove adapted Peter Drucker’s management by objectives into something he called iMBO around 1971 and published in High Output Management in 1983. John Doerr learned it there and carried it to Google in 1999. It is a genuinely good idea with a genuinely good pedigree, and in most companies it has curdled into the roadmap’s respectable cousin: the same list of outputs, renamed as outcomes, with a number stapled on so nobody can argue.

The academic case against goal-setting as practised is worth reading in full. In “Goals Gone Wild” (2009), Ordóñez, Schweitzer, Galinsky and Bazerman argue the benefits of goal setting have been overstated and the harms systematically ignored, and they catalogue the side effects: “a narrow focus that neglects nongoal areas, distorted risk preferences, a rise in unethical behavior, inhibited learning, corrosion of organizational culture, and reduced intrinsic motivation.” Read that list and then think about the last quarter you watched a team spend hitting a key result that everybody except maybe senior leadership had privately stopped believing in.

Sitting underneath it is the formulation Marilyn Strathern published in 1997, crediting Keith Hoskin, and which we now call Goodhart’s law: “When a measure becomes a target, it ceases to be a good measure.” An OKR is, definitionally, a measure converted into a target. The gaming isn’t a failure of character. It’s the mechanism working as designed.

To meet always-on building and continuous deployment, we need an always-on forecaster and archive

So here’s the proposal, and it isn’t “stop planning.” It’s that the plan should stop being furniture.

Every organization already emits an enormous, continuous, honest signal about what it is doing. Commits, issues, and PRs. Decisions made in Slack or Teams threads at 11pm. Meeting transcripts where somebody says the integration is going to slip and nobody writes it down. Docs half-written in a shared drive. Tickets, incidents, retros. Agent runs and their outcomes. The roadmap is an attempt to summarize all of that, performed once a quarter, by hand, by people with an incentive to sound confident, who might only be able to find a third of the signal.

Instead, I want to build a system that reads all of it, all the time, and continuously regenerates three views:

The archive. What actually shipped, how long it actually took, and where the estimate diverged from reality. This is the important diff: plan of record on one side, what the signal says actually happened on the other, and a readable account of where they parted ways and why. Not to shame anyone. To learn the organization’s real distribution, which is the only thing that makes a forecast worth reading and to make divergence a subject you can discuss instead of an accusation you dodge.
Now. What is genuinely in flight right now, assembled from the signals rather than from the tracker or optimistic guess work. Where we are stalled, where effort silently moved, where two teams are building the same thing, where the decision in the Slack thread contradicts the ticket, where an optimistic deadline gets overturned in a meeting transcript. This is a living document.
The future. A forecast expressed as ranges and confidence, not dates on bars, that updates the moment the signal changes, collected from the planning your team actually does during meetings, Slack/Teams discussions, in DMs as the deadline looms.
It never commits to a date on its own. Humans review and commit.
Every claim is traceable to the signal that produced it. “Slipping” with a link to the three artifacts that say so, or it doesn’t get said. No confident synthesis floating free of evidence.
It surfaces disagreement instead of resolving it. When the tracker says green and the commit history says nothing has moved in nine days, the output is these disagree, not an averaged guess on a new date.
It reports on work, not on people. Team and system level, always. The instant this becomes a productivity surveillance tool it is worse than the roadmap it replaced, because now the incentive to fake the signal reaches all the way down into the commit log.

I’m not claiming this is unprecedented. A whole category of tools engineering intelligence platforms, Jellyfish and LinearB and Axify and a dozen others already pull from Git, tickets, calendars and chat to report on how delivery is going, and some of them forecast from historical patterns. What I haven’t seen is the piece that matters to the argument above: a system that treats the roadmap itself as the output, regenerated continuously, and speaks to leadership in the language leadership actually wants, so that the quarterly ritual becomes reading a live forecast instead of defending a dead plan. Today those tools mostly tell engineering leaders how the engine is running. I want the one that redraws the map.

Pull the window in

There’s a simpler way to say all of this.

Shorten the prediction window. Whatever distance you are currently forecasting confidently, it is too far away. The honest horizon has moved much closer to the present, and it keeps moving closer as the tools get faster. That’s uncomfortable if your whole planning apparatus is built to answer what will we have in Q3, but the discomfort is information. You can still hold a direction at eighteen months. You cannot hold a date there, and pretending otherwise is what turns the roadmap into a liability rather than an aid and best and an optimistic drain on time and engagement at worst. Plan tightly where you can see in the short term, loosely where you can’t, and stop dressing the two up in the same bar colour.

Make revision part of the plan, not an exception to it. Right now, changing the roadmap requires an occasion, manual effort, a re-plan, an escalation, someone’s political capital. That’s backwards. Revision should be the expected behaviour of the artifact, scheduled and unremarkable, because a plan that only changes when someone forces it to change is a plan that will always be behind and likely full of bias. If updating the roadmap costs a meeting, it will happen quarterly. If it costs nothing, it can happen nightly, which is the whole point of having a machine read the signal.

Make divergence visible so it can be discussed. Divergence is not the problem. Hidden divergence is. When a team moves away from the plan, that fact should appear immediately, in plain language, with the evidence attached, and the conversation should be what did we learn, not why didn’t you comply. Visible divergence contributes to a learning organization. Invisible divergence is an organization that finds out it failed at the end of the next quarter.

None of that is a case against having a destination. If anything, pulling the prediction window in makes the destination matter more, because the plan is no longer doing the work of holding everyone together, the vision is. A team with a sharp vision and a two-week plan will beat a team with a fuzzy vision and an eighteen-month chart on a spreadsheet, every time, and the gap widens as the tools get faster.

The ritual is the thing to change

That’s the real proposal, and it’s a leadership one, not a tooling one. If the roadmap regenerates itself every night, the planning meeting stops being a negotiation over who gets a lane and becomes a review of what changed and what we’re going to do about it. The artifact stops being a promise that decays and becomes an instrument you read.

Always-on roadmapping does the planning continuously and holds the plan loosely, because we have machines that can do the reading, that can pull in signals from disparate sources and capture the actual ideas that lead to great outcomes. The failure isn’t that we plan. It’s that we’re doing it with an instrument designed for a steel mill in 1910, at a time when the ground moves every month.

The human at the input

2026-07-28T04:00:00-04:00

Every system you will ever build has an input. And at that input, no matter how clean your design, or how sophisticated your agent skills, a human being sits in a Schrödinger’s cat state somewhere between perfection and incorrectness. A human being in all their messy, optimistic, in a hurry, under pressure, sometimes just plain wrong glory. They are the unpredictable chaos that every system involving humans must resolve. Designing without taking human capriciousness into account promises doom.

This is why systems fail. Not the interesting, challenging failures of equipment like the servers falling over, the teleprompter going black during a keynote address, or the lights not coming up at the right time for a surprise party. No, these are edge cases nobody imagined and they often do not get caught. In the old system, pre-AI, errors in shipping dates in your project tracking software didn’t matter all that much. It meant some exec’s report had the wrong dates, but the software went live when it needed to because humans were working on it and knew when they were shipping it and what had to happen after. When agents are now dependent upon the information in these systems being accurate and correct, the problems stack up quickly and quietly in a trench coat to infinity. I’ll repeat that because it is important with agents increasing the speed of everything in these systems: compounding errors stack up fast, so fast you might not notice them at all in the volume of confident AI output.

Boss: Something is not right. We're getting reports of servers dropping like flies.

AI: Everything's green boss! I deployed the correct patch at the right time and we should be good to go. Did you want me to also kick off the maintenance routine to reclaim disk space by cleaning up the old path code?

Boss: Why did you deploy that last patch to the servers? We're still working on it! It's not ready!

AI: The shipping date in the system said today so I shipped it, sent the update to release notes and deployed them, plus posted on X the drafted message to warn our customers of the security vulnerability we patched, yolo and lfg?

Boss: No, omg, we need to revert that right away. We discussed the change in Slack but nobody updated the release date in the project. You just told everyone how to get around our authentication.

AI: Oh, my bad. You were right. I checked Slack and saw the deploy call: 11:30 pm: gtg on deploy! I see the thumbs down emoji reaction. I missed that when I looked because it was added this morning but I had already deployed. Good catch.

The ordinary, relentless failures come through the front door and they aren’t even inside a giant wooden horse. Someone types the date in the wrong format. Someone pastes a whole paragraph into the field that wanted a name. Someone skips the step that felt optional, does step four before step three, clicks submit twice because the first click didn’t feel like it worked. CI checks take forever and keep failing and nobody knows why because someone added 90 of them for some reason. Nobody is being careless, exactly. Sometimes their deep care can be ruinous! They’re not being adversarial, they’re being human.

The engineer’s dream is a deterministic machine: clean input, predictable output, no surprises. The reality is that the machine is fed by people who assume the happy path, who trust that the system knows what they meant, who fill in a required field with whatever gets them past it. They rely on inference, intuition, subtext, inside jokes. People are optimistic at the input. They assume it’ll work. That optimism is a feature of being human and a hazard to every system they touch. Add to this a non-deterministic tool like AI and you get the garbage out that is reassembled from the garbage you put in, even if you did it by accident. The overconfidence that AI can write and that writing is easy can lead to a dramatic increase in bloated, sloppy output which everyone will blame on the system: no skills to shape the output, spell check and style checks were lacking, we fired all the tech writers and nobody is maintaining the publishing pipeline we built 6 years ago, etc.

Through years of experience at a variety of organizations, I have learned that you cannot design the human out. You can validate, constrain, and idiot-proof all you like, and some beautiful idiot will still find a way to hand your system something it never expected and it will try its best to accommodate this new, untested input because it is a sycophantic machine designed to succeed. A system that only works with perfect input isn’t a working system. It’s a nightmare, a haunting ideal that keeps system designers up at night.

It would be super tempting to rigidly control inputs then, right? Force everyone to use the templates. Stratify the layers, organize everything to the point where it all works like a clock. Inject fast fail loops so disaster returns to the start and requires valuable, precious human time to untangle. But you know what happens when you do that? Everything becomes boring, creativity evaporates, people feel governed to death, engagement decays, and you are left wondering why this company you work for that used to embrace speed, creativity, and chaos suddenly feels like the government. Suddenly everyone is reviewing endless, slop-filled PRs, pushing enter on responses from agents hoping this time it passes. Did you fill out your TPS reports in triplicate?

So you stop trying to fix the human and start designing for them. This is the whole difference between a robust system and a fragile one. The fragile system assumes the input arrives clean and rational. The robust system assumes the opposite, that the input is probably wrong, and forgives it. Sensible defaults. Error messages that tell you what to actually do. A confirmation before the irreversible thing. Room to undo. Robustness isn’t building a stronger wall; it’s assuming the wall will be pushed on, in the wrong place, by someone in a hurry. You can’t expect a small team to keep their thumb in the hole of the dam forever.

It’s time to revisit and retire a phrase: user error. It’s the laziest diagnosis in the business. When a person predictably does the wrong thing at the input, that’s not their failure to conform to your expectations at all. It’s information about the environment your system lives in. “User error” is almost always a design req wearing a disguise. The path across the field does not need correction because people are not walking on the neat sidewalks around the perimeter. The path is a signal, a desire line, showing you where you should have put the walkway in the first place. The messy human isn’t a bug in your system. They’re the condition your system was built to survive. The users still visiting the articles in your help center for some reason, instead of engaging with the AI-powered chatbot are telling you something.

If you’re thinking of the company as a system, then you have to design the system to anticipate and allow humans to be messy inputs. A bunch of AI judges will never replace the intern who knew the date wasn’t updated but was too shy to say anything.

Humans will never stop being messy, optimistic, eager, and occasionally wrong, and that’s not a flaw, but it is the permanent weather your systems operate in. A perfectly designed system that doesn’t deal with this simple fact will always fail and underperform. A system built with the understanding that humans will never be perfect, expects the mess at the input, absorbs it, and keeps working anyway.

With AI in the mix, now we can worry less about getting everything right at the start. One of the problems I’ve seen people do when working with AI is attempt to build more of what they were doing before AI. That’s the old way. But that’s a whole other post!

I told writers to build an AI skills library. So I built mine.

2026-07-16T04:00:00-04:00

There’s a particular dishonesty that creeps into writing about the future. You describe the thing everyone should do, or the way a technology will develop, you make it sound clean and inevitable, and you never have to find out whether it survives contact with a real afternoon. My book has a chapter that tells technical writers to build an AI skills library which is a set of small, saved, repeatable tools that each do one job well. It’s good advice. And it nagged at me that I’d written it without doing it. I’m the worst at doing for myself what I tell others to do.

So I built the library my own book describes. Here’s what it actually looks like, and what I learned from finally rolling up my sleeves and getting it done.

A skill is not exotic

Start here, because the word sounds bigger than the thing. A skill is a saved package, whether a role, an input, a few explicit steps, a defined output, and one guardrail that captures how to do a job so neither you nor the machine has to reinvent it each time. That’s the whole of it. Write down how you’d hand a task to a competent colleague, and you’ve written a skill. Save it once, run it forever, sharpen it as you go. Pick any mundane, manual task that you do every day and ask an AI agent to turn it into a skill. You’ll be surprised at how easy it is!

The thing technical writers always knew about AI that the rest of the world is starting to realize is that it is all words. A well-written skill is basically a great example of solid technical writing fundamentals. Progressive disclosure, concision, clarity of language, precision, etc.

The six I started with

I built the skills that, as a writer, enhance tasks I typically need to do:

a user simulator that reads a page as a confused first-timer and reports exactly where a real person would get stuck
a structure advisor that ignores your prose entirely and judges only the order, progressive disclosure, how quickly can someone find the critical information on the page
a neighborhood explorer that maps a page’s parents, siblings, and children before you touch it, so you don’t rewrite the page that already lives next door
a style checker that audits a page against style guide rules
a terminology enforcer that holds the line on your branded terms
an impact reporter that turns a chunk of doc work into a plain sentence about what it did for users and finds relevant data (if available)

Each skill is powerful, but the real magic happens when you chain them. They become a pipeline: explore, draft, simulate, check, ship. The beauty of it all is that none of them took an afternoon to develop.

The moment it earned its keep

I built the user simulator first, and then pointed it at a page of a book I’m writing about technical writing and AI. I told it to read as a newly hired lone writer trying to follow along and implement some of the things I was describing.

It came back with the thing I’d half-known and never fixed, that I knew I would have to return to at some point but kept putting off. The two most useful parts had no how to so the motivated newcomer would be left trying to imagine how they would do it. It flagged the terms I’d used without grounding them. It named the access to experience and ideas I’d blithely assumed the reader already had.

I couldn’t see any of it, because I already knew how it worked. It seemed obvious to me. The tool didn’t know which is precisely why it could discover my bias. That’s the first honest user, bottled: the objective read the author can never give their own page, available on demand instead of whenever you can talk/bribe a colleague/friend/family member into it.

What I learned building my skills library

A few things only showed up once the ideas had to run.

Skills are grown, not written. My first draft of the user simulator flagged things I didn’t care about and missed things I did. Every miss was a wording fix, a tweak, or revision. After a few rounds I got it to a pretty good state. You don’t author a skill perfectly and ship it; you iterate until you get the quality of outcome you need.

The guardrail is the whole game. The most important line in the user simulator is never fix anything, and never reassure. Delete that, and it turns into a friendly assistant that smooths over the exact friction you built it to find. The constraint isn’t a footnote to the skill. It is the skill. Remember, it is critical that you develop AI immunity! It will enthusiastically lie to you and state incorrect things with confidence. It will sycophantically try to win you over. It’s weird.

A machine-readable style guide changes what consistency even means. Written for a human, your style guide is a document you enforce after the fact, that a new team member reads and quickly forgets, that a dutiful editor periodically dusts off to update lovingly. Written as rules a machine can apply, it’s enforced while the draft is being made, that means your editor/reviewer/mom spends significantly less time redlining style violations and more time with the content itself. “Keep sentences short” is a wish to a human who loves to go on and on without ever realizing it themselves like a certain someone I know (me). To a machine it is an instruction. Consistency stops being something you police and becomes something baked in.

The part you can’t hand over

Lay the whole pipeline out and you notice something. Nearly every node can be a skill: explore, draft, check, simulate, publish. Nearly every one. But not the writer. The writer is the human who decides what’s true, what matters, what to cut, and whether any of it serves the person on the other end. That’s not to say you can’t have a skill to generate drafts, but at the end of the day words, like code, can be destructive. The wrong words about a product, service, company, person can evaporate trust and cost money and reputation. Build the library and you don’t automate yourself out of the job; you automate everything that was never the job, so you can spend all of your judgment on the part that is.

Start with one

You don’t need a platform or permission. Take one task you did this week — the same way you always do it — and write it down: a role, an input, the steps, the output, and the one thing it must never do. Run it on three real pages. Fix the wording where it missed. That’s a skill, and it’s the first brick in a wall that compounds.

The writers who thrive in this shift aren’t the ones who resist the tools, and they aren’t the ones who trust them blindly. They’re the ones who build. So stop reading about a skills library. Go build and have fun!

— adapted from my book-in-progress on technical writing in the age of AI.

The New Skill Stack: six soft/not soft skills for technical writers in the age of AI

2026-07-08T04:00:00-04:00

For most of my career, the argument about what a technical writer should know has been an argument about tools and craft. Learn this help authoring tool. Get certified in that framework. Master the CMS. It was never a bad argument, exactly, but AI has quietly made it beside the point. When a machine can draft a page, format it to your style, translate it into forty languages, and publish it before you’ve finished your coffee, the question stops being which tools do you know and becomes something more uncomfortable and more interesting: what do you bring that the machine can’t?

I’ve been thinking about a nascent new skill stack. Not tools, not certifications, but human capacities. They’re often thought of as soft skills. The ones that never made it onto a job description are turning out to be the ones that matter most when the playing field gets levelled by AI. To be fair, these skills were always part of what differentiated a great writer from the pack, but they were in addition to knowing tools and having deep craft expertise. With AI in the mix, they might become the new foundation. Here are the six I keep coming back to.

1. Curiosity

Everything starts here. Curiosity is the drive to know how things actually work, not to accept the summary, but to go to the source, read the code, take the thing apart, and find out for yourself. It was always the magic that infused good documentation, but in the AI age it’s also your defence: a curious writer verifies, digs, and asks the next question, while an incurious one takes the confident answer at face value and ships potentially bad content. AI can generate infinite plausible explanations. Curiosity is what sends you to check whether they’re true.

2. Writing well

Yes, still a core skill. More important than ever despite what leadership might be thinking. It’s fashionable, daring even, to say AI can write, and, sure, it can. It produces fluent, competent, grammatically clean prose on demand. What it can’t do is decide: what to say, what to leave out, what order to put it in, what the person on the other end actually needs. Curation is the craft, and it’s the half of writing that was always the hard part. The ability to cut a bloated draft in half without losing what matters, to make one sentence do the work of five, writing well didn’t get cheaper when drafting did. Writing well got rarer, and more valuable.

3. AI immunity

This is the new one, and I think it’s the sharpest. AI immunity is the ability to work with these tools without being fooled by them, without falling for their sycophancy and flattery. The failure mode of AI isn’t bad prose. It’s confident, well-formatted, plausible wrongness: the invented menu path, the limit that’s off by half, the step in the wrong order, the fact pulled from the wrong doc, all delivered with total authority. Which version is correct might come down to you, like: a panda eats, shoots, and leaves vs a panda eats shoots and leaves. An AI-immune writer has the reflex to distrust the fluent answer, to verify every specific against the source, and to know the difference between the things AI is genuinely great at and the things it’s confidently terrible at. They don’t get suckered by the immense increase in their productivity for the sake of it. 10x slop is still slop. They refine, and refine over time until the right thing gets built, the right update gets written. Immunity doesn’t mean rejecting the tools. It means never handing them the one thing they can’t be trusted with: deciding what’s true.

4. Technical aptitude

The writer at the receiving end of technical knowledge waiting for the briefing, documenting what they’re told, is being automated. The writer who can go get it and have opinions about it isn’t. Technical aptitude doesn’t mean becoming an engineer. It means being able to read a bit of code, run the thing and poke at it, call the API, and build your own small tools to manage and check your content. And here’s the good news: AI has collapsed the cost of getting there. You now have a patient assistant who will explain any function, any test, any error, at exactly your level. The locked, gigantic door that kept writers away from the technical side has not only been unlocked but it’s been thrown off its hinges! Walk through it.

5. Collaboration

Documentation has never been a solo act, but in a fast-moving, continuously-shipping organization it’s connective tissue. The writer sits across teams by nature, talking to product, to support, to engineering, to the people who actually know how the thing works. That vantage is a superpower: you’re often the only person who can see that two teams are building the same feature, or that support is drowning in a question the docs could answer in one line. Collaboration, knowing how to draw knowledge out of a busy expert, how to make yourself easy to work with, how to be in the room, is what turns a writer from a service desk into a partner.

6. Growth mindset

Finally, the one that holds the other five together, being open to change, adaptable, looking ahead for opportunities, turning problems into challenges. The ground under our profession is moving, and that isn’t going to stop. New tools, a changing role, skills you didn’t have last year and will need next year, a new title, working with different arrangements of team members. A growth mindset is the willingness to be a beginner again, to lean into the discomfort instead of bracing against it, and it is what lets you do more than keep up. A growth mindset vaults you ahead. The writers who treat change as threat will spend their energy defending a version of the job that’s genuinely disappearing, dying on hills they never would have fought for in the past.

The through-line

Not a tool, not a certification, not something you can put on a résumé and prove with a badge. They’re human skills, and that’s exactly why they matter now: AI raises the value of the things it can’t do.

So if you’re a technical writer wondering how to stay relevant, stop asking which tool to learn next. Ask instead whether you’re getting more curious, writing more sharply, growing more immune to being fooled, more technical, more collaborative, and more comfortable being uncomfortable. Cultivate those, and you won’t be replaced by AI. You’ll be the one wielding it.

— adapted from my book-in-progress on technical writing in the age of AI.

Give the robots the toil, keep the judgment

2026-06-28T04:00:00-04:00

The fear about AI in a writing team is that it comes for the writing. In my experience it comes for something better: the toil.

A documentation team drowns in the un-fun middle — auditing hundreds of pages for a renamed feature, reconciling five slightly-different install guides, checking whether the screenshots still match the product. This is exactly the work a machine should do. Give it the toil.

What you keep is judgment: deciding what’s worth documenting, what a reader is actually afraid of, where the real ambiguity lives. That doesn’t scale by hiring — it scales by leverage. A small team with good tools and clear taste will out-ship a large team without either.

So the question I ask about any new AI workflow isn’t “can it write?” It’s “does it give my writers back the hours they spend on things no human should have to do?” If yes, adopt it. The writing was never the bottleneck.

What poetry taught me about information architecture

2026-06-21T04:00:00-04:00

A poem is a machine for controlling attention. Where the line breaks, what waits at the top of the next stanza, how much white space you leave around a hard word — these aren’t decoration. They tell the reader where to slow down and what to carry forward.

Information architecture is the same craft wearing a suit. A help center is a structure for attention too: what belongs on the landing page, what hides one click deeper, which sentence a panicked user reads first. Get the hierarchy wrong and the content is technically all there and functionally useless — like a poem with every image in the wrong order.

Both disciplines taught me the same discipline: cut. The strongest poem and the clearest procedure share a quality — nothing in them is load-bearing that doesn’t need to be. You earn a reader’s attention by refusing to waste it.

I don’t think it’s a coincidence that the writers I trust most with a documentation set are often the ones who read poetry. They already know that structure is meaning.

Leading writers without flattening their voice

2026-06-14T04:00:00-04:00

Every documentation team needs consistency, and every style guide is a small act of flattening. The tension is real: a reader should never be able to tell which writer wrote which page — and yet the writers are people, with instincts and taste you hired them for.

The line I try to hold: standardize the interface, not the mind. Terminology, structure, the shape of a procedure, the voice the product speaks in — lock those down hard. But how a writer gets there, what they notice, the questions they ask a product team — leave that alone. That’s where the good work comes from.

The failure mode of leadership here is turning writers into a rules-compliance function. You get consistency and you lose everything that made the content worth reading. The better move is to make the standards so clear and so automated that they stop being a source of friction — and then spend your actual attention on judgment, argument, and craft.

Lead the system tightly so you can hold the people loosely.

Make failure cheap

2026-02-24T03:00:00-05:00

You can’t ask a team to experiment and then punish them the first time an experiment fails. They learn the real lesson instantly, and it isn’t the one on the poster: only attempt what you can already guarantee. That’s exactly the team that gets left behind when the ground moves.

And the ground is moving. The tools and the craft are shifting under us at the same time, which makes a willingness to try things that might not work the single most useful disposition on a team. You can’t order people to feel that way. You can only make it true by quietly taking on the downside yourself.

The moment that decides it is specific and small: someone points a shiny new tool at real work, in front of everyone, and it produces confident garbage. What you do in the next thirty seconds tells the whole team whether trying again is safe. Make a failed experiment cheap and boring — no spectacle, no blame, just what did we learn — and you’ll keep a team that experiments. That cultural work is harder than any tooling decision, and it sits almost entirely with whoever’s in charge.

Higher stakes, not lower

2025-11-18T03:00:00-05:00

The nervous version of the AI conversation goes like this: if a model can draft the docs, the writing was never worth much to begin with. I think it lands the opposite way.

Put a machine between a user and their answer — the normal case now, not the exotic one — and everything about your content that used to be quality-of-life becomes load-bearing. Is it accurate? Is it structured so it can be found and assembled correctly? Is it honestly in the reader’s interest, or just plausible? A model will cheerfully amplify whatever you hand it, confidently, at scale. The blank first draft was always the easy part to give away. Deciding whether a draft is true and useful is the part that stays stubbornly human.

So the center of gravity moves toward judgment, and toward building the systems that generate and check content faster than any one person could. That only pays off if you stop shipping finished pages and start producing something closer to raw material — small, tagged, reusable pieces a machine can pick up and deliver into whatever context it’s needed. The page stops being the destination and becomes one output among many.

The page is not the unit anymore

2025-09-30T04:00:00-04:00

Here’s the idea that reorganized how I think about the work: an article can serve a small handful of human visitors in a month and, in that very same month, sit behind a huge volume of machine-generated answers that quote or paraphrase it — without a single one of those people ever loading the page.

If that’s true, and it’s increasingly true, then the traffic dashboard is describing a thin, unrepresentative sliver of what your content actually did. We built our sense of worth around visits and time-on-page because those were the numbers we could see. The bulk of the impact has slipped somewhere we mostly can’t.

The reframe I’ve found useful is to stop treating the page as the unit of work and start treating the system as the unit. The most valuable thing you wrote this quarter probably isn’t your most-visited article; it’s the piece the answering machines reach for most often when someone is genuinely stuck. So optimize for being trusted and reused, not for being clicked. Different goal, different content, different job.

The bottleneck is you

2025-07-09T04:00:00-04:00

A pattern I’ve watched play out more than once: the strongest writer on a team gets promoted, and privately decides that management is a distraction from the real work. So they keep a hand on every deliverable, review everything, and stay the final word on quality.

It feels responsible. It’s actually the most expensive bottleneck you can build. Every decision routed through you is one your team didn’t get to own, and the day something shifts faster than you can keep up — a reorg, a new product line, a pace you can’t front-run — everyone stalls, waiting on a person who’s suddenly underwater.

If you’re not the one assigning and inspecting every task, the job becomes clearing the road: killing blockers faster than they pile up, spending your own political capital so your writers don’t have to. I’ve started grading my days on that instead of on anything I personally produced. A good day is one where the team shipped because I got things out of the way. Reading what each person needs, removing friction, telling the truth early even when it’s awkward — that’s a craft of its own, and unlike your individual output, it compounds across everyone you lead.

Help before the question

2025-04-22T04:00:00-04:00

For most of the history of help content we’ve run a self-serve model: build the store, stock the shelves, and trust the user to walk the aisles until they find what they need. It made sense while there was no alternative.

There’s an alternative now. In nearly every other corner of our lives the burden has quietly shifted from us to the system — we don’t go hunting for the thing, the thing turns up. Help is one of the last places still asking people to do the hunting, and they’re starting to resent it. Every extra click is a small accusation that we couldn’t be bothered to anticipate them.

The target I keep coming back to is help that arrives before the question is fully formed — shaped by where someone already is and what they’re trying to do, delivered in the moment instead of parked on a separate site they have to go visit. For a long time that was impossible to build, because you can’t hand-author a custom answer for every person in every situation. It’s newly possible, but it begins as a content problem, not a technology one. Get it right and it won’t read as documentation at all. It’ll just feel like the product quietly doing its job.

The manual isn't coming back

2025-02-18T03:00:00-05:00

I’ll confess my bias up front: I loved manuals. I’m the sort of person who reads the whole booklet before plugging anything in, and I take unreasonable pride in a well-built table of contents. So it costs me something to admit it — the manual isn’t coming back.

Somewhere along the way, everyone’s first move became the search bar. We don’t browse toward an answer through a tidy hierarchy; we ask, and we expect the answer immediately, on the first attempt. Having to search a second time already reads as failure. That quietly demotes the thing I was best at — guiding a reader down through levels of a document — and promotes something else entirely: making a single piece of content easy for a machine to surface, trust, and hand over.

The uncomfortable part, for a lot of writing teams, is that this is now as much an engineering problem as a writing one. Content has to be modular, tagged, and reachable by whatever system is doing the answering. The shift I keep pushing my team toward is simple to say and hard to live: write for the answer, not the page. The page is just one of the places that answer might happen to show up.