For years, local media publishers have been fixing problems with duct tape — one-time vendors, making their own tools, keeping freelance “experts” on speed dial and setting up workflows that only make sense at the time. It worked, until it didn’t. When staff left, budgets tightened, or a platform changed its rules, the foundation began to show cracks.
Shared services are not a brand-new improvement. They show a more basic understanding: five houses on the same block don’t all need to buy their own ladders, saws, and cement mixers, especially if none of them can afford to hire a full-time contractor.
For the first year that the Knight x LMA BloomLab has been running technology-sharing services, a clear pattern has emerged. When shared services act like a general contractor, they work best. The job is to fix the wiring, stop the leaks, and ensure the building is safe so the people inside can do their work.
For publishers, this method bridges the gap between doing everything in-house and hiring vendors who don’t understand their business. Shared services can standardize fixes, prevent the same mistakes from recurring, and keep core systems running even when staff, budgets, and platforms change.
Why technology shared services?
No matter how big or small they are, most local newsrooms have the same technology problems. They often work with:
- Few to no technical staff
- Systems added to meet immediate needs rather than long-term plans
- Infrastructure that still works but hasn’t been kept up
- The need for better analytics, security and data use
As time goes on, technology starts to look like an old house that is still standing because of a series of well-meaning repairs. At the time, each repair made sense. When you put them all together, they make things more complicated than they need to be.
Shared services came about as a way to make these systems more stable without taking away local control from newsrooms.
Key lessons
Governance is more important than tools
Early experience shows that the success or failure of shared services depends on how work is prioritized, not on the tools used.
Publishers don’t want more choices or additional steps. They need help figuring out what’s most important right now, especially when everything seems urgent. Without a straightforward way to set priorities, shared services becomes another line of requests instead of a place to focus.
The best process is to make sure that everyone understands:
- What work is most important
- How to manage trade-offs when you don’t have enough capacity
- When quick fixes are more important than long-term gains
This structure lets publishers stop dealing with the loudest issue and start dealing with the most important one.
In this case, governance is more of a way to frame things than a set of rules. It helps publishers and shared services teams agree on the work.
Standardization is useful when it lowers risk
When technology shared services focus on systems that are essential to daily operations and hard to fix when they break, they work best. Standardizing these vital systems, such as hosting, backups, security updates, and core analytics infrastructure, helps keep the infrastructure stable and stops problems that could affect the whole newsroom.
You don’t have to force every publisher to use the same platform with this system. Instead shared services can support a small number of standard options. Limiting support to one or two platforms streamlines processes, allows people to share their knowledge and makes shared services scalable.
The point is not to have everything be the same, but to have reasonable limits. A set of supported systems simplifies things, reduces risk and makes it easier to fix when things break, without making every newsroom work the same way.
Stabilization, not innovation, brings early value.
The first step is to stabilize, not grow.
A lot of the early work is about fixing long-standing technical debt, such as getting rid of old systems, closing security holes, clarifying who owns essential infrastructure, and, in many cases, reducing the number of platforms used. Having too many tools, unused services and systems that no one actively maintains can often add more risk than value.
This step isn’t about adding new technology; it is about figuring out what doesn’t need to be there anymore. When you remove platforms that aren’t being used or are redundant, it simplifies workflows, reduces the risk of failure and makes it easier to support the systems that remain.
This work doesn’t often add new features that are easy to see, but it does add value right away. The effect is apparent in what no longer happens: fewer outages, fewer emergencies and fewer last-minute fixes. It’s easy to overlook these gains because they stop problems from happening instead of providing new abilities.
Trust is key to success
Shared services adoption depends on trust, which grows when publishers feel heard.
When technical decisions are explained in simple terms and grounded in shared experiences, newsrooms are more likely to adopt because they feel understood.
Listening is essential. Publishers often have to deal with anxiety about systems they rely on but don’t have control over. Recognizing those worries and explaining the trade-offs in plain language lowers doubt and raises confidence.
As time goes on, understanding takes the place of doubt. When editors and publishers understand the decision made and how to fix problems, they can plan with more confidence. Proven results back up that trust. Systems are more reliable. Problems happen less often.
In this case, trust doesn’t mean getting along with someone. It’s about being transparent and credible, and showing that you understand how each newsroom works.
Final thought
Technology shared services work when they make decisions easier and problems less stressful.
Publishers don’t want more systems, meetings, or jargon. They want fewer mistakes, better workflows, clearer priorities and infrastructure that doesn’t need constant care to keep working.
That, more than any one tool or platform, is what keeps the house standing.
Editor’s note: Illustration conceptualized by Apryl Pilolli and rendered by Google Gemini.