<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Jason Christie — Journal</title>
  <subtitle>The personal and professional site of Jason Christie — poet, technical writer, and documentation leader in Ottawa.</subtitle>
  <link href="https://jason-christie.com/feed.xml" rel="self"/>
  <link href="https://jason-christie.com/"/>
  <updated>2026-07-06T01:08:51+00:00</updated>
  <id>https://jason-christie.com/</id>
  <author><name>Jason Christie</name></author>
  
  <entry>
    <title>Give the robots the toil, keep the judgment</title>
    <link href="https://jason-christie.com/journal/2026/06/28/give-the-robots-the-toil/"/>
    <updated>2026-06-28T00:00:00+00:00</updated>
    <id>https://jason-christie.com/journal/2026/06/28/give-the-robots-the-toil/</id>
    <category term="AI &amp; workflows"/>
    <summary>The point of AI in a documentation team isn&apos;t to write for you — it&apos;s to clear the toil so your judgment scales.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>What poetry taught me about information architecture</title>
    <link href="https://jason-christie.com/journal/2026/06/21/poetry-taught-me-information-architecture/"/>
    <updated>2026-06-21T00:00:00+00:00</updated>
    <id>https://jason-christie.com/journal/2026/06/21/poetry-taught-me-information-architecture/</id>
    <category term="Poetics"/>
    <summary>A poem and a help center are both structures for attention. Line breaks and page hierarchies are the same craft.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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 &lt;em&gt;is&lt;/em&gt; meaning.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>Leading writers without flattening their voice</title>
    <link href="https://jason-christie.com/journal/2026/06/14/leading-writers-without-flattening-their-voice/"/>
    <updated>2026-06-14T00:00:00+00:00</updated>
    <id>https://jason-christie.com/journal/2026/06/14/leading-writers-without-flattening-their-voice/</id>
    <category term="Leadership"/>
    <summary>Style guides create consistency, but the wrong kind of consistency erases the writers. Here&apos;s the line I try to hold.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;The line I try to hold: standardize the &lt;em&gt;interface&lt;/em&gt;, not the &lt;em&gt;mind&lt;/em&gt;. 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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;Lead the system tightly so you can hold the people loosely.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>Make failure cheap</title>
    <link href="https://jason-christie.com/journal/2026/02/24/make-failure-cheap/"/>
    <updated>2026-02-24T00:00:00+00:00</updated>
    <id>https://jason-christie.com/journal/2026/02/24/make-failure-cheap/</id>
    <category term="Leadership"/>
    <summary>You can&apos;t ask a team to experiment and also punish the first experiment that fails. They learn the real lesson instantly.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>Higher stakes, not lower</title>
    <link href="https://jason-christie.com/journal/2025/11/18/higher-stakes-not-lower/"/>
    <updated>2025-11-18T00:00:00+00:00</updated>
    <id>https://jason-christie.com/journal/2025/11/18/higher-stakes-not-lower/</id>
    <category term="AI &amp; workflows"/>
    <summary>The nervous version of the AI conversation says the writing was never worth much. It lands the opposite way.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>The page is not the unit anymore</title>
    <link href="https://jason-christie.com/journal/2025/09/30/the-page-is-not-the-unit/"/>
    <updated>2025-09-30T00:00:00+00:00</updated>
    <id>https://jason-christie.com/journal/2025/09/30/the-page-is-not-the-unit/</id>
    <category term="AI &amp; workflows"/>
    <summary>Our sense of worth is built around visits and time-on-page. Most of the value has quietly moved somewhere we can&apos;t see.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>The bottleneck is you</title>
    <link href="https://jason-christie.com/journal/2025/07/09/the-bottleneck-is-you/"/>
    <updated>2025-07-09T00:00:00+00:00</updated>
    <id>https://jason-christie.com/journal/2025/07/09/the-bottleneck-is-you/</id>
    <category term="Leadership"/>
    <summary>The strongest writer gets promoted and quietly decides management is a distraction from the real work. Here&apos;s why that backfires.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>Help before the question</title>
    <link href="https://jason-christie.com/journal/2025/04/22/help-before-the-question/"/>
    <updated>2025-04-22T00:00:00+00:00</updated>
    <id>https://jason-christie.com/journal/2025/04/22/help-before-the-question/</id>
    <category term="The future"/>
    <summary>For most of its history, help content has asked users to do the hunting. That era is closing.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>The manual isn&apos;t coming back</title>
    <link href="https://jason-christie.com/journal/2025/02/18/the-manual-isnt-coming-back/"/>
    <updated>2025-02-18T00:00:00+00:00</updated>
    <id>https://jason-christie.com/journal/2025/02/18/the-manual-isnt-coming-back/</id>
    <category term="The future"/>
    <summary>I loved manuals. That&apos;s exactly why it costs me something to say they aren&apos;t coming back.</summary>
    <content type="html">&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;
</content>
  </entry>
  
</feed>
