Nobody Hands You the Manual

Lenora is the happiest baby I have ever seen in my life. I am not exaggerating. We are fairly convinced she actually smiled at my husband in the delivery room. She is just... delighted to be here.

Until she's hungry.

The moment she realizes a bottle is not immediately in her mouth, something switches. The smile disappears. The eyes go wide. And then she becomes, and I mean this literally, a banshee. Zero to inconsolable in about 0.67 seconds flat. There is no warning, there is no grace period, there is no negotiating with her.

The problem was the logistics. After a really scary NICU stint early on, I decided to exclusively pump so we always knew exactly how much milk she was getting. Which meant the milk lived in the fridge. Which meant it needed to be warmed up. We had the fancy warmer, the good one, and it still took three minutes. Three minutes of Lenora screaming is not something I would wish on anyone.

I spent a lot of time researching and brainstorming until I figured something out. Breastmilk is safe at room temperature for over four hours. I was pumping every four hours. Which meant that as long as I was producing enough, there was always a bottle of fresh, room temperature milk ready to go. We kept the current bottle out, stored the surplus in the fridge, and moved anything beyond that to the freezer as needed.

We didn't get a faster bottle warmer. We redesigned the system so the bottleneck didn't exist anymore.

It sounds small. It was not small. It changed everything.

I've been thinking about that solution a lot lately in the context of something I've run into more than once as a Quality Engineering leader: the documentation problem.

Every QE org I've walked into has had some version of it. Knowledge scattered across tools nobody updates. A wiki that was comprehensive two years ago and hasn't been touched since. Processes that exist only in the heads of the three people who've been there the longest. New engineers who spend their first month asking questions that should have been answered before they started.

The instinct, when you see this, is to write more documentation. Build a better wiki. Create a runbook. That's the bottle warmer solution, you're trying to warm things up faster instead of asking whether the fridge needs to be involved at all.

The real problem isn't that the docs don't exist. It's that the system was never designed to keep knowledge fresh, accessible, or owned.

At one company I joined, there was a beautifully organized Notion workspace for the engineering team. Detailed, structured, clearly loved. Quality Engineering had a folder. Inside it was a collection of pages that ranged from slightly outdated to completely obsolete, with no way to tell which was which, no owner on any of them, and no clear connection to how the team actually worked day to day. It wasn't malicious. Nobody had decided to leave QE behind. It had just never been treated as a first class citizen of the knowledge system.

New engineers would find it, try to use it, and get quietly misled. Experienced engineers had stopped looking at it. The knowledge they needed lived in Slack threads, in the memory of whoever had been around longest, and in undocumented conventions that you only learned by making the wrong call first.

That's not a documentation problem. That's a knowledge culture problem. And you can't fix it by writing more pages.

Here's what I've found actually works.

Treat QE documentation like a living test suite, not a filing cabinet. A filing cabinet is for things you store and occasionally retrieve. A living test suite is something you run, maintain, update when it fails, and deprecate when it's no longer relevant. Documentation should behave the same way. If a page hasn't been touched in six months, it probably needs a review date, an owner, or a deletion.

Build onboarding so that it teaches people how the system thinks, not just how to use the tools. The goal of a good QE onboarding isn't to get someone filing tickets correctly in week one. It's to give them a mental model of how quality works in this org, what the team owns, where the risk lives, how decisions get made, and what good looks like. That can't come from a doc. It comes from pairing, from shadowing, from structured conversations with the people who carry that context in their heads.

Make knowledge transfer a team responsibility, not an individual one. When knowledge lives in one person, it leaves when they do. The goal is to distribute it, through documentation that's actually maintained, through onboarding buddies, through rituals that create regular opportunities to surface what's known and share it.

Nobody hands you a manual. In parenting or in engineering. The goal isn't to find one. It's to build a system so good that you barely need one.

What does knowledge management look like in your QE org right now? And when someone new joins, what do they actually learn on day one, and from whom?