This is the transcript of a talk that I gave at LeadDev Berlin 2024. This was my first big conference talk, in a big room, but I’m happy with how it went. Revisiting the text of this, I realise that most of my humour relied on visual gags in the slides, so this will probably read a bit dryer than the video, which is over here.
The conference organisers are excellent; I felt really well looked after and supported. If you get the chance to attend or speak at a LeadDev event, go for it.
We are surrounded by borders.
Everywhere you look, we’ve drawn these lines: imaginary and real, big and small, and we’ve carved up the world into these neat little compartments. And on these lines we’ve built barriers: to keep us in, to keep them out. In the technology world, we’ve taken this to extremes. We’ve got teams working in sprints, writing objects, in packages, for microservices, to be deployed inside containers, in pods and namespaces… it’s borders all the way down.
The promise of all these borders is that the things inside the lines don’t need to care about what’s outside the lines. If that true, our teams could just smash out features unimpeded by what their colleagues are up to around them, but we all know that sooner or later there’s going to be some critical dependency that’s misbehaving, or a company-wide initiative that’s going in the wrong direction, or a problem that could be halved if only we could share it. So we need to look outside of our borders. But reaching out to unfamiliar teams can be quite intimidating. We’ve all got our own roadmaps and deadlines. We’re all trying to do more with less. It’s no surprise when our unsolicited bright ideas are met with indifference. So how can we make these people do things in our collective interest?
As luck would have it, this is not a new problem. There’s a whole industry out there dedicated to working across borders, creating influence, and applying soft power. While it not be going fantastically just now, there’s a lot we can learn from the work of diplomats and those who are trying to create peace around the world. I’m going to tell you a story about how my teammates and I fostered some new relationships to get some stuff done, and we’ll look at some of the parallels between international diplomacy and the dynamics in organizations like ours.
Context
For some context, here’s a bit about my organization: Form3 handles payments for some of the largest financial institutions in the world. If you’ve recently made or received a bank transfer, there’s a good chance that we handle it. You’re welcome. As for me, if you were to look at GitHub you would conclude that I’m someone who used to write code for a living. I spend most of my time drawing diagrams and talking to people, in particular relating to payments for the United States. The US is one of many business lines that make up Form3, each of which addresses a particular market. These business lines are not separate businesses, we’re not in competition. We all present a consistent interface to our customers, and we all consume a common set of APIs and platform services. One of these shared services is orchestration. We have orchestrators that coordinate the flow of a payment through our internal services and handle interactions with customers. This was initially built for our customers in the UK. It’s a really sophisticated system designed to meet the complex needs of our biggest banks with the performance required to handle a big chunk of the UK’s instant payment traffic. We in the US were the first team to build new products on top of this solution. Every market comes with its quirks and eccentricities, so our job was to figure out how to fit this orchestration system onto the unique requirements of the US. Over time we started to get some bad vibes about this arrangement. As a staff engineer, I was reviewing more PRs with gaps in understanding, I was attending a lot of calls where teammates had questions or complaints about the orchestration solution, and our team leads were stressing because every time one of their Engineers worked on something that touched orchestration it took much longer than expected. Our head of engineering assembled a group of his best eggheads to work out our options.
Our remit was quite broad, we could offer solutions anywhere on the spectrum from just telling our team to integrate better, to fully declaring independence from this company-wide core service. The power got to our heads, and the first mistake we made was when I named the Slack channel for our project: Orchestration Rebel Alliance. This naming biased our approach to the project. In fact, it summed up our whole attitude: we were not in the mood to engage with our colleagues. So in an undisclosed location, hidden from the orchestration team, we got to work building a proof-of-concept. We built, discussed, and iterated far beyond an initial toy implementation, and by the end of this process we were pretty convinced that we had our dream orchestrator. It was a big departure from the existing service, but we were confident that it solved all of our problems and probably those of the orchestration team. It’s just a shame they would never understand…
Cynicism
It’s really easy when we think about other groups of people to get lost in cynicism, and it’s quite natural to be reluctant to get into a conversation with them. Governments do this too. Governments often refuse to talk to groups of people that they see as agitators, and they usually will give three excuses for this:
- They don’t want to legitimize the group, because we can’t have these people telling us what to do
- They don’t think that the group can be reasoned with because they’re a bunch of delusional zealots, and
- They don’t believe that the group genuinely want a solution to the problem: they’re just a bunch of troublemakers.
When we are thinking about other people one of the many cognitive biases that leads us astray is the Fundamental Attribution Error. This skews how we explain other people’s behavior relative to our own. So when we think of ourselves, we usually see the circumstances that led us to behave in a particular way, but we’re much less charitable with other people. We tend to see their behavior as the result of some flaw in their character.
There’s a very real chance that we won’t understand our colleagues or their abilities or their motives unless we actually engage with with them. So the next time you feel like calling your coworker something unspeakable, maybe you should just talk to them.
Now you’ve got two jobs to do: First you need to find the right people. This should be straightforward enough, they’re not going to be in hiding from the authorities. Then, you have to accept that you need to talk to them, even that guy. Approaching and another team for our first time can feel a bit like a school disco. The fear of rejection is real. In large organizations, the people you’re talking to might have never heard of you, or even your team, so the social capital that you’ve built in your corner of the company might be worth nothing on the other side of the org chart. Some humility is going to help here. When negotiators first make contact with an armed group they often have to go through some quite intimidating introduction, like having to meet dangerous strangers in secret locations under cover of darkness. Now hopefully that won’t be necessary wherever you work, but it can be helpful to build trust in the same way by showing some vulnerability. Let them choose the date and time of the meeting, and set the agenda. If you work in an office, go to where they are. If you’re working remotely, allow yourself to be outnumbered on the call. Remember this is just the starting point. The goal of this first meeting is just to get to know people and to start normalizing the process of talking.
Reaching Agreement
Once we got talking, we didn’t think there was much left to do. We’d done our homework, we knew the problem space inside out, we had a solid proof-of-concept, we’d sunk a lot of energy into it at this point, so all we needed was for the orchestration team to acknowledge our genius and we’d be done. But there are no shortcuts here. You need to take the time to get there together, and I learned this the hard way. Initially, I was really impatient to reach agreement. I knew that our proposal was radical and I was skeptical that the orchestration team would accept it. So I watered down our suggestions. I only raised things where I thought we could reach agreement. This sort of self-censorship did two things: it delayed the orchestration team from understanding what we were trying to achieve, and it demoralized the folks who’d worked on the proof-of-concept. In the end, laying out the full spectrum of possibilities helped us to reach an agreement. If there’s some extreme outcome that neither of you want, putting it on the table gives you something to agree on. But if the extreme is appealing to you, then including it in your negotiations pulls the middle a little bit closer to where you want to be.
Code Wins Arguments — Code Challenges Assumptions
When we finally got round to unveiling our proof of concept, the orchestration team were underwhelmed. What we realized is that they’re busy people with ideas of their own and they were a bit frustrated they hadn’t had the chance to implement them themselves. We weren’t going to win just because we’d written some code. But working code was useful to challenge assumptions. When someone told us that something couldn’t be done, we had a running example to point to.
Tell Stories — Draw Maps
Ultimately, we needed to take our colleagues with us to help them understand the problems that we were facing. When we look to persuade others it’s really tempting to tell stories, because given a beginning and a middle, we expect everybody else to reach the same ending that we did. But people can feel when they’re being railroaded like this. I’ve seen people argue about a perfectly sensible premise just to derail an argument. Instead, we tried to draw maps to describe the landscape, look at its features, its pitfalls, and then agree on viable routes across it. Wardley Maps can be a really useful tool to visualize strategy. The key feature for me is that at the core of a worldly map is a value chain, with customer needs at the top. As I said before, different business lines within Form3 are not competitors; we succeed in fail together. In some cases we even share customers. A map like this can be a useful reminder of our common goals: we all succeed when we make our customers happy. We also got some value from mapping out our problems by visualizing our pain points and their relationships. Our colleagues could see for themselves where the most important most important bits were. They were also free to challenge any of our premises or the rationale that we’ used. Once we had a shared understanding of the issues, we could look to the properties that a solution would need to have in order to address them. By doing this we weren’t presenting our colleagues with a fait accompli, we could leave the door open to other solutions, or we could adapt the solution that we were offering. Crucially, we didn’t restrict our colleagues to picking one option from a list of possibilities. Instead, we showed them examples. We could evaluate each, mix and match their parts, or come up with something new. Or, since we’re in Germany, Keine Speisekartenangst, nur ein Ideenbuffet.
Use the Lingo
I apologize, I promise I won’t do that again. The thing is, communicating across cultures is pretty tricky. While it might not feel like the people in the office next door have a distinct culture, every group has its habits, its funny words, its ways of doing things, and we should be sensitive to those. Let me tell you about a beautiful mountain range in my adoptive homeland of Wales. If you’re unfamiliar with Wales it’s a country of about 3 million people just to the left of England. About a fifth of people there speak the Welsh language, many of whom will tell you that they’re unhappy with the influx of people buying up holiday homes in this beautiful location, and the effect that it’s having on Welsh speaking communities. There are two names for this place, and which one you use says a lot about your attitude towards it, and the people who live there.
We faced a similar problem. To those of us on the outside side, the orchestrator was a single entity, but to the orchestration team it was made up of an orchestrator — that they built and ran — and workflow definitions — written by market teams like mine. When I showed up complaining of problems in the ‘orchestrator’ I was confusing my colleagues, displaying my ignorance of the architecture, and was ultimately blaming the wrong people for the problem. Please don’t be like a British person abroad: learn some of the local terminology. It will help a great deal, both to convey your meaning and to show some respect for your peers. In much the same way, names carry a lot of baggage, so we need to tread carefully when we name things. But if you’re having a hard time picking a name that isn’t triggering for your colleagues then just pick something stupid. If you’ve got a service that does things, that’s a ThingDoer, or even call it Bob. You can pick a more sensible name later.
Third Parties
You might be tempted to involve a third party to help in your discussions but be careful about the role that you want them to play. We invited a more senior colleague to preside over our negotiations. This was a mistake because we’d actually been talking to each other quite happily until this point, but when he showed up we went from talking to competing, trying to win the approval of this third party. It also put him in an awkward position, trying to arbitrate over our negotiations with limited context. Where we had more success was having our senior colleagues reach out to their opposite numbers to make sure that people were made available, and that meetings happened. In international diplomacy, the best examples of third party involvement follow this pattern of facilitation rather than intervention. Katherine Ashton was the high representative of the European Union, a bit like a foreign secretary. She brokered a peace agreement between Serbia and Kosovo. She invited the leaders to meet in her office and they agreed that she would type the agreement, just because she was the fastest typist in the room, but she refused their suggestion that it be called the ‘Ashton Agreement’ in her name, and instead insisted said that every word of the agreement came from them. Ultimately they would have to defend it back to their constituencies at home. That story also reminds us that you can’t take the view of an individual even a leader to be representative of a group.
Meet Jeff
We quickly identified Jeff as an ally in the orchestration team. He’d been thinking along the same lines as us for a while. He thanked us for our involvement and shared some complementary ideas with us. We took this as a really encouraging sign that our suggestions would land well with the rest of the orchestration team, but when we got Jeff together with his teammates he was much less enthusiastic about our suggestions. Despite his seniority he didn’t feel that he could contradict his peers. If you want to get a real consensus in your organization, you’re going to have to speak to lots of people, together and individually, including that one one you’ve been avoiding. In the course of all these discussions sometimes things are going to get a bit heated. Some of the best advice I’ve heard is to concentrate on and respond to the words, and not their tone, but being the most chilled person in the room takes some energy and is no fun. So don’t forget to take care of yourself. Sometimes people will try to make themselves look like a big animal, they’re going to get loud, they’ll start swinging their arms about, showing their teeth, banging the furniture, which works because it appeals to the part of our brain that keeps us from being eaten by big animals. But they’re not going to eat you and this threat of physical violence is totally inappropriate at work. So now is a good time to remind yourself that you’re not actually trying to solve world peace. We’re just trying to get a job done. Luckily Zoom has an excellent feature for this. Right when when your colleague starts kicking off you just press the big red button in the corner and your situation will improve immeasurably. Leaving a situation like this is not a defeat. The way we win these battles is by coming back the next day. Sooner or later people realize that you’re not going to go away and they’re going to have to deal with you. This is actually an advantage that dictatorships have in negotiations. People realize there’s no point waiting around hoping for a change of leadership at the next election, so to make the greatest impact you just need to be there for the long haul.
The End?
So what happened? Did the Rebel Alliance take down the orchestration Death Star? Well, we agreed some changes to the orchestrator. This wasn’t our radical redesign, but rather a set of new features that could be added to the current orchestrator to give it the properties we needed. We could add these incrementally over time without changing the behavior for our existing customers, and allowing the orchestration team to evaluate them as we went. We also agreed that we would implement those changes so as not to disrupt their roadmap. Among those features were some suggestions from Jeff which we had dismissed to begin with but actually have turned out to be essential. In the end, after all the back and forth, writing of documents, and seeking approvals I’d started to really obsess over those little check boxes in GitHub that signified my colleague’s approval. It was a massive relief to me to finally see them all ticked off. But that’s not really the end, is it? We actually want the orchestrator to behave differently, so we need to implement the changes we’ve agreed. We’re partway through those now, but but I’m conscious that we need to land them soon otherwise we might have to negotiate them all over again.
I’m also happy to report that as an organization we’re working much better together now. We’re in much closer contact with our peers around the company, so the next time we feel like changing the world we won’t have to do it from scratch. My colleagues at Form3 have been great both for persevering through all of this while we figured it out the first time, and then for reliving the experience as I was preparing this talk. At the company offsite last month Jeff and I went on some roller coasters together reminisced about the project.
I want to wrap up by giving you three key takeaways. That’s what people do isn’t it? Three’s a nice round number. But really there’s just one: Do the work. You can’t expect to blind your colleagues with science, or charm, or irrefutable logic. You’re going to have to take the time to build relationships, trust, and a shared vision together. I hope this leaves you just a little better equipped to look beyond your own borders and to get talking.
Be kind.