How to Actually Run a Consortium Without Watching It Fall Apart

Picture this: You've assembled a consortium. Eight organizations. Different countries. Different business models. Different legal frameworks. One of them is Google. One of them is IBM. And you're the coordinator.

Your job is to keep this ship from sinking.

This is the position Kostas Tserpes found himself in back in 2010 when the European Commission funded the Socios project—a multi-million euro research initiative designed to leverage social media analytics to build business platforms for everything from citizen journalism to film production. Eight partners. One vision. Or at least, that's what the proposal said.

The reality was messier.

What makes Kostas's experience valuable isn't that he managed a perfect project. It's that he managed something genuinely difficult and came out the other side with actual results. And more importantly, he learned something that almost nobody talks about: Managing a large-scale research consortium has almost nothing to do with project management and everything to do with human psychology.

The First Problem: Nobody Has the Same Vision

When you write a research proposal, you're selling a dream. You're describing a future that doesn't exist yet. And here's the problem: Eight organizations reading the same proposal are going to imagine eight different futures.

Google sees possibilities for their data science research. IBM sees a chance to develop new platform capabilities. A French software company sees a commercial opportunity. A German media company sees a different problem entirely. A university research lab sees a chance to explore new academic directions.

Everyone says they're excited about the same project. They're not. They're excited about completely different projects that happen to share the same funding.

Kostas learned this early and made what turned out to be a critical decision: Stop trying to force everyone into the same vision. Instead, find the overlap.

His job became less about management and more about anthropology. He had to understand deeply what each partner actually wanted. Not what they said they wanted in meetings. What they actually needed. What their organizations cared about. What their constraints were.

Because here's the thing nobody teaches you about consortiums: You don't manage by authority. You don't tell Google what to do. You don't tell IBM anything. You can't. You're too small compared to their organizational mass. So instead, you find the common ground between their interests and the project's interests and work there.

It sounds simple. It isn't.

The Relationship vs. Policy Problem

Kostas is clear about what didn't work: Trying to implement high-level management decisions that nobody actually agreed with.

When you're coordinating a consortium, the rules matter. But they matter way less than the relationships.

He describes situations where things seemed like they were going to collapse. Big companies with conflicting policies. Legal concerns that could tank the whole thing. Moments where it felt inevitable that someone would pull out and the whole initiative would fail.

And every time, the way through wasn't a better policy or a clearer process. It was people with good relationships doing extra work on their own time to solve problems.

Yaniv Corem, who was part of the IBM team, would spend hours understanding what the legal department actually needed, what they were actually concerned about, and then finding ways to keep the project moving while addressing those concerns. Not by compromising the work. By doing the human work of making people comfortable.

That sounds like overhead. It's actually the only thing that works.

This is what most organizations miss when they scale. They think: "If we can just get the systems right, the processes right, the coordination right, this will run smoothly." And then they're shocked when it doesn't. They're shocked when good systems fail because the people in them don't trust each other.

The systems matter. But trust is the infrastructure everything else runs on.

The Consortium Design Problem

Here's where it gets interesting though. Kostas didn't just inherit a consortium and try to manage it. He helped build it from the beginning. And the way he built it reveals something important: Consortium design is actually product design.

He and the team didn't just pick eight random organizations and hope for synergy. They identified gaps in the vision and then deliberately recruited partners to fill them.

They needed organizations that would use the technology in real contexts—not just theoretical academics. So they brought in Deutsche Welle, a major news agency, to explore citizen journalism applications. They brought in a film production company to explore crowdsourced casting and location scouting.

They needed someone to handle the technical integration. A French company called Cognum, who were doing exactly that kind of work commercially, became the platform integrator.

They realized they needed expertise in something obscure but critical: the economics of information. How do you assign value to what people contribute? That's not something most companies think about. But it's essential. So they brought in the University of Haifa, which had researchers specialized in exactly that.

They knew legal and privacy issues would arise. They brought in KU Leuven, a university known for interdisciplinary work between computer science and law.

At each step, they didn't add random partners. They identified a specific gap and recruited someone who could fill it.

This is completely different from how most consortiums get built. Usually what happens is: "Who's important in our network? Let's invite them." And then you end up with people who have resources and credibility but no actual reason to be there.

The Weekly Phone Call and The Physical Meeting

Kostas talks about two tactics that actually worked: Weekly phone calls, even if they were just 10 minutes of "hi." And physical meetings.

This sounds absurdly basic. I promise you, it's more powerful than most people realize.

The weekly calls weren't about making decisions or problem-solving. They were just about staying connected. About reminding everyone that this was a real relationship, not just a transaction. Ten minutes. Just talking. Sometimes that's all you need to keep people from drifting toward their own agendas.

The physical meetings were different. They served a purpose beyond information transfer. They created moments where people had to be in the same room together. Where misunderstandings could surface and get resolved in real time instead of festering in email chains. Where relationships could deepen.

This is something that video calls will never fully replace, by the way. I know that's a controversial thing to say in 2024. But the research is clear: There's something about being in the same room that changes how people interact. They're more patient. They're more willing to work through tension. They're more likely to see each other as human beings instead of obstacles.

The Uncomfortable Truth About Scale

Here's what Kostas learned that most people don't want to hear: As your consortium grows, your ability to manage it through relationships diminishes. At some point, you run out of bandwidth.

He had one experience where he tried to have a session where different consortium partners could talk to each other. A partner from ICCS was supposed to facilitate a conversation with Google. It went badly. The ICCS partner came back feeling like Google was trying to extract work from them without doing anything in return.

Was that actually what happened? Probably not. But it felt that way. And feelings are the reality you're managing.

Kostas realized that without a mediator—someone who understood all the relationships and could interpret intentions—bringing people together directly created more problems than it solved.

This tells you something important about consortium design: There's a maximum size at which you can hold things together through relationship work alone. When you exceed that size, you need systems. Clear protocols. Better communication infrastructure.

But the mistake most organizations make is thinking systems can replace relationships. They can't. Systems can reduce friction. They can't create the kind of trust that lets people work through difficult things.

Why This Matters Beyond Consortiums

You're probably not going to manage a multi-partner European research project. Most people won't.

But the principles Kostas discovered apply anywhere you need to coordinate complex work across organizational boundaries:

First: Recognize that written agreements are not the same as shared vision. People can agree to the same words and imagine completely different futures. You need to do the anthropological work of understanding what each person actually needs.

Second: Trust is not overhead. Trust is the infrastructure. You can have perfect systems and clear policies, but if people don't believe in each other's good intent, everything slows down and eventually breaks.

Third: Design your consortium (or team, or partnership) to fill specific gaps with specific people. Not "Let's work with important organizations." Rather: "Here's what we need, here's who has it, let's bring them in."

Fourth: Invest in regular, lightweight connection. You don't need long meetings. You need consistent, reliable contact. The weekly call that's just "hi" matters more than you'd think.

And finally: Understand that there's a scale limit to relationship-based coordination. When you hit it, you don't abandon relationships. You layer in more formal systems to support them.

The Real Outcome

What's fascinating about the Socios project is that the "deliverables" most people would point to—the platform API, the tools they built, the software they released—weren't really the most valuable thing. Those things became obsolete relatively quickly as the underlying social media platforms changed.

The real value was the knowledge the partners gained. How to work with social analytics. How to leverage user-generated content. What the real possibilities and constraints were. And for some partners, like Deutsche Welle and a consultancy called ATTC, there were even tangible commercial outcomes—they continued working together after the project ended and built actual products that went to market.

But that only happened because of the relationships. Because people trusted each other enough to see what was possible beyond the formal project boundaries.

---

Want the Full Story?

Kostas Tserpes is now a faculty member at Harokopio University of Athens, working on AI model architectures and distributed systems. His experience managing the Socios project across eight organizations in four countries and multiple continents is a masterclass in how to coordinate complexity without losing your mind.

If you want the full conversation—including specific examples of what worked, what didn't, and how to handle conflicts between major technology partners—listen to Yaniv Corem's interview with Kostas on The School of Innovation podcast.

Because here's the thing about managing large-scale projects: The technical part is the easy part. Humans are the hard part. And the organizations that figure out how to coordinate human complexity without trying to engineer it away are the ones that actually get things done.

The question is: Are you willing to do the relational work?