[TL;DR] Documentation investments become easier to discuss when they are framed as repeatable organizational capabilities tied to priorities leaders have already named, rather than solely as repairs to the documentation team’s local pain.
I’ve attended many meetings where documentation teams tried to explain why they needed to change the way they created content; and why they needed funding to make that change.
Those conversations rarely went as the teams hoped. 😕 More often than not, the meeting ended with someone saying, “Let’s circle back on this,” which is corporate shorthand for “This is not a priority.”
Why Pitches Fail
Over time, I started noticing what happened before the ask. The docs team would describe the friction it was living with: repeated rework, inconsistent content, weak governance, or tools that no longer fit the job. The list of frictions would inevitably be accompanied by complaints about tasks that irritated them and distracted them from making progress. All actual problems. But the business case they were attempting to communicate was often being built from the doc team’s experience of the friction.
Jed Simms spent his career studying why projects succeed or fail — as an IT strategist at the Boston Consulting Group, and later as founder of the project-value advisory firm Totally Optimized Projects. He called the business case itself “the greatest destroyer of value.” That line describes a problem I’ve watched doc teams often run into. They know why the current situation hurts, while leadership still needs a reason to connect the proposed investment to explicit business goals.
Alyson Riley, Andrea L. Ames, and Eileen Jones described a related problem while working at IBM. Writing in Intercom, the magazine of the Society for Technical Communication (now defunct), they wrote:
“Our industry as a whole is starved for data that prove the business value of content—particularly post-sales technical content—using facts that resonate with our colleagues in business strategy, finance, sales, product management, and marketing.”
That was 2013, and the problem still feels familiar today.
I’ve made a version of this argument before — that technical content deserves credit for its role in sales as well as support. The same gap shows up when tech doc teams try to justify investments in structured content, content operations, or a component content management system. The team can clearly see the need. Leadership not so much. They usually are receptive, but they need to hear the how the request for support is directly connected to something it already cares about.
