Skip to main content
Shakewell

Field Guide

In-House vs Outsourced Technical Publications

A comparison you can't lose isn't a comparison — so here's the honest one, including the cases where building your own team is the right answer and we'd tell you so.

The Ledger

Count Everything, Not Just Salaries

The in-house line item everyone prices is writers. The ones that decide the math are everything else: the tool stack (authoring, CSDB, publishing pipeline, delivery — each with licenses and an administrator), the standards-currency work of staying honest with moving specifications, and above all the utilization problem: documentation demand arrives in waves — a conversion, a program stand-up, a certification push — while headcount is a flat line. Staff for the peak and pay for the trough; staff for the trough and miss the peak. Small teams add the quiet risk this site keeps meeting: the single person whose departure is a program event.

And the honest other column: proximity is real. Writers embedded with engineers absorb change by osmosis and answer the 4pm question. Where documentation is continuous, high-volume, and core to the product, a standing internal capability is often simply correct.

The Resolution

Split by Function, Not by Ideology

A lean core team backed by external capability
Keep what proximity buys — product knowledge, review authority. Outsource what scale and specialty punish — peaks, deep skills, infrastructure.

Framed function by function, the debate mostly dissolves. The stable pattern: a lean internal core owning product knowledge, review authority, and the customer relationship — backed by a partner for the things the in-house shape punishes. Peak capacity, so a conversion doesn't require hiring a temporary department. Deep specialties — BREX authoring, pipeline engineering — mastered only through constant use. And the infrastructure layer: tooling operation and delivery platforms run as a service, the way the small-fleet model already works.

Our stake in this is obvious — we're one of the partners — so the credibility has to come from the cases we argue against ourselves: the high-volume OEM whose manuals are the product should build the core team, and we've told buyers exactly that. What we won't endorse is the default-by-inertia in either direction. Run the ledger, split by function, and revisit yearly — publications operations drift, and the right split drifts with them.

FAQ

Questions We Hear

What does an in-house publications capability really cost?

More than the salaries. The full ledger: specialist writers and illustrators (scarce in standards-heavy niches, slow to replace); the tool stack — structured authoring, CSDB or CMS, publishing pipeline, delivery platform — with licenses, upgrades, and administration; the standards currency work of tracking issues and business-rule changes; management overhead; and the utilization problem, because documentation demand arrives in waves while headcount is a flat line. You staff for the peak and pay for the trough, or staff for the trough and miss deliveries at the peak.

What's the strongest argument for keeping it in-house?

Proximity to the product and its engineers. Writers embedded with the program absorb changes through hallway osmosis, build institutional knowledge, and are there for the undocumented question at 4pm. When documentation is continuous, high-volume, and central to the product itself — an OEM whose manuals ship with every unit — a standing internal capability is often correct, and we say so. The honest cases for in-house are real; they're just narrower than org-chart inertia assumes.

Where does the in-house model break down?

At the edges of scale and specialty. Small teams carry single points of failure — the one S1000D-fluent writer whose resignation is a program risk. Peak loads (a conversion, a new program stand-up, a certification push) exceed standing capacity exactly when stakes are highest. Specialist skills — BREX authoring, conversion pipelines, viewer quirks — are needed occasionally but mastered only through constant use. And the tool stack demands care and feeding that a two-writer team can't amortize. These aren't people failures; they're shape mismatches.

What does the hybrid actually look like?

The pattern that works in practice: a lean internal core that owns product knowledge, review authority, and the customer relationship, backed by a service partner for peak capacity, deep specialties, tooling operation, and delivery infrastructure. The buyer keeps what proximity buys; the partner absorbs what scale and specialty punish. Most 'in-house vs outsourced' debates dissolve once framed this way — the real question is which functions sit on which side of the line, and that's answerable function by function.

Get In Touch

Run the Ledger Together

Bring us your publications operation and we'll map the function-by-function split honestly — including the functions you should keep, and the ones you should never have been carrying.