Is your organization an archipelago?
An archipelago is a collection of islands. Sometimes, it refers to the sea containing a small number of scattered islands. We borrow the word to refer to an organization made up of many subsidiaries under a central governing authority.
If you are part of a:
- University
- State government
- Sports league
- Large media organization
Then you are probably part of an archipelago. Why does this matter? Why should you care?
Because in order to have a successful website, these types of organizations have some unique challenges to overcome. Sometimes, they have additional stakeholders to take into account. Or they might need to budget time for evangelism to persuade and entice other islands to join together in cooperation.
Either way, it's best to understand the terrain before you undertake a journey. So let's start by going over the most common types of archipelagos.
The three types of archipelagos
Each archipelago is unique, but most can be categorized in one of three ways.
Centralized
The central authority dictates the technical platform and its implementation across all subsidiaries. Everything flows from the top down.
Most of the staffing in terms of development, design, and strategy is usually part of the central authority, though the subsidiaries have content authors, editors, and other subject matter experts. Subsidiaries can write and publish content, but all content must adhere to the higher governing standards. In some cases, all content must go through an approval process.
Example: gov.uk
Decentralized
There might be a centralized organization, but they have no real authority. They can only make suggestions. Subsidiaries have their own staff and make their own rules. Sometimes, they even have their own branding and design systems. Each island is its own fiefdom.
Example: Harvard University
Mixed
There is a central authority, but the subsidiaries maintain some level of independence. These can vary widely. Sometimes the central authority controls the technology platform, and sometimes the subsidiaries can take their toys and do their own thing.
This mixed model is the most common. It's also the one that presents the most challenges.
Example: Georgia.gov
The challenges of governing archipelagos
While you might not think it matters whether you are part of an archipelago or not, when we start talking about websites, the importance begins to clarify.
Let's take a hypothetical mixed archipelago. It was organized this way because it makes sense that each entity owns the piece of the pie that falls within their area of expertise. But below the surface, there be dragons.
What if your central organization wants a coherent content strategy, but the subsidiaries don't want to play the same game? It can make recommendations, but it has no authority to enforce.
Do you invest money in a technology product, knowing that subsidiaries can simply reject it? How can you make sure a new project won't be a total waste?
How can the central organization juggle conflicting demands when it has no real authority to enforce terms and solutions? If it tries to take every need into account, it risks creating something that pleases no one.
On the flip side, there might be subsidiaries that have more influence, perceived importance, or political capital within the organization, and the tail can end up wagging the dog. With universities, this can happen with libraries or alumni associations.
You don't have these problems with a decentralized archipelago because there isn't a central authority to appeal to. There are still problems, but there is no expectation that a central authority has the responsibility to fix the problems. Responsibility is as decentralized as everything else.
A mixed archipelago doesn't have this luxury. A central authority will have at least some responsibility, so it must come up with an answer for these problems.
Forgotten end-users
With most websites, there are two main stakeholders: the organization and the end-users. This gets more complicated with an archipelago. You can now have the central authority, the subsidiaries, and the end-users they all serve.
This triangle can add a lot of tension. If some subsidiaries have strong political capital, the central authority can spend more time responding to subsidiary needs than to the needs of end-users. The true audience is forgotten.
You never see an RFP with this primary goal: design this site for tenured staff and the departments that bring in the most money from alumni.
But this ends up being the goal focused on by the central authority. They must cater to internal users before getting to the business of serving actual end-users.
How do you begin to manage this tension?
Intersections of success
It might seem counterintuitive, but you must focus on the people in the middle to find where all of their needs intersect. Subsidiaries all have different use cases and audiences, so your task is to find commonalities between them without excluding their unique aspects.
The best way to start finding these intersections: user research and talking to people. You must give people a voice, so they feel like they have been heard. There is no substitute for this.
- Treat internal users as end-users and go through the research process. This means developing personas, getting a good representation of each, and asking the right questions.
- Analyze your current content. Find the extremes and edge cases. Find the similarities between subsidiaries.
- Break down silos and build bridges. Don't let anyone stand alone. Start working on a ubiquitous language, so everyone understands what everyone else is talking about. Your island chain needs to be more connected.
After some common ground is established, you will need to figure out how to extract implementable ideas from it. You must remain focused on this common ground. If you don't, you risk isolating groups or individuals. They feel disempowered, so they strike out on their own to find solutions within or outside of the system. Measure, validate, and iterate.
Notice that we haven't talked about the technology yet. At this point, it doesn't really matter. Yes, it will need to be considered, and the decision will be an important one. You want something that will be flexible enough to meet subsidiary needs without leaving anyone behind.
But it will never be as important as finding out where these intersections of success actually are. No one benefits from implementing a solution that no one asked for, no matter how wonderful the underlying technology is.
Conclusion
Most of the problems in an archipelago are organizational and political, not technological. Managing these problems is never part of the official scope. Solving them will not happen overnight. Cultures can take decades to change.
But you can move the needle forward wherever it's possible, even if it's just a couple of inches here and there. Next thing you know, you've moved a foot, then a yard, then a mile.
Knowing where you are in the archipelago will help you understand where you need to build bridges. Giving people a voice will help make sure those bridges aren't burned down after you've built them.
The work isn't easy. But it's worth it.