This Is How We Do It

Why Everyone's Doing This Is How We Do It Wrong

I spend most of my week reading process documentation from teams that swear by the "This Is How We Do It" framework. Ninety percent of it is useless noise. The problem isn't the concept itself. The problem is that people treat it like a template to fill out rather than a living system that actually changes when the work changes. Here's what I've learned after going through three company restructures and watching this methodology get implemented, butchered, and occasionally done right.

The Core Idea You're Missing

"This Is How We Do It" isn't a document. It's a ritual. The entire point is that a team explicitly records what they actually do, not what they wish they did or what some consultant told them they should do. The friction between the documented process and the real process is where the value lives. Most teams skip that friction and go straight to a sanitized version that helps no one. I learned this the hard way in 2022 when our engineering team tried to standardize our deployment pipeline using this framework. We spent six weeks writing perfect documentation. Then we looked at what we actually did during incidents and realized 80% of the doc was wrong. The workaround I ended up implementing was brutal but effective: I started recording every deployment for two weeks without any documentation. Just raw observation. Screenshots, timestamps, who touched what, where everyone got stuck. Only after that did I write the actual "This Is How We Do It" doc. It took three days instead of six weeks and was actually useful.

How to Actually Implement This Is How We Do It

Step one is picking the right scope. Beginners always try to document everything at once. That's why it fails. Pick one specific workflow. Not "how we do development" but "how we handle a production database migration on a Friday afternoon." Specificity is the difference between a document people reference and a document people delete after reading. Here's the concrete method: Record the current state first. Before you write a single word of "how things should work," interview three people who actually do the work and shadow them for at least two complete cycles. Write down every step exactly as they describe it, including the shortcuts, the workarounds, and the things they do without thinking because it's become muscle memory. That last part is critical. The unwritten steps are usually the most important ones.

Then identify the pain points. Where do people get stuck? Where does handoff happen? Where does information disappear? This is the section most people skip because it feels negative. Don't skip it. The pain points are why this exercise exists in the first place. After that, you draft the actual process. But here's the counter-intuitive part: write it in second person as if you're explaining it to someone who's smart but has never done this before. Not "we deploy to staging" but "you push your branch to staging and then verify the environment variables are set before running the integration tests." The difference matters more than people think. Second person forces clarity. First person lets you hide ambiguity.

Common Pitfalls That Will Waste Your Time

The biggest mistake I see is treating this as a one-time event. The process document becomes stale within three months if nobody owns it. I've seen teams create beautiful "This Is How We Do It" wikis that haven't been updated since 2021. That's worse than having no document at all because it creates false confidence. Another pitfall: involving too many stakeholders in the writing phase. Every person who reviews the doc adds polish and removes practicality. Keep the writing team to two or three people who actually do the work. Let reviewers comment, but don't give them edit access. I had a case where twelve people reviewed a deployment checklist and it went from twelve actionable steps to forty-seven vague guidelines that nobody followed. There's also the tooling trap. People spend weeks setting up the perfect Confluence space or Notion database before writing a single line of actual process content. The tool doesn't matter. A Google Doc with a clear structure beats a beautifully configured wiki every time. Get the content right first. Optimize the delivery later.

When This Approach Fails Completely

Be honest about when "This Is How We Do It" doesn't work. If your team is smaller than four people, you probably don't need a formal process document. Verbal communication covers it. If the work is highly creative or research-based with no repeatable steps, forcing a process framework will just slow people down. And if your organization has a culture where documenting the real process gets you in trouble with management, don't bother. I've seen competent teams burned for writing honest process docs that exposed systemic problems leadership didn't want documented. In those cases, the alternative is lighter-weight. A shared checklist, a quick reference guide, or even a monthly team retrospective where people verbally walk through recent work and identify what worked and what didn't. Sometimes the best documentation is a conversation, not a page. One more thing that might save you hours: version everything. Date-stamp your process documents. Add a changelog at the top. When someone six months from now asks why Step 3 is different from what their manager told them, you'll have the history right there instead of playing archaeologist.

I still use this framework in my own work now. It's not perfect. It won't fix a broken team or a bad product. But when it's done right, it's the single highest-leverage thing a group of people doing the same work can do for each other.