Scaling Impact: Building High-Performing Product Teams Across Borders

Romain Berthomé, Alex Burke at UXDX EMEA. Video: https://youtu.be/-fqGMNDQ_zY

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Designing the org around three sites

[00:00:10] Alex: It is great to be back at UXDX. I think there are about 300 people in here, and as Rory said, we come from about 30 countries, which I'm going to take a guess means that we're working in, or we're in, 10 different time zones. At our company, we have eight people here, and we're actually across five time zones. Romain is based in Amsterdam, and I'm based in Sydney, Australia, so you couldn't get a more distant time zone. This talk is going to be all about how you can bring teams together, how you can collaborate, how you can build culture, how you can build high-performing teams. So welcome, Romain. Romain has a team in Amsterdam, a team in London and a team in Bangalore, India. How do you think about that from a structure standpoint? Let's kick off with that.

[00:01:12] Romain: Yeah. Maybe just: hi everyone. Romain, head of product at Booking, and I'm really happy to be here today and share some insight into how we build high-performing teams across the globe. As you pointed out, in the area that I lead, which is around identity verification, we have three different sites that we operate across: London, Amsterdam and Bangalore. When we design orgs at Booking, one of the first things we think about is how we can get rid of any bottleneck, anything that is in the way of our execution speed. Because we want people who are located across different locations to be able to execute as freely as possible, without having to deal with geographic blockers or different time zone issues.

[00:01:58] The core thing we do is, when we design the charters of teams, we try to ensure that those teams can operate as much as possible individually, from strategy to execution, in order to ensure that there is nothing in their way. To give you a pragmatic example of how that translates in my area: when you talk about identity verification, essentially you're doing two things. You're collecting data about your users, and then you're verifying that data to ensure that people are who they say they are. For us, what that means is that one of our core tracks in Amsterdam is everything around collection of the data and storing of the data, and our other teams in Bangalore are purely handling the verification side of things. That means they're fully responsible end to end: from the strategy of which vendors they're going to integrate with, to the execution of integrating with those vendors, to how they optimize the metrics and objectives that are linked to the verification capability. That org design that you do at the beginning is really important to ensure that you can build successful teams across different locations.

[00:03:08] Alex: Is that helping, then? If you think about it, the Amsterdam team is almost like a centralized team.

[00:03:14] Romain: Yeah.

[00:03:14] Alex: And then you have your independent team in Bangalore. Does that help them in terms of speed, autonomy? Are those the main drivers?

[00:03:23] Romain: Of course. I think there is the theory around dividing roles and responsibilities across different time zones to be efficient, but it's not the only ingredient in the secret sauce that you need to have. I think one of the other key things is the culture that you try to have within your team. Because as much as you're trying to remove dependencies, if you have worked for, let's say, five or ten years in the industry, you know that at some point you will hit some roadblocks, and with anything you build in tech, at some point you need some teams to talk to each other. What's important there is to set up a culture within your team where you have strong ownership. Meaning that whenever there are dependencies across teams, people are not going to be looking at each other for too long wondering who is going to take the action, but people are actually showing up to take the next action. It's really important that you set up that culture, and I think we'll talk a bit more about that later, in order to ensure that whenever your organization design is falling short, people's behavior is proactively addressing it.

Working across time zones

[00:04:38] Alex: Yeah. What's your weekly setup, then? Because obviously if you're working across time zones, you're not always going to be working at the same time. When you think about alignment, are you carving out specific times of day where teams can collaborate?

[00:04:54] Romain: Yeah, of course. Where I'm lucky personally is that I have two of my teams located in Amsterdam and London, which we almost consider the same time zone, because there's an hour difference, and to be honest, plus or minus one hour doesn't make a big difference. But with our Bangalore team it's a bit more challenging, because we have a three-and-a-half to four-and-a-half-hour time difference. In that case, we have established processes and guidelines that encourage the teams, when they are working on projects that are going to have a really high level of dependency between two sites, to free up a bit more of their morning, in order to ensure that those are Bangalore-friendly times.

[00:05:33] Alex: European time, you mean. Europe.

[00:05:35] Romain: Exactly. In Europe and in the UK, we ensure that our first hours in the morning are a bit more free of meetings for European or UK colleagues, in order to be able to have those meetings with Bangalore. That's something that works on its own. Sometimes you need to remind people a bit when you get some feedback.

[00:05:59] Alex: Carve out that time.

[00:06:00] Romain: Exactly. But that's a guideline we have set, and I've seen it working at Booking, or at Uber when I was working previously at Uber.

[00:06:09] Alex: And is that how you manage it in terms of out of hours? For us to have a call, for example, one of us has got to either lean in early morning or late at night. How do you manage that balance and keep the team engaged and empowered?

[00:06:23] Romain: Yeah. I think one of the positive things that COVID brought is the remote-friendly aspect of collaboration. One of the things that we're trying to do, obviously, is to foster those morning calls for the Bangalore folks, to ensure that they can be in the office and be maximally engaged, because no one likes to have a call at 7:00 p.m. or 8:00 p.m., and we know that your attention drops. But at the same time, if we have mandatory calls or important meetings at that time of day, we're going to completely enable the folks to work from their home and take the call from their home, in order for it to be a bit more friendly with their personal setup. That's one of the positive things that the remote work environment brings.

Strategy, OKRs and autonomy

[00:07:15] Alex: Yeah. I guess because communication is reduced to certain time periods through the day, how do you think about your toolkit and enabling the team? You mentioned in a chat before that we were talking about AI and how much you're leaning into that. Do you want to share some of your thoughts around how you're approaching that?

[00:07:35] Romain: Yeah. What I like to do is really set up the framework clearly for my team. What I mean by the framework is ensuring that we set out really clearly our strategy and our OKRs: what is the direction we're trying to go in, and if we want to achieve that, what are the objectives and key results that it's going to translate into.

[00:08:00] Alex: Are they big goals? Are they big corporate goals, or are they more "in our next 90 days we need to have a run at this"?

[00:08:07] Romain: The objectives are going to be yearly objectives, but the KRs measuring those objectives are supposed to show progress on a monthly basis, as long as we make enhancements to our product. That allows us to ensure that during the year we keep being on track for those goals. And that's important to set up in order to ensure that your team can run autonomously, because once you have these guidelines and the strategy set, it's much easier to ensure that your team is operating with that context and embraces that context. You don't only need to define the strategy on your side; your team needs to co-build it with you. You need to have them advocate for it as their own strategy, so they have it in their core. And when that entire direction is embraced by everyone, you know that regardless of the remote work they're doing asynchronously, they're marching in the same direction as you.

[00:09:05] Alex: Right.

[00:09:05] Romain: That allows you to not be a bottleneck that they constantly need to check with. They can run.

[00:09:13] Alex: Things get lost in translation, right? How do you quality control that? Are you doing any special techniques? Are you just dedicating a short period of time where you manage the team in a certain way?

[00:09:28] Romain: Yeah. I would say there are different processes that we have established. First of all, when it comes to people, in the end we are all human, even if Zoom and all those other tools and Slack try to make us believe that we can work in an almost perfect remote world. No, you need to have human-to-human connection, because this is how you build trust. This is how you build empathy, and this is how you create the connection and the trust, which is extremely important in that environment.

[00:09:58] Regarding the people connection, what we have is weekly touch points with each of the PMs. That allows us, first, to have a bit of a catch-up, to know how everyone is doing and whether there are any potential issues. And it's also an opportunity for the team to bring up some issues they are struggling with and get some help. Sometimes you need more resources, sometimes you need more brain power on solving a specific problem because you're blocked. It's an opportunity for them to say: hey, listen, I actually need help here because I'm blocked, and I would like your help. That's a really important thing.

[00:10:40] Then our product development life cycle is, I would say, quite codified, in the sense that we give a lot of autonomy to the team when it comes to what they want to build and how they want to build it.

[00:10:56] Alex: Tools are open?

[00:10:57] Romain: The tools are quite open. I would say as long as you follow what is mandated by the company, and we actually have a lot of tools that are available, we don't prescribe that the teams work on X or Y tool. Because in the end, what we believe is that whatever makes you more efficient and whatever works best for your team is what works best for the company, because what we want is your success. Regardless of whether you use a spreadsheet or Jira or whatever to run your roadmap, it's totally up to you, as long as you're able to show that you're making progress towards the strategy, towards your OKRs, and that your product is healthy.

Offline monthly business reviews

[00:11:40] Alex: How would you check that? Because if you give total freedom, potentially, because of the geographies, you get fragmentation. How do you pull people in, and how are you managing quality and managing process?

[00:11:54] Romain: That's a great question. We have two main ways to manage the quality of a product area. One is more on the strategic side of things. One of the things that we have recently introduced is what we call offline MBRs. That's an MBR that is run completely offline. It's actually run with code in the background.

[00:12:19] Alex: Okay. Like an ongoing pulse check.

[00:12:22] Romain: Yeah. If you wish, it's basically code fetching all your roadmap activities and OKR updates from the different tools you use.

[00:12:32] Alex: Okay, so checking progress overall.

[00:12:34] Romain: Exactly. Producing a monthly summary, which serves as a base for discussions between the leadership and the different teams. The goal is to see: how are we doing on our strategy, from an execution and a metrics perspective? Are there some areas that are at risk, and if some areas are at risk, how can we proactively address those before it becomes too late? That's something we use in order to get rid of unnecessary work for the team, and we use it as a base for discussion.

[00:13:08] Alex: Is that an artifact that you're bringing in, or is it something that's almost like live reporting? Here's the dashboard, check in at any point.

[00:13:17] Romain: It's something that kicks off every month.

[00:13:20] Alex: But you're orchestrating that as a leader.

[00:13:22] Romain: Yes, exactly. Let's say I'm orchestrating the triggering of the discussions, but then it's up to the team to come up with their plan of mitigation in case something is going wrong, what asks they have of us, any risks that they want to call out. It's a dual responsibility, in the sense that I'm going to ensure that we're monitoring what's happening across the different areas, but at the same time each individual owner of the different areas needs to proactively come up with some suggestions.

Ownership, bias to action and a learner mindset

[00:13:53] Alex: Yeah, great. Booking.com has, I think, a great reputation in terms of the culture that it's created. How do you know if you've got a strong culture, and how do you know that you've got a strong culture within your team?

[00:14:08] Romain: Yeah. Maybe just before answering that, I would like to expand a bit on the different values in the culture that we have defined and that I personally embrace.

[00:14:19] Alex: Corporate values?

[00:14:20] Romain: They're a mix, I would say, of corporate values and values that I'm promoting in my own area. They're all aligned, ultimately; you should not have values that are essentially different. Why I really like them is because they are also mapped to performance, I think. That makes it really easy for people to embrace them and adopt them. There are essentially three. The first one is ownership. How do you show up as an owner, when things go well and when something doesn't go as well? And things will not go well every time, whether it's a bug that you have in production, or some bottlenecks or delays you are hitting on a project. What's important is, when things happen, do you show ownership? Do you show care about the problem, about the customers, about the company?

[00:15:15] The second thing is bias to action. There is, for each of us, I believe, some portion of our job that we don't especially enjoy doing, but sometimes in our job we have to do stuff. An example: you're a product manager and your data scientist might be sick or on vacation, and you need to get access to data. Or your user researcher is out, and you need to talk to customers in order to make a decision. You need to be able to roll up your sleeves and say: okay, I might not do as good a job as that person, because this is their job, but I need to do this in order to ensure that the product can move forward. Bias to action is the second one.

[00:15:58] And the third one is really the learner mindset. When things go wrong and you get feedback, what is your ability to ingest the feedback, reflect on it and act on it? For me, ownership, bias to action and learner are the three things that I'm looking at when I'm trying to assess candidates and values in my team. Those are the three values that I'm trying to promote quite heavily.

[00:16:23] Alex: And as a leader, how often do you refer to those? Are they things that you're trying to bring in on a daily basis, shouting out people that demonstrate those skills? Or are they things that you talk through as an onboarding experience: these are our corporate goals, these are the values that we're shooting for?

[00:16:41] Romain: I think there are different moments. One of them, as you point out, is onboarding. Whenever I lead a new team, or whenever I'm onboarding a new joiner into our team, I have this memo, which is a set of slides called "How to work with Romain". It's a mix of how I operate, and it also contains some of the values that we embrace within our department and the company. That's there to help set the stage.

[00:17:13] But culture is not something you do once and then forget. It's something that you have to constantly act on. And the way you do this is by ensuring that you reward the good behavior that you see embracing those values. Just before going on stage, actually: we had some issues in one of our metrics yesterday, and the team all worked together across the different areas, trying to unpack what was happening. They drafted a document all together and submitted it to me, and the first thing I did this morning when I saw it was a shout-out in Slack: guys, amazing job, to see how you have all come together, worked together and put that together in no time. There was no me versus you or whatever. This was really a one-team spirit where no one dropped the ball, and everyone acted in order to try to solve the problem. Rewarding is extremely important, and that takes different forms, from promotions and end-of-year conversations, which are more performance-related, to giving people more opportunity to show the great work that they have done.

[00:18:24] The other thing that you need to do is, when something goes wrong, unlike when something goes right, you don't praise in public; you have those discussions in a one-to-one setup. One of the things I like to do, that I feel works quite well, is asking people to reflect on the situation. When you observe some things that don't link to the values that you want to foster, you ask the person to reflect on the situation, and in 90% of cases you will find out that the person will see what they missed in that setup or process, and be able to course correct in the next few weeks or months.

Measuring organizational health

[00:19:01] Alex: With your values and how you're approaching the team, it feels like you've got a very strong connection to high performance and action. Is that ultimately how you're measuring it? That's how you know you're successful, because you're meeting the goals? Is that the way you think about it?

[00:19:17] Romain: I would say when you're leading an entire area as a head of product, there are multiple metrics that come into play, and delivery is not going to be the only one, and hitting your metrics and goals is not going to be the only one. The way I see it is really split into two sides, or even three sides actually. The first one is the people side of things. How healthy are we as an organization with our people? You measure it with something we have at Booking that a lot of big organizations have, which is what we call the Your View[?] survey. Those are the quarterly or biannual surveys where people are able to give anonymous feedback on how they feel in the company and how they feel in the team. That's really precious, because it's a reflection on your management style and the opportunities you are giving to people. It's really deep, full insight into how your organization is doing.

[00:20:19] The second thing is going to be more around how much progress we are able to make towards our strategic direction. That's going to be monitored more over the long term, against the big objectives or KRs we're held to. And the third one is much more short term: what is the velocity? Are there some hits we're taking on velocity, more on the engineering side of things? Because sometimes you have some processes that are not working, or you lack resources in one area, or whatever. So people, product strategy and goals, and engineering are, I would say, the three buckets that we are monitoring at the head of product level, in order to see if the organization is healthy.

Building trust in person

[00:21:07] Alex: Right. As a leader, I think it's much easier when you're working with a team that's in person. You can look them in the eye and build trust. How do you build trust when the majority of your time you're going to be on a Zoom call? You're also at different times of day, so sometimes you're coffee-fueled and your Bangalore team is probably going, come on Romain, I need to get home, I've got other stuff, I've got my kids to sort out. How do you build trust in that environment?

[00:21:37] Romain: I think you don't build trust over Zoom. You build trust in person. That's why one of the big things that you need to do, when you have remote sites, is to go as often as you can: travel and spend some face-to-face time with those people. What we try to do is go to Bangalore at least twice a year, and we go to our London site every quarter, or every two months. When we are there, our calendar is free. We spend our time only with those teams, and we ensure that after some work sessions we spend some time out of the office, whether it's having dinner or doing some fun activity, to be able to connect on a personal level and know a bit more about the people. That's how you start building that human connection.

[00:22:35] The second thing we do is, twice a year, we fly everyone from our different sites to Amsterdam, and we spend at least a full day all together. In the first half of the day we have more of those workshop sessions, where we try to reflect on our strategy and the progress we have made. We try to have a bit of fun, with some of our UXers sharing the latest insights that we've learned from the latest research, and some of our analytics folks sharing some fun data insights. It gives food for thought to the different teams. And the afternoon is completely fun activities, whether it's a barbecue in a park, doing some bowling or whatever. That's the meet-up-in-person aspect.

[00:23:21] Then the next thing is you need to show the behavior that you're promoting yourself.

[00:23:28] Alex: You're demonstrating it.

[00:23:30] Romain: Exactly. That means that when...

[00:23:32] Alex: You are the values.

[00:23:35] Romain: You try to do a good job at doing that. I'm not saying that I'm doing it 100% of the time. I'm a human, I'm probably failing, and I'm sure my team would have some feedback for me, definitely. But yes, I believe that you cannot be promoting values and not embracing them yourself. Otherwise your speech is not coherent with your actions. For me, when my team is on the front line firefighting, I'm not going to go home. I'm going to be: hey, is there anything I can do to help you? Do you need me to get some data? Do you need me to ask for support from another team so we can get more resources? Do you need me to handle the communication with the leadership, or what is it? I feel that our job, even as a leader, is not to purely stay on people management, the strategy or whatever. There is at least 20% of our job that remains, at every layer, some form of execution. And sometimes it's helping the team when they need it the most, and that's in those firefighting cases, for example.

Has product leadership changed?

[00:24:39] Alex: That's great. The environment is changing. You've been a leader now for quite a while, and it's shifting. Are you finding that you're having to shift your leadership style? Is being a product leader now quite different from how it was maybe three or four years ago?

[00:24:53] Romain: I actually don't feel it's that different. I know that we're talking a lot about AI, and I'm sure there is a lot of AI talk today. But whether it's AI, or the cloud three or four years ago, or mobile 15 years ago, I believe your responsibilities as a leader have stayed the same, and for me they bucket into four categories. The first one is people management, development and growth. How do you attract the best talent, grow that talent and place it in the best spots, in order to ensure that people can develop themselves?

[00:25:36] Alex: The same.

[00:25:38] Romain: Exactly, that has stayed the same. You might use different tools, but essentially your responsibility there stays the same. The second thing is setting the strategy and the vision for your team, so your team knows in which broader context they should operate, and they know what they should prioritize versus what they should not prioritize. The third thing, as I just mentioned, is a bit of execution. Your team might need you to unblock them on some more complex project, or in some firefighting case: how do you roll up your sleeves and help them?

[00:26:13] And the fourth bucket: I don't think it's changed. The tools you're promoting have changed, but your core responsibility is not changing, which is how you keep updating your processes and tools to stay up to date with the industry standard. For now, this bucket is mainly driven by AI. How do you ensure that your team has the right time to play with some AI tools, and to use AI tools in order to be more efficient, in order to be able to do more stuff? It's up to you to define the process that will be able to go into your organization, in order to try to maximize the value that those tools will be able to have. So really four buckets: people management, strategy, execution, and the update of the processes and the tools that your team can use.

Q&A

[00:27:02] Alex: Makes sense. I can't quite see the clock. I can see the clock now, that's good. I think that's fantastic. Should we open up to some questions?

[00:27:11] Romain: Yeah, definitely, from all of you out there.

[00:27:16] Alex: Okay, all right, let's kick off with the first one. Does each team do user research and get user feedback, or is it centralized? How do you handle user feedback from different markets, as they have different needs, while still ensuring you deliver fast and are high performing?

[00:27:31] Romain: That's a really great question. Does each team do user research? The answer is yes. I'm a strong believer that whether you are working on a front-end product or a back-end product, everyone has a customer. Often, when I arrive in a given area, there is every time this platform team that does a bit more of the data storage or those platform capabilities, and every time the discussion or debate I have with them is: yeah, but I have no customer. Your customers are internal. They are the teams using your product. If you were a SaaS company, you would sell your solutions to B2B customers. User research can take different forms; it can be with internal customers or external customers.

[00:28:19] All our teams are essentially doing user research. The way we're set up is that we don't have a user researcher per team, but we often have user researchers per area. For example, in the identity verification area that I have, we have seven teams and we have two user researchers. The way we see user researchers is as the guardians of the methodology for doing user research. That means, one, they're going to help us run end-to-end complex user research, where the questions might not be straightforward, we haven't really figured out exactly what we want to know, and there is a bit more uncertainty. There we really want to have expertise.

[00:29:05] On the other side, because we have so many user research initiatives that we want to pursue, more than our capacity can handle, we want the teams to be able to do user research by themselves. In that case we go to a model where the PMs and the designers run the user research on their own, but they still have to document the methodology that they want to follow, and that's going to be reviewed and assisted by a user researcher. That allows us to run as much user research as we want, so user research is never a bottleneck and we're able to build the best...

[00:29:42] Alex: That's how you scale.

[00:29:44] Romain: Exactly, scale that process. And I think another big benefit is that everyone gets a bit of strong user empathy directly from the user. It's different when your colleagues come to you and say, oh, I have learned from user X or Y about this important problem, versus you receiving it directly. Another thing that we do is we often invite some engineers to shadow this user research, so they themselves can...

[00:30:10] Alex: Build the empathy.

[00:30:11] Romain: Exactly, they can build that empathy link with the user.

[00:30:13] Alex: A nice way of also stopping silos, because you can work...

[00:30:16] Romain: Exactly. Work in one environment.

[00:30:18] Alex: Okay, great. Next question. How do you handle cultural differences with people working in Bangalore versus Amsterdam, e.g. in terms of working self-reliantly versus needing concrete direction? So, the guardrails of how you manage the team.

[00:30:33] Romain: Yeah, cultural differences, that's true. Even between Amsterdam and the UK you will see some differences in the culture, and it's probably going to be even more present with the folks that we have in Bangalore. But ultimately, as long as you set up those big overarching principles, which are your culture and the values, those three that I mentioned, you will be able to find people pretty much everywhere across the globe who embrace those values.

[00:31:04] One of the things I really like to do: I talked about this memo before, that I'm sharing with my team. What I ask them is to share their own version of the memo with me and with their team. That allows us to get to know each other. For example, in my memo you will find out that I'm not a morning person, and therefore when you want to schedule a meeting with me, you'll probably schedule it in the afternoon or the evening, because that's where Romain has his best attention. You're trying to build an understanding of the people and how they operate, and as long as they operate with the core principles that you have, everything else should be something you're okay to compromise on.

[00:31:51] Alex: Yeah. One top tip I had, actually, working with people where English is a second language and you're in a big meeting: what you should do is call out their name first. If you call out their name first, they then listen, so they can be more intent with you, and then interact and answer the question. It's a small detail, but it actually counts when English isn't their first language. Cool. All right, next question. Is compensation for equivalent positions or roles different based on location, and does that lead to friction?

[00:32:26] Romain: I don't have the full compensation grid in my head, but yeah, I think the compensation we do at Booking is based on location, obviously, because the market is different. What we care about is being able to attract the best talent in every market, and for that you need to be competitive in terms of compensation. Compensation is driven by the market where you are, which takes into account cost of living and all those things that are normal and expected.

[00:32:58] Alex: Yeah, makes sense. Okay, are we done? Thanks everyone. Thank you, everyone.

[00:33:07] Romain: Thanks, mate.

[00:33:07] Alex: All right. Cheers, mate. Thank you.