The ecosystem hackathon: one challenge, several entities

An ecosystem hackathon is a hackathon co-owned by several organisations because the problem belongs to none of them alone: a patient journey that crosses a ministry, hospitals and insurers, or a trade process that touches customs, ports and logistics firms. It succeeds when the owners agree four things before anyone writes code: the one shared challenge, what data each will open, who owns what comes out, and who will carry the winning ideas afterwards. Most of the work happens in the eight weeks before the event, not during it.

This piece covers the multi-owner version only. For the general mechanics of running the event itself, see How to run a hackathon that produces something real. For the bigger picture of entities working on shared problems, see Ecosystem innovation.

Why ecosystem hackathons are different

A single-owner hackathon has one sponsor, one set of systems and one decision-maker. An ecosystem hackathon has several of each, and the friction shows up in predictable places:

• The challenge drifts. Each partner pushes its own priority, and the brief becomes a list of five problems.
• Data arrives late or not at all. Legal teams in each organisation review separately, at their own pace.
• Judging turns political. Each partner quietly hopes "its" team wins.
• Nobody owns Monday. A solution that needs three organisations to change usually has no single home.

The upside is real: participants see the whole journey, not one organisation's slice of it, and the partners meet each other's people working on the same problem for the first time. Many ecosystem hackathons matter less for their winners than for the working relationships they create.

How to run one, step by step

1. Map the ecosystem before you pick partners. Draw an ecosystem map of the journey you care about: who touches the user, who holds the data, who sets the rules, who pays. Then decide who must be a co-owner and who can be a contributor. Three to five co-owners is workable; more than that and decisions slow to a crawl.

2. Agree one challenge, written from the user's side. Run a half-day session with a decision-maker from each co-owner. Use a problem tree on the shared journey, then write one challenge statement that names the user and the moment where things break between organisations. If a partner's priority does not fit, it goes into a later event, not into this brief. See How to write a challenge statement people want to solve.

3. Sign a short memorandum before announcing anything. Two pages is enough. It should cover: the challenge; each partner's contribution (money, data, mentors, venue); intellectual property (usually teams keep their IP, with partners getting a right to negotiate first, but your lawyers decide); data terms; how judges are chosen; and who leads each phase. Agreeing this after the announcement is how events get delayed by months.

4. Prepare data early, and prepare it jointly. Decide which datasets each partner will open, in what form (real, anonymised, synthetic or sample), and under what terms. Put them in one place with one description format. Give legal and data-protection teams a deadline at least four weeks before the event. If a partner cannot open data in time, a realistic synthetic set with the same structure is better than nothing.

5. Assign one lead and a clear role chart. Co-ownership does not mean co-leadership of every task. Name one lead organisation for logistics and communications, and use a RACI for the rest: who approves the brief, who recruits, who provides mentors, who signs off winners, who funds the follow-on.

6. Recruit participants across the ecosystem. Mixed teams are the point. Reserve places for staff from each partner, and aim for teams that combine at least two organisations plus outside developers, designers or students. Ask each partner to send mentors who know their part of the journey and can answer "how does this actually work on your side?"

7. Build a joint judging panel with published criteria. Each co-owner nominates one judge; add at least one independent judge. Publish the criteria before the event and weight them (a weighted decision matrix works). Include a criterion that rewards solutions working across organisations, not inside one. See Judging criteria that pick the right winner.

8. Run the event with a shared journey on the wall. During the hackathon, keep the full user journey visible, with each organisation's part marked. When a team's idea needs a change from a partner, they should be able to see who and to ask that partner's mentor in the room.

9. Decide the follow-on before the final day. Agree in the memorandum what winners get: a pilot with named partners, a fixed period of support, access to real systems. Name one owner per winning concept and a date for the first follow-up meeting. A stakeholder communication plan keeps all partners informed after the event, when attention fades.

Illustrative example

Illustrative. In a European port city, the port authority, the customs agency, a trucking association and the city's transport department shared one frustration: lorries queuing for hours on city roads waiting for clearance and slot times. Each had tried fixes on its own.

They spent seven weeks preparing. An ecosystem mapping session revealed that the delay sat between three systems that never exchanged arrival estimates. The single challenge read: "How might we give a truck driver arriving at the port a reliable time to come, before they reach the city?" The memorandum gave teams ownership of their code, gave the four partners first right to pilot, and committed each partner to one mentor for the full event. Customs could not release live data in time, so the port authority's data team built a synthetic set with the same structure.

Fifteen teams took part, each with at least one member from a partner organisation. The judging panel had four partner judges and one independent chair. The winning concept was a shared arrival window that drew on all three systems. Because the memorandum already named the port authority as follow-on owner, a twelve-week pilot started the month after the event.

Do's and don'ts

Do

• Agree on one challenge. One clear problem beats five partial ones.
• Sign the memorandum before the announcement, including IP and data terms.
• Name one lead organisation for logistics, and give everyone else a clear role.
• Reward cross-organisation solutions in the criteria.
• Fix the follow-on owner and date before the winners are announced.

Don't

• Don't invite every possible partner as a co-owner. Contributors can help without voting on everything.
• Don't let data access be a last-minute question. It is the most common cause of delay.
• Don't let partners judge their own staff's teams without an independent voice on the panel.
• Don't brand the event as one partner's. Shared problems need shared visibility.
• Don't end with a group photo and a press release. Without a pilot path, the event confirms that cooperation is for show.

Questions people ask

Who should own the intellectual property in a multi-organisation hackathon? There is no single right answer, and your legal teams must decide. A common arrangement is that teams keep their IP, while partners get the right to negotiate a pilot or licence first. What matters most is that it is written down and published before people register.

How many organisations can co-host one hackathon? Three to five co-owners is workable. Beyond that, add organisations as contributors (mentors, data, venue) without giving each one a vote on every decision.

What if one partner cannot share its data? Use a synthetic or sample dataset with the same structure, describe it honestly to participants, and plan for the real data to be used in the pilot phase under a proper agreement.

Methods to prepare with

Start with an ecosystem map and a stakeholder expectations map to see what each partner wants. Agree the challenge with a problem tree, then share out the work with a RACI. For the full range of formats, see the hub guide to hackathons, jams and challenges, and for convening a whole sector beyond one event, How ministries and regulators convene a sector around one challenge.