One of the things I do when I work out or drive alone is listen to podcasts. One I’ve followed for a while is the Art of Charm, which covers self-improvement topics ranging from social skills and entrepreneurship to business and fitness. This particular episode stopped me mid-commute.
I was listening to episode 505 with Karen Baetzel, one of the first female Naval aviators. She talks about communication, leadership, and lessons from military culture that translate well outside of it. It’s worth your time.
One of the topics she covered was the difference between procedure and technique. She defined procedure as a standard regulation that can’t be arbitrarily changed — the policy or rule governing how an action is carried out. Technique, on the other hand, is the way an individual carries out a procedure in whatever manner they choose, so long as they stay within the guidelines.
Why It Matters in IT
This resonated immediately. We’re all aware of change management and how changes affect our environments — and we should all be documenting those changes. But there’s rarely a standard for how to create that documentation. I’ve worked in organizations where documentation quality fluctuates wildly from team to team, even department to department.
That’s technique running unchecked. Writing style, format preference, and tool choice are all fair game for individual variation — but the substance, structure, and minimum requirements of a document shouldn’t be left to chance.
What Good Looks Like
Procedures, policies, and work items should be documented well enough that anyone can walk in and take over. That requires a document standard — a template or baseline — created at the organizational level that each team adapts within their own style.
Think about what happens when it doesn’t exist: critical runbooks live in someone’s personal notes, deployment steps are tribal knowledge, and post-incident context is buried in an email thread from an account that’s been deactivated. The last place important operational information should live is in the mailbox of someone who’s no longer with the organization.
In a DBA context specifically, this applies to:
- Database build and configuration standards
- Backup and restore procedures
- Failover runbooks for AG or FCI environments
- Change scripts and their rollback counterparts
The technique can vary — some people write tersely, others verbosely — but the procedure should be consistent enough that a competent colleague can follow it cold.
Key Takeaways
- Procedure defines the standard; technique is how you personally execute within it. You need both.
- Letting technique replace procedure is how critical knowledge ends up siloed in individuals rather than the organization.
- A document template is a lightweight investment that pays off every time someone new inherits a system.
- If institutional knowledge can walk out the door with a person, it isn’t really documented.