Clark Chahine - Working in and with overly distributed teams (EN)

[00:00:05] Thank you very much for joining us. Um, my name is Ka Shaen. I'm the VP of Product at Kepler. Um, most of you do not know this company. Um, even so, uh, you are all affected by that what the company does. We provide data for financial market, um, to help, uh, basically the trade efficient trades of commodities. So basically looking at real-time flows of commodities around the world. Oil and gas, food, grains, um, and recently power. Um, and this presentation is actually, uh, has been not just built by myself, but actually by my entire product and engineering team. Because it's a topic that is quite at the heart of the way we build software today and the way we build data solutions for our customers. It's working with distributed teams. So funnily enough, one of your colleagues, literally five minutes ago, asked me, but Clark, what do you mean by overly? And I said to him, well, I'm going to explain you this. So the first thing I'm going to do is actually change my title. It's not going to be overly anymore. We're just going to use highly.
[00:01:23] So why do I change it? Well, first of all, I made a mistake when I wrote it, as basic as this. Um, because in English, overly has a very negative connotation. But actually in our teams, it's, it's pretty good. I mean, it's a pretty good connotation to be distributed. And that point about English not being my first, uh, language will come back in the talk actually. So first of all, let's talk about distributed. What do we mean by distributed teams? Can anyone tell me, give me a definition?
[00:02:08] Well, it's as simple as, um, having multiple teams or team members in different locations and working in a different time zone, uh, different countries and so forth, or even in the same country, but in different locations. Well, actually, it's a bit more complicated than that. Why? Because you can be distributed as a product development R&D team, but your team, your squad, can be co-located.
[00:02:39] I'll give you two examples. The first example is coming from my previous company, where I was working for Schlumberger, and most of you, I'm pretty sure, do not know Schlumberger, but it's the biggest oil and, uh, oil and gas service company in the world. Um, it has the one of the biggest software department in, uh, the energy, uh, space. It has more than 300 product managers. More than 5,000 developers. So it's pretty big. And the team I was in charge of was, um, uh, composed of eight tribes, 18 squads, across all the countries you see here, mostly in Europe, so Norway, UK, France, Germany, and a team in Houston and a team in Beijing. So 30 product managers, 180 engineers, eight tribes, 18 squads. Eight tribes fully distributed.
[00:03:32] Different countries, different locations, working quite well. But within each tribes, the squads were co-located, and that was a choice, a historical choice because the way we were developing software. Now, let's go to the other extreme, where at Kepler, thanks to COVID, we've learned to be truly distributed. By all means, we have five tribes or product lines, um, 16 squads, 15 product managers and designers, more than 80 engineers and data scientists, and we have also data operation teams and data managers.
[00:04:10] And, um, and by the way, the squads at Kepler, we call them crews. Not that that matters too much, but to us it's important. It's, it's in our grains. Um, uh, and the tribes are obviously distributed, but the squads as well. Because there is not a single tribe that is co-located, a single squad, sorry, that is co-located. As you can see on the map, you have a lot of people in Europe, both in France, in multiple locations, in the UK, in Belgium, in Italy, in Ukraine, in Poland. We have people in, uh, the US, in South America, people in Middle East. In India, in, uh, Singapore, quite a lot of people in Singapore actually, and, uh, in Asia in general.
[00:05:02] So how how did we make it work? How did we come to be like this? Right? Two years and a half ago when I joined Kepler, we were not that big. We were 80 in total in the company, and two years and a half later, we are three times the size, three times the revenue as well, so we are close to 260.
[00:05:24] And we also, uh, are fully distributed, a remote first company. And we grew so fast, not just organically, but inorganically as well. We acquired in less than 12 months three companies. Imagine the pain of integration. And imagine the the challenge of actually making sure that those teams across the world can work together.
[00:05:48] So what I'm going to do now is share with you some of the learnings, some of the things we succeeded at, some of the things we failed at, and see how basically we can, um, learn from it. So, the first rule is very simple. Find your single point of failure. In reality, there is not one single point of failure, there is multiple of them. The most obvious one is the time zone. Is how do you manage teams and how do you does teams manage to work efficiently even so they are not co-located? Well, let's look at the challenge historically.
[00:06:29] So, as I said, back in 2020, in the midst of COVID, when I joined, well, I joined remotely, even so I was based in Paris, I couldn't join and meet my teams. But the teams were not as big as as now, and they were basically spread between Paris and Singapore. That was easy. Two time zone, right? Six hours overlap per day, it worked just fine. At that time, there was five people in product and around 30 people in engineering. So it was fairly fairly scalable.
[00:07:07] One year ago, we acquired our first company. They were based in, uh, the US, in New York and its area. And then we thought, well, if we could work across two time zones, certainly we can make make it work for three time zones, or at least way more time zones, multiple ones.
[00:07:31] So, we tried.
[00:07:34] Two months later, we failed. No, we cannot work across three time zone, obvious you would say, right? But not so obvious when you really, really want to try. And that was not a big learning, but it was a fundamental one that drove the way we organized the teams and the way we structured also the teams. By all means, for example, when we acquired the the company, we ingested some people in the product team, some people in the engineering team, some people in the data science team and etc. And we did that every time we acquired a company. But it opens also opportunities.
[00:08:18] So let's talk about that specific problem because it's one of the biggest that you are facing when you are distributed truly distributed teams.
[00:08:27] Well, here's the time, basically, the the different time zones, right? So in Singapore, they are six hours earlier than us, right? And in US, they are six hours behind. Right? So we have basically people in Paris and consider Paris more as a Europe, London, Paris, Belgium and so forth. Um, you have DBX is Dubai for the people who travels a bit, Singapore is SG P, New York is known and Houston is the last one. And you have those bands that are six hours over up. Well, when we started to actually integrate the people, we realized that, well, obviously, this middle zone, it's either too early and either too late. And here is our first, let's say, um, mistake and in the same time it's a good thing because we saw a tremendous effort from the teams to actually in both side in in Asia and in the US to try to make it work.
[00:09:28] It was beautiful. One week Asia would go would start with end work late and one week US would basically wake up early. Great. But it affected the teams tremendously. It generated a lot of stress and fatigue. It affected their work-life balance. Luckily, um, or or I don't know if it's luckily, but um, we have young teams, so they could manage. Not too many uh kids involved, even so some uh uh some family had had difficulties. Comes we're still relying a lot on visual and virtual meetings, which is not necessarily the most efficient way in that case to actually make it work. And then the informations were lost. So the first thing we did after those two months is to reorganize our teams. We scratched it all. And we thought, well, if it worked before for two time zones at the same time, let's make it work. Let's not break something that was working basically. Which is normally the first rule you do in you you you learn in product and engineering, but you know, you got to try. So we did two big, um, two big time zones with Europe in the middle, and basically, um, we wanted at least the minimum of six hours of overlap, and the squads were a maximum of two time zone. And even then, it's not fully ideal. Because what happens when you do that and everybody in your squad is in different location, well, you need to learn to communicate differently, more efficiently. And also, um, in in, uh, you learn to trust and to let go of certain things. That by the way also opened opportunities, career-wise within the teams, to move location if they wanted, and that was also an open option.
[00:11:28] So now, what did we do to actually make it work? Well, the first thing we had to learn, and it's far from being obvious, is to communicate asynchronously. Even the dailies were asynchronous. How did we do it? Either recording a video personally and sending it to Slack or a document. Or a confluence document or just notes on Slack. But we learned to document everything. Why? Because when you actually work in such a breadth, in such a wide time zones and and different teams, you need to, um, basically make sure that everybody has the same information. So this is where the second point appears.
[00:12:15] Never assume anything. So when I ask all the engineering and product team, what's the key thing that distributed teams have basically brought to their mindset was that the key say was, never assume anything. Never assume that someone understand or know what you are doing. And therefore, you need to repeat, ask the question if you do not know, repeat again and even if it's sometimes too much, it's better, so everybody has the same information and the same goals. And it's even more important for the leaders of a team to actually make it happen. And talking about the team itself, the squad, the tribe at any level in that case, right? You need to clearly define what the team does, right? And is and take ownership of that team. Why? Because distributed teams needs to be more autonomous so to be more efficient.
[00:13:14] And clearly define its mandate. Generally, people say, well, we have this mission, this this this value, this this vision and so forth. That's not the mandate that I'm talking about. The only thing I'm talking about here is what are the boundaries of the team, what do they not do and what do they, what do they do, but what do they not do? Like that, it is very clear across team that something is working, that someone is working on something, sorry. Now, let's talk about teams actually. Let's talk about the subtle one, the cross-team collaboration.
[00:13:54] Most people say, and in all teams, uh, in all companies that I've had the the chance to either work with or coach, that product and engineering needs to talk continuously and talk continuously. That's what they think.
[00:14:11] Because what you realize that when they say that they talk continuously is that they have a lot of informal chats. That are not recorded and that are difficult to track. In the case of distributed teams, one of the things we had to learn is actually to share as many information as you can all the time. But not overwhelming the person and this is where the asynchronous part comes in. And this is where, um, our engineering team, for example, often talk talk about it as the 360 behavior. Our VP of Engineering often tells me, you know, um, product and engineering, um, leaders, so the tribe leaders, uh, the lead PM, the lead engineer manager, they basically needs to to walk in sync and always know everything that's happening in their team respective team. Why? Because to better manage crisis, to better manage issues and to actually avoid having those issue raising up too much. The other one is actually the ceremonies.
[00:15:23] You know, the toolings and the ceremonies, both of them needs to also be aligned. So, when we were 80 in the company, so as I said, roughly 40 in the in the, uh, technology team, we had one full day of sprint review and planning for everyone. Everybody could attend. It was open. It was made so we could actually make sure that we had a great transparency across the team, the bigger team. We had a great mapping of dependencies. But that took a whole day. Every Thursday, every three weeks, we had a whole day of meeting. Um, at at the end, I know, at at start it was great.
[00:16:05] At the end, as we were growing, it was becoming more and more difficult because that doesn't scale. It's too much time-consuming for everybody.
[00:16:13] Now, you could choose to not attend, but then you might miss some information because it was not well documented. Then we changed early this year, we did two-hour sprint review and planning just for the highlights. So there was a document where all the teams were just putting the key highlights, the key delivery, the key plans, and the key issues if they had some or dependencies. And every team were in charge of their own sprint planning reviews and ceremony, and they would choose what works for them. That's great because it gives more autonomy to the team, it it's, um, a good for mapping dependencies, it's good for documentation, but it still doesn't scale.
[00:16:58] So what we did, um, just before summer, we said, well, you know what? Um, every team is going to run fully autonomously, and we are going to trust each other, but we are going to make sure we document things very clearly. So every three weeks, we have a single document that is, uh, hosted in in Confluence that basically states every key points, so deliverable issues that we had, dependencies, plans, but also some miscellaneous information, for example, team changes.
[00:17:31] Um, uh, changes in, uh, in in resources, if there was a problem and so forth. And when required, we do those cross-team meetings, specifically for specific topic. Why? Because we can't scale anymore otherwise.
[00:17:47] So that provided full autonomy to the teams and full responsibility. They loved it. They really liked to be in charge of what they do and how they do things, even so there was a certain framework and ways to do it that has been ingrained over the time, over the last couple of years in them. It's very good to mapping dependencies ad hoc and extremely good for documentation. I mean, you should see our confluence now, it's actually compared to even six months ago, it's, it's clear. Yeah, we do not use notion. It's not because we don't like it, it's just because we we had that, so we kept it. The only challenge that that creates is silos. And this you need to watch out for, and that's the job of the VP of Engineering and myself to ask the right questions to the right people to make sure that there is no silos. That's my job.
[00:18:43] So what else did did we do then?
[00:18:48] So, just to summarize that point, product and engineering team needs to have a 360 behavior. By all means, trust each other with information and not hide from it, not necessarily to to to to talk behind the backs or or to not share information. Why? Because it's for the benefits of the business. And simplify your ceremonies or your processes around that and tooling. You don't need 300 tools to make you to make it work. You just need to to know how to communicate efficiently and accept that every team will communicate their way, but there is a single point of information where a single point of of truth where everybody can go and and check and ask the question.
[00:19:34] So basically is building natural touchpoint.
[00:19:38] Now, there is a more challenging and very often underestimated challenge about the the the working in distribu in distributed teams. Is the diversity and the psychological well-being. Does anybody know what psychological well-being means? and tooling. You don't need 300 tools to make you to make it work. You just need to to know how to communicate efficiently. and accept that every team will communicate their way, but there is a single point of information where a single point of of truth where everybody can go and and check and ask the question. So, basically, is building natural touch points. Now, there is a more challenging and very often underestimated challenge about the the the working in distributed teams. is the diversity and the psychological well-being. Does anybody know what psychological well-being means? Great, me neither. No, I'm kidding.
[00:20:02] So, um basically, it opens up great opportunity to work and be very diverse in in in the culture of the company, but it's also challenging to adapt to that.
[00:20:15] For example, understanding a new culture is not a given to everybody. Let's be very honest, otherwise they wouldn't be any war, there wouldn't be anything. But even more importantly, in the workplace, um, it's and when you have such a difference of culture between the Eastern hemisphere and the Western the Western hemisphere, right? You get to have sometimes issues and problems of communication. So in this case, one of the learnings of the teams is that they they should not hesitate to ask about actually the different ways of working. There's also another problem that arose is um, the focus that the more the challenge to focus on removing the the friction points. And very often those friction points comes from what every person or every location would think as that's the norm, that's the quality, right?
[00:21:09] Um, and this is very this is very challenging. To be honest, I don't have a secret source for that, uh it's just you need to work it out. It takes time. That part is is probably the most time consuming. because you need you you need to try to build a relationship with people you probably never seen. I've been two years and a half in the company and for the first time in two years and a half, I'll be going in two weeks in Singapore for two weeks to meet some of the teams that I've never met there. Right? Not my team, but the engineering team because I didn't have the chance. Why did I wait so long? Well, mostly because, well, there was COVID. And then, um, after that, well, when you have so many teams, you have to to go where also the customer needs and and and and once and I was not called then there, um, before. Now, there is another problem. Do you speak English? So, as your colleague has said to me, why overly? Well, as I said, that's a problem of English. That's my uh interpretation of, well, overly means a lot, right? No, it means a lot in a bad way. So, when you talk to someone, especially in different countries, especially when they just on-boarded, and they are not feeling comfortable speaking in English, you might think that they are they are not engaging with you or they are not engaging with the conversation. But actually, more often than not, it's just that they are shy to actually speak in English. They do not feel comfortable or they do not know. I remember the first time I I started my career, I was in Aberdeen, I was out of university in Aberdeen, in Scotland, right? So, it's quite quite quite challenging. My English was bad, very bad. I used to use Google Translate and back in 2010, Google Translate was not good. So, imagine the quality of my emails. Well, the level of English is also to take into consideration. and be patient. But not just the level of English. Well, I have a French accent and all accents can be difficult.
[00:23:25] Um, the best example is, um the Scottish accent actually.
[00:23:30] When I arrived in Scotland, I didn't understand a word of what they said, and I needed to learn English. So I opened and started the TV and started to look at series, but um, we even had that challenge at Keppler where our VP of engineering, and bless him, he will probably see the recording, but he knows what I'm talking about, he's Scottish and sometimes when he's excited, he goes very fast. And a Scottish accent with someone speaking natively English, extremely fast, it's not very it's not easy to understand.
[00:24:02] So, sometimes we had to ask him to kindly slow down. Especially with other cultures that didn't understand, they they were saying yes to him without understanding. So, that happens. Bless him, Scott, if you see me, don't worry, you are great. Um, now, language is one thing.
[00:24:23] But I mentioned earlier that onboarding is also a challenge. How do you onboard someone from home all the time? How do you make sure that this someone is feeling um, that he believe he or she belongs in the team, in the squad, in the tribe at any level in that case. Well, that's a critical period. Um, over the time, we got better at it, right? We didn't only rely on videos or documentation, we actually relied on calls and people and spending time with those people. And when they were in a location close to the office, to a one specific office, we would make them travel the first couple of weeks to the location to actually get to know people. During pandemic, it's a bit difficult, but now, it's common. We have people all over France, we have people all over Asia and they always travel to the the relevant location for that. So, documentation is definitely not enough, FaceTime, even virtual FaceTime, is the the the simplest solution.
[00:25:37] Another key point, the easiest path is not always the best. Do you recognize this logo? Who uses this software? Raise your hand. Very good, everybody, right? So, Slack is a wonderful software, right? It's great, but sometimes it's not your friend because it's the easy path. When you have Slack, you are it's very quick, it's very easy to just send a message and just be done with it, right?
[00:26:07] But you also have this problem that you get onto a lot of channels, you see a lot of noise, a lot of people are pinging you, and therefore you are slightly less focused. Because when you're in office, people see that you are busy, they don't necessarily come to your desk and say, oh by the way, um, did you see this? Where in Slack, they don't know. Even so, when you put the the little sign, who care about the little sign? Raise your hand if you actually care about the little sign, the emoji. Yeah, there is one person, two person, three person who who raise where everybody of everyone here actually uses Slack. So that's that's the challenge. So focus in that case is very important. For you, for the work you do and for your squad, or your tribe. So, in this case,
[00:26:51] well, you have to do with what you you have anyway. So, Slack is still a very good tool. very good for asynchronous, actually, communication. But to collaborate, I think we need to make sure that we come back to the basics of even so you are in different location. Well, there is a simple thing that exist, which is a phone or a video call, right? So ET phone home back in in the 80s, already wanted to use the phone. Right? Same for you. Use the phone. And actually Slack released a very good tool uh called Huddle and I remember talking to um to someone in another company and the the button was just there and they never actually used it. But it's such faster to just say, okay, I'm not going to ring someone, I'm going to just open a discussion into a channel or else and just use it. But pick up the phone. Because it's much better to actually talk to people sometimes. And and that second point comes from a couple of our engineers, actually, multiple of our engineers saying that having a camera on calls is very important to actually build a relationship. And I quote,
[00:28:08] Sorry. We don't care about your dirty dishes, but we care about seeing your face. This is what they say. And this is why I put it on the slide. Do not underestimate cameras, right? We don't honestly, after a while, we just after now, now and ever, we never care what's in the your background. What we only care about is we are talking to a human person, not a screen, and that's a very key difference. So bring back the human in the the communication even at distance.
[00:28:41] So, psychological well-being is very important. Bottom line, be yourself. And use the tools necessary to actually communicate, but don't forget you are actually a human being. A lack of engagement could just be a language barrier, a language issue, right? Uh, do not underestimate that and don't hesitate to ask someone, shall I slow down? Can I shall I repeat or did you misunderstand something? Certain culture they're going to tell you know. In Asia, for example, um, it's not knowing is not great, but you need to put them in in in a safe place so they can say, oh actually, could you repeat please? And then lastly, one thing we decided to do this year and we came back to to our finance team and say, we are going to make travel more than 50% of the teams into a single location for a week to co-work together. And we did. A whole week in June, we basically made a physical gathering for more than half of the teams. And it was great. Why? Because it built somewhere just seeing each other for the first time. I saw some of my team for the first time because they were based in Canada, or in Singapore. It was fantastic. And luckily, I got COVID just before. I didn't get COVID, but I was almost, I was going to almost miss it. Now,
[00:30:06] all of those are challenges with solution. But the outcome of this, or the output, both of them work in that sense, is when you make it work, you have amazing outcome towards the success of your company and the success of your product. The first one that suddenly you realize is that because you have so many time zones and your teams are working continuously in a very efficient manner, for a single squad, you basically develop continuous and support your product 18 hours a day. And for the tribe, it's actually 24 hours a day. So, you know, when everybody tells you, yeah, we have continuous development 24/7 and so forth. Most of the time, it's not really true because they have a lot of inefficiencies and a lot of communication challenges. But distributed teams in different countries and different location can enable you that if you manage well communication, people, and the challenges that I was describing before. And that equal to what? Right, yeah, it it it works for real. Um, it equal to continuous value to customers, right? Through continuous support, through continuous improvement, through faster output. You know, Daniel just before me was saying, output over outcome, and he's right. I agree with him, right? And in this case, you are bringing a lot of value to your customers faster and you are responding to to their need faster and working both in the business side and the R&D side. The other thing that is very good about it, is that you start to hire the talent where they where they live, where they are. And not where you are, which open up a massive pool of talents, right? We are talking about the whole world. Obviously, it has some challenges from an HR perspective, but we generally could make it work. So, here is an example, right? That's the map with a lot of countries missing, but it's the map of all the location we have at Keppler. And we are going to carry on hiring where the best talent are. Both in Europe, in Asia, or in in in the Americas. Uh, Middle East as well.
[00:32:27] So, all of this is very important because everyone here who work in teams knows how difficult it is at the moment to hire people. Especially if you bound yourself to a specific location. Now, imagine the whole world is open, well, you can really, really find your uh your teams. uh a little truth. It doesn't simplify necessarily um the finding, but it definitely simplifies the sourcing. of the person. Another one is what I mentioned before, which is opportunity to work with far more diverse people. We often talk about diversity around about gender. But it's not just that, there is diversity about uh culture, uh about uh experience, about age and so forth. And all of that is extremely important to actually improve the your capacity of delivering the relevant software or data solution. culturally because it also brings a lot of more fun. You you learn way more, you actually open up and you get to get friends everywhere in the world. There is probably um, there is 42 countries I've traveled around the world and I know that there is one person in those 42 countries that I I know I can have a coffee with every time I go there.
[00:33:51] And experience-wise, well, you learn differently. And that's something that basically has no price. For everything else, there is Mastercard.
[00:34:00] That was bad, I know.
[00:34:03] So, um, it enables you also to choose your lifestyle. Well, you know, we have people who love mountains, well, they they go for a few weeks and months during the year working from the mountains. We have people who um, I had a product manager, one of my lead product managers, he needed to follow his partner into Cambodia for an internship and he did for six months. What did we do? We trusted him. We trusted him and trusted anybody doing this because you can work from anywhere, but get the job done on time and with quality. That's the only thing we ask. And it works. When you trust people, it works. And it also increased your team engagement. It um, it increased because you trust we we trust you. It also increase increase the retention. We have less people actually leaving because they have this flexibility. And recently, actually, we have more and more candidate asking us, you seem to be a remote first company, and being working in distributed teams, that is actually appealing to me because I would like to be able to work wherever I live and choose where I live, so my work life balance is better.
[00:35:21] So, all in all, it's a pretty good experience. It's actually a very good thing, it it actually propelled our company and our product into other stratosphere. It really helped us, first of all, mature new ways of working. Be more actually collaborative because when you are forced to when you can't walk to the desk anymore. Well, you are forced to find other ways of communication and also adapt to the communication of each other. So we got better people-wise, technology-wise, and so forth.
[00:36:02] So, working in and with highly distributed teams and not overly, thank you.
[00:36:09] Well, it's uh definitely not easy, but completely worth it. Thank you very much.

Transcript