‘Effective Strategies For Leading Development Teams’ With Anton Zaides, Development Team Lead At Taranis

Kovid Batra: Hi everyone. This is Kovid, Kovid with a K, your host at Beyond the Code by Typo. Today on this episode, we have an amazing, cool guest from Tel Aviv, Anton. He’s the development team lead at Taranis. He’s the author of newsletter ‘Leading Developers’, which is about to cross 2000 subscribers within six weeks. Amazing, Anton! And on top of that, he has 12+ years of amazing engineering experience. Let’s just hear it from the expert. Welcome to the show, Anton. 

Anton Zaides: Thank you, Kovid. Glad to be here finally! Yeah. 

Kovid Batra: Great! So as for the format, we have a quick fireside chat, wherein we will be asking you some questions that would help us understand more of the personal side of Anton. 

So, we are going to start with that. Are you ready? 

Anton Zaides: Sounds good. Yeah. 

Kovid Batra: Alright, Anton. So, the first question. Let’s say, a friend visits you in Tel Aviv. Let’s say I visit you in Tel Aviv, okay? Which would be those places where you would take me to, to show around the culture, the people, and the natural beauty? What should be those places? 

Anton Zaides: I think my favorite one would be the Tel Aviv beach. It’s one of the most beautiful around the world. Tel Aviv itself, it’s like, I’d say it’s the most expensive, but also the best city that exists. So, I really love it. So, it starts with the beach and see how we enjoy it, and then continue.

Kovid Batra: Alright. So, basically you are a beach person then, right? 

Anton Zaides: Yeah, definitely. Yeah, I’m playing beach volleyball, I like running on the beach, swimming, all of it, yeah. 

Kovid Batra: Perfect, perfect. Alright then, moving on to the next question. You have this 12 years of experience, you’re writing, leading developers. I want to understand, what’s your source of learning? Like, what exactly helps you learn the most? Is it your mentors? Books? What is the main source? 

Anton Zaides: So personally, it’s 100% books. I know a lot of people love mentoring, but I really love the format where someone spends months or even years putting a lot of knowledge in one page and hundreds of pages. So, I read like, I don’t know, two or three books every week for the last decade. I know it’s not everything might be useful, but I really love it. So, definitely a bookworm. 

Kovid Batra: No, I think that’s one best way to learn actually and most successful people whom I have talked to, they are fond of reading. So yeah, I think that’s a great habit. But for audience, which one would be one or two books that you would recommend, like for the engineering leaders and the engineering managers? Which books you would recommend to them? 

Anton Zaides: I think the top one that really changed how I manage is ‘Radical Candor’ by Kim Scott. That was a big, big one. And, a more general one is about Netflix, the ‘No Rules Rules’, like about how they built the culture over there. So those two are, I think, my favorite ones.

Kovid Batra: Alright. Last question from the fireside chat. Can you tell us one funny production outage that you encountered? 

Anton Zaides: I caused a few funny ones, I think. I just sent a newsletter before the talk about one of them. And, I wrote an SQL query, where it was “update (some) table set is_deleted = true”. And then I had a line break. And then the ‘where’ condition. And then when I ran it, the ‘where’ condition was ignored, and I basically deleted all of our orders in the database, real orders. 

Kovid Batra: Oh my god! 

Anton Zaides: Yeah, yeah. It was on a weekend and it took me an hour to recover. I was the most nervous I ever was. But yeah, that was it.

Kovid Batra: I think almost everyone who has been into coding has done that some time. 

Anton Zaides: Yeah. Yeah, definitely. But you do it once. I never did the same mistake again. So… 

Kovid Batra: These mistakes should not be repeated. 

Anton Zaides: Yeah, definitely. 

Kovid Batra: Alright. I think that was cool. Now, Anton, we’ll move to the main section wherein we would be learning some practical tips from you on how to lead the dev teams. That’s what the theme of our today’s episode is. So, I’ll start off with a few questions, but, I think the first thing that I want to know from you is, you have come across a lot of challenges for sure in your engineering career, right? So, I would want to know which of those one or two challenges were really, really hard for you. And how did you overcome those? If you could share some of your experience. 

Anton Zaides: I think the main challenge, and it’s a bit of tough to say it, but I’m a micromanager by heart. The easiest way for me is to be very into the details, and know everyone, and ask questions every time and be very, very annoying. Like, I’m a control freak. That’s my nature. And it took me a lot of time to understand how toxic can it be and what’s the effect on other people. And I still fight with it. For example, we are working hybrid, and on the remote days, I like to know what everyone is doing. I like to send them messages and understand what everyone has problem with. So now, I’m in the stage where can I just, you know, let go for a day or two, but it’s a constant struggle, right? Because the people tell me they need the freedom and they don’t need me to be so controlling. But, it comes from the good place. Usually people, you know, bash the micromanager saying, you know, “That’s the most awful managers.” But usually, it’s because you care about the people, you want them to succeed, you want to help them. So, when it’s from a good place, it’s hard to fight yourself, you know, and just let go. But definitely, it’s something I’m improving on and I know I should. Yeah. 

Kovid Batra: Yeah, I think this comes very naturally to human beings, like having control. It’s a very primal instinct of a human to have that control, right? So, even if it is coming from a good place or from a bad place, people perceive it mostly in the negative sense, like the people who are getting managed. So, it’s hard to change. Of course, when you have right intentions, you’re not able to motivate or incentivize your brain to not do it because you’re already doing it for the positive. So, yeah, it’s difficult, but how do you exactly deal with it? I think that would be really, really interesting to know, like what goes on in your mind? “Okay. In this situation, Anton, don’t call that person.” You have to stop yourself. So, what exactly do you do to recall that and be doing that when you are in the day-to-day?

Anton Zaides: I think that for me, it’s mainly about asking questions, right? Someone works from home and I think they might have a problem or need me. So, I have like this habit that before I send a slack message or before I go to someone’s place to talk to him, I think to myself, “Okay, they probably know that I’m available if they need me, right? So, is this so critical that I need to stop them from doing work?” So, I’m thinking about the negative effect of it. If they need to respond to me they might be right in the middle of coding something or thinking about it. So, when I try to think about the negative effects, it usually helps me stop, you know, bothering people. And the main thing is hearing from them. Like, that’s the main thing that changed my behavior. When people tell me, “Okay. You can trust me. I can handle it. I don’t need you to, you know, babysit me or see how it goes.” And when people tell me that, it makes me feel like more, you know, ashamed. It’s not that I don’t trust them. I want to help them. I want to make sure I’m available. So when they tell me it’s bothering them, that’s why I know, “Okay, I crossed a line. I need to take control of myself.” So that’s the two things.

Kovid Batra: I think if they’re gonna listen to this podcast, they might have a different perception about you now, because you are mentioning that you’re doing it from a positive, positive intention. So, yeah, I think that’s cool. It’s a very good advice. We should be considerate of other people, might have to context-switch or they might have to pause in between, which is very critical right now. So, putting that thought before asking a question or doing something which is related to your management, probably can take a backseat for a while if you are considerate and you’re doing that consciously. So, that makes sense. That makes a lot of sense. 

Anton Zaides: I thought that saying, “How is it going?” is micromanaging, but saying, “Is there something I can help you with?” is fine, right? So, usually the messages I send, “Is there something I can help you with?” But, it’s still micromanaging, and this took me time to understand. Even if you only offer help and you’re not pressuring someone. So, that’s the kind of thought. Yeah. 

Kovid Batra: Cool! Got it. Alright, moving to our next question. So, as we know, in your career you have led the software engineering team. You have also led the DevOps team. How is it different leading both the teams? Of course, altogether they help each other, definitely. But, how is it different leading both the teams? 

Anton Zaides: Yeah, as you said, many differences. Different professions, right? DevOps is what was considered Ops and IT. Now, it’s a completely different profession, DevOps engineer. But I would say the biggest difference is the people you develop for. So, when your clients are developers, internal teams, they know what you’re doing, they have technical knowledge, so they give their input. They are pushy. They’re never satisfied with what you do. They think you can do better. So, if you improve performance by 50%, they want 80%. So, you know, customers don’t always know and don’t always demand things. And this one was hard for me to understand. Like, I’m doing my best. What do you want from me as a DevOps team leader? And as a software team leader, you know, you work with the PM and you manage the expectation and you are the authority. When you say something will take X time, that’s usually what it takes. So, that’s one major difference. 

And the other one, I think it’s the priorities. I’m used to having a big project, let’s say 4-6 weeks or something like that, and just working on it, with minimal distractions in a regular software team. In a DevOps team, it’s like, you know, fires all over the place. You know, everything is more urgent, you have the SOC review, and then you have some new features someone needs, and then the database needs to be restored, whatever. There is like, so many distractions. And that was very difficult for me. Because I tried to do like, sprints, and you know, 2-week sprints and everything, it was not a good success. Yeah. 

Kovid Batra: Just a follow-up question on that. which one do you think you like more? What aligns more with you?

Anton Zaides: I think software teams, not DevOps team for me, mainly because I like less distractions. I like the ordered work and mainly I love the communication with our customers, right? I feel like as a DevOps team, one of the toughest part is you don’t directly affect the business. You might not even know what the business is about, you’re focusing on the development process. And, I love to know like everything, from what the customers are using, how the sales are going, helping the sales people. So, that’s the major difference that I now, feel that’s the main reason. 

Kovid Batra: Perfect. Thanks for being so honest. Alright, moving on to the next question. Setting expectations, and then delivering on them with the product teams & the business, is something that every engineering manager or a lead developer or a team lead wants to do, right? We have had a chat around it. So, I really wanted to know, like, what approaches or methods do you take to actually build things in time, fulfill the commitments? Because that’s the expectation of the business side of the product side and me coming from that background, I feel that is what usually we have to fight over and discuss in the team. So, I really want the audience to know what approach or method they could take to actually deliver on time. 

Anton Zaides: Yeah, that’s, that’s your toughest question, I think, and would require the longest answer. It is something that I’m heavily focused on and I can say it’s improved a lot in the last two years.

My first mistake is committing to something I was not comfortable with. So, saying, okay, I was pressured to commit. “You need to release this project in three months.” And, even before the scope was clear, I said, “Okay, I will, I will do it.” without completely understanding the picture, right? Asking the questions, going down to the details. So, if you start developing when you’re not comfortable with the time, you already start on the left foot, right? You need to be comfortable and give pushback to your stakeholders. So, if they say, “Commit to this in three months.” you need to understand exactly what you’re committing to. Ask why shouldn’t we do something simpler in one month. Right? Why should we do such a long project? Because you know it probably. The longer the project, the less likely you’ll finish on time, right? A three-year project never will finish on time, and five year will never finish. That’s how it works. So, the smaller the project, the more chance it will finish. So, that’s the first thing that I had to overcome because as a young team leader, it’s very hard to give pushback to your manager or the PM (the Product Manager). They say something, they have experience and you trust them to estimate it correctly, but you will be the one held responsible for delivering on time. So, you have to be comfortable with that. 

Kovid Batra: Yeah, I think that’s a very good point. Anything that you usually practice, or you use as a tool to actually overlook what’s going on? So, as a team lead or as a manager of a team, how do you ensure things are moving on time? Let’s say, you have signed up for a sprint and during this sprint, five, six days have passed and you want to keep a check on what’s going on in the team. So, how do you usually do that? And how do you proactively take measures to actually reduce the bottlenecks, and making things smoother and move faster? So, how do you do that?

Anton Zaides: Yeah, that’s something I actually haven’t solved yet. So, have a clear understanding of what are the pain points, who is stuck where. So currently, because the team is pretty small, right? Five developers, four now, we had some re-org, so it’s basically based on dailies, and talking to people. So, there is no, like, understanding. I tried to use the burndown chart, you know, that says ‘how many things you completed’, but it’s a bit of a lie because you almost always complete everything in the last 2-3 days of the sprint. So, even if you feel pressured, it’s not necessarily a bad thing. So… 

Kovid Batra: It makes sense, but I think, here, a few tools could be a real good help. Just a suggestion from my end. Like, you can have certain tools which give you a clearer picture on things that are happening on day-to-day basis in your sprints as well. I think there would be, something that you would want to improve on here where you have a clarity on what’s going on on day-to-day basis to proactively take measures. 

Anton Zaides: Yeah, I definitely agree. I think there is a need for it. But it’s more of the change, the habits of people, right? You need to educate people about the need, and I think that’s what you and Typo are doing with the podcast and with the tech itself, to share the need and I agree, I feel the pain.

I have many more, like, thoughts on how to deliver on the expectations. I think we covered the first one, right? Never being comfortable with what will you commit to. And, we touched a bit on the second one, never commit to tremendous, long, long projects. Even six months is long. And even three months is too long. I recently read a book about ‘Basecamp’. I don’t know if you hear about it. Those guys are amazing. So, different perspective, they do a bootstrap without VC and they have different culture. And they say they don’t have a roadmap, they have 6-weeks projects. They don’t know what they’ll do in more than six weeks. That’s how the whole company runs. There is no 1-year plan, no quarterly plan. 6-weeks projects. And I think that’s actually a good recommendation. Not having your roadmap, right? You cannot control that as a development team lead, it comes from the management. But, having projects no longer than six weeks and making sure you release something, right? Because even the most complex projects, you can have an MVP in six weeks and get feedback and it’s, it’s obvious, right? Everyone talks about lean startup and everyone knows it, but it’s very hard to do because you want to deliver something beautiful, right? You want to deliver something super useful from the day one and you don’t want to deliver like small part. So, that’s a fight I’m constantly having with myself saying, “Okay, it’s fine to deliver a small piece in two weeks, in four weeks.” And that’s the obvious one. 

And the last one, I think, which was the biggest learning for me is, you know, the triangle of time, cost and quality, right? if you commit to the same scope for the same time, something will suffer, right? So, the things that we are currently optimizing for is the scope, right? So, you deliver the same time, you deliver high quality, but you can change the scope after it starts. You can remove things that you think are not necessary. You can play with it, because if you fix the scope and the time, it will be lower quality. And I felt it. You can release on time, but the code will not be reviewed, right? Because you don’t have time. No QA. You don’t have time. Lots of bugs. You do not have time. So, if you want high-quality code on time, you have to be very, very flexible about the scope. Yeah. And that’s something that our organization improved on. I feel the improvement and I think it’s a great way to work when everyone is aligned that the scope can change. That’s a good way. Yeah. 

Kovid Batra: Yeah. I think what I get, an essence from the two points that you have mentioned about how to deliver on time. One is, of course, being comfortable and confident in what you want to do and what you can commit to. That is one very, very fundamental thing which one should have. And the second point is breaking down into small projects and then being flexible with the scope, would really help. But, at the same time, I also feel that there are times when you have to stretch, when you are in a startup mode, when there are things to be delivered, and there is less time for planning, actually. That’s where the problem comes in, right? If you will have the time for planning, then you will be able to estimate it better. But, when you don’t have time for planning, what exactly works for you? Is it like, just keep the scope flexible? On the run we will decide what is something that we see getting completed or we don’t see, is that how it works?

Anton Zaides: Yes. I think the main benefit and it’s still hard, but especially if you don’t plan to release as fast as possible as you can, under a feature flag, easily reversible, but to get a real feedback from your customer as soon as you can. So, let’s say, there is an idea. We had a good example of it, of something that our U.S. team, our customers in the U.S. We are an agritech startup flying drones over field and our whole team is in the U.S. like sales and customer success. And, they flew here and we had a meeting, you know, with a whiteboard and they had an idea to do, but there was no time to plan. We are an agricultural startup and now is the money time, right? People are in the fields harvesting. So, there is not much time to plan. And we had some idea and we just went with it. And after a single sprint, up 2-3 weeks, we did something that was not perfect. It was different than what they thought, but it let us have a conversation, right? I remember a lot of creators saying that code wins arguments, right? That you can do something. So, that’s my solution for when you can’t really plan and it’s not perfect. Definitely in this case, you don’t commit to anything because you don’t know what you do. You’re saying, “Okay, I work as fast as I can and we’ll see what happens.” And sometimes in startups, as you say, that’s the way to go. You don’t even need to plan. You just need to move as fast as you can. 

Kovid Batra: Makes sense. I really like your thought process on this. Is there more that you want to talk about? Anything else you want to add to the already-defined approaches that you’re taking? 

Anton Zaides: No, I think to summarize it, like as a team leader, it takes, and it leads us to the next question. it takes a lot of time to have the, I would say the strong base to say no, to give your own estimates, to have pushback to the other people. So, as you learn it, it gets easier. That’s what I want to say to new team leaders that it’s hard. It will be hard, but it gets easier to both estimate and push on what you believe.

Kovid Batra: Perfect. Perfect, Anton. I think that’s a great piece of advice. I hope this helps a lot of our audience, the aspiring leaders, aspiring managers. I think we already touched this topic and that is, what exactly is this experience of transitioning from an IC to a team lead role? I feel it requires a lot of change in your behavior. And some people are natural leaders, so they easily move into that, but there are sometimes biases, there are sometimes already built habits that actually, are not healthy when you are leading a team. So, you have to change that. So, that phase really is difficult for a lot of people. What’s your experience, what’s your thought on that, and anything that you would like to share? 

Anton Zaides: Yeah. With every team leader I talked to, this transition was hard. There was no single one, even the most, you know, leadership-prone ones, like the best leaders. It was hard for everyone. I think this is the toughest transition in tech. If you go like higher, everything is tough. But this one, from being an individual contributor to manager is crazy. And mainly because you’re doing so many things, it’s like you knew how to juggle 3 balls and now you need to juggle 27, right? It’s like, “Okay, how can I do that?” And that’s really, really overwhelming. And the biggest part, I think, is as we talked about micromanaging and the downside. It’s really trusting your team. And, the one thing that is hard is requesting help from them. So especially, when you start, you want to reject an image of a strong leader that knows what they’re doing, you know, lead the team to a new place, especially if it’s your own team. If you’re promoted in your own team, suddenly you try to behave in a different way to be the manager, right? And it’s not your teammates anymore. And this is what makes the job hard when you don’t depend on your people. You try to do everything on your own. You don’t trust and also try to code a lot. So, the combination of you feeling everything is on you, is really hard. And the one thing that helped me to start delegating is really ask for help saying, “Okay this project I know I will not be able to do it the best I can.” Talk to a developer and say, “What do you think we should do here? How would you tackle that? Do you think you can lead this?” So, it comes from a place, not delegating like, “Okay, you do this, and you do this.” Right? You decide with your team, play on the strengths of each person. That was the main game-changer for me. 

Kovid Batra: That comes from a very core feeling of, again, humans. Like, when you see someone sitting on top of you, who has been an equal, let’s say previously, you definitely would have that insecurity developed. You would already be defensive towards a lot of things and not accepting a lot of things. So, in that situation for a person who is moving into that role, I think the best thing one could do is have a clear mind of treating everyone equally, because if you’re doing everything with that intention, as you just mentioned, would really, really help. Like, be inclusive, take the team along, make decisions with them. Just don’t put work onto them, or simply delegating things, it should be more of a discussion. So, yes, I think that’s where you have to actually think through and be very particular and conscious of your actions and words that you take when you are in a meeting or when you’re discussing it with the team. So it makes a lot of sense, I think, Anton. Yeah. 

Anton Zaides: And, also just admit it’s difficult for you and admit your problems. So, for example, when you transition, you have your first 1-on-1 with someone who was your teammate, right? And it’s always awkward. It’s like, “Okay, it should be different. We never had one.” And even admitting this really simplify the conversation saying, “Okay, this would be awkward for a few weeks, I know it. We’ll find the balance. I want to hear from you. You are knowledgeable. I trust you to help me to do this transition. We are together in this.” Like, “I want to hear feedback from you as soon as possible. Let me know what I don’t do right or where can I improve.” So, when they feel part of your transition to leadership, they will be more receptive. That’s my experience. 

Kovid Batra: Right. This is one great advice, Anton. Thanks a lot. 

So, I think that brings us to the end of today’s episode, it was really, really nice talking to you. I would love to have more such conversations with you as you transition into even higher positions in your company and really feeling great and happy about your newsletter growing so well.

So, all the best. I think you’re doing great.

Anton Zaides: Thank you. Appreciate your time and great questions. I didn’t know I like to talk so much, but yeah, you have great questions and it was a pleasure being here. 

Kovid Batra: Thank you so much. Thank you.