On doing your best work where nobody looks, and what that means for being seen.

A friend of mine has a job you can explain in one sentence. Mine takes a paragraph, and even then people nod politely.

We talked about this recently. Neither of us has results you can easily point at. But his job title does the explaining for him: people hear it and think they know what he does. Mine doesn’t come with that shortcut. If I want people to know what I do, I can’t wait for them to stumble across it. I have to step out and show it.

I don’t love how true that is, but it is.

Substance without appearance

German has a phrase for something we’ve all seen: mehr Schein als Sein. More appearance than substance. Engine-room work has the opposite problem. Plenty of substance, very little appearance.

I’m definitely not shy. I give talks, I speak about my work in public, I’m happy to stand in front of a room. But talking about a topic is one thing. Showing what I bring to an organization is another, and that part rarely fits on a slide.

Ask my husband

It’s not only strangers. I struggle to explain to my husband what I actually do.

I can name the topics and list the tools, but when I try to describe the work itself, it slips away. People only really get it by working with me: by being in the room when a whiteboard brainstorm goes in circles and somebody quietly draws out the information that matters, or when a technical discussion sprawls and somebody gets its core down on digital paper. Or by noticing that a problem you’d carried for months is gone, without being able to say when it stopped.

That’s the engine room, and it’s where I work. My title just says technical writer.

When my husband read a draft of this post, his feedback was short: sometimes you have to beat the drum. He’s right.

What happens down there

It usually starts with a small crack. Two people say “done” and mean different things. A topic is discussed for the fifth time this month. A feature has three names depending on who you ask.

Most people step around a crack like that. I tend to stop and look at it. Where does it come from? Who else is walking around it? What would make it stop coming back?

When it works, it disappears. Nobody remembers the meeting that didn’t need a second round. Which is exactly why it’s so hard to talk about.

The shape behind it all

Almost everything I’ve done has the same three steps:

  1. Friction: understand where exactly something is harder than it should be.
  2. Pattern: find a pattern that fits, one that already exists or a new one.
  3. Practice: apply it so the friction stops coming back.

The document is never the point. It’s just one way of applying the pattern.

Three times this shape showed up in my own work:

Onboarding. New colleagues kept asking the same questions. The answers lived in people’s heads, so the same conversations happened again and again. Nobody had decided which answers were needed, or where they should live. Once that was settled, everything got one shared home. Now newcomers find what they need before they have to ask.

The style guide. The same discussions kept resurfacing, and proofreading had no guideline. We weren’t disagreeing about language — we were missing shared decisions. A style guide settled them once. The result: fewer discussions, a common baseline, and linting, so a tool now catches what people used to argue about.

The API guidelines. API quality varied, documentation was uneven, and there were no consistent patterns. Every team made sensible choices, just different ones. Shared guidelines changed that: more consistent APIs that are easier to use, with patterns that carry from one API to the next.

How I get there

It’s an approach I use again and again, in full or in a lighter version, depending on the challenge.

I talk to people one by one, to find out what they actually need, not just what they say in a group. Then I lay everything on top of each other and look at where it overlaps and clashes. I test it against real work, live, with the people who will use it. Then I revise and test again.

By the end, nobody has been handed a rule. They’ve helped shape it, which is why it sticks.

Why I’m stepping out

I’m not leaving the engine room, and I’m not trading it for the stage either. I do good work in both places. But the work down there doesn’t show itself, so I’ve decided to show it. That’s why I write, here and elsewhere. It’s why I keep a wide network across tech, and why I go to conferences, partly as field research, partly to speak. All of it is a way of showing the part of my work that rarely fits on a slide, and the thinking behind it.

I can’t invite you into every room I’ve worked in. But I can show you what stayed behind: a debate that was settled for good, teams that build things the same way, a newcomer who finds the answer before asking.

A job title is a claim, but a pattern that holds is a trace. More substance than appearance is a good place to work from. Every now and then, though, the substance deserves a drum.

If you do engine-room work

  • Describe the friction, not your role. “The same questions kept coming back” says more than “I’m a communicator.”
  • Say what got easier. “Nobody argues about that tool anymore” is a whole story.
  • Show up on purpose. Being visible isn’t showing off, as long as what you show is real.

If you lead a team

Questions worth asking when a team scales fast:

  • Where is growth creating friction?
  • What feels harder than it did a year ago?
  • Who do people ask when something is unclear, even though it’s not their job?
  • Which questions get answered again and again, by the same people?

The answers are rarely in a job title. They’re in the gaps between roles.

Still a paragraph

My job still won’t fit in one sentence. It doesn’t have to. The best description of it was never a sentence anyway. It’s what stays.