Becoming Better Communicators To Enable Team Performance

Transcript

Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I'm sitting down with Arpit Mohan. Arpit is in Bangalore, India. I'm still in little Ōtaki in New Zealand, and we are going to talk about people in culture. Arpit, welcome. Thanks for taking the time to talk to us today.

Arpit Mohan: Absolutely. Thank you so much, Shane, for having me on.

Shane Hastie: My normal starting point with guests on the show is, who's Arpit?

Introductions [00:33]

Arpit Mohan: I'm a software developer and I've been in this industry for about 13 or 14 years and a good part of the previous decade, I've largely dabbled in and around startups. And by virtue of being in these startups, I've had the fortune of seeing a lot of different products. A lot of different industries, ranging from AI, FinTech, Mobile Gaming, Telecom, eCommerce, and this time around with Appsmith, which is our third startup, which is our third venture, we are building in the area of Developer Tools. We are building a Low-Code Application Builder platform. It's an open-source project and has been for the past two and a half years. And I'm super excited about finally, I get to do open-source in a paying job. So, that's the part I'm super excited about. And throughout my history, I've largely led most of these engineering teams.

And while I got into software quite accidentally, if you will, I've been always been fascinated with technology, right from childhood. I've pretty much unscrewed most gadgets that my dad bought in the house. Right from the video recorder, the VCR to Tamagotchis, which was a little toy that you had early nineties, to computers. So while I've always been fascinated with technology, with hardware, et cetera, I learned the skill to put everything back together, much later in life. So while I could disassemble stuff, I couldn't assemble things again.

And if each time I disassembled, I was always fascinated by that little green chip that always came out of each of these devices, which was the little board, the little micro controller that came in. And I remember as a child, being fascinated that this green chip is what powers this fantastic world of Road Rash or Tamagotchis or televisions, et cetera. And ever since then, I've been fascinated with robotics, with powering and building stuff and creating stuff on that green chip. So I had decided that this is super powerful and yeah, and most of my life since then has been based around creating worlds, creating products that run on this little green chip.

Shane Hastie: Moving away from the little green chip to building the software, but going beyond the software to the people behind the software. One of the things that intrigued me in our earlier conversation, you made a wonderful statement. Code is easy to change, people not so much. Let's explore communications and communication skills in teams.

The history of software is the history of teams [02:58]

Arpit Mohan: So most engineers, when we get started with our or during our, whether it's our internships or early jobs, et cetera, most of us, we tend to focus a lot on the actual coding. What is the Java Syntax look like? What are our design patterns? What does architecture look like? Et cetera. So there's a lot of emphasis over there. On the other hand, interpersonal relations, being able to communicate with your team, all of these are termed as "soft skills", but these skills are much harder to, a, learn and master and secondly software, as a principle, so the history of software is the history of teams. So there is no great product that has been built by an individual developer. So if you and me, we want to build great lasting software, we have to build it with teams.

We have to build it with other people. That is why interacting with other people and team members is a lot more important and code can be changed, super easy. You just change a line of code, you commit it to Git, get a pull request, you're done. But on the other hand, if I don't like something about you, Shane, I can't just do a git commit. I can't just raise a pull request on Shane and say, hey, you know, Shane, I don't like this aspect about you. Here's a pull request. And bada bing bada boom, Shane, here's an improved Shane, right? Or a different Shane. That's not how the way the world works. And the way as humans, as people, as team members, we navigate this is, we have to, at each given point of time, we keep trying to find that bridge, that connector between each of us.

And that is a very unique connector between each team member. So if you're a team of say, 10 people, as an individual, you will have nine individual connections and you'll have a unique way, a unique idiosyncrasy, a unique thing that you will do with each nine of these. And this comes very intuitively to humans. Human brains are geared for this. But I think just being able to develop that, being able to identify that and say that, oh Shane does this really well, so maybe Shane likes predictability a little more. So when I'm talking to him, I'm going to focus a lot more on predictability. While somebody else prefers a more wild west way of working. So with them, I'm going to let them take a free hand at the problem. I'm not going to keep a tight leash on the problem statement.

People change over time and relationships need to change along with that [05:22]

Arpit Mohan: And just going to let them run wild, because that's when they perform best. So everybody has a unique way of operating. And the interesting part is this way of working, people change. So if I figured out a way of working with you today, a couple of years down the line, we'll be re-evaluating our entire way of working or the way we talk to each other, the way we work with each other. And people who have life partners see this day in and day out. There are very rare occasions where you work with a team member for 30 years or 40 years, but having a life partner for 30 or 40 years is quite common. So this is very apparent in those scenarios where, with your partner, you keep re-evaluating your relationship every few years because you see that the person has evolved, they have changed.

And so have you, and you have to find that new normal. And this happens with every team that you work with. So if it's a new team, it's about establishing that normal, but if it's a slightly longer-term relationship with them, you've been in the team for a few years, a couple of years, you'll try to keep finding that new normal. And all of this comes under soft skills. But to be honest, I think that's much, much harder. And if engineering colleges or coding camps or et cetera, just did a three month boot camp on, forget about Java or Python, you learn that on the job. That's the easy bit. Here's a three month boot camp on how to work with people. This is how you speak. This is how you document. This is how interact in a, which is in a most stressful environment. So on and so forth. If people did that, I think we would have much more empathetic, much more calmer and more productive, happier people overall.

Shane Hastie: I'm not aware of a coding boot camp that puts people first. I am aware of some that do today, bring in the focus, the understanding on, you are going to be working in a collaborative team and with the adoption of agile approaches, every organization claims to be using an agile approach today. So we see more of that emphasis, but how do we help people build those skills?

Helping people build interpersonal skills [07:31]

Arpit Mohan: The first thing is the will to actually invest time and effort over here. So it starts from obviously the will. The second is being conscious about the language and the tone of voice that is being employed in a given situation. So just being conscious about, hey this is a stressful environment, let's say production went down. So everybody's under stress and being conscious about the way you are expressing yourself. The type of words that you're using, the tone of voice that you're using at that given moment. And if it's written communication, I would highly recommend people to go back and reread what they said a day later. Once they're out of that situation, once they're out of maybe that stressful situation, or you're trying to get multiple stakeholders on the same page, so on and so forth, so just reflecting upon, hey I said this in the meeting, could I have done anything differently?

Did I do well? Did I not do well, et cetera. So just being able to reflect. So, that's a very critical piece, of being able to communicate better. The second is something that I have done personally, and I would recommend is, I ask myself, who's the best communicator out there. And one of the names that popped in my head was Barack Obama, the president of the United States. And I was like, okay, what can I learn from him? And I literally went and I watched, I think about 70 or 80 of his speeches, back to back. I just watched him through and through to get a sense of, how does the president of an entire country communicate? What are they saying? Where are they laying emphasis? On what point are they driving home? So find that gold standard that you think is the gold standard in your industry, in your field, in your team or etcetera, and just be very aware of what and how they're saying it.

And the more you, either read or listen to a particular person, the more you start writing or something like that. Because your brain implicitly starts to generate what it just heard. So, that's the other way to get much better at this. And the last bit I would say is, when it comes to, especially written communication, there are some very basic principles which we tend to miss out on, and that is consistency of language or communication in terminology. So the consistency in, if I say a server and you said instance, so while we might mean the same thing, but we are probably not on the same page. We are probably talking about some things that are slightly different and they may diverge.

The importance and value of consistent language [10:05]

Arpit Mohan: So being aware of this, and it's much easier to do this in written format than in a verbal format, but once you start looking for those inconsistencies that, hey let's get on the same page with terminology, let's get a consistent language going first. Just having and drilling down on that, the consistency, goes a very long way in establishing that relationship because the person in front of you also knows what to expect. There is a predictable behavior, and once it's predictable on both ends, life becomes much easier. Versus you're constantly second-guessing, they said X, but did they really mean X? I'll deliver in one week. Okay. So if Arpit said one week, it's probably going to be 10 days or it's probably going to be one month. You're not second-guessing. If I say one week, it just means one week.

I know I said last, but sorry. The other bit I would also recommend is, there are some really good books around this. So a few that I've found useful were, Managing Humans and then there is the other one by Camille Fournier, she was the CTO of Rent the Runway, sorry, I'm forgetting the name, but Technical Managers Path or the Manager's Path. So these two books are really good. So yeah, I would highly recommend reading about this.

Shane Hastie: And we'll make sure we include the links to those books in the show notes. And that's the thing that you were saying to me earlier is, you are a distributed systems engineer, but you would advise people not to build distributed systems. And in fact, Appsmith has been built as a monolith. So why is this?

Don’t start with building a distributed system [11:29]

Arpit Mohan: I’ll nuance that answer a little bit, I'd say 90% of the systems that we built do not require a distributed system because when you are doing a startup or you're getting started with a new project, you should largely, as an engineer, focus on just getting to product market fit. Just getting the job at hand completed. That is a lot more important than massaging some ego or some skill set around, hey, I know how to do Kubernetes or I'm a Kubernetes engineer or I'm a Distributed Systems Engineer. Those are much more complicated pieces of software. And while Kubernetes or systems like Kubernetes or Apache Spark or any distributed system, they're absolute beasts, they're fantastic pieces of software, but highly unlikely that you need a distributed system that scales, that auto scales, that auto-scales up and down in the early days of any project or any product in your startup or team.

So unless you're Netflix or Google, it's very unlikely that you need a distributed system for, I don't know, your blog. If you're writing a blog, just put it on a single VM, like a small, tiny VM, even if it's serverless, it's even better. You don't need to do all of that. Take the overhead of complexity. And this comes from a lot of experience. This comes from having burned my fingers with distributed tracing, with debugging in a distributed systems environment. I really don't want to take all of that overhead for some product that's maybe not yet reached that particular skill. And the philosophy over here is, do what works. Do what you know, and just do what works. Instead of constantly overcomplicating the solution at each point of time.

Shane Hastie: And the other thing that we were talking about was taking the ideas from distributed systems and applying them to managing distributed teams and working in distributed teams. How does that play out?

Taking the ideas of distributed systems into working with distributed teams [13:28]

Arpit Mohan: So early in Appsmith's life cycle, so very early on, we became a distributed team. We were an open-source project and being an open-source project we said, hey we are going to be a distributed team because Conway's law applies. So we said, if we are distributed, we'll be able to work with contributors better. We'll be able to work with our community a lot better. But at that point, this was the first time that we were doing a globally distributed team. And I was struggling a little with how the modalities of operating across different regions, across different time zones. And even if you're in the same region or time zone, just not being in the same room. And while I did try to read up on how GitLab has done it in the past, how Basecamp has been doing it for many, many years.

I was trying to read how some of those best practices, one thing that helped me get onboarded on this journey is, okay what do I know? Do what you know. And I started from the principle, okay, what do I know about distributed teams? And I was like, okay, I know the word distributed. Okay. So let's start there. And I looked at a lot of the engineering principles that we've developed over the years to manage and develop these systems and like, okay, can this be applied to teams as well? So the first one, for example is, like I was just saying earlier, is having a consistent language. So in an engineering context, you would use an interface file, a Thrift file, a Protobuf file, or a published documentation to say that hey, this is my API interface and this is how you will interact with me.

Similarly, if you're working in a team, just having that consistent language and terminology and saying, this is the way I work, or these are the keywords that we will use within our product, within our team. These are the acronyms. So if I'm in AWS, for example, I will call it an EC2 Instance. If I'm in Azure, I'll call it a VM. They mean the same thing, but they're slightly different again, because I will not call something in AWS, a VM. I'd call it an Instance. So those little, little things, so just establishing the common base of consistency in language, that's the first thing. In case there is anybody who is using different keywords, then you immediately know that they're probably not on the exact same page as you. They're probably in the vicinity, but they're not at the exact same page.

So, that's the first thing. So first is, establish an interface of communication. And this interface of communication by the way, is for humans, that's the interesting part, is different for Arpit to Shane, is a slightly different person than Arpit to my co-founder, versus Arpit to my partner. So humans have this unique way of having many, many different interfaces to the exact same thing, the exact same person. And the fun part about distributed teams or people is that you get to figure this out without documentation. So, that's one. The other is, there's a concept called Fail Early. In an engineering context, if a particular service is misbehaving or it's not doing too well, more often than not, what we would like to do is just to remove that service, like get it to fail, get it to crash and we responded in some other VM, or we just restart the service.

But that's the concept of Fail Early. And this applies to teams as well, where if we are going through a sprint, we are going through a project cycles and we see that something is not working as per our timelines, something is not going just right. By default, we should try to fail early, either term the project to failure much earlier than going to the absolute end and then saying, oh the project was a failure in this quarter. I mean, everybody probably knew within the first month of the quarter that we are so not making it. So calling out failures a lot earlier in the life cycle, and this applies to people as well, that in case for example, if I'm not doing too well in the team, instead of letting me coast along for a while, before we come to a point where I'm put on a performance plan or et cetera, or I'm asked to leave the team, just fail early. Just call out that failure much earlier in the life cycle.

And it might be a much smaller failure and it's much easier to correct, to course correct, to just respawn the project. It's much easier to correct that if it's called early versus much later in the life cycle. So, that's the other one, is fail early. The third one is around, what should I say? Service SLS, in any engineering system, reliability and latency are two metrics that are looked at for any service. And they are typical, hey, I have a microservice, how reliable is it? Out of 100 times, how many times does it return the correct result? That's reliability. And latency is how quickly did it return that result? And any service that is super fast that has very low latency, but is super unreliable, is crappy service. It does not matter. You might as well have taken a lot more time, but just be correct about what I'm asking.

The way to establish credibility is to be reliable [18:26]

Arpit Mohan: And that applies to teams as well. Reliability is the first thing that you want to establish within the team. Latencies is much lower down that order. So when we add any new engineer or any new person in the team, one of the things that we are going to tell them is, any new person, there's a human tendency to establish credibility by doing work, that hey I'm being a part of this tribe, a part of this group. And for me to establish my credibility, I'm going to try and do a lot more things than I probably can, or I'm going to push myself in the first few days, few weeks, few months to show that Arpit is a great guy. But what we tell a lot of team members within Appsmith today is, the way to establish credibility is to be reliable.

So commit to fewer things, do lesser things, but be reliable about them. So attend fewer meetings, participate in fewer projects. It's okay. We are not going to judge you on the number of ticket GitHub issues you closed, or the number of things, what everybody innately judges other people on is, if Arpit said that he's going to get X done, did he get X done in that timeframe that he committed? So establishing the reliability, especially when you're coming in as a new member in the team that is the first and upmost requirement that you should do. That's the best way to get credibility and then comes latency. Where, are you consistently slow? Are you consistently fast? Or are you like spiking up and down, up and down up and down. So if you're consistently slow, everybody in the team knows how to work with you.

If you're consistently fast, again, everybody knows how to deal with you. And obviously as humans, we will go through some cycles, like some slight curves where you're productive some days you're not really, and that's okay, but at a two week timeframe, in a month's timeframe, are you by and large consistent? But if you see a lot of spikes and that unpredictability again, becomes very hard to deal with. And with any team member again, that we see where we see maybe a spike in productivity, and then we see a dip. So, the next time we see a spike, we actually call it out. At times, we've called out people who are being super productive, we reach out to them and say, hey, what's happening? How did you suddenly become so productive? Are you on your path to burnout? Are you doing something that is unsustainable?

If so, please scale back. It's okay to be again, instead of closing 10 issues this week, if you consistently try to close three to five, it just makes things easier versus you closing 10 this week and then going AWOL for the next two weeks. I might as well have you close at a more consistent pace. So we've actually called out productive people as well saying, you're too productive. Please, please stop. And there's something else that's up. So those are the latency requirements. And with everybody in the team, I've learned to write down their latency numbers, what I call latency numbers, where I literally, after each call, they say, oh, I'm going to do X issue or whatever X problem in so much time. I just literally, for my personal thing, I just write it down. And now I have a multiplier factor for everybody in the team.

So now when you say two weeks, I have historical data to know that two weeks, what does it really mean? And that's what, then I go ahead and commit to my co-founders or I commit to any other stakeholder. This way, everybody is on the same page. Again, I know what the latency numbers are for everybody. Sorry, I've gone on for a little bit over here, but the last bit is having a single source of proof. Where in any system you want to have a database or a centralized source of proof because when you have different stakeholders or different people who are operating on the same information, you'd ideally like to have a centralized place where you can refer to if there are any discrepancies, that's one. So having a centralized documentation. So that's one piece of it and the other is having a leader.

The role of leadership in groups [22:25]

Arpit Mohan: So in any distributed system, you have a leader and then you have followers. And in case there is any discrepancy in results, the leader takes precedence, the leader chooses which answer to actually pick, and every system needs to have that leader. So even if you're a small team of three people, in case of any discrepancies, whose voice will finally be accepted? And establishing that again, within the team is important. And it can't just be pure anarchy, or even in a democracy, you choose a leader. So everybody gets to choose a leader, but then you actually still choose a leader. And this should happen in distributed teams as well, regardless of how big or small that group is. Is having a voice or a leader that you might agree and commit to, or even disagree and commit to. But the important part is committing and following that voice that you're on.

So yeah, so these are some of the distributed systems principles that helped me get at least started and establish some protocols within the team and get my head around it. Been trying to get much better and trying to start looking at it from a more human perspective as well. But this helps me bridge that gap between the engineer's mindset that I've had to a more people first mindset.

Shane Hastie: What advice do you have for the newly promoted technologist who is now in a people leadership position? What are the things that they should look at?

Advice for new leaders [23:50]

Arpit Mohan: The first is a lot of people who are new to technology leadership, they believe that the important part is technology and the less important is leadership. So I would A, switch that in your head, the title around and say, Leadership of Technology, rather than Technology Leadership, or instead of saying an Engineering Manager, I would say Manager of Engineers, because the more important part is the leadership and the management. So letting go of the technology bit in your head and saying I'm no longer a developer, I'm not a coder, I'm not a designer anymore. I am actually a leader. I'm a manager. Making that your identity, that's the first switch that I would make. I would recommend people to do. It's not an easy switch that happens, but that's important for it to happen. So, that's the first thing. The reason that the switch is important is because if people need to get better at leading teams or managing teams, I have seen very, very rare occurrences of people doing coding or technology bits well, as well as people leadership well.

So there's only one of these two that you can do really well. And if you want to get really good at either one of them, so either you stay as an individual contributor, there are companies, there's an engineering track that you can take, you can become a distinguished engineer or a whatever staff engineer, or et cetera. But if you want to get into the leadership or management side of things, which leads to maybe VP Engineering or Head of Engineering, et cetera, then let go of the day to day technology bits and focus on just learning about the people, learning about the teams and how you update and focusing a lot more on the processes and how things are moving. That's one. The other, I would say is a lot of people who get into technology leadership early on, they think about what can I do in the engineering?

Or what can I do over here? They look at engineering as a little bit of a microcosm because they're Head of Engineering or they're an Engineering Manager, but ideally what they should be doing is starting to zoom out and starting to look at the larger picture around what is blocking my team. Just start from that question, rather than looking at it from an engineering perspective. What is happening in engineering is less important as what is blocking my team from delivering value. And this could be a myriad of other things. It could be that maybe the designs are coming in too late. The product requirements are not clear. And just starting with asking that question is a very easy and quick way to define what your OKRs for the next three months or six months should be. Otherwise, a lot of people who are new to this role, find it hard to define, what should I be doing?

What should I be judged for? What should my OKRs be? And a way easy way is just keep your OKR, what is blocking my team from delivering value? And this can be measured, quantifiably measured, like do we go to production 10 times a day or 10 times a year? So whatever that number is, oh, I want to improve that number. And just look at that one or two numbers and say, okay, now this number needs to go up. That's it. Now I will do everything which is, either engineering or nonengineering for that matter and try to improve that metrics. So, zoom out.

Shane Hastie: Arpit, thank you very, very much indeed. If people want to continue the conversation, where do they find you?

Arpit Mohan: I think the easiest way to find me is on Twitter. My handle is @mohanarpit. And otherwise you can always reach out to me on email. My email is arpit@appsmith.com. So these are the two easiest ways to reach out. Apart from that, I'm super easy to find otherwise on the internet.

Shane Hastie: Wonderful. Thanks so much for taking the time to talk to us.

Arpit Mohan: Thank you so much, Shane. This has been an absolute pleasure.

Mentioned

• Appsmith
• Camille Fournier – The Manager’s Path
• Arpit on Twitter