Skip to Content

Networks and relationships

Collaboration on the time axis

Time Long version

A big part of my collaboration investigation is learning from people I respect. Joel Yarbrough, VP of Asia Pacific for Rapyd, sat down with me to unpack what makes collaboration hard, why cultural nuance is vital and why time, networks and customer engagement are keys to successful collaboration.

Below is the transcript of our interview, edited for clarity.

Will: Let’s begin with the basics. Are we correct that companies who collaborate more effectively are going to be more competitive?

Joel: Well, fundamentally that's true. Particularly in Asia, but worldwide, communities are an essential component of doing business. They're an important component of where you find customers and partners. They're an important component of where you find employees and teammates. It's how you develop relationships with regulators and people in a non-transactional or a less transactional manner. So, collaboration of all types is foundational to business, and developing some skills and behaviours around it. Figuring out how to position both yourself and your company in collaborative communities is very, very important going forward.

Will: I like what you said about developing skills and behaviors, because this is really where many people get stuck. Why do you think that's hard?

Joel: Let's start at one extreme. In an American public company, in particular, you have a quarterly tempo around results. You have an assumption that everything is about getting to a deal, So you end up with the impression created by many people that the American guy wants to fly in, browbeat you into making a deal, shake hands, and then assume that whatever you guys shook hands on will be executed exactly as intended. Whereas, the Asian model is much more about developing the relationship, understanding each other as people to some degree and understanding a larger set of organisational goals. Maybe there's an opportunity to work together right now, or maybe there's an opportunity to work together in the future, but almost inevitably, whatever you shake hands on will adapt over the life of the relationship.

It's not about the contract. It's about the spirit of the relationship and that contract - if there is one - is just something that codifies that you have a relationship over time, but the relationship will have many, many facets. And it may follow both of you over jobs and different industries, but ultimately you're building a network. And your company is building a network of partnerships. Obviously there's exceptions to both and those are both extreme examples, but that idea of these relationships, having a non-transactional component to them, is an important differentiator.

Will: This is the difference between selling products and serving clients.

Joel: Just one example. A friend of mine, a very, very successful entrepreneur with multiple exits, was flying from California through Hong Kong to Singapore. When he got to Singapore, I had lunch with him. He said, “Oh my God, my experience in Hong Kong was super frustrating. I was there to negotiate how we do our market entry into the China market.” And he said, “It's obvious that I've got to use Ali Cloud. I'm going to put my software in the locker and lose control of my IP. There's no way to do it. It's all ruined. It's endlessly horrible.” I asked, “How long were you actually in Hong Kong?” Three hours. In three hours, he thought you would negotiate the future of his business for China.

They realized the value of his product, but you still have to start the discussion acknowledging they have goals of their own; that they want respect and to be heard. They want to know that their assets are being valued, etc. Whereas he wanted to fly in, fly out, shake hands, and be done. It's just not how many things work.

Will: It seems this is one of the most awkward aspects of platforms and collaboration for many Financial Services firms. If you're going to collaborate successfully, it only works if both sides create value from engaging in this exercise. Traditionally, Financial Services firms have been structured and rewarded based around the amount of product sold. So if somebody is going to buy our product, we love that. However, if we have to give away some of our value in order to help them meet their goals, that's not as familiar. Where have you seen good examples of firms that made that cultural shift?

Joel: An easy one would be AWS. They've invested in business strategists to help you do everything because they realize that if there's a 51% chance you're going to use their services, they really just want you to grow your business. It's not essential that you do this or that, it's essential that your business be in a position to be successful. They hire successful entrepreneurs, bring them in-house almost as if they were a VC firm, compensate them well for the primary goal of building their network and getting people to use the platform in some way, shape or form.

They win in aggregate if the market rises overall, the same way that a Google, which is probably less good at opening their doors, give people consulting, advice and data to help them understand the tools. Even if it's non-transactional, they know that they have more than a 51% share of how you'll spend whatever money you spend anyway. It's easy for them to do it because they're the default place to spend your money in many cases. It's harder for someone who's much smaller to say, “Hey, let's build a huge network and then someday it will monetise”. If they're relatively smaller, they need to be a lot more focused on monetisation themselves.

To narrow it, most FinTechs exist in networks. Even much larger financial institutions are almost inevitably heavily ensconced within a network with webs of vendors and partners. Almost nobody does everything themselves. The industry cluster model is equally true in the clothing manufacturing sector and in many different sectors where people have intersecting needs that get leveraged in different ways over time. You're creating a collision of people that can help each other, even if they're not uniformly focused on the same goal at the same time.

"You're creating a collision of people that can help each other, even if they're not uniformly focused on the same goal at the same time."

Joel Yarbrough

Will: I agree with you about the example of AWS. Our friends at GCP will be sad to hear that they didn't come out as well in your scorecard, but the example is quite true. But I wonder, is it telling that the example you gave is from a technology company? Do you think incumbent banks or insurers or wealth managers get a fair assessment in terms of their willingness to engage in partnerships and collaboration?

Joel: In terms of external recognition financial institutions are definitely partner driven. Someone who's the biggest payments company or the biggest bank in their local market will be doing many B2B and infrastructural services on behalf of other banks. Or if you're international, you may be the primary correspondent bank, etc. So you're definitely sitting within a hub of relations, but it can break down. I used to work at JP Morgan, which has a huge correspondent network. But I didn’t see many examples of them saying, “Oh, customer number one, you should talk to customer number two because you guys could collaborate well together”. Instead, it was more, “Hey, work more with me and let's keep the customers away from each other”; or it never even came up.

The other view is to make our ecosystem larger because if our ecosystem wins, then we win by default. I don't think they approached it the same way that Zara would approach how their suppliers function. Tech firms are inherently interdependent on each other in many cases. Financial services firms start to exhibit more of these signs in elements of the market where APIs are available. APIs start to break down barriers because integration costs go down and the quality of what you're seeing can go up in a more measurable way.

"Financial services firms start to exhibit more of these signs in elements of the market where APIs are available. APIs start to break down barriers because integration costs go down and the quality of what you're seeing can go up in a more measurable way."

Joel Yarbrough

Will: There’s a real challenge for companies to incentivise a change in behaviour.

Earlier you said how difficult it is for smaller companies to build a large platform and wait for years to monetise it. In today’s macroeconomic environment, there is a lot more investor discipline and insistence on ensuring the unit economics are profitable right now. If that pressure's there and smaller firms need to focus on monetisation, what's the right approach for a smaller firm to take advantage of collaboration and platforms?

Joel: From my perspective, every company needs to be thinking about themselves, both as a publisher and a consumer of platform services. It's very rare that you're going to ring fence software or operational IP behind your web portal, salesperson, or a narrower set of channels. Instead, the best collaborators say, “Oh, we've got some process knowledge. We're going to convert that process knowledge into technical knowledge. Maybe we have access to some resources based on wherever we're coming from - effectively, we will be a manufacturer”. The way you expose knowledge-based assets or technology-based assets that you manufacture is ultimately through APIs.

Which, generically, you could say is part of a platform: the API and then the rules and business model that governs the API. Even if you are a very small company, you should be thinking about saying, “How does my IP get out into the market and scale, and how do I deliver at least one thing that someone else wants to use consistently?” That then forces you to think about what aspects of your business are human-based, but can sit behind or in the middle of a technical process, what can be engineered out over time through software. Ultimately, you're bringing your hard won business knowledge to bear thinking about the high-value elements of a problem versus the highly repeatable elements of a problem. That's what starts to turn into platform thinking. To go back to the JP Morgan scenario, one of the most important ways to be successful in the bank is to consistently improve the efficiency ratio of your business unit.

High top line performance isn't valued, whereas high efficiency is valued and that’s why Jamie Dimon believes that over time, the top line fluctuates, whereas an efficient bottom line generates free cash flow. So if you've organised your business as a system of interlocking systems that generate free cash flow at an increasing rate, ultimately you will have built a cash machine. As opposed to a machine where your day traders come and go and ultimately will go somewhere else for half a percent more and you've been left with nothing. The idea of building systems is the core of what you do and then monetising systems, even if your own desk sitting in front of it is the primary consumer, it's important to have that systems knowledge and systems thinking regardless of what business you're in. Even very small businesses should start life with that as their framework and look to expand access to it. Everyone should be thinking about how their IP, over time, becomes leveraged at an increasing rate and improves quality and efficiency over time.

"Everyone should be thinking about how their IP, over time, becomes leveraged at an increasing rate and improves quality and efficiency over time."

Joel Yarbrough

Will: That is very important to understand how that efficiency improves. One of the things that's quite hard is understanding some of those efficiency improvements will come from external sources, and are firms willing to open up to enable that improvement? Is it hard to structure a system or a platform in such a way that you're open to external input on efficiency?

Joel: It's hard in the sense of more hours in the day, more than anything else. If you think about the product management world, you have internal PMs who primarily have relatively limited exposure to the customer: maybe, 10% of their time. Most of their time is spent dealing with internal issues. Then you have people that spend time with the customer, but who may not have many windows to inject things into the product roadmap. You’re trying to marry those two tensions together. Much of the customer knowledge, insights, communications, etc. are held with the latter group.

But the latter group isn't necessarily able to turn 100% of that into actionable items for the first group. So there's a knowledge mismatch. If I'm in the product group and very internal facing, but I've got a window to say, “Oh, we're touching this particular widget. Tell me everything I need to know about how the customers want one to evolve, or help me interview a bunch of customers”. Then, in four hours, magically, this customer is going to tell me something that I'm really listening for when in reality, the customer’s got a billing issue, a content issue and 10 other issues, and they don't necessarily know what I care about. This communication impedance between the product and customer groups is a real problem. Ideally, you'd have these conversations often to find hooks that they marry up. Product teams need ways to receive direct customer feedback from the support process. Zendesk tickets should be turned into knowledge. At every turn you have to be focused on learning.

"The product manager needs to be reading a shit ton of tickets. There's knowledge again, stranded, which takes effort to understand."

Joel Yarbrough

Will: We've been talking a lot about what makes for effective organisational rhythms around engaging in platforms and with partners, collaborating to develop efficiency, and deploying your company's knowledge. As you look out over the marketplace, what are some platforms that you like? Who's doing a good job?

Joel: I mentioned AWS earlier. I see it a little bit less now than when they first came out, but every six or eight weeks or so you get an email from them saying here's a whole bunch of new features we're launching. But they're very rarely what I would consider very broad-based features. They're very often weirdly narrow features around one particular industry that implies an extremely deep level of knowledge of that individual industry. I always find it's just so incredibly impressive to think about, who on earth is getting that close to one industry segment to say, look, let's ignore 10 other things we could do that might be more broad and really help serve this one segment. And then, eight months from now, we'll go serve a different segment and a different segment after that, etc.

I've always liked Stripe because the breadth of their vision is very wide. Aspects of what they do are not particularly wide, in terms of the number of payment methods or the number of countries they operate in, but their vision for building a nervous system for payments that goes all the way through the lifecycle. Relatively early on in their life they had services like Stripe Connect, which is really cool, but barely utilised because most people don't really understand it. They committed to them a long time ago and have built around it. They haven't quite figured out how to get it into the market really in a way that it becomes the thing that they think it can be, but they really committed to this idea of programmatic entities and programmatic payments a long time ago, which helps them stand out from my perspective. They had a product architecture vision and a vision for what the future might look like, and then committed the organisation around it. That's pretty cool.

When you think about IOT, the idea of saying here's a transactional service that appears to be non-network, non-intelligent and relaunch it without those constraints. Once I've networked it, what can I do differently that it wouldn't have been able to do before? The product will be so much better than the alternative because they decided networking will be a core part of it.

If you look at Airbnb as a system, they decided a long time ago that their asset wasn't the real estate, it was always the people who travel and the people who host. They've had a tough time during COVID, but they had already started three, four years ago moving towards the events model and really understanding what it takes to enjoy a destination. Their ability to pivot and add in these other services is because their product was the community. It was always the social network more so than a network of real estate. If your product was managing hotels and no one needs hotels, then obviously you're out of business. If your product is people who feel a certain way, who think a certain way, who want to communicate a certain way, then you can have some resilience.

Will: You mentioned the community in the very beginning and that's so important to understand. So much of the model that we used before was inherently transactional, product-focused.

Joel: Back to the first point, once you take out the constraint of time - a relationship with a time constraint is transactional - the relationship is about many touchpoints, over time. Part of the big difference is having a more elastic definition of time.

In my case, I've been here for a little while and adapted to make messaging a big part of my daily business process. I'm now in a position that I can ping people I haven't seen in a long time, ask them a question, get an answer, get a rate card, cut a contract, literally, in nine WhatsApp messages because we already have a relationship. They're equally happy to have something be very efficient because that trust is already there in some way. That's the asset over time.

Collaboration Investigation Articles

See allChevronRight

Listen better: Collaborating with your customers

How can customers be empowered to select the Financial Services they want?

Submit your story