In this podcast, Shane Hastie, Lead Editor for Culture & Methods, spoke to Gilad Shoham about building effective mentorship relationships, leading fully distributed teams and the evolving role of developers in an AI-augmented future.
Key Takeaways
- Effective mentorship requires being a good listener first, creating psychological safety, and guiding mentees to find their own answers.
- Effective mentorship requires being a good listener first, creating psychological safety, and guiding mentees to find answers within themselves rather than just dispensing advice.
- Successful distributed teams require clear boundaries and responsibilities, strong asynchronous communication skills, and hiring people who can make good independent judgments.
- Trust-based management means eliminating strict deadlines and time monitoring, allowing team members to work flexibly, and assuming everyone shares the same organizational goals.
- New technical leaders must learn to delegate tasks, shift from being a doer to a helper, and earn leadership through trust and belief rather than relying on positional authority.
Subscribe on:
Transcript
Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, I'm sitting down across half of the planet apart with Gilad Shoham. Gilad, welcome. Thank you for taking the time to talk to us today.
Gilad Shoham: Thank you for inviting me. It's great to be here.
Shane Hastie: So my normal starting point in these conversations is who's Gilad?
Introductions [01:24]
Gilad Shoham: Oh, okay. Great question. Lucky, I know the answer. So my name is Gilad. I'm the VP of engineering at Bit.cloud. We are building a product for developers for improving their velocity and quality. This is like my day job. Apart from this, I'm also doing a lot of podcasting and public speaking about JavaScript, TypeScript, architecture, and of course AI, especially around AI and co-generation for developers.
And I'm also managing and leading two big communities in Israel, the MCP community, the MCP Israel community, and N8N Israel community. And I'm also doing a lot of stuff around IoT and smart homes. I have my brand with a podcast, a blog, a YouTube channel about home automation, which is kind of a hobby that I do, connect my laundry machine to my coffee machine just because it's fun. And also doing a lot of mentoring. I've been an entrepreneur before, so I'm doing a lot of mentoring for developers, for team leaders, for startups voluntarily, usually to give some advice and help the ecosystem and other people.
But this is my main hats, let's say.
Shane Hastie: That's many hats and wide range of interests. I think we've got the basis for a good conversation.
Gilad Shoham: Yes.
Shane Hastie: Let's start with mentoring. What does it take to be a good mentor for up and coming technologists and technical leaders?
What Makes an Effective Mentor [03:01]
Gilad Shoham: That's a good question. I think in the basis, a mentor is kind of like a combination between a coacher and maybe a psychologist. Basically, first you need to be a good listener. So mentorship is not about you, it's about the mentee. So you mostly need to listen to his needs or question and not just put stuff out there because you like to talk. So first, to be a good listener and to be someone that he can trust and feel safe. It's a lot about...
As a mentor, you're more guiding him. You help him to feel safe and find the answer inside himself, giving advice and let him feel good with his decisions and thoughts. So you need to be someone he can trust and lean on. And I think this is the basic. It's much more about the soft skills than about your knowledge or technology knowledge, which is of course important as well. Probably you cannot be a good mentor if you don't know anything, but it's about sharing your experience, but giving a place for understanding that your experience might be different and not well fit the mentee process or experience.
Shane Hastie: What level of experience should somebody have before they want to be a mentor for someone else?
Gilad Shoham: It's not much about the level of experience. It's about having a similar road. If you want to be a mentor for a team leader, you probably want to be a team leader before, at least for a few years, let's say. Or maybe being a team leader in few different companies so you can have some kind of collective information. Being a mentor without being on the same place, it's sometimes not really understanding the issues, the pains. And it's also about personality and about confident in yourself that you have something to give. So I think it's much more internal process than a checkbox that you can mark. I've been a team leader for five years. I can be a mentor for team leaders. I've been an entrepreneur, I can be a mentor for entrepreneurs.
Shane Hastie: Turning that around, what does it take to be a good mentee?
Being a good mentee [05:20]
Gilad Shoham: Oh, that's also a great question. I think one of the most important when I'm looking for mentees, I do it voluntarily, always. I give my time for free to help someone else. The most important thing for me is that the other side doing his job and really get benefit from it. So he need to be proactive. He need to be the initiator of meetings and help with all the logistic scheduling and stuff like this. And he needs to come prepare to meetings. So he needs to come with questions, with dilemmas, with issues that he face. So it won't be like just waste of my time 20 minutes in the beginning to understand what are we trying to achieve in this meeting. And after the meeting, you need to do something with this information. You need to change something to have the decision. So if I'm giving knowledge and information and the other side do nothing with this, then it's just waste of my time. So he needs to be proactive and reflect how our session help him to do something or to achieve something or to change something.
Shane Hastie: Yes. Make the point that you do this voluntarily, I'm guessing, outside of your own organization.
Gilad Shoham: Yes.
Shane Hastie: I don't see a lot of mentoring programs. So should organizations be making this more structured?
The value of mentoring programs [06:43]
Gilad Shoham: I think that would be wonderful to an organization doing this more formal or structured. Unfortunately, I think that many organization, just... As organization, you have a lot of stuff to do. You need to handle a business basically. And helping employees to get this mentoring, it's how to measure its ROI, it's fundamentals, but there are organization who does these programs. And yes, I wish, because I think it's really, really helpful and I think everyone should have some kind of mentoring, at least if you want to go far and to achieve great stuff. It help for anyone.
Shane Hastie: Thank you. And jumping topics, I know that Bit.cloud is a fully distributed organization. In the era, I want to say the day of return to office mandates, why remain fully distributed and what is that enabling you to do?
Choosing to be a fully distributed organisation [07:42]
Gilad Shoham: We have few reasons of keeping our company fully distributed. The first is a decision that we get long time ago at some point that we build a product for developers to help them better communicate on their code. And I'm not going to go too technical about how and the technical stuff, but basically it's a product for developer teams to help communicate and collaborate over the code base between teams, developers, projects, whatever. And we want to improve this collaboration. And in order to improve this collaboration, we are doing also a radical dogfooding. So we build everything with our technology. When we come to different organizations, even if they work in an offices, sometimes many of our customers have big enterprises which have different offices, different places in the world, which has different time zone and different cultures. So they need to communicate on the code base between different teams across the globe.
So we want to also dogfooding and try this approach, of course, in a bit small scale, but we want to see that we can use our technology to improve the collaboration between people in different countries. So this was part of our decision long time ago. So we decided to go fully distributed as a term of principle, not just because of other results of it. I don't know, don't need to pay for offices. So it's more like a strategic thought. This later on leads to we hire people across the globe. Okay, so for example, the team, the core team that's working on beat is composed from different people from different countries. We have love that was hosted here in one of the episode from India originally, but live in Canada. We have David, which is from Israel originally, but lives in Miami. We have Zoltan. Zoltan is the author of author of pnpm, who is Ukraine, but live in Hungary.
And we used to have more people around the world. We used to have Olivier from France. We used to have Kostas from Greek, but he lives in London and other people. And this form a new strategy of hiring where we know that we can hire the best talent for a specific task no matter where he lives. So that's kind of the main part of why keeping it fully distributed.
Shane Hastie: How do you keep such a distributed team well aligned?
Keeping a fully distributed team well aligned [10:20]
Gilad Shoham: Okay. So this is not an easy task. It's like everyone is a completely different country and different time zone and different culture and different holidays and stuff like this. So it's not an easy task. I think there are a few keys. The first one is about having very good responsibility and boundaries for the task. So we hire people with a very, very specific skills to focus on very specific areas, so they won't overlap too much and collide on working on the same place together all the time. So this is like having clear boundaries and responsibilities. Other than that, it's a lot about the team to be very good in communication. One thing that is very important for me when I'm hiring new people is to try to test and see how well they communicate asynchronously because I know that many people will need to work asynchronously with other teams.
So how good they can communicate in writing, how independent they are. Many times someone is working and they need to have some question, but the other side is not available right now because it's a day off from this country or because he's sleeping, because it's a midnight on his time. So you need... As someone in such team, you need to be good at decide which kind of decision you need to get alone and then maybe we'll change it later if it's not like unreversible decision and which decision you need to not get along and just hold the task and move to something else because it's really something that you need to ask before you keep going and choose the direction. So I'm trying to also test and see, which is also not easy way of testing this, but it's like trying to get clues if the person that I'm hiring is the developer I'm hiring has good judgment of what he need to do and how independent he is.
And this helps. And also, I think our team is composed from mostly top open source contributor around the world. These are people that really, really loves to write code and developing and building software for developers. So many times, say this is like not only their job, it's also their hobby, which leads to be more flexible about hours and being available for something. Because eventually, if I want JJ from Singapore, JJ is one of the core team members of View-JS, if I want him to work on something with Luv, which lives in Canada, then someone will need to be flexible on the hours, no way around it. So being open to this because you love what you are doing. And you understand that this is kind of like the culture and it's not happening on every day that JJ need to work on 3:00 AM, but sometimes one of the sites will need to be flexible and try to find maybe inconvenient time for a session together.
Shane Hastie: So with a team of people for whom work is also their hobby, how do you help the balance and avoid things like burnout?
Balancing work and avoiding burnout [13:40]
Gilad Shoham: So first I think that people who loves what they're doing are less suffering from burnout in general because it's not feel like a job. It feel like something I enjoy, which is important. If you work on a startup, it's always important to be, let's say, durable for burnout as much as possible. And I think that one thing that really helps is that I know that the people in my team will do the best they can to achieve the goal and to implement the task. And it's a very unique perspective which will not work in any other team, but I don't set clear timelines or deadlines for the tasks because I know that first, we are here for a marathon. It's not one sprint. Okay, I cannot push the people in one or two sprints just to achieve something because it will lead to burnout. Also, I know that let's say I come with a deadline, okay, you need to do this in two weeks.
This is much more work, okay, and I don't know to estimate maybe. And it's like two months work, okay? It doesn't matter how push I will hard, it won't end in two weeks. So my assumption, the base assumption is that the organization, the employees, everyone are on the same side. Everyone has the same goal and as opposed to some organizations that think it's like a zero game case, which if the organization is good, then it's bad for the employee or the opposite. I think we are all on the same side and I know the people will understand and will do their best effort to achieve it. So no reason for me to try to just push them or micromanagement them in order to do this. I'm here to help you achieve the goal. If you have question, if you are stuck, if you need someone to brainstorm, I'm here, but I won't force you most of the time, unless it's like a very, very unique cases with a production [inaudible 00:15:46] with a big customer or something like this, which is really time sensitive.
Other than that, I trust the people to do their best on their time and I don't monitor how much time they are working, when they're working, you prefer to work on morning, you prefer to work on night, you have some arrangements you need to do. So you work only like four hours this day, I trust you. I don't check it, I don't monitor it. I don't know how much time people worked. And if they need to take a break, they can just take a break. They don't need to tell me this. I trust them to take the break they need if they feel exhausted and come back with new energy when they feel good.
Shane Hastie: The theme there, and you used the word over and over again, is trust.
Gilad Shoham: Yes.
Shane Hastie: So important in organizations today, and sadly I see it lacking. But in that high trust environment, what are the day-to-day activities of managing? What do you do as a manager in that environment?
Building trust in remote teams [16:53]
Gilad Shoham: So I'm kind of working in mostly a star methodology because the teams is very different and it's how to combine everyone together on the same room. Then I usually do a lot of session one-on-one with the employees because I also really, really love what I'm doing. So I'm available all the time pretty much. I try to be available on different hours, sometimes from mobile, but to answer questions so people at midnight before I'm going to sleep, if I have a question, then I won't say, "Okay, I will answer this tomorrow", because it means that someone will waste his entire day now waiting for my answer. So first, I'm very, very available for question almost all the time because I understand this team and I really like and care about what I'm doing. Also, because we have very clear responsibilities, a lot of the tasks many times come from the developers and not from me. Okay, because I brought, let's say, Zoltan to work on dependency management.
Okay, Zoltan is probably one, if not the best developer across the world to work on dependencies. And he can come with the features and sometimes it's just two features even without fixing stuff, without even I know this before. Okay, he saw something, he saw a bug. He think about an improvement and he does this and this is like the judgment came back like, "Do you need to start working on this or maybe let's talk about it before we do this?" And I'm here mostly to help them to achieve... I let them be the drivers to think about what we need to do, which kind of improvement we can do in this different areas. Sometimes of course we have some stuff coming from the business and for me as well, and we are working a lot together. So I'm available, we're working with Discord as kind of like a virtual office, which is also very interesting.
We really, really use it as a virtual office, which means we have different rooms. Everyone goes when he start working, go into a room, put his headphones, I don't know, listening to music, working. And if someone want to talk to me, he don't send me a message. It's just coming to my room in Discord and start talking to me in my headphones without any introduction, without a message, you hear just like this. This is also very unique and help a lot with the remote culture because before we start this and it took us time to implement this method, people felt a little bit alone, right? You're working with us working right now, with on vacation, with on days off, with sleeping. I don't know, maybe I will bother someone if I will send him a message right now. And once we move to Discord, you see everyone that is now working, so you don't feel alone.
And it also help with the more... I don't know the term in English, but talking about stuff which does not work, which is also important. On a physical office, you meet in the coffee space and you do some small talk. On remote, you want schedule a meeting with someone to talk about nothing, okay? It's just not happening. Once we move to this and reduce all the friction of the scheduling and stuff, we see much more people doing small talks and creating friends among these teams. And we also see increasing productivity because maybe you are on Discord and then you see our designer which live in Berlin talking to some front end developer in some room.
And you see them share the screen, for example, and everyone in the company can jump to this room and just become part of the conversation. Just see, maybe the designer is showing this front-end developer a new feature that is coming, that is going to implement. So you can jump and be part of the discussion just like this. So like you go into a physical room in the office. So it's much more collaborative feeling once you do this and this really, really helps with every management aspect and not only management, but feeling like a team and not like a group of individuals.
Shane Hastie: What happens when you grow? How do you scale this? Can you scale this?
Can this approach scale? [21:16]
Gilad Shoham: This is a good question and the answer is that I'm not sure. First, we didn't scale yet, so I don't know if it will work on scale. I do know that there are companies that working fully distributed, fully remote in much larger scale, and they do this. Does it work good or bad? I don't know for sure. I'm sure they'll not put it out cloudly if it's not working good, so they don't mention this on the articles. And I also don't know if maybe it is working good, but worse than being on physical office, which also hard to measure and compare. I think if you try to scale it, you will hit more stuff that we don't see right now.
And we need to evolve if we scale. We need to improve the methodology. We need to improve our communication channel, our documentation for different staff, maybe create a bit more boundaries on Discord if we keep this method, because if you have 200 peoples jumping between rooms, no one can really do something because you'll get too much interruptions, so we'll need to improve this as well. So yes, I hope that we will scale and become large and we will find out. This is a good problem that you have.
Shane Hastie: Great. So leaning back into your mentoring conversation we had earlier on, a fair number of our listeners are new to leadership roles. They're relatively recently promoted into team leadership or they're thinking about that. What advice would you have for the new technologist moving into a leadership position for the first time?
Advice for new leaders [23:02]
Gilad Shoham: Okay. So I have a few advices. First, especially in the technology space, there are some kind of emotion or standard, it's not exactly a standard, that organization promote the best developer into leadership position. At this point, as new to leadership, you need to understand that one of the first thing you need to do is to learn to delegate tasks. Many times, you probably be the one that do the tasks the fastest or the best, but if you try to do all the tasks, you won't be able to do this. So you need to learn to delegate and trust your people and moving from a doer to a helper, okay? This is very important and I think many, many people, especially new to leadership, having a hard time to release and delegate and other things that they moved to do something else, which is one very important advice.
Another very important advice is that as a leader, you need to put your team on focus. The successful of your team is your successful, not your successful is your successful, but when your team is doing good, it means you are doing your job good because your job is to make the team being the best team ever. So you need to empower them. Also, giving good words and another term that I don't know exactly in English, but giving good words and let's say raise your teams, individual of your teams globally or publicly is basically cost nothing and has great impact on the feeling of the team. So now if someone did a good job, you can just, I don't know, put a Slack message in a large channel of the company, "Thanks to someone, he did this and this, this is a new feature, he led this feature, he implemented this feature, did a great job, you can enjoy it".
So just something like this to a huge impact on the team. And I like to say that there are a difference between being a manager and being a leader. And the base distinction is that as a manager, you take your power from your authority. You can decide what to do and you can tell someone to do something because you have the power by the organization to decide. Leader is about follower. When you are a leader, people are following you because they trust you, because they believe in you, because they know that you are doing the best and you are thinking about them all the time. So they do what you tell them to do, not because you have the power to decide, but because they believe that you think about it and this is a good decision or a good path to go because they believe in you.
And I advise anyone who is promoted to be a manager to try to think how we become a leader from being a manager, but you get the power when you're promoted. Now you need to try to minimize the use of the power and replace it or get you power from the beliefs of your followers, which is your team usually.
Shane Hastie: Gilad, thank you so much. A lot of really good advice and lots of food for thought there. If people want to continue the conversation, where will they find you?
Gilad Shoham: So there are a few places to find me. First, my website, it's gilad.dev. Gilad is G-I-L-A-D.dev. Contact me from there, and you can see other podcast blogs and talks I did there. Also, of course, I'm very available on LinkedIn. It's Gilad Shoham, G-I-L-A-D. Shoham, it's S-H-O-H-A-M. You will find me with a picture with some blue hat at the moment. So this is me. You can also find me on Twitter or X, so you can send me a message there, but I might miss it. LinkedIn is the best place to find me.
Shane Hastie: Thank you so much.
Gilad Shoham: Thank you too. It was a pleasure to being here and I really enjoyed this conversation.
Mentioned:
