Transcript
Balashanmugam: I was a cool, happy, developer for 12 years until I got a phone call from a company. It didn't mean that after the phone call, I became a sad developer. I just changed my roles. I got this phone call from a company and then they said, "Your profile looks very interesting for us and we want to have a chat with our manager." I said, "What's the role?" they said management. I think, "I'm not interested," but they said, "Can you have this chat with a person and then you can take a decision?"
I was not very curious to have the chat but since they asked a couple of times, I then said, "Yes, let's go for it." I went for the conversation with the director of India for a particular company which was having eight distributed offices. At that point when I came in, and we had a chat, he asked me "This is the kind of role, are you interested?" and all those things. I said, "I'm being very happy doing what I'm doing. I'm not really excited about the role that you are talking about."
He said, "What are you very interested about? Why are you liking the present job?" I said I'm building distributed systems. I'm working with the things that scale. I really like that. Then he said, "What is the maximum number of team members that you have ever worked with?" I said I am a technical lead for a team which was around size of 15. Then he said, "I'm talking about team of 200 people. Doesn't that mean people at scale?"
I said, "Sounds interesting, but how do you think I can help you?" He said, "You have a background in distributed systems. Just apply the same principles to people." Then I said, "It won't work like that." Then he asked why. Then I said, "Because people have feelings." Then he said, "Ok, that's why we're hiring you. We're not hiring any mission or a framework." Overall, the conversation was interesting enough that I joined them and wanted to really try the role. It was one of the initial thought process during which I had the same kind of concept, some of which I also adopted from distributed systems and applied to teams.
When anybody is speaking in a stage even especially in the QCon when I was seeing there are two people talking, especially when they're using slides, one is a person who is actually talking like me. Another one is the person who is actually talking the slides, literally the slides moving around. What I did was let us put a character to the slides and that's Craig. Can you guess which place is Craig from?
Participant 1: Australia.
Balashanmugam: Australia, good. He said, just put, "G'day mate," and then they'll know. I said, "Maybe not." He said, "Give it a shot." He's true. He's correct, actually. How many of you are from Ireland or Irish? Not many. Ok. More than a decade ago, I used to work with an Irish company which had an offshore development center in India. A couple of the tech leads came to our development center there, and in the evening, we all went for drinks. After a couple of drinks they're ok, eventually it had been for more than a couple of drinks. One thing I observed which was very common was over the whole conversations, one pattern was repeating. A lot of all our Indian developers, they are speaking something and then trying to tell some joke and Irish people telling their jokes. When they say the joke, both of them laugh out loud and some of us laugh and when we say the joke, they were not actually laughing but they smile and then say it's funny.
What I understood is whenever there is a distributed team, there are only two things that can happen to your joke. Either people laugh or they say it's funny. When you laugh, I understand it's a joke. When you don't, I understand it's funny. Craig thinks it's funny. I'll switch off Craig for a minute and let's do the talking.
One of the things most important in distributed teams is a lot of times, we see things at a macro level and then see things are all good, but we don't see things at a micro-level. If you have seen a lot of talks that happened through the morning in the same track, many of them were talking about some of the nuances that maybe we need to pay attention to. That causes a large shift in the way we work at a macro scale.
I'm going to end my talk by putting this slide which is continuous improvement through continuous feedback, and you can improve at a macro level and micro level when you keep on observing both of them. This is a good example. Generally, Craig and I work together. From morning, he asked me a lot of things that he needs. One of this is very standard. He says, "Can you give me the budget for 2020?" My general answer is, "I'll give you in some time." He asked for other things and the same answer repeats. One day he got frustrated. He put an actual Slack bot to whenever I say "In some time," "Can you be specific?" Every time I type that, it asks me "Can you be specific?"
It was not a behavior that I am just having. What I understood was a lot of people, in our team, when they were doing it, they were using the same context because culturally, or something like that, fewer of our people were having that thing of saying, "in some time." It was not very new for us because we understood what in some time meant, or we could actually put an estimate to it. When people on remote are doing this, it was "Why are these people saying in some time? I don't understand what their some time means," and get frustrated. That's a good example of taking things at a micro-level.
I am Ranganathan Balashanmugam, and when I say this, people say, "Rangana-what?" This happens a lot of times. People literally butcher my name. What I did was I put this to check how strong it can be as a password. That's without any special characters. It's an 85% strong password. I added one more character to it and it became 100% strong password. You can all use this password but pay some royalty fees to me or I'll expose your password. Call me Ranga. See, it's not so complicated. It's like 18% strong.
The point is, why are we talking about this? A lot of times, even in a normal setup, when you're talking with people, the hardest part is to understand their name. When we don't get their name and we're all having a beer conversation, we generally try to avoid the conversation with this person. " John is so easy to talk to," they're like "Calling Ranganathan Balashanmugan, what does this mean? I'll talk to John." There a lot of papers which say how people lose opportunities and conversations just because of their name. This is very important.
Who's problem is this? Is it my problem or is it other people's problem? I always see it from my side because I think we need to build that empathy that people come from different cultures and it will be really hard for them to pronounce this name. What I always do is I try to help them saying that "Pronounce this, Ranga. It's very easy." I tried this with a lot of people and all the people in this track, especially Judy [Rees], they asked my full name and asked me, "Help me pronounce this." Then somebody does that, you know that they really know this particular point and they are already working with the distributor teams. That's one real validation of checking how it is important.
My journey so far has been interesting. I graduated as a civil engineer, later on moved to computer science. For 12 years, I have been working as a software engineer, which I told. Almost last 15 years, I have been working with continuously different distributor teams across the globe. 2016, the story that I told, of handling 200 people kind of work, came through this company and eventually got acquired by Oracle. I came out of Oracle. Myself and Craig used to work with a company called Aconex. We both are co-founders of EverestEngineering.
What we do at EverestEngineering is consulting services, software consulting services. We started one year, four months back. Right now, we are 75 people distributed across three different cities. If you take all of them together, it's quite a distributed team. The actual developers of our side are also going to be distributed within these three cities. Last year in December, I was named one of the top 10 CTOs in India by "CEO Insights Magazine." I really don't know why.
Applying Distributed Systems Theory to People
One small thing, a request, if you can all stand up, ignore Craig. A small request – if you can clap for just three seconds. Thank you. Please, sit down. Thank you for the standing ovation. This is a technique, how you can get a standing ovation from a crowd, but that was not the point. How many of you felt it was peer pressure because of which I stood up? Many of you. How many of you felt stupid after doing this? A lot of you. How many of you are lying even if you felt stupid and you were not telling me?
The point is, when I went to the conferences, I've been seeing the patterns around all these different talks. When people come to the tenth slide, what most people try to do is, that's the first time they pull out their mobile or their laptop – I know few people are taking notes, but generally, what I'm saying is some people check Slack or check their WhatsApp. That particular thing started happening around eight or tenth slide according to my observation.
That's why I put this thing at the tenth slide. It's very simple according to that particular person who convinced me that you can apply distributed systems theory back to people. It's like this: you have a task, the task has both data and a function. You give it to the system and then it gets the task completed. You have a task, you give it to people, they finish it and then you have the task completed. Now you have a big task and give it a bigger distributed system, and the task is completed again. You have a big task, you have bigger teams, and then the task still gets completed.
Let us take the definition of distributed system. It says it's a collection of autonomous systems which appear as a single coherent system. Let us do some modification. Remove system with teams. When applied, that's exact definition of what a distributed team means. It is not different. It is exact. We need a set of different teams working together but, if all the stakeholders see it, it appears like a single team.
Let us take characteristics of distributed systems. They operate congruently and when they fail, they fail independently, and they don't share a common global clock. If you just change systems to teams, it's exactly the same. There is no change there, except for the global clock is the time zone. Having said all these things, one thing doesn't work. When you actually put the teams, it's how people work. It's quite complicated. People have feelings. People have relationships. People are "I don't like to work there with this person." It's not as simple as how you work with systems.
Coming back, fundamentals. There's a coach. He calls out all these boys for coaching and these kids come there and then they start to coach but there's no ball. The kids ask the coach, "Where is the ball?" The coach says, "How many players are there in a football game?" They say 22 players. "At any point in time, how many people have the ball?" They say one. "Then we're going to do what the remaining 21 people are doing. Let us practice."
Why Do Yo Want to Go Distributed?
Fundamentals are really important, which comes down to why do you want to go distributed? A lot of times it doesn't mean that "Somebody else is doing it. Our competitors are doing it." It's fine, but you really need to know why you are going to do distributed. If you're not clear on that, it's really not worth the effort. I'm giving some examples of answers that I've been hearing from a lot of people. A lot of people say it's cheap if you set up an offshore development center. If you go with that mindset, what happens? Then all your decisions are based on what is the cheapest set of people that I can hire? I said cheap by cost not by people.
When you go and say, "This company has started a per-hour billing" or "This is the kind of people that I'm going to hire," let's specify, go by $10-per-hour kind of people, then I'll choose $10-per-hour kind of people, the reason being I'm going by the reason of cheap. Business agreed that economically, that is more viable. A lot of times what happens is, thinking about the economics is really good, but you need to know how cheap you want to go and what is the thing that you can compromise on quality. You can't get everything at one point.
I talk with a lot of teams, and many times when I talk with those teams, they say that the biggest point that we have is even cheap we spent a million and then we had to put two million to clear off all the tech dates and the things that they have done. This thing is not a very new answer to me.
The next one is you are hitting hiring limits within your region and you want to go and hire from some other place. That's all good. Remote potential markets. You see a market here and then you know there is a market in that particular region or that particular continent and you want to set up an office because you get both functional context and also some sales and other departments that you can set up along. That way you are going to set up offices there.
The other interesting thing a lot of people say is "I'll outsource dirty work." What is dirty work? Maybe a kind of repetitive work that nobody else wants to work or there is a big monolith system nobody wants to work on and so on. You don't have very important work every day but you are just going and checking out for bugs and then fixing it. Now, what happens because of that? If you go with that particular reason, you are going and setting up an office in a different region with a mindset of, "These people are good enough to just set up or fix bugs." Once you go with that mindset, your hiring and all other things will get compromised. Eventually, what happens is some of those people will be bright. Some of those will not be bright, so we'll end up building a company with two different cultural values. A lot of times it ends up saying that they did this, they did that, so that thing keeps happening. What is more important is I really don't like that outsource dirty work kind of thing, but if you want to outsource something which is functionally not possible here or it's quite expensive here, that's a good reason to go there and then set up a center somewhere else.
Where to Go?
Ready to go. We're all clear on why. Then the next question is, where do you want to go? I can't just take the map and put two points and say, "I have an office here. I want another two offices here and there." It is not possible. The first thing, you are limited by the number of developers that you want to hire. Over the globe, you have 23 million developers and then you are filtered by these kind of filters.
First thing, you need to understand, "I'm going distributed, but because this office is full, I can't find an office nearby so I'm going to some other office which is close by or help other set up people who commute from very far distance within the city." That's one good reason. Or, you want to set up an office, like for example you are in Melbourne. You want an office in Sydney. That's fine. You are going to set up an office there, or you're going out-of-country because you find some advantages over there, so you go out of the country. Then that puts out a big filter on how many people you can hire. The next one is availability of developers and within that competitive pool, how many people are fighting to hire? That's the other thing.
The next most important thing is language. If you are from Germany, and then the whole company speaks German within the company and you want to set up a remote center and you think they only can speak English, they can manage. That's also hard because a lot of times, most of the decision making happens here and those decisions are not getting transmitted here. You need to put that filter of what is the common language across the company? That becomes a very big important filter.
Then there is agency versus our own teams. Ok, I don't want to set up an office there, but there's an agency. If I outsource it there, then I get it done for cheaper or better quality, whatever it is. Then that point is good but that again, filters a few more things. Then the cost of developers themselves. How costly is getting developers from there versus some other markets?
The next most important thing is trusted network for advice. What it means is, I go to this region. I want to set up an office in Bangalore. I am in Newark. Do I have friends or friends of friends who have already done this kind of thing and can I rely on their additions or help where I can rely on their network or help through which I can understand that particular culture and market and set up things?
The next one is also ease of travel. A lot of times we feel that's easy. It's not. Are you comfortable to go there and stay for one month if you are setting up? If you are comfortable or if you have a team who are comfortable doing it, that's good, because at a business level, you take additions saying that we are going to set up at a place where your team is not willing to travel. This happens and then that doesn't make sense because you are setting up things from a very remote place, and also getting this outside both ways. Can they get visas here if they are traveling or can I get a visa there?
This is a filter map that I'm putting. These maps are used in a high-level role but you cannot rely on it because it's not exact. If you just zoom in, here you see, Europe is not a very major player in software developers, but when you actually zoom in, Europe has a lot of software developers. What it means is basically you need to check by city rather than by actual region.
If you take a country, that's fine, but a whole country is now distributed software developers. Because they are putting that map, they're just distributed. You get 100 people, you are just putting that map on that map rather than you take a particular city and see the capacities on that city. Put city as a better filter than putting the maps.
Then this one is what I'm saying. People speak English in different places and one of the examples that I'm going to give later on, you'll understand what does speaking in English in different languages mean. That's a very important filter.
We Vs Us
This is a very interesting story. One day on a morning I was walking very fast in the office because some things were broken in production. The tech lead said, "Ranga, Ranga," and then I just ran to them. He was very happy, like he was doing something very busy. Then he looked very happy. He said, "Ranga, I think I'm very excited. We have good news." I said, "Did you find the bug? Is the production fixed?" "No, we found something which is very interesting." Then I said, "What is it?" Then he says, "It's not our services. It's their services."
The thing is basically, it's the same company and then you are saying that it's us versus they. It's not like that. It's we versus us. It's all the same thing. I want to ask one question so I'll come down and probably I need a volunteer. The question is what is the job for a goalkeeper in football?
Participant 2: To prevent people to score?
Participant 3: Keep the ball out.
Balashanmugam: What is happening is, this is the same thing on we versus us. What does that mean? Everybody believes in the team that if the goalkeeper can stop the ball, it's success. What happens if the opponent is hitting say 30 goals and your goalie is stopping it? Then he's a good goalkeeper. Or, he stops like 29 of them, still you get one, and you lose the match, is it right or wrong? The job of the goalkeeper, like everybody else, is to win the game. It's not to stop the goals.
Then what I understood from that lesson saying that the whole core value is gone. We are just fundamentally thinking something is right. Something is not right because things are failing in production. It's night for them. They had asked us for help and what all we did was look around all the things and then we are very happy because it's not what we broke. Not a good sign. You need to fix that.
First thing, what we started was, I need to be very clear why I'm doing this, then I have a set of filters on which I'm looking out where to go. Then the first and most important thing is us versus them because this part is very hard. It appears very simple because some people think, for example, it's cheap and a lot of people think that, "If I make them successful, which means they are cheaper and then they can scale there, I lose my job, so I'm not going to help them." That kind of mindset comes in. First thing is build their trust and then make everybody understand we are all one, otherwise it's very hard to buy in from people.
Hiring, Firing, Reatining
Ok. You have done all these things. Now, next thing is you are going to hire. What I'm going to tell you is, don't hire the best. You have heard it right. You are not hiring the best. What you are actually hiring is hire the right fit. Many times, I see people coming there and they're trying to set up an office, they go and find bigger companies like say Google, Facebook, find a fancy profile there, and try to offer them this job, "You have done this, you are like this, Google some X and Y. Can you come and set up an office for us in Bangalore?" They get excited at that point because they don't know, but these people also get excited because "I hired somebody with this profile," and they start setting up things, but what happens is it looks like it can happen for them. Maybe they are very skillful, but it's not exciting for them enough. You can't keep them longer happy, so even if you hire the best, they don't stay with you very long. They'll leave very fast.
The second thing is, again, don't go for weaker people and give them heavier weights. They'll also leave because it'll be a lot of pressure for them. A good advice is to seek people who are actually buying into your values, which is very hard in the beginning, but if you set it right for the first four or five people, most of the things will be in place.
Next thing. Ok, I am setting up an office there. On the left is a perfect model of how I am going to set up the team. On the right side is what actually happens. These are three different distributed teams and what I am actually having is – the square is the actual values and purpose on which the company works. You have your own values and purpose. Say, we're all looking for square-face people. When I say square-face it's like we're trying to put a shape to it so that it's easy to understand. You all want a lot of squares because it's easy to scale, they are all agreeing on same values, same purpose.
What happens is during interviews, people put who are circle, put a dotted square around and then they try to act and then they come in. It happens when you are scaling. That's not wrong, but what happens is as soon as you let one or a few people, the first thing is, because you are building distributed, you have that mindset that "If I fire, what will happen? Is there an anxiety that happens?" Of course, there is anxiety, but you need to fix it because if you don't fix it, they are going to scale.
You need to be very transparent on why you are not happy with that person. Try to help them with their goals, and if they don't fit in, they are not squares, ask them to leave eventually. Put up a goal plan. If you are not firing, you are definitely going to collapse. Especially, for example, the leadership roles are simply the ones who are in the bottom. They are going to hold the whole structure on, if you hire somebody who is not matching your values, the whole thing is going to dance a little bit.
Retaining is the hardest part because there are competitive companies. One company saw that you are coming in and setting up a distributed center. You are successful. They are trying to replicate you because that's the same market and they try to hire similar kind of people or they try to hire your own people. How do you retain it? You need to be very clear on how do you retain it, but some of those core things like having a purpose, coaching people, giving them autonomy, all those things really helps.
Virtual Distance
Next most important thing. We've gone through this journey and then we came to "I have done this team and then I have all these teams that I've done remotely. Now the most important thing I need to work on every day is virtual distance." This is a concept by a person called Karen. I have paraphrased it to appear in a different way, but what she says is there is a concept of psychological distance with others for collaborative performance.
What she is saying is it's limited by three things. One is the physical distance itself. You and I can be physically different. The next one is operational distance. The third one is affinity distance. I'm going to go one after the other. The first one is physical distance. You have been through the InfoQ. How many of you said hi to somebody in the lift during the three days? A good number of them. Did you start the conversation there? I think probably I didn't come in any of your lifts because nobody said hi to me.
What happens is generally, we are in the same apartment, same building or same workplace, we go in the lift every day. A lot of times we know that they are working in the same office but we are not connected. There's a physical distance. That's the actual distance. The other thing is people are coming from different organizations. They are consultants for your office. The problem is there is like you and them ideology in mind. It's very hard to remove. The point is there is a distance that gets created because of that. You need to address that, and the time zones, of course.
Once you are talking about distributed systems, you absolutely have no control on physical distance. We can ignore that but also one of the studies by Karen says that physical distance is not the major impactor of the actual collaboration performance. Affinity is the top-most impactor.
Let us talk what operational distance means. It is the noise in the system. What does noise mean here? The noise is actually, "I go for this call because it's distributed," and then do I get a better quality call or is it a poor call or what do I feel? Those are the operational things that I'm doing distributedly. How easy is it to do that? That is the operational distance.
The next one is affinity distance. This is the one with highest impact. What it means is, how far is the deep relationships within the people in the company? That's the actual affinity distance and this one has a lot of impact.
Now, we have come to this point where we have been in a journey and now the problem that we are going to solve is, how do I reduce this virtual distance altogether of which the first thing is really gone. You can't work on physical distance because you've already gone distributed. I wanted to map the [inaudible 00:28:15] with this, but I don't want to do that because it gets complicated but you got the concept.
7 Key Takeaways for Scaling Distributed Teams
These are things that we are going to talk about but I just wanted to give you an overview. Let us take first point. Communication is the foundation. All of this done right, the first and foremost important thing is communication. From left to right, how easy is it to read the left one? How many of you feel it's impossible to read the right one? It's almost zero. I can't even read.
This is the handwriting of different people on a similar kind of text, but when we are all online and working together in collaborative distributed teams, we need not worry about it because all of this comes like this. It's a simple text and we are all collaborating on the same thing. It all comes back to text, but where does the problem come? Because we are not communicating. When we are communicating through chat, it's fine, but still there are some new answers of a different way of expressing a few things in English when you are writing. That's one thing. Apart from that, this is what happens.
This is an actual story. Craig travels here and then comes to a place like in Bangalore and then he says hi and speaks for a few seconds to somebody and then they feel like "What's going on?" because they don't want to show, "This person is talking to me. I really don't understand. I don't know what to tell him. The best thing I can do is smile," but actually, they are not smiling. Internally, they are feeling really bad and Craig feels, "Yes, I started this conversation. I don't know what to do," so it feels very awkward.
This did not happen actually in the end. What Craig eventually did was started speaking very slowly, keeping words together and said hi. This is the pace in which he started talking and slowly started increasing the pace and eventually, both of them started understanding. Now, I'll ask you one question, very simple. Be open. A person is from England, and a person, say, from India, a particular village in India. Do they speak better English? How many people feel that the person from England speaks better English than the Indian? Most of you. The point is, what happened there was Craig is coming from Australia. His whole education and his mother tongue is English, but there are like 59 other people who are also speaking English but they are speaking a different version of English.
What it means is they are speaking something like the one in the middle or somewhere, but for when he is speaking even this English in Australia and other places, it appears like that. It is contextual. I'm not telling like who is speaking good English. If I'm coming back to the foundatio,n because I'm saying communication is the foundation, it means, are you communicating really well? Because you chose the language, you need to understand what and how people speak the language and you need to be helpful for each other when talking English.
Next thing, I told you about the microexpression. This is an actual video. He is generally smiling and then talking to the team locally, but on calls, there's a new client and then they are going through these calls and he is always doing this. I was in the calls and then observing and I took some pics and then put a small message to him on Slack saying, "Why are you like that?" and then I went and had a conversation with him.
He said, "When I'm concentrating or focusing something, I just tend to do this." Also he said, "Because it's the first time I'm going to do the new accent, I'm trying to understand and I'm putting that expression." Now, what happens is because of this, a lot of people, when they come to the initial cause for a new client, if everybody is this serious or doing like this, the virtual distance is really big. I can't collaborate with them. They are very serious people. Can I joke? No. Can I answer this? What if I do wrong? All these things come in and then we create a distance with them versus if they're close by, we know what kind of person they are and what they are speaking.
What happened is basically I gave the feedback thing saying that, "You all feel good, watch the video and then start talking, feel very comfortable, it's all fine." Then this thing happened. He's now called Happy [inaudible 00:32:58]. We actually had a Slack logo of him like this and everybody calls him Happy [inaudible 00:33:03].
This is an actual screenshot after the later calls. If you see even the later photo somewhere, we'll see him always smiling. It is not easy for people to smile. I'm not saying that everybody should say that you go and smile or something like that, but I know him personally in offline setting, and then when I saw him in a different behavior, you need to observe and then help them understand that, " you are doing a behavior here. Why is that happening?" and then fix that gap. That's how we close that virtual distance.
The next most important thing. How many of you do stand-ups? If I tell you to stop doing stand-ups, how many of you will do? We're not. We're staying like this. The point is we, at Everest, we work with different clients and different time zones. One of the things that we follow religiously is end-of-the-day updates. What it means is, these are really random screenshots from different dates if you can see from different people. What we do is, if it is a single person or a team, they definitely put all the status on what they are doing, every day. We can take our Slack, and there's a shared channel between us and our clients and you pick any of them. Always, it is like this. It is not only from our side, it's from both side. Say four people are working from their side, we force them to do it. If they are not, we just keep forcing them until they do it.
A few things we don't argue about. We just commit to it. This is something that we agreed on. The best advantage that we see is a lot of times because there is a time zone difference. Say for example a product person may not be active in the Slack every day but they really want to know the update at the end of the day. They come in the early morning and they are dependent on us or they want to know what is the status. They come and see this and then they are very comfortable with it because at their time zone, which is our morning, 3 or 4, they know what happen especially if there are blockers, it'll go away.
People know that, "If I don't fix this, by the time they come in in the morning, this blocker will be there." Or if it is late evening for them, by the time we are talking to them, it'll be hard for them to get it done so a one-day lapse will happen.
These are a lot of advantages over this. One of the things we do is written communication in the end. One of them asked, "We are doing this every day, do we really need to do stand-ups?" We said, "Absolutely yes." Why? Because both of them together form better communication. Why? Because they see this and in the morning, even if you are struggling with your accent or understanding others, you can still understand. Or, if you miss the stand-up, you still have this thing. It's a better way of communicating.
The other most important thing is, a company, as a whole, has only one framework which is decision-making. What are all these titles? VP, or director, I'm CEO, all those things, they are some and responsibilities, plus, the most important thing is who is taking the decision? Who is the final decision maker? That's it. This one you can adapt. What I saw was, when they've started building scalable systems, so before scalable systems, what they used to do is that for a data to be processed, they used to chunk and then do the processing somewhere else and then get it back, but the code logic or the bottleneck was a single system that was taking the final calculation.
Let us take Hadoop, for example, Hadoop 1. What they did was, it not only distributes the data, so if it has like 100 GB, it splits into like basically based on number of nodes. It splits and gives it back but also sends back the logic to that. There is a framework on which it operates. It doesn't mean that you can put anything everywhere, but within that framework, it can take all the decisions of calculation. You are giving back the logic.
When you are setting teams on distributed style, one of the most important thing is you allow them to take decisions, but give them a framework. What it means is tell them the norms on which they can take, there are some things which are rules on which nobody can negotiate. "Can I harass here?" No, you can't. Those are rules but there are norms on which you work on. You can say, "You are going for team lunch." In New York, the team lunch costs, for example, $50,000 for fancy socials. In India, for example, the similar one, was say, $10,000.
Then put that norms there so that people know that you have already built the norms but allow the decision making to happen there. That's most important. If you keep every decision making here, there is a bottleneck. There is a concept called the headquarters. They didn't approve, then [inaudible 00:37:28]. But if you give back the responsibility and autonomy to the teams distributedly, it all happens. If it's all within the norms, it's all good, but if anything is deviating from the norms, then they can ask you and then do that particular thing.
Choosing right tools, hardware and software – a very small activity. From the morning, people here are asking people to talk. Just turn on to the people on the right or left for you, whoever is closer. If you are three people, just three of you talk and just talk to them, what is the best tool, just one tool that they are using and why. I'll give you 1 minute.
I'm not going to give you a set of toolset but one thing is, the core concept is, for Samurais, there is a concept called daishō. What it means is they carry two swords. One is long, the other one is shorter. Why do they carry the shorter one? Because if it is a closed space or a room where they are fighting, they can't swing it enough. They have the shorter ones which are daggers, and they use it. Try to use right tools for right things. Don't stick to tools that are not good enough.
This was a random meeting and I just took a screenshot. Some of the things that [inaudible 00:38:41] in the morning are followed, but if you see somebody, like one of the person there, he's not using their video because he was in hospital and he clearly communicated that. The point is, basically, as much as possible, we try to follow this.
Then other important thing when you are distributed, there is collaboration time and concentration time. Why? Because you are always dependent on the other team. If you keep on talking on meetings and then keeping on collaborating, it doesn't help. The other most important thing is after your work hours, if you keep getting pings, there are two problems. One is you have this nudge of "I'm not responding to them." The other thing is, if you end up responding to them, then you're likely not having a very good family life. You're just talking work with your spouse always. What happens? A lot of beer happens.
Basically, try to, from the beginning, be very clear saying that you can have your own framework. Say that, "We are going to put all the questions there, but after 6, don't even worry about not responding at all. We don't even care about it. Whenever you come back, respond it, but we are putting it because we don't want to miss the actual conversation."
There is an architect called Matteo Ferroni. There's a place called Mali in Africa. He was in a relationship with a singer in Mali. He had this idea of "I'll go there and build an open-air theatre for them." That was the idea, but once he went there, the first thing that stuck to him was "This is culture is completely different. The mornings are super hot," and nobody was actually awake in the mornings. Everybody was sleeping in the mornings and they were working in the nights. That was the first cultural shock.
The second thing he observed was a lot of them are using kerosene and other similar kind of flashlights which were dangerous because that was carried along for different activities and if you just see the whole night, they would rest using that. The third one was people were not owning property. It was the community or the social structure owning the property and nobody was "I own this kind of thing," which means the problem that he found was, "What if I build a lamp post?" He can't build a lamp post and keep it there if individual people are wanting it because people can steal it. Based on this constraint, once he understood that locally, this is the final model that he came up with and it's actually a light people are using it right now. This happened in 2010.
The point that I'm trying to make is you can't take something that is successful in New York and then try to just replicate in Bangalore or some other place. You can't do that. It's really hard. You need to go there, try to understand the local things, and allow the local nations first, "Locally, this happens like this. I try to understand that," and then try it in the local fair first and then later on, add things that are better from there.
This is an interesting thing. This is a concept of local leader who is the connector, who has a very important role in a particular company. I used to work with a company which was U.S-based. I was working in a remote team in one of the cities in India. What happened was this guy was like a real micromanager, the office manager. What he used to do is he used to have a particular style. If you are in meetings, generally, if you are in meeting with my own meeting, then it's fine, but if sometimes say, some other person comes and asks me to stand up and we go into meeting room, he has this particular style, he just peeps into the meeting room and then asks, "What are you doing?"
This used to happen very frequently. I left the company within a month but what happened was one of the days when I was having a serious meeting with somebody, he came in and asked, "What are you talking about?" I got so pissed off that I told him that we're tossing a coin so that we choose who is going to win and go to the restroom first and then I resigned the same day.
It was so frustrating for us because the conductor is the one who is the cultural catalyst. If you choose them right, your culture will be replicated there right. If you are choosing them wrong, the culture stays there wrong. You can't change that particular person very fast. Even if you do, the culture that he has built will not change very easily. There is a big change management that needs to happen. Choose the right leader and that's the hardest part of the whole thing.
The last thing that I want to talk about is promote online chit chats. When we are in offline office, this is our actual few set of people. We used to go together for lunches and tea and coffee. What happens is this waterfall of conversations. We don't talk about work "Yesterday I had this. This thing happened. Something is going on." I know them really well. If they are not performing further studies, I know that they are having a late evening stay because their spouse is unwell and they are taking care of the spouse so they are not sleeping well. Then once I understand all these small nuances of them, then the actual affinity distance that I talked about is very very small. That becomes very easy for people to work with.
When we are distributed, this thing generally doesn't happen. Whenever we set up a new team or a new distributed team, the first thing that we do is, because we work with different clients, a one-hour meeting of just chit chat. It is focused chit chat, nothing else. The [inaudible 00:44:04] what happens is you set up a meeting and there is a serious business thing. "We are going to do this. This is the task. This is what we are going to do." That's not how actual teams work. When you come into an office, you just have this "hi," then you go for tea, talk to people then you are very comfortable. That's what we are trying to do at frequent intervals. Then there is a meeting which is more than one hour, then the first 10 minutes is reserved for chit chats. People say what's happening in their lives. We saw a considerable amount of improvements. You can't measure that but once you try applying it, you'll see a lot of value in it. This is one good example. They are working with a different team and they are showing their local things. You can see Happy [inaudible 00:44:51]. He's still smiling.
There is a bonus point. If you start thinking that it's working fine, it's actually not. You need to completely work and receive feedback and keep on continuously improving. One thing we always say at Everest Engineering, [inaudible 00:45:13] and every other place is we know this is the best way to do something. If anybody knows a better way of doing this, then we will do that, but because we don't know, we are trying to do this.
Summary
In summary, we started with why we want to do it, then we said we versus us, we don't want to do that. From there, we understood where do we want to go. Then we started hiring a team, firing and we talked about retention. Then we took the concept of virtual distance and started working on how to reduce the virtual distance. From there, these are the takeaways.
Basically, these are the ways in which we try to get the virtual distance lesser. This is the last story that I want to end up with. Napoleon was very powerful and was winning a lot of wars. He was quite confident that he was going to win Russia. He took 100,000 soldiers and went into Russia directly. What they didn't understand was they basically lost most of the army. They lost the war also and then they came back.
One of the theories – I don't know if it is true, but thre are a lot of documentaries there – says that Russia was super cold at that time and they used to wear tin buttons and when they went to that temperature, all these tin buttons crushed to powder. They had to close their clothes and then protect them from cold and also fight the war. That's the reason they lost the war.
The most important thing is, if you're trying to do something from remote, and it doesn't work, even if you're as big as the Napoleon army, you need to understand all these things before starting anything.
Questions and Answers
Participant 1: What do you do to deal with the cultural differences when you have a new client? What's some of the ways that you introduce...?
Balashanmugam: One of the photos that you saw was a team in Australia and they were telling some things about their culture in the first chit chat session. They talked about that didgeridoo, that long instrument that they use in this Aboriginal culture. They started explaining about it, but that doesn't help understand the whole culture and the way they work. It's very frequent chats but also setting up the initial framework key. We work on these norms. First, we ask them, "What are the norms on which you are working?" That's the first thing to understand the clients in which they work. Then we say, "This is the way in which we work. This is our experience," and come to a common ground on which we work.
Apart from that, a completely new culture, for example, it doesn't happen in day-one. We have to continuously put some effort. We have some people who are like customer success – not like the actual customer success, but general customer success people – who keep on talking with the clients. Then in a bi-weekly basis they keep taking the feedback and keep applying it back. That's how we improve.
See more presentations with transcripts
