A referral is not a handover
The training has finished. The participant knows more than when they arrived and wants to test what they have learned. The person who supported them suggests another contact. That contact asks for a document, which depends on someone else. The third person replies that the matter does not quite fall within their remit. Nobody has necessarily been rude. Everyone has done a part of the work. Yet the person who needed to move forward remains in the same place, now carrying a collection of referrals.
This is a hypothetical scene, but it is a familiar one. It helps us think about the leadership of projects in which several teams and institutions share the same journey. In a development model such as the proposed CAE, the connection between learning, incubation, the market and delivery capacity has to be more than a sequence of names on a presentation. I am not claiming that such a network is established in any particular municipality. I am arguing about the responsibility required for an integrated proposal to become a coherent experience.
The space between teams carries the risk
There is a difference between providing a contact and securing a handover understood by both sides. The first may be enough when someone is simply looking for information. When there is an expectation of support, the question changes. Does the receiving person know what they are receiving? Do they understand the request, the limits of what has been agreed and the reason their intervention is needed? Without that clarity, every stage begins the conversation again and may quietly change the destination.
The person being referred also needs to know what to expect. They may be invited to an assessment rather than offered access to a service. They may need to prepare information before the next conversation. They may discover that the original proposal does not answer their actual need. Explaining these possibilities does not diminish the value of support. It prevents an organisation from creating an expectation that the next team will have to dismantle alone.
This is why the handover should be treated as part of the work, rather than as an administrative detail at the edge of it. A referral is a promise about continuity, even when nobody intended to make a promise. If the receiving team lacks the context to act, or if the participant does not understand the next step, the project has transferred responsibility without transferring the conditions needed to fulfil it.
Coordination must be specific
Those who coordinate have a particular responsibility at these boundaries. They cannot turn every difficulty into a request for everyone to communicate better. Communicate what, between whom and at which point? General guidance may sound constructive while remaining operationally empty. If the same problem keeps returning, we need to examine the actual passage: the information that was lost, the decision that had no owner or the commitment that was made without checking capacity.
In shared projects, people may genuinely want to help and still lack the authority to decide. A team may offer technical time without being able to commit additional resources. An institution may take part in a conversation without having approved a collaboration. A professional may suggest possibilities without speaking for the organisation as a whole. These differences need to be recognised, particularly when the ambition of a project encourages everyone to speak quickly about what would be desirable.
Good coordination therefore does not mean making every participant responsible for everything. It means making the boundaries visible. Who can assess? Who can approve? Who can provide a service? Who can alter the route when the original plan no longer fits? If these questions remain vague, the participant becomes the mechanism through which the project discovers its own uncertainty. That is not an acceptable design principle.
Enthusiasm cannot replace authority
Enthusiasm has value. It brings people together and opens conversations that might otherwise never happen. But it does not resolve who answers when interests diverge. If an activity serves one team while overloading another, who can revise the design? If a participant needs an answer that crosses several areas, who follows that question until there is a conclusion? An integrated project needs enough authority to deal with such situations, with limits that are understood by everyone involved.
This does not mean concentrating everything in a single person. That may simply move the place where the work waits. It means recognising which decisions require coordination and giving them a practical route. Teams should be able to resolve what belongs to them and identify what depends on another party. When that distinction exists, asking for help stops looking like an admission of incompetence and becomes a responsible way of protecting the shared outcome.
The real test is not whether a project can gather a large group around a common idea. It is whether that group can make decisions when the idea meets constraints. Capacity, eligibility, timing, expertise and institutional permission are not minor complications to be handled later. They shape the experience from the beginning. A project that ignores them may look integrated while quietly exporting its unresolved tensions to the participant.
Look at the actual case
A disagreement between teams may reveal that the proposal is asking for two incompatible things. The person supporting the participant wants speed; the person assessing a condition needs more information; the activity organiser has limited capacity. The temptation is to choose a culprit and end the discomfort. I would rather understand which commitment needs to change. There may be an individual mistake, but there may also be a design that turns anyone into the next obstacle.
To distinguish these situations, the conversation needs a concrete case. It is not enough to say that one team never responds or that another always asks for impossible things. What was requested, under which conditions, with what deadline and with what information? What had been confirmed? What was merely expected? Returning to these questions can remove some of the drama from a conflict and restore its usefulness. The issue stops being a dispute about intentions and becomes work on commitments.
This approach also protects people from a familiar failure of leadership: treating structural problems as personal shortcomings. A conscientious professional can appear unhelpful because the process gives them no authority, no capacity or no clear brief. Another person can appear efficient because they pass requests onward before checking whether the next team can receive them. If we only judge the final exchange, we miss the design decisions that produced it.
Receiving bad news early is a leadership task
The way leadership receives difficulty determines when it will hear about it again. If the person who identifies a failure meets only irritation, they may learn to report it later. If they find a firm conversation that can distinguish warning from blame, they have a reason to raise it early. The aim is not to create meetings without consequences. It is to ensure that information arrives while there is still room to choose a better response.
This requires a culture in which clarity is valued more than optimism. Teams should be able to say that a route is unsuitable, that a request exceeds their remit or that a promised step cannot be delivered as described. Such statements are not necessarily signs of resistance. They may be the earliest evidence that the project is treating an aspiration as if it were an agreed service.
Leadership also has to resist the urge to protect the project’s image at the expense of the participant’s understanding. A difficult answer delivered clearly is often more respectful than an encouraging answer that leaves someone waiting. Continuity is not the same as perpetual referral. Sometimes responsible support means closing a route, explaining why it does not fit and indicating what information may help with the next decision.
A clear ending is part of the journey
Not everyone will move through every stage. An assessment may conclude that there is no suitable framework, that preparation is missing or that another solution would be more appropriate. A serious project must be able to communicate that outcome without leaving the participant indefinitely in suspension. Continuity is not measured only by the number of referrals. It is also measured by the ability to conclude a conversation with clarity, respect and useful information.
That conclusion should return to the team that began the support, to the extent that this is appropriate and without unnecessary circulation of personal information. Otherwise the project never learns what happened to the people it referred. One team celebrates the activity it delivered, another records the requests it received, and nobody understands the distance between the two. The indicators may appear healthy while the participant loses confidence in the journey.
This is where responsible information practice matters. Feedback does not require everyone to know everything. It requires the project to know enough to understand whether the route worked, where it stopped and what should change. Privacy and learning are not opposing goals. They can be designed together when responsibilities are explicit and information is shared for a defined purpose.
Test the passage before expanding the programme
The question I would put to a coordination team is simple: show me a complete passage, from the initial request to the final response. Not the ideal presentation. A sufficiently clear case for us to see where there was understanding, where capacity was missing and who took each decision.
Before adding another activity to the programme, it is worth making sure that existing activities can receive one another’s work. That means testing the points where expectations change hands, where authority becomes uncertain and where a participant may be asked to repeat their story. It means checking not only whether a service exists, but whether someone can reach it through a route that is intelligible and supported.
Integration becomes real at the meeting between people. It is not secured by a diagram, a shared vocabulary or a generous list of partners. It is secured when a request can travel without losing its meaning, when limits can be explained without embarrassment and when somebody remains responsible for finding out what happened. The problem does not disappear because it leaves my team. Leadership begins when I decide what must happen next, and make sure that the next person is genuinely able to receive it.