Infrastructural Avoidance. Why Expert Institutions Ignore Their Tech Stack
In consulting, think tanks, research organizations, and other expertise-driven institutions, communications still often mean, first and foremost, text: press releases, reports, posts, newsletters.
Platforms, databases, site architecture, technology choices, and the adoption of new tools (everything through which these texts actually reach anyone) are often treated as a separate, peripheral, support function. Something “IT people should handle”.
Infrastructure is not treated as part of communications strategy and practice, but as a thing in itself: a closed zone handed off to a contractor or a colleague/subordinate and left untouched until it breaks, or someone forgets a password.
This is our inheritance from the past, and a consequence of our personal and organizational inertia. Platforms were chosen once every few years and never revisited.
But everything has changed… except us.
The environment now moves faster than a single strategic cycle can run its course. Platforms, formats, and solutions need to be reconfigured on the fly. A decision made three years ago and delegated “to the technical side” now rests on completely different conceptual and technical ground — ground that is already holding back further development.
And in our industry, this is a systemic problem. There are many reasons, but one of the most important is the absence of a direct link between communications development and revenue. Many organizations run on continuous funding (from government bodies, parties, foundations) or on grants.
Even an annual report with big numbers (never mind of what kind of numbers) is often already enough.
Everything described above is both a cause and a consequence of what I call the “infrastructural avoidance” among communications leaders across expert organizations (by analogy with the concept of information avoidance developed by Russell Golman, David Hagmann, and George Loewenstein).
Symptoms of “infrastructural avoidance”
Plans are formulated without any grounding in the existing infrastructure (its capabilities and its limits) and instead are built purely from more abstract concepts: mission, vision, and the like.
Annual communications plans are written as last year’s numbers plus 15%, with no deeper review, and the metrics that communications work is measured against are never revisited and are formulated with no connection to infrastructure at all.
Infrastructure automatically becomes “not my area” in how the communication leader frames things, even when it determines what’s possible in the first place. This shows up, for example, in how little space infrastructure gets in annual plans and reports (usually close to none).
The core metrics are: number of reports published, number of press releases sent, subscriber counts, and (God help us!) social media reach.
The annual communications budget either leaves out or barely covers maintaining and developing the technical side of infrastructure: everything from hosting and support to automation services and third-party platforms.
Success is always credited to content (”that post worked”).
“Innovation” in the organization always means a new content format and almost never a new infrastructural decision: a different way to collect or use data, a new integration.
The communications leader can’t explain, in two sentences, how the current stack of tools actually fits together — the website, the automations, the newsletter platform, the analytics — and keeps asking what these Vercel charges they’re signing off monthly on even are.
You’re invited to a communications meeting (weekly, monthly, quarterly, or annual), and the only thing discussed is the content plan.
All knowledge of the existing communications infrastructure (and all intention to develop it) sits with a single employee. Their departure means, at best, a long stall in development; at worst, a panicked scramble for passwords to unfamiliar services and agonizing attempts to figure out what does what and how.
Without understanding what the existing infrastructure can and can’t do (its potential for development, or the lack of it) it’s nearly impossible to put together a communications plan that actually works.
Unless, of course, press releases, holiday posts, and photos from the latest conference are the entire arsenal you’re after.
The infection spreads slowly
It starts innocently: delegating a technical task because “it’s beneath my level.” Soon, foundational concepts, skills, and solutions fade away. It’s like sleeping at the back of the classroom through the first few chemistry lessons, then trying to figure out what the teacher is even talking about.
A few years in, all that’s left is a “good pen,” media contacts, and a fear of being exposed. Resistance to innovation is rarely strategic skepticism; it’s anxiety over showing how far behind you’ve fallen.
Organizations default to comfortable press releases over working email funnels simply because the old way doesn’t force them to confront what they no longer understand.
I know real cases where a company’s marketing plan for a professional event left out an existing newsletter with thousands of subscribers, betting on press releases instead, simply because a press release is straightforward, while building a working email system, a funnel, and the connections between registration platforms and tracking is hard.
What do we do about all this?
Our industry — small and mid-sized consulting, regional and national think tanks, research institutions, expert NGOs — isn’t made up of huge corporations. These are organizations of 10 to 100 people, and in organizations that size, the communications lead often is (and honestly should be) at least a partial operator of their own stack.
Our main task is to pull technological infrastructure out of the “someone else’s responsibility” zone and back into the core of communications strategy.
There can be many solutions; I’ll walk through a few that can help.
What can the Organization’s Leader do?
Your main job is to tear down the organizational wall between “content” and “hardware,” and to change the incentive system.
Rethink communications KPIs.
Stop evaluating work purely by output volume — number of releases, reports, posts. Metrics like these incentivize a “production line”: a research organization turns into a factory for churning out PDFs, texts, and posts, while the infrastructure for delivering and retaining an audience never develops.
Introduce metrics for infrastructure and distribution quality.
Example 1
Time-to-reach: how long after publication a piece reaches, say, 50% of its eventual audience. It shows whether distribution is active or just a slow organic trickle.
What this pushes you toward: moving from single-shot publication to multi-channel distribution infrastructure — segmented auto-sends, re-engagement workflows inside your newsletter platform, media kits prepared as structured data rather than a PDF someone emails on request.
Example 2
Owned vs. borrowed reach: share of audience reached through channels you control (newsletter, direct) vs. channels you don’t (social algorithms, aggregators). This is a proxy for how dependent you are on platforms you can’t influence.
What this pushes you toward: building and owning your own distribution infrastructure instead of depending on platforms that can change the rules overnight. It pushes toward direct relationships — co-publishing with allied organizations, guest slots in their newsletters, personal outreach — rather than hoping an algorithm surfaces your report.
Example 3
Findability: can someone locate a specific finding across five years of your reports?
What this pushes you toward: treating the archive as a knowledge base, not a chronological dump of reports. That means a real tagging taxonomy (internal and external), cross-links between related pieces, and periodic audits of old publications — rather than a site that only ever points forward to the newest thing.
Example 4
Cross-report engagement: does a reader who engages with one report go on to engage with others, or is every piece an isolated dead end?
What this pushes you toward: designing publishing infrastructure as a connected body of work rather than a series of unrelated one-offs — deliberate cross-referencing between pieces, thematic series instead of scattershot publication, a “related reports” layer on the site and in the newsletter, and follow-up sequences that route a reader from one piece into the next based on what they actually engaged with. This is where distribution infrastructure and knowledge-base depth start to depend on each other.
What can the Head of Communications do?
Your job is to overcome the fear of not knowing, take ownership of the stack, and make it visible.
Run a “one-page infrastructure audit.”
Draw a simple diagram (in Miro, Notion, or on paper): how does someone find out about the organization, where does their data go, how do they receive the newsletter, where is the analytics stored, and what does each link in that chain cost — including that Vercel or MailerLite invoice. If the setup isn’t clear to you, that’s a signal to go figure it out immediately.
Shift the planning focus:
Stop planning a “content calendar” and start planning “distribution mechanics.” Every new research report should be planned alongside an infrastructure decision: How are links tagged? How does the auto-funnel work? How is the report indexed and reused?
Legalize the right to not know — and to learn.
Admit to yourself and your team: “I don’t need to know how to write code, but I do need to understand the logic of attribution and how data moves.” Set aside working hours for learning tools, and treat that time as a direct job responsibility, not “self-development” on the side.
Recognize the digital stack as a core asset
Build SaaS, automation, CRM, and support costs into the base communications budget as a protected line for development — not as leftover “IT expenses.”
What can the Communications Manager do?
Your job is to move from the role of “copywriter/content-maker” to the role of “communications system operator.”
Take on an adjacent technical role.
Become the team’s go-to person for one specific piece of the stack — how the Airtable/Baserow database is built, how analytics are set up in GA4, or how trigger-based emails are configured. This sharply raises your professional value.
Translate technical friction into the language of losses.
Don’t just complain, “our sign-up form is clunky” — document the fact: “Because the registration form doesn’t connect automatically to our email service, we lose 30% of event participants instead of converting them into subscribers.”
Keep a “knowledge map” and document your part of the system.
Write simple instructions (SOPs) for every routine operation, from uploading a podcast to exporting a database. This frees you from repetitive work and protects the organization from stalling if your role changes.
Design automation for routine tasks.
Ask yourself: “If I’ve done this manual, mechanical thing a third time — copying contacts from a form into Excel, laying out the same type of announcement — how do I automate it in 15 minutes?”
All of this will either help fix the system, or at least let you walk away more capable than when you arrived :)
I write about what I actually work on inside expert institutions and knowledge-driven organizations. How to build not just the production of new knowledge, but the technical and project infrastructure around it. So the process of producing new knowledge doesn’t end with a published report and three social media posts, but continues: reaching new audiences and becoming more accessible and applicable.
Thanks for reading!
See you next week!
Best,
Danil | Make It Work