Making cross-border collaboration readable inside a group of eleven banks
Eleven banks, twelve countries, and nobody had written down how any of them actually work.
- 01 Problem
- Cross-border work ran on personal relationships and trial and error, and left with the people who had learned it.
- 02 Approach
- Four rounds of client interviews, then one co-design session where practitioners voted on how the service should enter the organisation.
- 03 Findings
- Standardising communication would remove the local effectiveness that was absorbing the friction.
- 04 Outcome
- Moved the brief from unifying communication to making differences readable, and fixed the service to tooling people already had open.
When a cross-border project went badly, nobody could say where
Not because the reasons were complicated. Because they were unwritten. Response windows. Whether silence means agreement. Who is allowed to say a deadline is unrealistic.
The group had standardised the intranet — one design, one visual system. Our research found that language was the only variable that changed with it. Cultural adaptation had been reduced to translation.
We built two profiles from the interviews. One sat in group communications in Milan: once content left his hands he had no visibility on whether it was published, adapted or understood, and every signal he did get was accidental — a newsletter delay, an email from an employee. The other was a front-counter teller in Cluj-Napoca. The strategic whywas stripped out before it reached her, and she would not tell her manager she had not followed it: in that workplace, raising confusion reads as questioning authority. The award-winning new intranet sat on a desktop she reached during rare breaks, because her job faces customers.
Her silence was not a gap in the system. It was the system protecting her.
We stopped guessing how it would be adopted and put it to a vote
We wrote ten ways the service could enter the organisation — from a launch event run by headquarters, to two teams in different countries starting at the same time, to a pilot with a few self-selected teams — and took them into a co-design session with the communications and HR people who would have to live with the result.
Piloting won. The conclusion they left us with was blunt: leadership-led launches are inappropriate.
Then they took something away from us. Our research pointed at disagreement as the sharpest friction — who can object, and how — so we had put how disagreement is expressedforward as something the record should hold. They rejected it harder than anything else we proposed, and their reason became a rule: the record describes communicationbetween entities, not inside teams.
Nobody wants a company system that says silence means no in our team. So the service documents only what is observable between teams — channels, documentation norms, real working hours, meeting culture, vocabulary.
The friction still becomes readable. It stops asking anyone to expose their own team.
A record each team keeps about itself, inside the tools they already have open
I secured the access this section depends on. I got a manager inside the international division to walk us through what their internal systems actually look like — which ruled out a new platform before we could fall in love with one.
- 01Write it downA peer session led by HR and communications staff. Everyone writes alone before the group talks, so daily observations become stated norms.
- 02CompareBefore a project starts, each team sends one representative to put the two records side by side, then takes the result back to their own team.
- 03Use itDecentralised and daily. Under deadline pressure you look up the other team's record instead of sending an email into another timezone.
- 04Change itShort periodic reviews. When habits shift, the entries shift.
I led the interface design and produced all of it: modular templates that sit inside the intranet and Teams. No new tool, no new login, nothing for anyone to learn.
I also designed the comparison stage. Each collaborating team sends one representative, who puts the two records side by side and carries the result back to their own team. It was the cheapest form of cross-border exchange we could find that still changes behaviour — nobody travels.
The brief moved from unifying communication to unifying people. In practice that meant the service stopped being a standard to enforce and became a record teams keep about themselves.
We never ran a pilot. The adoption logic holds on paper, but the first domino needs one real team to go first, and we did not test that.
Four rounds of interviews and one session with three practitioners was enough to rule out wrong answers — standardisation, a headquarters launch, documenting internal politics. It was not enough to prove the right one. The session told us more about what not to build than about what to build, and we did not pretend otherwise.