In the recent episode of ‘Beyond the Code’, Host Kovid Batra welcomes Limor Bergman, tech leadership coach and mentor with a rich background in organizations such as DigitalOcean, Quantum, Sun Microsystems, and more. She also hosts her podcast series ‘From a Woman to a Leader’. Their conversation revolves around ‘Empowering Women in Tech’.
The podcast begins with a fun fireside chat with Limor, allowing the audience to see her candid side. Later in the main section, She delves into the distinct journey of women in the tech industry, and strategies for overcoming them. Limor provides insights into managing fast-changing technology challenges in engineering teams and making optimal choices in tech career. She also shed light on how to define the success of your engineering teams.
Lastly, Limor shares parting advice for the audience, encouraging them to take risks and embrace failures.
Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. I am back with another episode and a new guest who is passionate and a powerful engineering leader. She has an experience of 20+ years, currently serving as an executive coach and a mentor. She’s all about supporting women in tech. She runs her own podcast, ‘From Woman to a Leader’. She’s coming up with season 2 of the podcast, which is ‘Women of Color’, where you can find her talking about different diverse cultures and women growing as a leader there. Welcome to the show, Limor. Great to have you here.
Limor Bergman: Hi, Kovid. Thank you so much for having me. It’s a pleasure being here today.
Kovid Batra: Perfect.
So, all right. I’ll quickly tell you about the format of the show, Limor. We start with a quick fireside chat, and then we jump into the experiences that you have had as an engineering leader. So this fireside chat is to know more about you outside of work a little bit, some interesting things about you.
So, are you ready for some quick questions?
Limor Bergman: Yeah, absolutely.
Kovid Batra: Perfect. So, let’s get started. I have been like reading a lot about the tech blogs, the tech bloggers who have been producing a lot of content and you being one of those. I just really wanted to understand what inspires people like you who are writers to come up with writing. I have this thing, which I really need to know and understand because I someday want to write a book, whatever I’m learning from here. So yeah, that’s the first question for you.
Limor Bergman: Absolutely. And, I want to write a book as well, to be honest with you. It’s on my plan as well. So actually, you know, when I grew up, I thought that I couldn’t write. It started with a teacher that actually told me that I’m not a good writer. I mean, I was very good in STEM, you know, math, physics, chemistry, but I got kind of a traumatic experience from writing. It was traumatic because I got negative feedback. And also, you know, although I took a tutor and that was like the only tutor I took in high school just for writing. And my teacher was always criticizing me and that left, you know, an impact for years to come. That. Yeah, I may not be able to write, but what happened, the interesting thing that happened then, I wanted to express myself. I wanted to share my thoughts. I wanted to share with others, you know, all the insights I had and I actually started writing.
Kovid Batra: Okay.
Limor Bergman: And I found out that first, I really enjoy it. And then, I also, I’m not that bad. I mean, it’s not that terrible. And the great part nowadays, because everyone can be a writer, right? Everyone can write a book. Everyone can start a blog. You don’t have to be Shakespeare. You don’t have to be like super-duper excellent. Just express yourself, be genuine, express and share what you have, and do it. Everyone can do it.
Kovid Batra: Yeah, it’s a very simple thing, actually. Like, you just have to have that feeling of expressing your thoughts. You just, you probably can perfect it over a period of time, but you don’t have to fear starting off. You just have to have that feeling that you want to share what you have in your mind.
Perfect, Limor. I think that’s quite enlightening for me at least. All right, moving on to the next question. What advice would you like to share with young joinees in tech?
Limor Bergman: Yeah, that’s another great question. So, I’ll start with a quick story. So, when I started my first software development job, I was still you know, in university and I started like a part-time job. And, the experience was terrible because for multiple reasons. First, I had a very, very unsupportive manager. She was actually a woman. My first manager was a woman, but she was very strict. She was not nice. I guess she felt like she needed to keep a very clear distance. She was not supportive. I really did not enjoy working with her. The second thing is that I was working on ancient things, like on COBOL, on Mainframe, and I hated every second. I hated every second. It was clear to me that while it was comfortable for, you know, while I was at school, you know, because it didn’t require much challenge from my side, it wasn’t going to last. As soon as I’m going to graduate, I cannot keep doing what I was doing.
What I did was that I went to the manager above my manager back then, and I had a conversation with him and I told him, “Listen, I mean, I really like the company. I would like to stay here. But, I cannot continue working with, with that, you know type of work. That’s not what I signed up for. I want to move.” I mean, back then Java was the shiny new technology, new language. And there was a team that actually wrote Java Applets. Yes, I’m that old. So, and I told him, “Listen, I mean, that’s the team I want to join right after I graduate and move to a full-time job, otherwise, I mean, I just cannot see myself staying here.” So, I wasn’t threatening per se, but I was making clear that, I mean, that’s not going to work for me. And, you know what happened? He listened. I mean, I was lucky, right? I mean, he could’ve not listened, but he listened and he moved me to that team.
And long story short, I would say that the advice I would share is that even if you’re just starting out, appreciate yourself and what you are worth, know what you want and don’t be afraid to ask what you want, even if you are just starting out.
Kovid Batra: Yeah. I think I can, I can relate to this feeling and when I had joined my first job, I was always under this impression that something should not go wrong, people should not perceive me wrong. And on top, like the most important thing was the managers, the leads should not perceive me wrong in any way. So, I used to, like not express much and I couldn’t be genuine there and it definitely affected me in a negative way rather than in a positive way. So, that’s a very good piece of advice that you have to be fearless, in a reasonable way. Like, you have to be polite and respectful, of course, for others. But, you cannot be just listening and not expressing your views, not being genuine there. So, yeah, I think that’s a good piece of advice, Limor. Thank you for sharing that experience, by the way.
Limor Bergman: My pleasure.
Kovid Batra: All right. I know you are super passionate, super powerful. I get that vibe. And, I just want to understand what’s your daily dose of energy, like what keeps you going every day when you wake up? What is it that pushes Limor to, like go up?
Limor Bergman: Yeah, absolutely. That’s another great question. So, I like going to the gym. You see, my hair is a little bit wet still because, I just I got back from the gym about an hour ago. So, my daily dose of energy is just running. I actually discovered running, you know, when I was in university. So, I was going to a gym there. But, I stopped for years, you know, when I got married and started a family, I have four children. So, you know, it was hard and I kind of was very inactive. I lived very sedentary lifestyle. In the beginning of my forties, I really wanted to change that. I couldn’t believe I will be able to run. You know, I had those limiting beliefs, it’s impossible for me to run, but I actually worked on breaking those beliefs and started running and found out that it’s a great source of energy for me. It motivates me. It gives me not just motivation, but a lot of strength, a lot of joy. So, that’s kind of my daily dose, either running or just doing weightlifting at the gym, meeting with people, you know, that I already know. That’s what keeps me going.
Kovid Batra: Cool! All right, Limor. Thank you for this fireside chat. And I think we got to know a lot more than we already did about you. So, that really helps.
Now, moving on to the main section, uh, wherein we want to talk about a lot of things. But, we’ll keep our curiosities in our pocket and try to restrict it to a few questions. Can I get started with you there?
Limor Bergman: Absolutely.
Kovid Batra: All right. First of all, it’s already out there, and I really appreciate from the bottom of my heart, the kind of push you are giving to the women in tech. Really hats off to you. We know that this journey is different for a woman in the tech industry. How do you think it is different from the male counterparts? And, what you really think should be done about it?
Limor Bergman: Multiple reasons. I mean, first of all, we are still outnumbered. So, there are fewer women in tech compared to men. When I started my career, for years, I was the only woman working surrounded by men in my team. I was the only woman. It wasn’t terrible. Don’t get me wrong. And, I worked with wonderful men, very supportive. I learned a lot from also very supportive managers, but I felt different. Felt like, “Okay, I’m not exactly the same.” And, sometimes it was harder for me to feel a sense, a sense of belonging, right? Because the men, they wanted to do different things to hook up after work and maybe not everything interested me. And so it’s, it’s about belonging and feeling like I belong, I’m worthy, I’m like the rest of them. Men tend to be very competitive, ego-driven, not a bad thing. I’m not saying that negatively, but it’s like, “Okay, I’m better than you.” Like, they have this tendency to really thrive from competition. I don’t know if you’ve seen that, but men have this tendency.
Kovid Batra: No, definitely that’s there. It’s just that I’m keeping my thoughts to myself and listening to you.
Limor Bergman: Yeah. And for women, at least for me, less so. I thrive by growing and becoming a better version of myself every single day. I don’t care much about how I am compared to others rather than to me. And that, like having those different mentalities, it’s sometimes difficult because I don’t want to compete with someone else. I don’t want to prove anyone that I’m better, I don’t need to necessarily. That can create a lot of uncomfortable feelings. Sometimes confidence issues, when people make comments, not in a mean way, but just that’s the way to communicate because they want to show how better they are. You know, so a lot of more differences, you know, women, you know, create life that comes with its own set of challenges. So, I think that the mentality and the way of communication, and the way of work is kind of very, very different. And the fact that we are outnumbered.
Kovid Batra: Yeah. But, what do you think exactly can we do about it? Actually, that’s something which is a long-term, long-held problem. What do you think today.. I think that ratio has definitely changed from the time probably when you joined as a leader or a woman in tech. Now, it has changed. But, what according to the current scenario can be done around it to solve this problem?
Limor Bergman: I think, first of all, it starts with awareness. Even if you have a team that most of the team are men and there are fewer women, just take that into awareness that how can I make the women in my team feel like they belong, feel comfortable? What can I do to support them and be sensitive to them, to what you say or don’t say? You know, I remember I was deeply, deeply demotivated and hurt by just code review comments that people wrote me because they wrote it in a way that was not sensitive enough. It was like very blunt. Again, nothing, it’s not a bad intention, but it can really hurt confidence of someone when you make a code review that is very, maybe you’re right, or maybe you’re trying to make a point, but it can really hurt the confidence of a woman or even what you share in a meeting and how you, how you talk. If you’re telling someone ‘you’re wrong’, if you use strong words, right? When a woman starts to express an opinion and you kind of contradict her, or maybe talk over her, that can really hurt her confidence. So, just awareness and being a little bit more sensitive can go a long way.
Kovid Batra: Yeah, I think so. That could be the first step, right?
Perfect. Anything else that you have felt in your journey as a woman was different and could have been done differently?
Limor Bergman: I mean, I wish I had met more mentors in my career. You know, when I started, I felt, as I said, I mean, I was always pushing myself forward, but I felt a lot of times confidence issues and whether I’m good enough. I think having more mentors could have helped me with acquiring knowledge, with learning better and faster, with feeling worthy, and probably advancing my career even faster than I did.
Kovid Batra: Do you think does the same problem exist right now for the women of this gen? Like, right now?
Limor Bergman: Yes. But luckily I think that they are, because, you know, it’s a complete different generation. There are a lot of online communities for women.
Kovid Batra: And there are influencers like you who are now helping people.
Limor Bergman: There are influencers like me, that’s true. There are communities. I think that mentorship, sponsorship, you know, all of those things that I didn’t even know existed when I started are kind of the norm. I mean, and I volunteer, by the way, I volunteer in organizations in women-related mentoring organizations. So, yes, there is still a need, but I think that there is more awareness both from the women’s side and also, you know, there are different communities and organizations that support women, both paid and unpaid, by the way, which makes a huge difference.
Kovid Batra: Absolutely. Absolutely. It is critical, it is very important to have a mentor, be it a male or a female. But, how did you find it difficult for a female to find a mentor at that time? Like, again, is this just because of the gender difference or is it in general, like, women don’t have the tendency to go up to a male mentor and talk to them? What exactly is that?
Limor Bergman: I think that, back then I didn’t even think about that in, I didn’t even think that I may need one that even the word ‘mentor’ was not something top of mind for me. So, I didn’t even think. I was occasionally asking, you know, people for help, right? For, “Oh, can you look at something?” Or, “Can you help me?” But, I always felt uncomfortable. I think, I don’t know if this is a generic women thing, but I personally have a tendency that I’m always happy to help others. I feel less comfortable asking for help. And, I think that’s like the main, maybe barrier that if women feel uncomfortable asking for help, eventually that hurts them.
I was afraid of asking, afraid or uncomfortable, and also was worried whether asking for help is going to be seen as a sign of weakness, maybe I’m not as good, you know, because I don’t know something. Is it okay to tell my men counterparts that I don’t know something? That I haven’t heard of a term? Like, if I’m new, and I was new in many teams in technologies that I didn’t know, and like, is it okay to say I have no idea what you’re talking about? You need a certain strength and confidence to be able to say that.
Kovid Batra: Makes sense. Makes sense. But I think that, that problem of insecurity even lies with the men, I think..
Limor Bergman: Absolutely.
Kovid Batra: Even more there sometimes because of the “alpha” ego and that we carry. So yeah, I totally relate to that. But yes, acknowledging it and overcoming it, and then probably finding a mentor is the right way ahead.
You just mentioned like, people have to be more sensitive when there is a woman in the team and try to be adjusting and offering help. One more thing I realized right now, like it’s a biologically also, it’s a very different journey, right? Like, we can’t give birth to babies, right? Unfortunately. But, that is a time when I know a woman has to choose between work and personal life, right? And I’m sure you have had that point of time in your journey also. How did you go through it? What’s your piece of advice as a mother and a woman leader to the aspiring woman leaders?
Limor Bergman: Wow! That’s an incredible question. So first of all, I am a mother of four children. And, my oldest is 19, and I have a 16-year-old, and my youngest are twins, they’re 13. And, I worked throughout my career. So, it is possible. I worked and I advanced my career. Children are not a barrier. It depends what you prefer and what, you know, it’s very personal. I would say that it was not easy for me, and as you said, like, choosing. It shouldn’t be that way. I shouldn’t need to choose between career and family. Because men don’t have to, right? I mean, there’s a mother and there’s a father. Why should there be a difference? I know, yes, we give birth. Yes, we stay with the babies a little bit. But, why should there be a difference? And, there were times in my life, actually, there was a time before I was planning my second child that I was very unhappy at my work and I was debating with myself and with my husband. What should I do? Whether should I leave and find another job and start someplace else? Or should I stay and expand the family? My husband was very supportive, and he told me that’s my choice to make. But, why would I need to make that choice? If I was a man, that wasn’t the question. The men would leave and find another job and extend the family. But a woman, like if I’m planning to expand, I felt uncomfortable even interviewing for a company, knowing that I may be pregnant or may be pregnant soon. And, why should it be that way? It shouldn’t. And I do see a change. The good thing, I do see a change, but not frequent enough and not enough that employers sometimes, you know, even higher women knowing that they are pregnant, talk more freely about it and say, that’s not a problem. Join here, start and then go take care of your baby and come back. So I do see some employers do that, but I, I guess what I would like to say is don’t look at it as a barrier for employer sides, for manager side, and try to be more open-minded. It’s not like a problem. It’s natural cycle of our lives, right? I mean, expanding the families and women, we are very capable. We are capable of doing so many things, taking care of our kids and our careers, and doing everything. And, we do it very well and we know how to manage our time and be very, very effective. So, trust us that we know what we’re doing and don’t treat us as like, Oh, you know, “She’s having a baby, so she cannot do that.”
Kovid Batra: Yeah. I totally feel that. I respect my parents, but I have a little more respect for my mother, because I genuinely feel the kind of like, a, it’s a naturally built thing and it is hard physically and mentally and you still fight through it. So, you are better warriors, maybe you are the gladiators. The hard reality in the industry is people seek profits and when it comes to work, people forget, like we need to be sensitive towards such things. But I hope, I wish, with this messaging, with these kind of thoughts, we are able to change a few more lives.
Limor Bergman: Absolutely.
Kovid Batra: All right. That was really intense and interesting. Let’s move on to something that I think the audience would also love to know. Like, coming to the core work thing, like how do you deal with situation of fast-changing technology in your engineering teams? So basically, what kind of challenges you face? How do you deal with those challenges? Can you just give us a few examples?
Limor Bergman: Absolutely. So, as I said, right, I started with the story that I started with COBOL and I moved to Java. I didn’t know anything about Java, nothing. And, it wasn’t like today that you have so many online trainings and courses and so easy to learn something new. And, I just had to learn it basically by myself. There are some books. Yes. But I had to learn for myself and ask a lot of help, right? I mean, be willing to ask for help. I was joining a team of super-smart people, very talented and much more experienced than I am. So, don’t be afraid to ask for help, I guess. And, be always willing to learn. And then I, I moved from, as I said, I started with Java Applets, and then moved to backend to Java enterprise edition. It was back then in infancy was the hot new thing. So, don’t be afraid. Don’t be afraid to learn. We are constant learners. Technology changes so fast. And, if you are not willing to adopt and to learn, you will stay behind. You will stay behind, I’ll tell you that. You know, I took a challenge, you know, when I moved to Sun Microsystems, not at the beginning, but, but after about a year, I joined a team that did real-time Java. So, I actually had to dig into the virtual machine itself, and handle with real-time threads.
So like, I’m not saying I’m the bravest and smartest. But, I wasn’t afraid of trying, of getting into very, very uncomfortable situations. So, just keep on evolving and learning. I mean, never be afraid of a challenge. Be willing to learn and grow, stay up to date, and don’t be afraid to ask for help.
Kovid Batra: Perfect. Now, let’s say, as an engineering leader or an engineering manager, you’re working on a project and you feel that this new technology would be more supportive to the requirements of the business, and you have to take this hard ball of maybe branching out and working on this piece. Before you do that, this can go both ways. Like, it can become a problem in the fast-paced growth of a company, right? You’re adopting a new technology, then you have to skill up and do things. When you take this call, what all considerations come into your mind? How do you lay out that structure that, okay, now we have made a conscious choice, made a conscious decision that this is the right thing or the right technology to go forward with? How do you do that?
Limor Bergman: I think you start with the first, what you’re trying to build. You know, what do you need, what technology to use I think you need to assess, you know, what is out there, maybe what other companies are doing, what is industry standard, you know, be always, you know, on top of what’s going on of the trends and choose a technology that can provide you with solutions to the problems you need in the best and fastest way. And, a lot of times engineers are married to something, right? Because they, that’s what they know. So, there are, you know, I had like, engineers that wanted to use a certain database just because that’s what they know. Is this the right choice? Maybe not always. So, ask yourself, I’m just taking a database as an example, am I choosing it just because I know it? Or I have some, some favoritism for this? Or is it really the right choice for what I need? So, make a list, those are the requirements. And, consider several options. It’s always good to consider multiple options before making a decision, not just one. Try to remove the bias. Make it more data-driven rather than opinion-driven.
Kovid Batra: Yeah. I think getting rid of that bias automatically opens your mind. And, then get down to the point where you, you know that, okay, this is beneficial for the business, this is what we need in the next six months as a product. So, then you start thinking that way. Otherwise, I think it’s, if you go by the gut, if you go by the instinct, then of course you would do something that you already know. So yeah, it’s very important to get rid of that bias and then take a decision.
Perfect. Next thing that I would like to ask you for anyone, how should one progress in the career in tech? Like, how one can make the best choices for them? And especially, I would love to hear a perspective again on the women in the tech industry, like how should one progress in the career and what, how should they make the best choices for them?
Limor Bergman: I mean, that’s a hard question to answer because it’s very generic, because I would say, at first you need to be deliberate about what you want in your career, and what interests you, what you’re passionate about, how do you see yourself in a few years. I didn’t always know that. I remember when I was promoted to a staff engineer at Sun, that was when the career kind of progression was split between management and IC track. And, you know, I was on the IC track. My manager decided that, you know, that’s the right next step for me. But, I actually started doubting whether that’s what I wanted. Do I want to become a specialist? Do I want to continue being a software developer for the entire career? And I realized that no, I didn’t, and I wanted to, to become a manager. It took me several years to do that, just because I wasn’t really thinking about that strategically. So, be strategic and then find opportunities to build the skills that you need in order to move forward towards the direction you want. Whether it’s learning new technologies like I had. I had a client who wanted to move to machine learning and artificial intelligence. So, they knew what they wanted. So now, it’s about, okay, how do I learn? How do I find opportunities to meet people? And with that knowledge, build a network, contribute to open source, whatever. I mean, just you have to be deliberate about what you want and start building a plan towards that.
Kovid Batra: Makes sense. Makes sense. So, having a clarity on what we exactly need, and what, where we want to be based on that, the choices should be made. Yeah, that makes sense.
Perfect. This is my last question to you. Now you have been coaching and mentoring multiple engineering teams and engineering leaders. How do you define the success of an engineering team, and how do you measure it? How do you make sure that while you’re thriving for success, You’re taking care of the developer well-being also, you’re taking care of their experience, so that at the end of the day, your team is happy and motivated to do whatever you want to do as a team?
Limor Bergman: Yeah. So, there are multiple things, right? It’s about culture, motivation, and all those soft things. And there are productivity, you know, effectiveness and those things that, that you want to measure. I think, about soft areas, the motivation, it’s about connecting with people. It’s about caring for them. It’s about knowing how to ask the right questions constantly being interested in them and their career aspirations, what interests them, what they want to do, what they like doing, what they’re good at and helping them thrive, and building those connections.
About the team, whether they’re productive or not, there are different areas to look at that. So, you can look at quality, you can look at reliability, you know, there are different aspects, development speed, how predictable you are as a team. And, the best way to know that is to measure and look at data. So like, bare minimum, like when you run a team, use a tool, could be JIRA, whatever, I mean. And, start estimating your work, story points, whatever you want, doesn’t matter, you know, whatever works. But, start, you know, estimating, and then compare how much time it actually took to you to deliver versus, you know what you thought. Do retros and, and constantly improve, because you want to see how good you are with estimating, how predictable you are as a team.
I also, you know always looked at what was not planned. What kind of work did we do? And, I was forcing engineers to put in JIRA, I kid you not. Tags of this was not like, I don’t remember the tag you use, but like, this is something new that came up because it was important. And I explained to them, always explain the why. I explained, “That’s not because I want to spy on you, but it’s because I want us as a team to understand what are the things we haven’t expected and how much buffer do we need to take to those unexpected things that will come up.” Right? Eventually, we cannot avoid all of them. Maybe some of them we can.
And then, you have to measure things like mean time to deliver, mean time to recover, all those, you know, measurements that you can do with different tools to know how effective you are as a team, how fast can you develop a new feature, how fast can you find a bug, how fast can you recover from an incident. So, you have to measure all those things, and constantly thrive to be better.
Kovid Batra: Makes sense. Makes sense. This really helps. And with that, I think, we have come to the end of our show today. I would have loved to talk more on a few topics that I’m really interested in, but in the interest of time, like we’ll have to close here.
Any parting advice for our audience?
Limor Bergman: I mean, parting advice I would say based on all I said here, just continuous learning and growing, it’s a journey. And then, don’t be afraid. Don’t be afraid to fail. Take challenges and ask for help. It’s part of growth.
Kovid Batra: Perfect. Thank you so much, Limor. It was really a pleasant experience having you here.
Limor Bergman: Thank you so much. Kovid. It’s been a pleasure.
In the recent episode of ‘Beyond the Code’, Host Kovid Batra, welcomes Peter Kristianto Widjaja, Co-Founder, and CTO at Hubble.Build, Singapore. The focus of their discussion revolves around ‘Leading Tech Teams from 0 to 1’.
The podcast starts with a fireside chat with Peter, providing us a glimpse into his personal background. Moving to the core discussion, he offers an overview of Hubble.Build and shares the challenges he faced in his engineering journey. The conversation then takes a deeper dive where he discusses the importance of ‘Purpose-driven values’. Further, Peter sheds light on 360 evaluations and the importance of psychological safety within teams for measuring their well-being.
Peter concludes by offering parting advice to the audience.
Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. I’m back with another episode and a new amazing guest who’s an entrepreneurial soul from Singapore. He’s the CTO and Co-founder of Hubble.Build. And also, he is one of the youngest leaders so far on the podcast. Great to have you here, Peter.
Peter Kristianto Widjaja: Hi. Hi, Kovid. Hi, everyone.
Kovid Batra: All right, Peter. Thank you for coming on the show. And, as a usual format, we have this quick fireside chat with every guest of ours. And here, we would be knowing a little more about you personally. All right?
Peter Kristianto Widjaja: Sure. Let’s go. Let’s do it.
Kovid Batra: Perfect. Perfect. So, let’s get started. All right. So, tell us about your first production blunder.
Peter Kristianto Widjaja: Oh, hmm, okay. Well, production blunder…I guess it’s when the company was still small, right? So, it’s about 2017, 2018. We were running a very small engineering team, about three people. Everybody doesn’t know what’s a good engineering practices and we really prioritize speed over other things, you know? And, some of the points, you know, there’s some bugs on productions that happened. And as a CTO, obviously I have production access, I’ve root access last time to everything, and we tried to make a very quick fix for our customer because it was a business critical issues and it made things worse. Classic, right? And yeah, the customers scold us for a good few hours, the CEO has to hear all the customers making noise to us. And yeah, yeah, that’s pretty much, you know, and then we learn our lessons and then we know, “Okay, no more”! Right?
Kovid Batra: How many calls did you get from the customers that day?
Peter Kristianto Widjaja: How many what? Oh, oh, dude, don’t, I mean. I guess it’s just… okay, the good thing, it was, we’re still small, so it was just one customer, but it affects a lot of users within that customer. But, yeah, we have to say sorry for about 2,000 times that day, I guess.
Kovid Batra: That’s the best thing you could have done.
Peter Kristianto Widjaja: Yeah, I mean, but we managed to, I mean, we have backup. Luckily, we have backup, so we managed to sort of roll back things. But it took a while because everybody was not seasoned, yet at that point, yeah.
Kovid Batra: Sure, sure. I mean, I see that there’s a lot of energy, you’re young, but still, there must be some daily kick for you, daily source of energy that gets you through work I would love to know about that.
Peter Kristianto Widjaja: I mean, obviously the first thing in the morning is a cup of coffee. So, you get your caffeine kicks. That’s the first thing, the most important thing for all engineers. Well, I’ve been doing this with this company for about, six, seven years, right? Since it started. Obviously, you know, it takes a lot of things to keep it going. And, you know, sometimes you have just no motivations to wake up and like, you know, the same things that you were building a few years back, it was still at a stage, you still need to do something. But for me, it’s the people, right? So, we have grown so much that now I have a lot of people in the company, and you know we are doing great things. Everybody’s so talented in the team that it just makes you feel like, you know, it’s fun, right? Because everybody just heads down, talk about ideas and implementing it. Obviously, there’s the not so fun part about, like deadlines and all those things, but yeah, I mean it comes together, but it’s fun.
Kovid Batra: So, it’s people for you then.
Peter Kristianto Widjaja: Yeah, it’s people.
Kovid Batra: Perfect, perfect. All right. One last thing. What’s your favorite go-to video game?
Peter Kristianto Widjaja: Well, I’m an old-school guy. So, I still play Dota pretty often, and not that often, but it’s too often for my wife’s liking.
Kovid Batra: Got it.
Peter Kristianto Widjaja: I should… You know, yeah, well, yeah.
Kovid Batra: Well, great then! Great. Perfect. So Peter, this was great knowing you. These were some fun things that we got to know now. Now, moving on to some important substance. We know what Hubble.Build does, but for our audience’s sake, first of all, I would love for you to tell them what Hubble.Build does.
Peter Kristianto Widjaja: Cool! So, Hubble.Build- we are a construction tech startup. We are based in Singapore. We are mainly providing a lot of solutions, B2B SaaS, especially for the different construction companies, here in Singapore and Southeast Asia. We’re looking into essentially digitizing, automating, and obviously at the end of the day, doing more of insights, for our customers. Yeah. So, it ranges different operation and verticals in the industries.
Kovid Batra: Thank you. Thank you, Peter, for that introduction. So, now my question is, I personally have been an entrepreneur. I have seen that journey, but unlike you, I mean, this journey of 0 to 1, my experience is a little less than you. So, I would love to hear your experience, how it has been starting from a garage, because last time when we were talking, you told about this. It was just three members and now scaling it up, having around 40 dev members. So, this is definitely a journey and it’s almost been a decade for you into this, right?
Peter Kristianto Widjaja: Yeah. Yeah.
Kovid Batra: So, how has it been? Let’s start with some of your best experiences of this journey. The most challenging experiences of this journey.
Peter Kristianto Widjaja: I mean, you know, as a Co-founder/CTO, starting with three people and now you’re leading about 40, the whole company is about 70, 80 people. It’s about that transitions of like, you gotta, I would say adapt, and your role keep changing as the team grows. You know, when, when we started with three people, essentially I’m an engineer, I have to code, right? Everybody, like me and my, one of the other engineers, we have to code and I have to go deep into the backend, the frontend, everything. Every day is about code, code, just keep developing and launching new products. When in which 10, it’s about being a team lead and a manager, right? So now, you have these 10 people and you gotta make sure they are happy and everybody is aligned with what they are doing. Now, you grow into 40, it’s a different ball game by itself. And, each transitional period needs a lot of self-reflections, and also just humility just to know that, “Okay, I’m not good at this. I gotta improve on this.” But, if you are the person that, say, likes coding, right? At, you know, 40, you’re not gonna code most of the time, right? So, you gotta be like, okay, you know, you pick your poison. Obviously, you still can code outside of your most responsibilities, but you have to understand that your main responsibility is not to code anymore, it’s to inspire and direct the vision of the team. So, I guess, I guess that is the most challenging part Yeah.
Kovid Batra: Doing that transition from being an engineer to a leader is definitely a transition.
Peter Kristianto Widjaja: It’s crazy.
Kovid Batra: And, I think it doesn’t come easy, particularly with the engineers, right? They have this habit of just coding, being with their laptops and desktops. So yeah, it definitely is. So, let’s talk more about some of those incidents where you actually had to change your daily habits or behaviors while you were working as an engineer to a leader today. Let’s talk about those, some of those challenges.
Peter Kristianto Widjaja: Yeah, yeah, again, I guess the journey from 0 to 1’s and obviously 1 to 10’s is going to be very different between, you know, one community to another. For me, um, it’s when I think we reach, let me count, 1, 2, 3, 4, 5, 6, about 6 people in the engineering team. That’s when, you know, I’m still heavily coding and then what I realize is that people are just doing their own things, right? And, there’s a lot of miscoordinations with regards to what we are building, how we are building it, and somebody got to take charge, right? Somebody has to make sure that, you know, we do have product managers at that scale. So, somebody has to lead the product, talk to the CEO, most likely the CEO leads the product, right? But, you know, but the CEO also has to do sales and all the other functions. So, somebody got to step up and make sure that there’s a lot of coordinations and we are building the right things at a point in time, you know. I guess that’s sort of the trigger and like, “Okay, I can just keep coding. I got to, like you know, do something else, and should I hire someone to make sure that I don’t need to put that much anymore?” That question start to come to mind. And, you will realize that because you feel unproductive at the start, that’s what I felt, when you know, you’re not really code anymore, you don’t write anything, you’re not developing anything, but you’re just talking to people, writing some documentations, you know, setting up infrastructures, talking to AWS guys, you know, all these different people.
Kovid Batra: Right. Right.
Peter Kristianto Widjaja: And you feel like, “Hey, I’m not producing anything.” But, you realize then, your team actually is moving faster, because you’re building the right things, everybody’s on the same page, everybody’s happier in general. And that’s, I guess, I guess that’s a trigger for me. And they’re like, “Okay, I guess that’s how my role has changed.” Yeah.
Kovid Batra: No, it makes sense. Actually, there is a point when you start leading teams, the motivation for you is to make them work without any friction. You start working as the oil for the team. So, your efforts start becoming the oil for the team and that’s what your daily motivation should be. So that’s cool. I think I can totally relate to it.
Peter Kristianto Widjaja: Yeah. Yeah.
Kovid Batra: Perfect. Perfect. All right. Apart from this, for Hubble, I’m sure that this journey of 0 to 1 involves this very important step, which we call as ‘product-market fit’, right?
Peter Kristianto Widjaja: Hmm.
Kovid Batra: So, back in that, like 10 years back actually, when you started this, what was the landscape like? Why did this idea come up and how did you figure that out that, “Okay, this is something that the market needs and this is what we need to build.” And, how as a technical Co-founder, you contributed there, because that’s a very important piece. A lot of engineers, a lot of technical Co-founders skip on this step of realizing that how they can drive the business impact. So I would love to hear that from you, how you did that in that 0-to-1 journey.
Peter Kristianto Widjaja: Yeah, Well, it’s gonna be quite a long story, but you know, I’m trying to…
Kovid Batra: No worries, we have time!
Peter Kristianto Widjaja: Yeah, I tried to make it, you know shorter for this. So, we started out actually just building different projects. The company was not building what we are building today. So, we are more of like an agency at the start, you know? So we’re building different things, right? And, one of it was for constructions, and that time was more for manpower tracking. We got this from a construction company, obviously. And that’s when, you know, as we’re building it, we’re realizing that, “Hey, the solutions in the market are not that great.” Right? There’s opportunities… I thought, you know, it was kind of, when I look at a product, I was like, “Hey, I think the market should have this kind of solutions already.” Right? It’s just natural. But again, construction is very backwards. Even until now, it’s sort of at the same level with agricultures, and like mining industries, and all those industries. So the adoption of new technologies is taking a while. So, it started with a real problem. So, we’re not inventing a problem, it’s actually a problem in the industries, and I was just making sure that the product actually solve that problems we are highlighting the values. And with that, we start entering the industry, we talk to more people and realize the bigger issues of things, like really there’s nothing that is automated, there’s nothing that is digitized, everything pen and paper. And, we can’t really do anything because there’s no data for us to do anything right? So, the first step is to collect those, create infrastructures for people to at least have a digital space and database of things. And then, we can start doing more things and enhancements on top of it, like analytics and all those productivity stuff. Yeah.
So, that’s sort of how it grows. So, it’s pretty organic at the start. Again, we didn’t take venture fundings or like institutional capital funding at the start, until about 2020, that’s when we get our Series A. Before that, we’re just really reinvesting on our profits, so, we really grow organically by talking to the users. And, what we realized is that everybody got to talk to the users at the start, right? And, this is what I preach, or not I preach. This is what I sort of try to envisage in the company as well. As an engineer, you got to know what you’re building, right?
Kovid Batra: Yeah.
Peter Kristianto Widjaja: And it, it, it’s not, you know, we, when we hired engineers we take time to sort of make them realize that it’s not just about doing the tickets that the product managers create for you, right? A lot of people, when they come in, they will just like, “Okay, I have this ticket. Let me just do it. I read it. I’m done. Push it. Somebody reviews, merge and stuff.” But, it goes beyond that because you need to know a few things, right? You need to know who you’re building it for, who’s going to use the product. And, what is it for? And, why they need it? Because the way you build it is going to be different, right? And, my point is that, yeah, you can have your product managers, product designers, and you know, they all work so hard to figure out the user experience and all these things. But, as the engineers, you need to really understand what you are building as well by talking to the PMs and the UI/UX about what they have been writing and designing. And then you build it in a code, right? In our company we call it the ‘purpose-driven values’. It’s one of our core values that we always talk about. So, essentially what I did now is, I just do some random conversations with my engineers and I’m sort of, I ask them like, “Hey, what’s up?” “How are you doing?” “Okay, what are you working on today?” And then they will, like start explaining what they’re working on and I’m like, “Oh, why are we building that?” And, if they can’t answer, I’m like, “Okay, you go and ask your manager and you get back to me.” So, there’s a bit of, you know, just random checks here and there. The one answer that I hate, that I always tell them I hate is that when they say, “Oh, because whoever says I need to build this.” Or, “PM wants me to do.” I’m like, “Dude, okay, figure it out.” Right?
Kovid Batra: Yeah.
Peter Kristianto Widjaja: Yeah.
Kovid Batra: No, I think this is really amazing. And, with all the previous conversations that we have had on this podcast, this has been highlighted multiple times. This purpose-driven building from the engineering teams has to be, like ingrained. That doesn’t come naturally in the dev team.
Peter Kristianto Widjaja: It’s not, yeah.
Kovid Batra: So, it’s a very good point that you understood and realized it as a Co-founder in the early stage and then you could actually, okay, preach actually in the teams and then make sure…
Peter Kristianto Widjaja: Yeah.
Kovid Batra: It’s, it’s kind of that only, and it’s really cool. I think this is one amazing thing which every tech Co-founder should keep in mind, and should make sure how things are proceeding ahead. Amazing. Amazing, Peter.
All right. And now, there is something which I would love to know from the current scenario. So, now you’re 40-devs teams, right?
Peter Kristianto Widjaja: About that, yeah.
Kovid Batra: One thing you already mentioned that you are trying to bring in that value of purpose-driven development, right?
Peter Kristianto Widjaja: Yeah.
Kovid Batra: But, there are more aspects when you have to handle a 40-member dev team, right?
Peter Kristianto Widjaja: Definitely.
Kovid Batra: You have to take care of their experience, you have to take care of their well-being, you have to take care of whether they are being efficient or not, because on day-to-day, even if you align them with the business goals, you give them those values. Still, you just need to like make sure how things are moving.
Peter Kristianto Widjaja: Yeah.
Kovid Batra: Are we really moving on the right track or not? Because sometimes you tend to deflect, right?
Peter Kristianto Widjaja: Yep.
Kovid Batra: So, in simple words, how do you measure the overall well-being of your teams? That’s my question 1. And then, how do you ensure that they are being efficient at the same time? So, that’s a thing that we would really need to know.
Peter Kristianto Widjaja: Yeah. Yeah. I would say that’s a million-dollar question, right? You know, I mean there’s a lot of literature on that. I mean, the infamous literature from McKinsey, you know about it. It’s tough, right? Because we’re trying to measure something that is intrinsically hard to measure into something that is chewable as a management to just see. But in, in Hubble, essentially we are looking at a few things. So, one is obviously the team structure itself, you know, how we put the different middle managers and make sure that they’re not overwhelmed with, like 30 people, for example, like one person leading 30 people. So, we always keep it about 8, a maximum. Yeah, it’s about 8. Max is 8. Some people are definitely less than that. And, make sure that everybody knows that you can talk to this guy about anything. So, that’s the first one. Second, well-being… So, we have two approaches here, right? So, one is what we call the metrics and KPIs. And, second is the qualitative, right? So for qualitative, we do this thing called the 360 evaluations. And, this is obviously something that we built with HR in terms of like, “Okay, we need to have these routine checks, 360 evaluations of all the people.” So this is actually the only time for individual kind of measurements. And, when we talk about KPIs later, everything is at squad and team levels, there’s no individual metrics. Right? So, the only individual evaluations that we get is from the 360 evaluations. And, this is where people will, okay, how can everyone improve, right? So, the idea is not to rat people out that they’re not doing their job, but it’s more of like how each one can improve, what they feel they’re doing well, what they feel they need to improve, and what they feel they need to be stopped doing. Right? And it includes me.
Kovid Batra: Can I ask you a question here?
Peter Kristianto Widjaja: Go ahead.
Kovid Batra: Sorry. It’s just that I’m too curious to know a lot of things. When you say that you’re doing this 360 at the individual-level, do these people know that when this feedback is collected, their names would be there along with that? So, let’s say, I’m one of the developers in the team.
Peter Kristianto Widjaja: Yup.
Kovid Batra: I give you my feedback around all the questions or survey questions that you ask. So, do I know that my manager would know that this is a feedback from Kovid?
Peter Kristianto Widjaja: Ah, no.
Kovid Batra: Perfect.
Peter Kristianto Widjaja: Okay. So, the way, the way it goes is this. So there is the, what we call the manager feedback. So, the manager gives feedback to the team, the individual people in the team. That is obviously transparent because the manager has to say to the team.
Kovid Batra: Ya, of course.
Peter Kristianto Widjaja: And then, there is the peer review, which is between the team members. And then, there’s the upwards review, which is team members evaluate the managers.
So, for peer review and upwards review, it’s all anonymous. The only one that knows is the HR, and then basically, HR will come up with this report, which is just the evaluations and the summary of all the different scoring and the qualitative feedback, but the names are not all there. Yeah.
Kovid Batra: Got it.
Peter Kristianto Widjaja: So, the idea is that, again, we want a very candid, very open.
Kovid Batra: Exactly, that’s what the point is that if they know that this is going to be, uh, non-anonymous, then they would hide away the real facts, they would not come up with things. So, that’s what my concern is.
Peter Kristianto Widjaja: The thing is this though, sometimes with the qualitative feedback, because you’re so close to your team, you know how they write.
Kovid Batra: Ya! That’s definitely there.
Peter Kristianto Widjaja: So, I mean, I was, I was reading my own feedback because I get my managers to feedback to me and I’m like, “Oh yeah, this is from this guy.” Like, I can really figure it out from the way he write, but again, like we established such a relationship that is okay.
Kovid Batra: Exactly!
Peter Kristianto Widjaja: Like, that culture has to be open enough that I tell my team, even like anyone can say, “Hey, you have feedback from me. Just drop me a message.” I’m okay. Obviously I can say that, but it’s still, you know, there’s so many of them, but…
Kovid Batra: Yeah, I totally second that.
Peter Kristianto Widjaja: With your direct reports, you’ve got to have that kind of relationship, because if not, there’ll be politics involved, and you know, people are not saying things that they really feel. It’s gonna trickle something. Oh wait, it’s sort of deviate from the question, but yeah.
Kovid Batra: No, I think this is very important. This detail is actually important that even if you put in systems and processes in place to measure the developer’s experience or measure their well-being, it is important to understand that the underlying psychological safety in the teams is very, very important.
Peter Kristianto Widjaja: Yeah.
Kovid Batra: Otherwise, the truth will not come up and you will not be able to identify the problem.
Peter Kristianto Widjaja: Definitely.
Kovid Batra: So, I think this is a very important point. You have to, like promote it as a founder, as a promoter of the company, you have to promote this culture also within the team, so, that totally makes sense.
Peter Kristianto Widjaja: Yeah.
Kovid Batra: Cool!
Peter Kristianto Widjaja: I mean, we have like, so I enforce the managers to have to go, have this thing the 1-on-1s with the team members, and there’s also skip levels whereby I can skip level to the seniors or, you know, there’s the different structures of skip levels. And, the thing that I enforce is that the skip levels, you are not ratting people out because, you know, when you do a skip level, somebody want to feedback about the managers, right? To you.
Kovid Batra: Right.
Peter Kristianto Widjaja: Now, you cannot say that to your managers and, “Hey, this guy says this about you.” And, you’re like, “Yeah!” That’s very confidential between, you know, the two people.
Kovid Batra: It has to be.
Peter Kristianto Widjaja: Even 1-on-1s. So, anything within the 1-on-1 stage, within 1-on-1s between you and your manager, it doesn’t go out to everyone else.
Kovid Batra: That’s cool.
Peter Kristianto Widjaja: Yeah. Well, so that’s the qualitative part, and from there, actually it’s more of the, again, the experience. Is people happy? Anything wrong with the pay or with the career progressions, with the challenges? That should be, you know, we can spot it up through the 360 evaluations and also the 1-on-1s. With regards to performance though, this is the very tricky part because people like to know, like which engineer performs better than which engineers, and then there’s like, oh, line of code written. No, not exactly! You know? And the key thing is this, when we sort of build this, we need to understand the engineering culture itself. And, with software engineering, right, it’s a very interdependent team whereby you cannot just do things alone, especially at our scale, because, okay, when you build this, it might impact another team, it might impact the frontend, the mobile end, you have to constantly talk to different people, right?
Kovid Batra: Sure.
Peter Kristianto Widjaja: And, it’s a very highly collaborative environment. If you start doing individualized metrics tracking, for example, story points completed by a person, I can get that metrics, right? I know exactly how to get that metrics. But if you start putting that as the North Star, people will not help each other. And actually, that will become worse for your company or for the team. So instead, what we are looking is actually the full team, the whole team philosophies, right? So, I’m not going to trickle down to individual guys, I’m just looking at the whole team. So, within each of y’all, doesn’t matter. So, y’all figure it out collaboratively, who is doing what, who is better at doing what. And basically, the numbers I’m looking at is the squad’s philosophy, and this is owned by the EMs, right? The engineering managers, for this particular squad, right? So that’s one, you know, we’re looking at.. Again, I’m not, then I’m not comparing between squad one, squad two, squad three, how come velocity’s slower? What I’m looking at is your progress, your trends. If suddenly there’s a dip, you’re slowing down, I want to figure out why. And the idea is not to penalize you, but let’s figure out what we can improve on. And obviously, because there’s a lot of things, like the kind of problem statements that each teams are handling is very different, the number of members are different, so you can’t really put a benchmark, “Oh, everybody got to achieve like 40 story points.” Like, it’s, it’s very, it’s, it’s nonsense. Now, what we’re looking at as well is, because one of the values again is accountability. We are looking at the number of stories promised, or like putting into the sprint versus completed, because what we want is, “Okay, we are evaluating on overestimations or underestimations.” You know? And, making sure that when the PMs, say, or engineers are not doing their work, you have a data, all right? And, how to improve on that. We are as well looking at things like ‘backs per stories’. So, backs per stories is very interesting. It’s something that we just really built the infrastructures. It’s more of like, because we want to increase velocities, but we don’t want that to hamper the quality, right? And with backs per story, it’s very interesting because you know if people are rushed. So, that’s what we are looking at. So, if you are rushed, you tend to just quickly get it out of the way, hack things out, but you have like 2,000 backs, right?
Kovid Batra: Yeah, correct. Quality gets compromised there.
Peter Kristianto Widjaja: So, Yeah. So again, and it’s for the managers to say, “Okay, I’m rushing too much.” Right? So, let’s work with the PMs or with whoever stakeholder’s involved to like, “Hey, my team needs a bit more time. We’re not going to hit it because everybody start doing things very fast. There’s a lot of bugs being churned out.” And, obviously there’s a lot of miscellaneous things like, you know, code churn rate, at the macro level. We have code review durations, which is sort of like, we don’t, like, a lot of the blockers was like, “Oh, somebody’s not reviewing the code.” You know? And stuff. And then we, “Okay, tell you what, let’s have measurement on this and how to improve the process for code reviews.” Something that is very interesting whhich is developed by my previous VP of engineering was the ‘commit push time’.
Kovid Batra: Okay.
Peter Kristianto Widjaja: So, at which time of the day the commit is being pushed. So, what we’re trying to look here, and as well as the line of code changes distributions. No, so, basically what happened with these two metrics, is that it requires a lot of context of what’s happening with the team. So, you cannot just put a blanket context, and then just, oh, if you are like, who is, like the most, the highest contributors with the lines of code? It’s not like that. So, the idea is that what we want to look at is technically just distribution of work, right? If you see that the line of change distributions is heavily skewed towards a single person, first and foremost, that person is a ‘bus factor’.
Kovid Batra: Yeah.
Peter Kristianto Widjaja: Right? And, are you relying too much on this person because maybe this person is so good, and you just dump every single thing on him? And it’s not distributing to other people. That’s one. Commit push time is the same thing. If you look at your engineering team and some people just keep pushing at 2 a.m., 3 a.m.. Are you being sustainable to that guy, you know? Are you pushing that guy too hard? What’s going on? Right? So, but again, some people like to work at that hours, you know? We can’t say, “Hey, you cannot push at 2 a.m.” That’s not gonna work. But it’s more, again, that’s why it requires context, because the managers will look at this and figure out, “Oh, wait, this guy, why is this guy constantly pushing at like 2-3 a.m.?” Then, he can engage, or that person can, the managers can engage, like, “Hey, are you okay?” “Why are you doing that?” “Is it your style?” You know? It’s more of that.
Kovid Batra: I think that’s, that’s pretty amazing actually, how with these metrics where you are trying to understand the efficiency of your team. At the same time, you are being very considerate about that they are not overworked, or they’re not, like doing things like that. So, that’s pretty amazing. And that’s a new way to look at some metrics.
Perfect. I think, one question here I have when you talk about the distribution of the work, right? How do you ensure, like once you identify, okay, like, this person is the one who is doing the maximum amount of work in the team, and, that can be done from various ways. One of them could be like how many one is doing the lines of code and for the team, what is the ratio, right? You can understand that. But, let’s say, you identify, what usually are your next steps? Like, how do you make sure that this thing gets better?
Peter Kristianto Widjaja: Well, technically it’s this. Firstly, what we need to identify, is this even an issue, right? So, once is that, if it’s just because this guy is super fast, blazing fast, then we can’t follow, “Hey, you cannot do too much changes.” Right? Now, if it’s actually an issue, this is when the managers and me, we gotta figure it out. And, what some of the steps is that we look at when we do the sprint planning, like how is the task actually being distributed, right? So, we want to know, it’s more of like, are we, as a manager side, relying too much on this guy or not, right? And obviously, then talk to the teams and the rest of the teams, and being very proactive and very intentional when we distribute a task and make sure that he’s not, like skewed in terms of the distributions, and ask him to chill sometimes, that works too.
Second is that sometimes there are things that comes ad hoc without the manager being aware of what’s going on, and because, you know, everybody’s on Slack, some people, like some designers or even myself sometimes is a culprit of this, you know, just text one of the engineers that I know is very reliable, and like have been working with me for a while, I’m like, “Hey, I spot this. Can you help me with this?” And then, he was like, “Okay, done.” Right? Aand more of those might translate to, you know, again, we only have X amount of hours a day, if you are doing too much ad hoc works, you’re not doing the actual product strategies, and, you know, pushing product forward. So, it’s more of that. And, it’s tough, right? Cause at one point you still want to make sure that guy is producing.
Kovid Batra: Ya, of course.
Peter Kristianto Widjaja: You know? But, you have to be very intentional because you don’t want at the same time, say, for example, you have a feature, call it feature A, right? And feature A has a lot of parts. So, what you don’t end up happening is that guy in charge of, if it’s a big features, everything about that big features. So, you have to be intentional about, okay, you work for us. Okay, let’s build this one for you and then give it to someone else. The idea is that you want another engineer to have context about that as well, such that when he is, say for example, sick or he’s on holiday, you are not screwed, right?
Kovid Batra: Right. Well, I think that totally makes sense and it answers the question really well.
Great! I think this conversation can take really long and we have so many areas to touch here. But, I think we will take a stop here. And, I would really like to thank you, Peter, for sharing your insights and thoughts about how to scale from 0 to 1, and then how to manage teams at this scale. This was really amazing.
Any parting advice/words for our audience?
Peter Kristianto Widjaja: Parting advice? Take care of your engineers and they will take care of your product.
Kovid Batra: Amazing! Thank you, Peter. Thank you so much.
Peter Kristianto Widjaja: Cool! Thanks so much Kovid for the invite.
In the recent episode of ‘Beyond the Code’, Host Kovid Batra welcomes Ashik Uzzaman, Director of Engineering of Treatment Platform at Twin Health, and the creator of 'Leader's Whiteboard' - a blog and an educational YouTube channel for engineering leaders. He has previously contributed his expertise in Marqeta, Adobe, and TubeMogul.Ashik engages in a compelling discussion focused on the theme of 'Enabling ICs to move into management roles'.
The podcast starts with a fun fireside chat with Ashik, offering the audience a glimpse into his unfiltered personality. Following that, he delves into the details of understanding the 'Why' and 'When' behind the decision to shift individuals from individual contributor (IC) roles to engineering management. Ashik sheds light on how to enable the team and support their development. Further, he dives deeper into effective leadership styles and provides insights into their effective implementation. He also emphasizes the ‘Trust but verify’ approach and leveraging metrics for the success of the team.
Wrapping up, Ashik shares parting advice for the audience, emphasizing the crucial role of continuous learning and networking in professional growth.
Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. I’m back with another episode and a special guest who is a curious soul, passionate about reading and writing, has 23+ years of engineering and leadership experience, currently working as a Director of Engineering at Treatment Platform Group. On top of that, he’s author of Leadership Whiteboard, which is a YouTube channel and a blogging website that talks about engineering leadership. So, a really good source of learning for our audience there. Welcome to the show, Ashik. Happy to have you here.
Ashik Uzzaman: Thank you. Thank you. I am humbled and honored to be with you here, Kovid. Thank you.
Kovid Batra: Thank you. Thank you so much. So, Ashik, we’ll start with a quick fireside chat, wherein I’ll be asking you two to three questions which would be more around your personal life. And from there, I think our audience and I would love to know more about you.
Ashik Uzzaman: Definitely.
Kovid Batra: Are you ready?
Ashik Uzzaman: Yeah, sure.
Kovid Batra: Perfect! Alright, there you go. We’ll start with some sports, okay? So, which is your favorite indoor, outdoor sport that you really love to play?
Ashik Uzzaman: Yeah. So, my indoor sport is actually chess. And, me and my son, we have been playing competitive chess. But outdoor sport, I’m, I’m a little bit lazy person. I’m more of an audience rather than actually player. I like soccer a lot. Yeah.
Kovid Batra: So, you watch soccer a lot?
Ashik Uzzaman: Yeah. I watch soccer a lot. Yeah.
Kovid Batra: Perfect, perfect. That’s nice. Okay, moving on to the next one. What do you think, as a leader, as a manager, is the best way to learn for people? Or, if I should ask, how do you learn your leadership style? So, when you were a manager, how did you come up with those thoughts that this is how you should manage it, manage your teams?
Ashik Uzzaman: Yeah. So, definitely learning management and leadership, the first thing will come is the hands-on experience. As you work, as you get into situations, there is no alternate of getting through situations to learn, how you manage team, you may be making mistakes and so on. But, it has to be their hands-on experience, I should say is the number one thing. I think the number two thing is the actually reading. You can read a lot. There are a lot of literatures, articles or even just watching videos, like I started a channel as I was talking about where I talk about these theories. Another thing, I think along with hands-on experience and reading is actually collecting feedback from your team members.
So, these three, if you can properly utilize together, I think will be the right way to move forward to learning leadership and management.
Kovid Batra: That’s nice. So, I think it’s hands-on experience, learning, reading, and then taking feedback from your peers. I think that’s really amazing. Yeah. I hope this has really helped you in general to improve in your life. And I really appreciate this thought. Usually people are not very comfortable with the feedback kind of thing when they themselves are managers. Feedback coming in from the team, they usually don’t take it the right way. But, I think this is a good message where even if you’re a manager or a leader, taking feedback from the people whom you’re working with, your team, your devs, I think could actually make you learn things because when, when you operate, that’s what I have also felt, like we think that we are doing it right. And almost everyone does the same way, but when feedback comes in, there is a reality check for sure.
Ashik Uzzaman: Yeah. Like you don’t watch yourself very well. Other people watch you well. So, if you can know from others, then you know where to adjust your style.
Kovid Batra: Absolutely. Absolutely. Great! All right. So, what’s your mantra for success?
Ashik Uzzaman: Yeah. So, one thing I follow a lot is that I stay hungry for knowledge, and remain humble in success. So, stay hungry for knowledge and remain humble in success. I actually have been trying, and this is my mantra all throughout my life. I don’t know if you can ever perfect the art or not, but if you are not hungry, if you are not curious, you know, you will not grow. After a certain point you’ll get satisfied, you will not grow any further. So, you have to be hungry. On the other hand, once you start getting some results, if you don’t show humility, you are going to slip from there. So, you’ll be downhill also. So, that’s my mantra.
Kovid Batra: You have to feel it, you have to feel it from within actually, like gratitude, being grateful and being thankful makes you humble. I think it’s a very good point. I think Steve Jobs had already been saying this. And curiosity, I still feel that comes very naturally to people and they develop also over a period of time. Humbleness is something, I feel is not a natural trait for people. Like, we want to be alphas, like we want to be like there, right? So, I think, yes, you’re right there. It’s an art of, like learning this and ever growing, because you’re killing your primitive feelings and subconscious there, and then coming up with a new thought process. So, it’s really nice. But, I think that what really helps is, like in general, if you feel that you’re really grateful and thankful to people, family, friends, your peers around you, I think that really makes you humble. So, when you achieve something, the first thought that comes to you is that, okay, I did something there, but this would not have been possible if everyone was not involved. So, I think, great. I think I really appreciate that thought. Very well said.
Ashik Uzzaman: Yeah, thank you.
Kovid Batra: Perfect. All right. So, that was cool. It was great knowing you there. Now, I think what our audience eagerly waits for is the learning from engineering leaders like you who have seen success failures, and past so many years of hands-on experience. So, in this section, we’ll talk about more from your experiences.
I have, I am also a curious soul, so I’ll have some questions there. So can we get started there?
Ashik Uzzaman: Yeah, definitely. Please go ahead.
Kovid Batra: Okay. All right. So, this is a very common question, but I think a lot of people find it difficult to make that move in life, which is moving from an IC role or from an, like a developer role, or let’s say senior software engineering role, into engineering management. That’s the first step towards leadership.
So, when do you think people should move there, and what should be the thought process behind it?
Ashik Uzzaman: Yeah. This is a very good question actually. Like, I have moved many engineers, individual contributors to engineering management in my last few jobs as part of, I mean, a manager of manager roles. I had to go through this a lot. So, I would say the first thing that should come into anyone’s mind, like if you want to move someone from IC to manager, or someone wants to go from IC to management role is, “Why?” “What’s the motive?” “Why do you want to become a manager?” So, there are many different reasons, but financial reason should not be the reason why you should be moving into management. Some good typical reasons that can be very reasonable is if you want to desire, or amplify your impact on project or organization. If you feel very good or happy when you see someone else being successful, rather than the product being consumed by a customer, and then, If you see that you are pretty good at strategic thinking, or maybe you have a tendency to drive organizational changes. These kinds of tendencies when you see in yourself, or if I see as a manager in someone else, these are good reason why you think this person may, you want to give them a try to get into management.
On the other hand, there is a “When?” So, the ‘why’ is the first thing you have to answer. The second thing is, you have to make sure that the individual contributor whom you are thinking to move into a leadership position, management position, are they willing to actually do it? Is there mentorship opportunities? Like, if they get into this new role, they will need help. If you are the direct manager, you have to continue to coach them. Are they ready, receptive of that? Do you have the capacity or bandwidth to do it? If not, then you should wait until you have that bandwidth. Or, if you want to wait until they gain a certain technical expertise or experience, after which you want to move into management. So, you have to think there and take a balance between that ‘why’ you want to move, which is to serve others, and ‘when’ you want to move. Is that person ready to take the challenge now, these two things, right?
Kovid Batra: I think that’s very well said, and that I think clarifies a lot of people’s doubt when they are stepping into that management role, that until and unless it is coming from within as a natural motivation. Like, one of my friends who is right now a senior engineering manager, he told me that he wanted to move into this direction because he thought that he wants the visibility of the back that he’s creating, like he want to see end-to-end what’s going on. So, I think what you are saying is also in line with that. There was a natural curiosity and motivation to see that impact, create that impact, and that’s, that’s a perfect ‘why’ you should actually step into that role.
Ashik Uzzaman: In fact, there is a book by a management guru called Patrick Lencioni. The name of the book is ‘The Motive’. And through a business fable, he explained why someone should consider moving into management or leadership role. There, he shows that you can move because of reward-centric reasons, like, you know, financial benefit and so on, or responsibility-centric reason, like you want to serve, you want to make impact and so on.
Kovid Batra: Yeah. Perfect. Yeah, I think that would be a good read to really understand the depth of this belief. I think that’s cool.
Perfect. Let’s move on to the next question, Ashik. So again, as a leader, it becomes important, and even as a manager, it becomes important to enable the team. So, when you’re a leader, you have to enable probably the engineering managers. And then, if you’re a manager, you need to enable the ICs skill up, right? What do you do to actually enable these people? Like, from a different perspective, from an engineering leader perspective and from, let’s say, a manager perspective, but what all you should be doing or what all you have done in the past to enable people who are working with you?
Ashik Uzzaman: Yeah. That’s a very good question. Thank you, Kovid. So, there are a couple of ways we can think of. It is one, enabling a team. So, you are a leader, you are an engineering manager, you’re responsible for the team, how you empower the team. Another is developing a particular person within that team who reports to you. So, maybe you want to grow them as a technical leader, you want to grow them into management position. So, when it comes to enabling the team, the way I consider is that management is at three level. Either you are a line-level manager, let’s say Engineering Manager or Tech Lead or Senior Engineering Manager, or you are a mid-level management, like Director or Senior Director, you are in a manager of manager roles, or you are an Executive.
So, for frontline managers, I think what’s very important is to see the team that you are managing, what’s their maturity stage, what’s their experience, what kind of people are there, the structure or composition. You want to enable them based on their experience, as much as they can take, and because you are a frontline manager, definitely you have to be involved in the day-to-day process.
On the other hand, when you are trying to enable or empower an individual, you’ll have to figure out what their, you have to identify the potential of that person. You have to have open conversations. You have to provide mentorship to that person. You have to offer training. There are so many trainings or materials. You can do personally, as well as they can get it online from resources, and so on. You have to try out that person by rotating roles. So, let’s say there is an engineer who is writing a code, but you see, they are also very good mentor. They write well, they communicate well. Maybe you move them into a Tech Lead role where they manage the team or share the responsibility of running a project with you or with the manager 50/50, so they get a playing ground and you can test them how, where are their strengths and weaknesses.
So, this is how you have to see, and then you have to clarify, “Okay, you have been doing good in this area. There are certain other areas I want you to focus on particularly soft skills.” That’s how we’ll have to try out the, uh, an individual to grow them in leadership roles.
Kovid Batra: I think that’s actually really nice. And the last part was very good. I think the best way to test someone is, like put them on the field, be there to support them. But, I think that’s a very nice way on day-to-day in your team, if you identify those gems in your team, I should say, then yes, giving them a playground and then seeing how do they do, how we can help them improve.
Perfect, Ashik. I think that was really nice advice.
Ashik Uzzaman: Thank you.
Kovid Batra: Moving on to the next bit. I’m really impressed with the thoughts that you are sharing here. You must have seen a lot of people who were leading you in your career, right? What were those best leadership styles? What did you learn? How did you implement them? Just talk about those experiences.
Ashik Uzzaman: Yeah, yeah, This is an interesting question. The leadership style, there are a lot of debate is actually how many different type of leadership styles are there. So, the way I think of some of the possible styles before I tell which one I like is let’s say transformational leadership, servant leadership, situational leadership, democratic or participative leadership, autocratic leadership, transactional leadership, charismatic leadership, coaching leadership. So, there are different types of styles.
Kovid Batra: Oh, okay. This, this was something really new. Yeah.
Ashik Uzzaman: So, yeah, depending on like which book you pick up or which personal leadership guru you’re talking to, you’ll see these words are coming out mostly. But, one thing you will see very common for particularly two, you will see very common. One is the servant leadership and another is situational leadership. So, my favorite leadership style is servant leadership actually, so much so that some management consultants think that this is the only type of valid leadership, which is servant leadership. So, maybe that’s a little bit too much extreme, but servant leadership focuses on the person, the team, the people who we want to develop. If you follow this style, what you do is you’ll identify the right people in the team and put them in the right place. For example, maybe a person is a good engineer, but you have put them as a Product Manager. So, they are in the right team, but in the wrong role. The servant leader will figure out not only the right person for the team, but they’ll find the right seat or the role for that team.
So, my style, I believe is that. Why it goes very well with why you should be a manager or leader in the first place is to actually serve others to grow others, and servant leadership really goes very well with me.
Kovid Batra: Perfect. And what about the participant leadership? Can you just throw some light there?
Ashik Uzzaman: Yeah, so participative leadership, it’s another name is democratic leadership, where the leader actually tries to lead the team based on consensus. So, they say, “Okay, what’s the majority seeing?”, and so on, versus in a servant leadership or in a situational leadership, often the leader will actually make the choices. They will still take the input, but they are not going to run the team by consensus, not by majority. Participative or democratic leadership, leaders actually go by majority most of the time instead of they making the decision often.
Kovid Batra: Makes sense. Makes sense. But then, in, in participant leadership, I have this feeling that it becomes difficult to lead, right? Like, every time getting consensus on everything, of course, critical decisions, you will take a consensus. But, maybe it’s just me, I’m feeling that, but what’s your thought on that? Like, isn’t it?
Ashik Uzzaman: Yeah, that’s the case. So, basically what happens is that the participant leader or democratic leader is so much conscious about taking consensus from others that they will often not take the right hard decision for the team. First of all, they will slow down the team because they have to take consensus.
And then, as a leader, you know, sometimes we don’t become leader to become popular, right? We become leaders so that we can make the right impact on the team. And sometimes the right impact of the team is actually a hard thing to do. It’s an unpopular thing to do. When you run the team by consensus, you are not going to get those unpopular decisions from the team, right? So, you’ll often not be taking the right steps for the team. So, that’s why this is not one of the leadership style that goes well with me. In certain type of team, in certain type of industry, this may work out. Yeah.
Kovid Batra: Understood. Okay. So, I think it’s more like these leadership styles are in general suitable for different scenarios, different kinds of teams.
Ashik Uzzaman: Right.
Kovid Batra: Got it. Got it. Got it. I think this is an interesting topic where I think we can have a podcast dedicated to this itself.
Ashik Uzzaman: Yeah. Yeah, definitely.
Kovid Batra: It’s enlightening actually, because we got to know that, okay, these things exist. It was something that you don’t know what you don’t know, kind of a thing for me.
Perfect! Let’s move on to the last question of this discussion. So, when you’re leading teams, you have your leadership style in place, you have a clear thought process whom to enable and then how to enable, but when teams are operating at this scale, how do you make sure that overall team performance or overall team well-being is in place? How do you define that success for your engineering team?
Ashik Uzzaman: Yeah. So, this is a tricky one because it actually involves a lot of things as a leader, you’ll have to do. So, maybe I can touch base on some of the items.
Kovid Batra: Sure!
Ashik Uzzaman: Like, the first thing is that you have to set clear objectives and expectations for the team. Like, this team is part of a larger organization. The organization has a mission, vision, value, strategy or objectives. And then, there are deliverables, and usually the deliverables are divided in quarter or yearly outcome and so on. So, you have to make sure that the team members know why they are working in the team, what’s the objective and what’s the expectation out of them.
Now, setting the expectation is not good enough. That’s the first step, but you have to do regular check-ins. There is a thing called ‘trust, but verify’ in our leadership. It’s like, you trust your team member, but you also verify. You make sure they are on the right track. As a manager, this is actually your responsibility to keep on check. It doesn’t mean that you don’t trust the team members. It’s just that you have to be there to help them when they’re going wrong. There has to be good feedback mechanism within the team. Like, metrics is one of the ways, or 360 degree feedback, or the trust between the team members for each other, so that they are vulnerable to each other. They hold the peer to peer accountability. You have to keep those process in place. The communication channels has to be open. Anyone should be able to, free to come to your leader. They should not be scared or they should not be hesitating or they should not be silent when they see something is not working.
And definitely, you’ll have to prioritize the professional development, not just deliver the project or product. Like, you know, particularly in startups, people are so busy, go to market, go to market. They often forget about the work-life balance, or their well-being or health, or are they growing as a professional, not just in terms of coding, what about are they growing as a communicator, for example, or as a mentor and so on.
Those are some of the things I think. You know, another thing is the reward. You’ll have to recognize and you have to appreciate when people are, the team is doing good and when they are not, you have to give feedback. These are some of the things I think you have to accommodate as a leader for the team, otherwise, they will become a dysfunctional team.
Kovid Batra: One interesting point you raised here, like with the thoughts that you have just mentioned, we can definitely establish that bed for the team from where they can jump and like fly, right? So, creating that psychological safety, creating a culture where people can be vulnerable, probably leading by example. These kind of things. And then, aligning them towards the mission, strategy, the goals, the objectives that you set for the team, right? So, that’s absolutely perfect. I think once that is in place, 80% job is done, or let’s say 60% job is done, to be very fair. But then, on day-to-day basis, things change, right? Like, as humans, if we have some long-term plans, we definitely want to achieve the goals based on those. But, when you operate on daily basis, there are so many things going around, there are so many emotions coming into play. And, to have things right on track on daily basis, not to make situations stressful, but to keep things on track, we need that objectivity. And as you mentioned, that you have to trust your team, but then you have to validate, right? So, validating comes in with some, probably engineering metrics in place, looking at certain, like developer experience points to ensure that there the people are happy, right? So, how do you do that? Or, what kind of metrics do you use to do that?
Ashik Uzzaman: Yeah, definitely very interesting question. So, you know, the, in many different companies, they track those metrics with different names. Like, some companies call those KPIs, like ‘key performance indicator’. Some other places say KIs, ‘key initiatives’, and so on. But, the idea is that there has to be data available to the leaders who’s running the team or to everyone in the team to see on a day-to-day basis, in a weekly basis, in a quarterly basis, how the team is doing. There are already some tools or frameworks available, like commercial, as well as free that you can use.
Kovid Batra: You’re talking about these DORA metrics, SPACE framework.
Ashik Uzzaman: Right. Yes, exactly.
And then in our company, the company I’m working on is a AI health tech startup. We are using different tools provided by Atlassian, like, let’s say starting with Jira. So, Jira is one.
Kovid Batra: Got it.
Ashik Uzzaman: Or all the other Atlassian product, the Bitbucket, or they are pull request, how much is going. We have developed CI/CD pipeline, as well as workflows to make sure that everything runs smooth.
Kovid Batra: Right.
Ashik Uzzaman: But, this is pretty basic level. I think you can actually use framework or tools like DORA kind of tools on top of it. That makes the life of an engineering manager or leader very easy, if you want to track it at a day-to-day level.
Kovid Batra: How critical do you feel it is for a team to operate with these frameworks or tools in place? How critical do you think it is?
Ashik Uzzaman: Right. I think this is very critical because we believe one thing is that ‘measure what matters’. If you don’t measure something, you are not going to make improvement on that area. So, we must measure. And these tools are there so that you are able to measure and verify and decide the next step, you can plan. Without these, you’ll be kind of running blind, or you’ll be running the team based on gaze or gut feeling and so on. So, that will not work.
Kovid Batra: Perfect. I think that’s really, I would say a hands-on experience advice that I, that I’m listening here. So..
Ashik Uzzaman: Thank you.
Kovid Batra: Great! I think that brings us to the end of this show. If there is any parting advice for our audience, please feel free.
Ashik Uzzaman: Yeah, definitely. Yeah. The one thing is actually study. Mix with people, network with people. It can be virtual, it can be face to face, but the more you talk to people, particularly your peers, your fellow industry peers, the more you will see. There are so much to learn. There are so many areas where you can focus yourself. So, I would say network, study.
Kovid Batra: Thank you, Ashik. Thank you so much for such insightful hands-on advices that you have shared with us. We would love to have you on the show again. I would definitely want to learn about those leadership styles and spend more time on that. Yeah.
Ashik Uzzaman: Yeah. Thank you so much. I’m so happy to be in your, this podcast. Thank you, Kovid, for inviting me and definitely we’ll stay in touch. Thank you everyone.
Kovid Batra: Pleasure. Thank you. Thank you so much.
In the recent episode of ‘Beyond the Code’, Host Kovid Batra welcomes Jeff Watkins, CPTO at xDesign. He has previously contributed his expertise to various organizations such as AND Digital, BJSS Ltd, and more. Their conversation revolves around implementing technology and processes in the age of AI.
The episode starts with a fireside chat with Jeff, providing us a glimpse into his personal background. Transitioning to the main section, Jeff imparts valuable wisdom on the concept of the ‘Iron Triangle’ and the ways to balance it. He also delves deeper into implementing the latest technologies that involve AI and security while also exploring effective methods for defining team success. Jeff also sheds light on the importance of understanding the psychology of programmers in effective organizational leadership.
Wrapping up, Jeff provides meaningful advice to the audience to approach tasks with a focus on efficiency and smarter practices.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a fascinating personality who is a technology leader, tech blogger, public speaker, and a technical architect. He has 25 years of experience in engineering and leadership, currently serving as a CPTO at xDesign, leading 250+ engineers.
He has great hunger for learning in technology. And I can surely say that because at this point of career, after 25 years, he has gone for a degree in Cyber Security, and he is going for another degree in Implementing AI. Happy to have you here, Jeff. Welcome to the show.
Jeff Watkins: Thank you very much. I’m glad to be here, Kovid. Yeah, you probably give me too much credit there, I think, I’ve really enjoyed my career in tech and it’s been hugely rewarding, and also, subjects as Cyber Security and Artificial Intelligence are so really of our time. I think it’s really important to make sure that as somebody who sits in the Exec space to really understand them as, as best as possible, really.
Kovid Batra: No, I think you deserve this. I’m sure people around you feel so. All right. So, we will get started on this. The first part is going to be a quick fireside chat where we’re going to know more about Jeff personally rather than professionally. So, are you ready for that?
Jeff Watkins: Sure. Yes. Looking forward to it.
Kovid Batra: Sure. So, the first question. So, I already know that you have a cat. Last time when we talked, she was also joining the call. I just wanted to know, why cat, not a dog?
Jeff Watkins: Oh, I think.. So, I love both cats and dogs. In fact, I’ve got a cat, sorry, a dog sat next to me here just out of camera shot at the moment.
Kovid Batra: Oh! That’s amazing.
Jeff Watkins: So the cats are definitely not here cause they’re not really good friends at the moment. I’ve grown up with both of them, but, cats certainly I think they’re quite independent. They’ve got a lot of personality. They knock everything off your desk. I think they are just very great fun to be around. I love both, but certainly, for me, I just slightly prefer cats, but I’m trying not to make the dog jealous. I’m sure she’s listening.
Kovid Batra: Amazing, amazing. So, this is the next question. What was your first encounter with technology?
Jeff Watkins: So, yeah, I remember it really well, which is bizarre because I was around 6 years old, so I was quite young. And my father had just bought a Commodore VIC-20, which is a exceedingly old computer. I had 4 Kilobytes of RAM. It had an incredibly.. It couldn’t support like things like sprites and he just had a beeper for a sound chip. It was very, very basic and rudimentary, but that was my first real technology introduction. I mean, obviously we know, we use other bits of technology in our everyday lives, but actually a bit that you could program and you do things with. And, I could put, 10 print “Hello World” and 20 GOTO 10, and be amazed that you could do that. So that was my first, and that was what got me hooked. And I started learning to code pretty soon after that.
Kovid Batra: Oh, that’s amazing. And that’s quite old. Which year are we talking about here?
Jeff Watkins: So, this would be around, maybe 1983. So, a long time ago. I mean, it’s a MOS 6502 processor running at point something of a Megahertz. I mean, we’re talking seriously primitive technology. Certainly never imagined that in my lifetime, the entire way of living would change because the internet, I think has existed since the 50s in some respects, but the actual web, you really in my lifetime, seeing it flourish and become that way of life, you know. When I grew up, we didn’t even have a telephone inside the house. We had a telephone box at the end of the street. To go from that to having always on instant communications throughout the entire world is, is, and this has all happened in my lifetime, which is absolutely crazy to me.
Kovid Batra: Yeah, of course. I mean, seeing this transition.. I was not even born then. So, you have seen technology since that time, not to make you feel old at all. I’m sure you are younger at heart than me, of course. But this transition.
Jeff Watkins: Nice save!
Kovid Batra: But this transition from that point till today, I think you have seen a lot. I’m sure you have seen a lot.
Jeff Watkins: And the thing is, looking at a little bit of a taste of what’s happened this year with artificial intelligence, I don’t think it’s the last one of these we’ll see. We’ll see another great change in our lifetimes. Now, if I could predict that, then I would be the next Bill Gates or the Steve Jobs, but I think there’ll be another one or two, the… If you look at the industrial revolutions, they’re getting shorter and closer together. So, you know, the first one happened, I can’t remember the exact date, some time ago. And then, we’ve suddenly started squeezing together and the, and when will we be seeing industry 4.0, 5.0, they’re getting close together and we will see these huge changes in how we live and how we, how we think even, you know. AI and Google have already started to change how we think. The different studies on things like neuroplasticity, and seeing how people retrieve rather than store information, you know. School used to be about learn loads of facts and cram it all in and keep it in there. And now it’s like, how do you go and get information? So, yeah, it’s very exciting. very exciting time to be alive.
Kovid Batra: All right. Amazing! Moving on to the next one. I’m sure you’re reading a lot of books. Which one’s your last one? And, share some learnings from there.
Jeff Watkins: I buy far too many books. So, I love to read, but also I buy more than I could possibly read. I think there’s more than I could read in my lifetime. The last one I read was, ‘Team Topologies’. I’d been thinking for some time about how teams are formed and also how static they can be. And I think this backs up the idea of, like, thinking about moving to more dynamic team structures, thinking about flipping Conway’s law on its head and thinking about actually designing your organization, and certainly within your digital arm around what you want to achieve rather than letting your systems end up being designed the other way around. I think breaking down silos with siloed areas of the business, you know, traditionally things like architecture was quite a siloed activity. I mean, once upon a time QA was security, still is, and that’s one of the big things I’m really with my fellow podcast host we’re trying to break down those barriers. Every time we, it’s like whack a mole, every time we break a silo down in tech, there’s another one somewhere as the tech world gets bigger and bigger. So, there’s a lot of lessons like that in there and things like around reducing cognitive load, because you want to be able to give people information and communication, but not too much because it becomes overbearing, you know. It’s good to have a big organization and the support of a big organization, but sometimes it can be a bit of a blunderbuss of information. It’s far too much.
Kovid Batra: Right. Makes sense. Cool. I think this is an amazing read for the audience as well.
Jeff Watkins: It’s quite short. It’s quite a short book. So also, don’t worry too much about the time investment. I think you’ll take a lot from it quite quickly.
Kovid Batra: Cool. All right. So, that was a nice fire chat with you. Now, we are moving to the main section where we would want to learn from your experiences, from your success and failures, the challenges that you have had. We will get onto that, I have a question from there. Last thing when we were talking, you mentioned about your philosophy of the ‘iron triangle’. So, I just wanted to know more, a deep dive on it, make the audience also learn the same aspects which you were mentioning. So, can you just throw in some light on that philosophy of yours?
Jeff Watkins: Yeah. For the listener who’s not maybe aware of the concept, it’s an agile project management concept of the ‘iron triangle’. Now, once upon a time, it used to be time, cost, and quality, but then people changed that to be time, cost, and scope. And the idea is you can choose two of them, but you can’t have all three because you can’t cross the triangle. And you’d put quality in the middle and hopefully make that invariant because really people usually don’t want poor-quality software. And the idea is, well, if it’s going to be cheap and fast, then you need to lose scope. And if it’s going to be cheap and have the scope, then maybe you’ll just need to take longer, cause you’ll need a smaller, more focused team, etcetera.
Well, how do you beat the iron triangle? And, in tech, I remember recently working on a system where we’ll use containerized Java services for this, a few years ago now. And we looked at it and went, “But, these services are really simple. Why not just use serverless tech? And they make this as light as possible.” And went, “Oh, but we haven’t done much of that before.” Well, learning’s fun. I personally did some of the first integration and went, “Oh look, that took us from zero to actually working maybe a couple of hours.” And really, if you were trying to build all that up and then put it in all those infrastructures, code, etcetera, that’d probably take days or weeks, anything. So it’s, it’s using this technology smarter. I think that in my opinion is the key to beating the iron triangle in tech, it’s using smart technology. What that does is it gets you more from your time and your money without sacrificing scope at all. There’s a set of scales here because you couldn’t just go, “Well, let’s just use a zero, a no-code platform.” And that’s kind of okay for some things. So there was some, I’d say back office applications where it’s fine, possibly. But if this is a user-facing application, it might not be fine to use a no-code app because some of them don’t necessarily have the most amazing user experiences.
An ex-colleague of mine, he came up with the term ‘lower code’. So, it’s not just a low-code platform, and ‘lower code’ is just like leveraging as much of Cloud Native as possible. And leaning into, well, what can it say something like as your DevOps, as your functions and making sure you use like these are database services, and like, what, what can you use with the minimum amount of configuration and the minimum amount of boilerplate to get you to where you need to be securely and scalably. And if you can crack that, then those kinds of services don’t really put any restrictions on how you deploy them and how you use them compared to maybe a no-code platform.
Kovid Batra: Yeah.
Jeff Watkins: So actually, this gives you all the flexibility of kind of coding it, but also that a lot of the speed of not coding it, which I think is a..
Kovid Batra: Is a big advantage.
Jeff Watkins: And we’re starting to, yeah, we’re starting to harness that appropriately. I think this is where consultancies really do help, cause they know how to do this. And, there’s loads of people still hand-rolling loads of stuff and wasting a lot of time on money, I think.
Kovid Batra: I think it totally makes sense. And I think that’s how you break the age-old iron triangle, and maybe just thinking out of the box, thinking about new technologies to be implemented, you can save a lot of time and maybe deliver fast and buy little cheap. So yeah, cool. I think that was really insightful.
I have another aspect that I wanted to know because you, you have been into leading teams and building things at such scale in organizations. So, you and your team, of course, approach implementing the latest technologies that are involving security and AI? How does that work out right now?
Jeff Watkins: I think there’s a couple of things that I think if we’re talking about security tech or AI technologies, one of the key things for, if you’re going to take something into your organization is doing a proper technology diligence process. And, that sounds awfully long and boring. But actually if you boil it down to what, what are the key things that matter to you? Well. It’d be slightly different between say an open-source project, maybe a proprietary or a SaaS product, but for say like, open-source, well.. How mature is this technology? How many people are contributing to it? When was the last major release? Is it actually, if you scale it, is it vulnerable or not? Is it still in good use of the community? And going on to Stack Overflow and looking at how many Stack Overflow questions are about it, is it a good yardstick for how popular something is. But it also could, is it too mature? You know, there’s a point where Log4j became so old and long in the tooth that the creator of Log4j said, “No, don’t use that. Use Logback instead.” So, it’s that balance of looking at maturity, the developer support as well. So, it’s no good procuring a technology if you have to train everybody to use it, really. It becomes then quite onerous task to actually upskill everybody on it. And, then you have a problem that well, how do you know best practice if nobody else knows it in the team? So, choosing technology, I think. But, when it comes to things like AI, there’s a lot of it’s around, well, what’s this going to cost? Cause AI is expensive to run quite often. And also where’s the data going? Because you probably, you know, we’re in GDPR countries. So, you probably want to be sure that your data, you’re not giving away personally identifying information, or clients or your own intellectual property, cause it’s not just the AI provider who might run away with that. They probably won’t, you know, it’s something like OpenAI would, but they themselves are subject to attack. They could be part of a supply chain attack. So, your data may or may not be safe. So now, safety is a kind of a… It’s never a 100%. There’s no such thing as a 100% security unless you turn off all your computers, seal them in 7 meters of reinforced concrete and dump them in the Mariana Trench. You know, that’s a particularly safe, you know, that I’ll be secure, but it won’t be reusable. So, it’s that trade-off of risk enabling innovation in that respect. But, things like, if you’re choosing AI tech, you know, in the case of, is, do we have a UK data center that makes things much easier? And if they’re within a GDPR country, that makes these things way, way easier.
Kovid Batra: Yeah, yeah, definitely it does. So, basically, whenever you are looking at implementing AI, there is definitely the aspect of security which you’re really emphasizing. How exactly, when you take care of the security part along with it, is there a framework? Is there any steps or guidelines that we have to, like, actually follow when we are implementing it? That would be my follow-up question there.
Jeff Watkins: Yeah. So, if you’re using an AI to build into a product, really one thing about AI is it’s really quite hard to secure the use of the AI if it’s like ChatGPT-based, because people try and put in protections around it, but what you don’t want to do is end up becoming effectively a free version of ChatGPT for people to abuse. So, really we recommend like thinking about the design of the security from the very far left as possible, and that’s for the product when you actually have a product and design space, because it’s really hard to, and it’s expensive to fix fundamental security flaws when you all get all the way to like release. So, you’re thinking about, well, actually, how do you make this? And it’s not just from a technical point of view. It’s almost all from a, well, who might abuse this service point of view? We call it, there’s something called ‘persona non grata’, and it’s the opposite of the persona. You know, when you do product persona, it’s the opposite. It’s the people you don’t want, they’re abusers.
Kovid Batra: Yeah, I got it.
Jeff Watkins: And then we put tenors into misuse cases and abuser stories, and link them to our security and our functional requirements. And when it comes to AI, it’s really hard. It’s like, well, what countermeasures do you put in place to stop people abusing it? But also there’s the, obviously the other sides to AI, you know, people could try and do a model inversion attack that might try and poison your model. They might use other adversarial AI attacks. So, it is also the protections you need to put around that model to avoid it being unduly influenced. How do you, kind of tear that model down? If you think your model has been poisoned, how do you tear down and recreate it in a safe way? So, you have to think about all of that before you really, before you build it all out. And the other thing is it’s like they could effectively attack your infrastructure by overloading that AI, that model or just blow your budget by spamming it with requests. So, there’s a lot of considerations. And the main thing is, like putting in threat modeling, to start with. And that can be product-based threat modeling through persona non grata, misuse cases, abuser stories, attack trees, and things like that. But then also, once you’ve got the basics there, move on to something like, using something like STRIDE to actually do structured threat modeling. And then, make sure you have a very robust way of managing your security threats and risks.
And the other thing is, and make sure you have, your entire development pipeline has got a really good automated security pipeline in place as well.
Kovid Batra: That sounds something like a good step-by-step advice for a lot of things while implementing AI and taking care of the security alongside. That’s great. I think that really helps our audience learning more about it.
Next question is, again, there are things apart from implementing technologies and delivering projects. We particularly look into the developer experience. When we are at this scale, we need to have a good culture in place. So, when you try to make sure that your team is efficient, what kind of metrics you look at? How do you define success for a team? And, when you identify problems in your team, how exactly you end up solving them? So, you can just give some examples here that you would have seen at your organization or your previous organization.
Jeff Watkins: So, obviously there’s old-fashioned… traditional, I think old-fashioned is too harsh, traditional metrics of things like velocity, but then you can start thinking about DORA metrics. And, a lot of it is around I think helping people understand the Lean and Agile together. And nowadays, we’re implementing SPACE metrics, which covers kind of quite a broad range of things. I think it’s really useful to look at where our pipeline stalls in the process, and where there’s waste in the process. So, if something keeps going around the loop, because it keeps failing, or you’re getting high defect injection rate. Well, why is that? It’s not about blaming people. It’s about figuring out what part of that process or culture is broken. Maybe things like staying in review for too long, maybe things are taking too long to release. And quite often for the most part, I’d say most teams do want to do a good job. It’s just their environment around them, it’s not allowing them to do so because it’s inefficient in some way.
Kovid Batra: Yeah.
Jeff Watkins: It might be poor infrastructure, it might be poor release process. It might be tedious red tape. It might be over the wall mentality because you’ve got a separate team doing QA, rather than bringing them together. So there’s a whole raft and it’s measuring the waste. Basically, for the most part, it’s measuring the time wasted because there’s a gap in the process, or because it hits the process and has to go back again. So, any measurements like that, and obviously things like actual quality measurements, stuff that’s relatively non-controversial, like SonarCloud coverage. Test coverage is a hot, you know, it was a hot topic for a long time because people would try and get towards a 100% coverage, but actually, if you just measure coverage, that’s a good hard slothing. When a measurement becomes a target, it ceases to be a good measurement, and people would just fake tests to make a 100% coverage. It’s all about the actual quality of that coverage as well. And there’s, I don’t think there’s a shortcut to quality, but we can do is try and bake it in as much as possible by measuring what you can in a sensible way. I think McKinsey drew a lot of ire from the industry by saying, “Oh, you can measure developer productivity.” And well, I think if you’re measuring productivity in a way to actually help, like remove blockers and build the ideal culture and efficient way of working, that’s fine. If it’s measuring productivity, so you can shoot the bottom 10%, that’s not fine at-all.
Kovid Batra: Yeah, of course.
Jeff Watkins: So I think there’s different ways of looking at that lens. And I think actually, if you take away the emotive aspects of what McKinsey published, and then look at some of the areas they’re looking at, like kind of the organizational maturity, and then engineering maturity, like, okay, so this is very sensible stuff to measure. And, we’ve actually started building out all these measurements. We’ve been assessing our internal projects, you find some really interesting things. You find improvements in where a CI/CD can be made, and improvements where you know, things like security champions can be, um, the program can be improved.
So, and when you start measuring and you have to understand that you will find that you’ll probably find a lot of stuff. Then, once you’ve measured, it’s then it’s actually about prioritizing what’s going to be the most impactful change.
Kovid Batra: Right.
Jeff Watkins: Things change, because you might find 50 things, and which one of those is going to give you your best return on investment? That’s where you need to start evaluating and think, “Well, actually this is costing us, we’ll say 80 developer hours a week because it’s really hitting the team. And, well, this probably needs fixing.” If this is an annoyance that’s costing us half an hour every sprint, well, we can probably live with it, but also then, there’s the impact of other things as well. You know security deficiencies may not actually have any actual productivity impact, but they sure will if you get fined because you’ve lost all your data, or your system goes down, or you, or your data is stolen.
Kovid Batra: So, this is something which would really help in identifying the inefficiencies or the bottlenecks in the whole software delivery pipeline. I would like to also emphasize on the point where you define the success for your engineering teams. Of course, these metrics are something which would give you symptoms or would tell you problems and where they exist, but ultimately… So this is again, a generic as well as a personal opinion that for engineering teams, there should be certain goals, how we define success for them. So, how do you see that success? I would be interested, and the audience would definitely be interested in knowing that.
Jeff Watkins: Yeah. So again, I don’t think it’s around the age-old thing of how many lines of code have you delivered, I think it’s more about the, for me, it’s reducing cycle times and increasing the quality of builds, reducing failures, reducing the waste. So, you should be aiming towards, well, what’s our effective, like what’s our uptime of our builds, and, incentivizing on things like that, incentivizing on quality going up. You know, the measurement should be if you’re improving quality, then you are being a good citizen. If you are leaving the campground in a better state than you come along, you are being a good citizen. That should be, you know, that should be acknowledged. It should be, people should…
Kovid Batra: Rewarded for that.
Jeff Watkins: …Celebrate that people have taken an interest in quality. And then there should be, there should also be notifications if there are problems, if the quality is dropping, if cycle time’s getting longer, because sometimes it might just be, “Well actually, we need to fix our build process because our build process is taking too long.” I’ve had that in the past where people are going, “Our productivity is awful because our build process is too long.” We found some ways of paralyzing pieces. We took the build down from half an hour or 40 minutes to about 4 minutes, so. And suddenly, and that’s not about anybody being non-productive. It’s just about, unfortunately, over time things change. And, but if you’re measuring that and you understand where’s the waste in the system, and set targets for people, if they’re not meeting the targets, not there to beat them over the head with a stick, it’s like what’s preventing you from hitting these targets?
Kovid Batra: Absolutely. So, in an organization where you have 250+ engineers, how do you measure it? How do you ensure? Is it done through processes? And then how do you ensure that the process is followed, or you use some tooling around it? So, I would like to understand that as well.
Jeff Watkins: So, there’s a mixture and because we’re a consultancy, so actually we use a number of different tech stacks. In some ways it’d be harder if we had nearly 300 engineers to measure in one giant team, but also in some ways it’s easier because the individual engineering managers can see at their smaller level. So currently, it’s a mixture of we take metrics from things like the build systems we’re using, the CI/CD we’re using on things like Jira. And also, then there’s elements of kind of manual inspection around. Basically, we have an engineering maturity framework where we come in and kind of lift the lid on each projects within that on a rotation.
I think moving towards a more holistic dashboard of, and I think this will be even more useful for product companies, even more so for like product companies where they have very large engineering teams, all working towards the same kind of goals, the same kind of metrics, is having a metrics platform where you can actually see, you know, what does your build stability look like, what does your throughput look like, what does your waste look like. We’ve come a long way in these platforms in the last few years, but there’s still, I think there’s still room for challenges and still room for new innovation in that, because I think there are ideas of metrics also evolving as well. And a lot of companies still haven’t adopted any at all, or if they do, the most rudimentary ones.
Obviously, you know, as the industry becomes more, continues to grow and become, becomes quite cost conscious. I think it will be a growth area.
Kovid Batra: Thanks a lot for this insight. And the one last thing which is definitely of your interest, which is psychology. So, you mentioned that you are into psychology and understanding the psychology of a programmer, particularly. So, how your understanding of a psychology of a programmer has helped you lead at the organizations?
Jeff Watkins: So, yeah. You know, first of all, you can’t completely a 100% put people in one box, but, there’s a good chunk of us got into software for one type of reason, some for another. But, a lot of us got into it because we enjoy solving problems and we enjoy learning, and we enjoy the challenge of all, rather than, um, just the money. And, I think when it comes to, and this is backed up by research and we’re like, “What do developers want?” And, I broke it into several key things. And, there’s enablement, like people who are very smart, like to be able to work creatively. I think there’s a misconception that developers aren’t creative. And I think, it’s just not, maybe splashing paint on the walls or making music. It’s a different kind of symphony. It’s a symphony of code. So it’s enablement, like giving them the tech and the tools, and the automate and actually build and problem solve. And there’s the kind of, there’s the excitement as well. Developers work so much better in my opinion, and from my experience, when they’ve bought into the vision of what they’re building, I think that was all. So, 20 or something years ago, it really was kind of, “Well, we’ll pay you some money, build some stuff.” And it was back, a lot of it was backend stuff, not so much web stuff. And then, but the modern graduate and the modern younger developer really do care about the ethics, and the company ethos and culture, of what they’re building and where they’re working. So really having a really, really clear set of values is really important to the modern generation of developers.
And then, there’s also the kind of engagement as well. As engineers are thinkers, they like to be engaged, they like to have their opinion heard and to also see that people act on that opinion. It’s no good asking for feedback, if you then just discard the feedback. So, it’s that kind of 3 things of enable, excite, and engage. And there’s a number of different topics under there, and almost none of them really mentioned money. And people will stay somewhere if they feel all of those 3 factors, if they feel that they’re excited and enabled and engaged, and it’s, and it goes back to some of the measurements as well, you know. If you actually start to produce the waste in the system, produce enablement, and allow people to work super-efficiently with modern tech, then actually, people will stay, even if they can see a higher salary somewhere else.
Kovid Batra: Yeah. I think this all, all brings it back to the point where you have to have a good understanding of who your audience is, and when you’re leading a dev team, the developers are your audience and you have to build an experience for them. And it totally makes sense to understand their psychology and then build around it.
Jeff Watkins: Well, there is, there’s a whole field of developer user experience. People go, “Oh, user experience?” You think about the end customer. Like actually, there is another user and that user is often the developer or the other people in the team as well. You know, the team is having an experience at the same time and you can neglect that at your peril.
Kovid Batra: Yes, absolutely. Great, Jeff. I think that was really, really insightful and great talking to you. Any parting words for our audience?
Jeff Watkins: I think, whenever you’re next looking at doing something new, think about how you could be doing it smarter because you can’t beat the iron triangle any other way, in my opinion. It’s think about doing things smarter.
Kovid Batra: Amazing. Perfect. Thank you, Jeff.
Jeff Watkins: Thank you very much for having me today. It’s been wonderful.
Kovid Batra: It’s our pleasure. All right. See you. Bye bye.
Jeff Watkins: Bye.
In the recent episode of ‘Beyond The Code’, Host Kovid Batra engages in an insightful conversation with Giorgos Ampavis, VP of engineering at Tide, who is also a renowned speaker with a strong presence at top-tier tech conferences including DevOps Enterprise Summit, SaaStr, and WeAreDevelopers. Their core discussion revolves around ‘Building tech teams from zero to one and beyond’.
The podcast starts with a fun fireside chat with Giorgos, where the audience gets to know his unfiltered personality. Following that, he shares the challenges faced in his engineering journey and strategies he used to conquer them. Giorgos sheds light into the framework for assessing new tools and technologies. Further, he imparts valuable wisdom on fostering a positive organizational culture and enhancing the developer experience.
Wrapping up, Giorgos leaves the audience with significant advice, stressing the importance of continuous improvement and a commitment to lifelong learning.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of ‘Beyond the Code’ by Typo. Today with us, we have a special guest who is a passionate, insightful thought leader. He has 18+ years of experience in software engineering and leadership. He’s currently VP Engineering at Tide, and he joined the company as early as, like, the 25th employee in the company.
He loves to discuss about technology, building and scaling teams. And post-COVID, you can find him at a lot of events talking about his thoughts. He has been to ‘DevOps Enterprise Summit’ in London. Then, he has been to ‘SaaStr’. And then, there was ‘WeAreDevelopers’ in Berlin. And now, you can find him in the upcoming events at CTO Craft on 7th and 8th of November in London, talking about culture at scale. And then, he would be at ‘LeadDev Berlin’, 4th-5th of December, talking about Native to Flutter transition. Welcome to the show. Welcome to the show, Giorgos.
Giorgos Ampavis: Hi! Hi, Kovid. Nice to see you here. How are you?
Kovid Batra: I am really well. Thanks for being on the show. We are really grateful.
Giorgos Ampavis: My pleasure.
Kovid Batra: Alright, Giorgos. So, we have this format of having a quick fireside chat with our guests, okay? And here, we are going to know a little bit about you, your personal life, and you have to be, like, honest, okay? All set?
Giorgos Ampavis: Will do. Will do. Try my best.
Kovid Batra: Perfect! So, I’m starting off the first question. I’m sure you’re reading a lot, but which is your favorite read, favorite latest read? And, what is your learning from there?
Giorgos Ampavis: So, okay. So, reading is tricky. First of all, I’ll have to say that I have a very short attention span, so I can be very easily distracted. So for me, reading is like it’s a struggle, but I try to push myself and I try to read a lot.
Kovid Batra: Okay.
Giorgos Ampavis: Having said that, I have a big pile of books here, which, you know, I haven’t read yet. My latest one, which I actually finished is ‘Never Split the Difference’, which is talking about negotiation. It’s actually a really nice book. I’ve just finished it last week. Really, really good book. I think it’s probably in everyone’s top 10 or 20 ‘must read’ books. Really good book about negotiation. And I just started. I’m not gonna advertise it. I’m not gonna because they want to advertise it. But, I’ve just started like reading ‘EMPOWERED’ by Marty Cagan, which I’m a big fan of, from the Silicon Valley Product Group.
Kovid Batra: Yeah.
Giorgos Ampavis: So, he has a series of book. I’m just reading now ‘EMPOWERED’, which is obviously talking about empowering product teams, product engineering teams.
Kovid Batra: That’s nice!
Giorgos Ampavis: Yeah. And I also like to read novels and the latest one I read, I can look at it here because I just put it down like a few weeks ago, ‘The Good Fairies of New York’, which is actually really nice. A book talking about two fairies traveling to New York, no surprise there. But it’s actually quite funny.
Kovid Batra: That’s such a diverse taste I must say. Perfect, I think it’s nice.
Giorgos Ampavis: Yeah, it’s actually quite funny. Yeah, but I have to say I’m also using Blinkist a lot.
Kovid Batra: Okay. You listen to audiobooks?
Giorgos Ampavis: Listen, yeah, or read, both, I can do both. But usually, I do like two or three books, like on every other day, while I run.
Kovid Batra: Got it. That’s nice.
Giorgos Ampavis: So, that helps me get the summary. And then, if I like the book, like it happened with ‘Never Split the Difference’, I’m going to buy it. And I’m going to read it.
Kovid Batra: Oh, that’s nice. And that’s a quick, like, really nice advice. Like, quickly have a summary of a book and then probably go back to reading it if you want.
Giorgos Ampavis: Time is precious, right? Time is precious. You need to optimize. You need to filter out the ones you don’t like.
Kovid Batra: Right. Right. Perfect. That was a nice advice. Nice books too.
Alright, next question. I would love to hear, like, what’s your favorite way to unwind?
Giorgos Ampavis: Okay. So I like, I like cinema. In my previous life, I did study cinema, like a cinematographer. So, I have a passion for cinema and movies, by extension. So naturally, you can find me, like, watching movies or TV series on I have all the possible subscriptions, like Netflix, Apple TV, like Amazon Prime, all of them. I try to limit it obviously because you know, I don’t want to binge-watch movies, like 3-4 hours a night. Again, time is precious, so we need to optimize that, but that’s my preferred option to unwind, like watching movies or music. Obviously, I listen to music all day long. And recently, I, you know, and obviously playing with my son is a big thing. How this unwinds…
Kovid Batra: Oh, is it?
Giorgos Ampavis: …or he winds me up or I unwind down. It depends on how it goes. But recently, I bought a guitar because I like to start playing the guitar together with him, who has been playing for one, one and a half year. So…
Kovid Batra: That’s really nice. That’s really sweet, man.
Giorgos Ampavis: Yeah! Electric guitar, by the way. I’m going straight to the…
Kovid Batra: That’s cool, absolutely great! I think, like, you have such diverse days; you’re reading, you’re playing electric guitar with your son. I’m already inspired. So, what’s your mantra for success in life?
Giorgos Ampavis: Okay. So, there’s two sides of it. The one mantra for success is looking outwards. And, I’m talking outwards is just like what I let people see, right? And, for the people that, like, they work with me or they live with me, my mantra is like, I try to be authentic. Whenever with my work relationships, I try to be as authentic as possible. I don’t try to pretend that I’m something that I’m not. I’m very direct, like in a polite way, though, respectful way. And I like…
Kovid Batra: Yeah, that’s very important actually, being polite when you’re there.
Giorgos Ampavis: I like treating people equally. But again, like, by being respectful is at the top. One of the red lines that I have, especially when I hire people, I keep telling them, when I interview people is, “I don’t like disrespect, like, you know, I have zero tolerance for disrespect from any direction.” Right? It can be me sometimes that I disrespect somebody else and I need to be put on my place if I do that, because sometimes you do mistakes, right? Things happen. So when you cross a line, you need to be told to actually to step back and, you know, apologize, right? That happens sometimes. But for me, this is very important, respectful and authentic, like being authentic. And, on the inwards, the way I approach my life, like my personal, which sometimes it is outwards as well, but it’s not in my mantra. But in words, is actually ‘continuously improved’. Like, that’s my mantra. When I wake up in the morning, I’m actually thinking what I’m going to improve today. And I actually am a big fan of Kaizen from the Toyota manufacturing philosophy.
Kovid Batra: So, tiny improvements, yeah?
Giorgos Ampavis: Small continuous improvements, obviously. Hence, the Blinkist. Hence, why I go running every day. Hence, why I do, like, small exercises every day. All of this is part of my mantra. Like, this is how I live my life, my philosophy.
Kovid Batra: Well, I think one good thing is, I noticed, you follow what you preach, right? Like, if sometimes…
Giorgos Ampavis: I try.
Kovid Batra: Yeah. So, sometimes if you disrespect somebody, you are okay that if somebody comes and tells you that you were wrong here and you have to be put in the right place.
Giorgos Ampavis: Oh, yeah. It’s very hard for people who report to you to actually believe you do that. Yeah. But you know, I try to walk the walk, like, and I prove it to them. Like, you know, I’m very down to earth. I don’t have any..I have ego, you know, like everybody else, but it’s not a hierarchical ego.
Kovid Batra: Yeah, got it. Perfect! It was good knowing you, Giorgos. I think the audience knows you now.
Now, the main section. We would love to know your experiences. You joined Tide at a very early stage, as the 9th engineer in the team, 25th employee in the company, and now the team is almost 500 odd developers, right? So, this experience, I’m sure, has been amazing for you. There would have been, definitely, many challenges. Just share something about those challenges. How did you overcome those?
Giorgos Ampavis: So, Tide is a constant challenge, but it’s a positive challenge. First I’ll start with something else. I like challenges. I like challenging myself. So, when I will talk about challenges, it’s not something that we suffered, right? This is always like a challenge comes with a positive outcome, always. So, but I’ll tell you about me. So, I joined Tide, yes, very early. In April 2017, I was the ninth engineer, 25th employee, very early employee, part of the original gang, actually. I’m number four now. There’s another, you know, most people left by now.
Kovid Batra: Oh, okay.
Giorgos Ampavis: And now we have 1500 people. Out of the 1500, roughly 500, they are engineers or in engineering, in general.
Kovid Batra: Yeah, got it.
Giorgos Ampavis: Obviously I played a key part in transitioning from that number to what we have now, because I was very early here. It was a constant challenge because we, you know, in the beginning, we didn’t have the resources that we have now, but we have the appetite. Then we have a small team, which we collaborate really, really well. Then the team started scaling, you know, with the, there was an overhead of communication. So, it was a constant challenge at every level because not only we scaled, we scaled really, really fast. So, if you look at the… I’m working on a presentation now and I was looking at, I created like a graph and actually the graph is exponential with the numbers.
Kovid Batra: Hockey stick.
Giorgos Ampavis: So, it is a hockey stick. Really close to hockey stick, yes, so that brings a lot of challenge and for a company that went from basically no processes, no tools, you know, going to what we are now, like, you know, you can imagine the pain…
Kovid Batra: Ya, ya, of course.
Giorgos Ampavis: …the pain of it. But, it was very rewarding because we learned a lot from the process.
Kovid Batra: Tell us one of those things which you found really challenging.
Giorgos Ampavis: So, okay, hiring. I’d say probably hiring is the biggest challenge because we scaled really fast. So, hiring and onboarding all these people.
Kovid Batra: Yeah, of course.
Giorgos Ampavis: You know, in some cases, it was actually four times in a year, like quadrupled in a year. Bringing all these people, you know, it was very challenging. And it’s very challenging, why? Because we also wanted to keep our culture, like the culture that we had when I joined Tide, and which was really people-centric and really about our members. We wanted to keep it and maintain it. And we actually want us to do that even now. Like, you know, maybe obviously it’s slightly different. It’s not, you know, obviously have different skin to it, but actually at the core, it’s the same. And that was probably the biggest challenge that I’ve seen at Tide. Like, how to keep that culture intact.
Kovid Batra: So, when you go out and you have this pressure of hiring, let’s say a hundred developers in next, let’s say 8 months or 10 months time frame. How do you ensure, how did you make sure that you get the right fit for the company? Just tell us some nitty gritty, like, how other people could learn?
Giorgos Ampavis: So first of all, let’s start with some base stuff that you need, right? You’ll have some prerequisites. You need to have an understanding between the team that is hiring, that nothing’s going to go perfect. Like, you will hire people who are not good culture fits, and you cannot avoid that, especially if you’re hiring fast. But what you need to do, is as you hire fast, then you also need to be very lean on actually identifying these people and then flushing them out.
Kovid Batra: Yeah.
Giorgos Ampavis: That’s actually an easy bit because usually, if you have a strong culture in house, like the bad elements of this, the bad apples usually are flushed out. And that’s actually what happened at Tide. Like, we never struggled to actually, you know, let somebody go, or we never had to let somebody go because usually they realize Tide is not a good fit for them, and usually they leave. We’re talking about, like, less than a handful of people…
Kovid Batra: Yes, got it.
Giorgos Ampavis: …all these years in my team. Then while hiring is really important; obviously, when the team is small, I could do it myself, right? So, it was easy. Like, you know, if I wanted to hire, like, going from two people, two engineers, which was in the beginning in-house, to five, okay, I could spend the time and actually manage to hire these people. Once we started scaling above, 50 and above a 100 though, that became tricky because we needed to have a hiring team, and that hiring team needed to be at the same time, like, hired as well with a cultural fit.
Kovid Batra: Correct.
Giorgos Ampavis: There was a time, I think there was a couple of quarters where I was interviewing like 60, 70, 80 percent of my time. Like, literally meeting everyone.
Kovid Batra: But, that’s actually very important also. I feel like bringing the right people in and just having the calls, the right calls with them is very, very critical. So, for any engineering leader, I would say, this could be a top priority. They can’t really ignore it. What do you think?
Giorgos Ampavis: So, it depends on the level. Obviously, you can’t expect the company, at a company of 1500 people, like somebody at the CTO-level or VP-level to actually interview every single one of them. But, what I’m trying to say is like, you build an extension around you, you build a team around you, which I wanted to do, like, you know, from the very early days, I hired my current Head of Mobile and Director of Web, who are now Head of Mobile and Director of Web, but then they were Lead iOS and Lead Web Engineers.
Kovid Batra: Yeah, got it.
Giorgos Ampavis: And, I hired them and together we actually managed to scale Tide. It was like extending my philosophy, my values like I managed. You know, when we talk about culture fit, I don’t try to hire people who are identical to me, but try to hire people who actually have the same values, core values, at least, right? So these people then, you know, by working together with me, they understand what we need to do. So, we did it together. And then these people, they brought other people, you know, and we expanded and this is how we managed to scale really, really fast. But there was a time where I was actually doing a lot of heavy lifting.
Kovid Batra: Yeah, I think that’s a transition time, the inflection time where you really need to figure out the process and you are doing the work. So yeah, I agree with it.
Giorgos Ampavis: Yeah, it’s a breaking point. It’s a breaking point. Like when you, then you actually, everything becomes amazing, but yeah, I think it was from January 2019 until probably I’m going to say Q3 2019, that was a struggle, like it was a lot of hiring.
Kovid Batra: Got it. Well, that’s on the hiring part. There must have been technical challenges also. I’m sure when you were a small team, you need to really build that MVP, get that product-market fit, and you’re just building, you’re not really caring about the technical there.
But when it comes to scaling after a point, which Tide of course did, did you experience any pains of the past, past mistakes?
Giorgos Ampavis: Yeah. Yeah, definitely. For the first five years, we’re trying to improve the platform, the iOS and Android Native platform, I was accountable for both of them. So, you know, had all these initiatives every quarter trying to improve, refactor. I think we had at some point in 2018, we had an initiative called ‘Architectural Refactoring’. So, we wanted to change the architecture, which we did, we went to modular architecture. So every year, there was a lot of workaround trying to improve and preparing for the next phase of scaling. So, that scaling at the company-level brought a lot of challenges within a team-level, but also the product-level, because, you know, it’s one thing having five engineers working in a code base, not having 50, which we have now working at the same code base, right? So, the challenges are very different. So it was again, a constant challenge trying to improve how we do things, trying to optimize. And then especially on mobile, it was critical because we are mobile first, we took a decision to move to Flutter, because. It was promising and it actually paid back.
So, that was another big challenge when we actually had to transition a whole mobile stack to Flutter, while at the same time, retain the people like the really, really strong iOS and Android developers we had, upskill them.
Kovid Batra: Upskill them, yeah.
Giorgos Ampavis: And then, also hire more Flutter engineers because we wanted to also scale the team. So, it was like, it’s like a train moving and then you are trying to change all the parts in it. But, we managed to do it, like really, really successfully.
Kovid Batra: During this whole time when the scale-up was happening, how much time do you think you were coding after the initial dates?
Giorgos Ampavis: Ah, coding? Okay, I have to admit I’m not coding now at Tide. I’m going outside Tide. I’m doing my own things outside Tide. But within Tide, I don’t code anymore. I don’t have the time to actually code. Or, I don’t think people want me to code anymore.
Kovid Batra: Right, that’s what I just wanted to understand. When you’re really scaling, at that moment, if you’re occupied with hiring, planning the tech strategy, making sure things are falling right, people are getting upskilled, you really don’t get the time to do it, but is it okay to not code at that time and depend on the complete team to make sure things are falling in line? Or, how do you exactly do it?
Giorgos Ampavis: So I think, you know, it depends on the person, but I’d be very skeptical if I see like somebody at the CTO-level or a company or a VP-level or even a Director-level at the size that we are now, and they’re actually coding. That’s…
Kovid Batra: Yeah, of course. At this size, I’m sure this is the perception, but, while you were…
Giorgos Ampavis: Something is not getting done. Something is not getting done, because I know, you know, by experience, I know that there’s a lot of things that you need to do that can keep you occupied, like, for a long time. And I’m actually very busy now so I can see it myself, but…
Kovid Batra: Makes sense.
Giorgos Ampavis: …it may be a case where somebody wants to code, right? It’s again, it’s good if they manage to…
Kovid Batra: Right. Makes sense.
Giorgos Ampavis: …if they manage to balance it, I don’t see a problem. I did phased out from coding in around 2020, 2019-2020 I stopped because that’s when I had to do all the hiring.
Kovid Batra: So, talking about this transition to Flutter, this was definitely a big change, but on day-to-day basis, such kind of big or small tech changes, new tools, new frameworks keep coming into picture and you need them. Do you follow a standard framework or a process while evaluating the frameworks, the tools, the new technologies that you want to implement?
Giorgos Ampavis: Yes. So, technology keeps evolving, right? So, there’s things that we can experiment and there are things that obviously are much trickier to experiment, like changing your tech stack every year. Obviously, it doesn’t make sense. So, it needs to be, like, very well-thought. So, and that’s what we did. Like, we didn’t just woke up one day and said, “Let’s move to Flutter!” Obviously, we had a lot of process, thought process behind it, evaluation process, before we end up to this decision. So, it depends on the scale of what you’re trying to do. I guess the decision is easier, right? If it’s just a tool that you want to evaluate and you can do a POC, you know, you can see if it meets your demand, like your requirements and then obviously cost is one of them, you know, everybody’s trying to cut down on costs now, everybody’s like trying to do that. So, that’s one thing. You evaluate based on the three, four, five criteria you have, and then you make a decision. I don’t want to overcomplicate it because it’s not complicated. But, reality says that it is complicated because then you have all the politics that come with it, especially when you’re talking about engineers. Because you know, everybody, like an engineer, it’s a classic phrase, like, “We can build it.” “We can build that tool. Why won’t we build that tool? We can build it.” And I’m actually facing these discussions, like even today with some of our engineers, like when they think we can build tools, which I get, right? Because we are engineers, we can build everything, obviously. But, we don’t want to build, we want to build whatever makes sense for Tide, and then everything else we need to buy.
Kovid Batra: Right.
Giorgos Ampavis: So, the decision to buy comes with research. We’re never going to go full without researching, like without doing due diligence, without actually comparing technologies, like, you know, and tools. Even with Flutter, we do compare technology before we actually chose Flutter. We did look at Kotlin Multiplatform and what’s the other one? And, Native. We decided, like whether we need to stick with Native. So, we compared these three and, you know, made a decision.
Kovid Batra: Perfect. But, what was the one of the most or one or two important criteria to decide, okay, Flutter is something that fits? Like, one is of course the scale that you want to move ahead, but, apart from that, did you look at some other critical pointers also?
Giorgos Ampavis: Yeah. So, we had three everything was framed around three objectives that we had at the time. One of them was actually ‘lead time’. We wanted to be able to optimize our lead time to market.
Kovid Batra: Makes sense.
Giorgos Ampavis: And, that’s between Native, obviously, and Kotlin will be far from Native, like obviously hypothesis, which I’m going to tell you how it turned out.
The hypothesis was that Flutter will out, you know, outperform the other two. And in fact, we have proved now that we can build much, much faster, definitely from Native, because we only need one team, we don’t need two teams. So, it’s definitely faster. But also, from Kotlin Multiplatform, like Flutter, literally you build once and deploy twice. I didn’t believe it before, but actually it is possible.
The second one was actually, economies at scale didn’t work. So, when we actually wanted to scale that much, like the whole Tide, we needed to hire like probably, I don’t know, another double the mobile engineers we have now, so it didn’t make sense to me at that point to have this big a team. So, based on the premise that build once, deploy twice, then we said, okay, even if that’s not the case, maybe you can optimize your engineering capacity by, I don’t know, 33%. Actually, we managed to optimize it by, you know, we managed to halve it. We didn’t halve people, obviously we managed the demand, we halved the demand, right? We’re still hiring people. But we managed to request half the people that we need it.
And the third one is actually having feature parity between two platforms like Android and iOS. Historically, we had features that were only deployed in Android, or vice versa in iOS. Now with Flutter, everything is in power because we built again once, deployed twice.
So, when we did the original research, we focused on these three, we gathered the data that we needed from the Google team, from other teams, and then we made the decision.
Kovid Batra: That’s really, really insightful. And, uh, like scaling always comes up with different kinds of challenges. And, apart from handling this tech debt, technology, hiring, then the challenge of building the right culture also comes in, right? When you’re scaling, of course, you did the right hire, you tried to find the right fit, but let’s say after that, there is something that you’re doing to actually nurture the team, reinforce the culture. So, how do you do that at Tide? Or how in general, your practices ensure the great culture at scale?
Giorgos Ampavis: Yeah. So culture has two sides of it. The visible parts of it, which is basically the office, the people, dress codes, you know, all that stuff, some behaviors, right? And then, there’s all the invisible stuff, which is, you know, all the rules you have, the unwritten rules, things that they’re not necessarily seen and it’s under, it’s hidden, right? So this, your job is actually to surface the good behaviors as well, that people don’t necessarily see. And you can do this with different ways, like you know, feedback is one of them, like providing feedback, celebrating like, the good behaviors, the ones you want to see, listening to the employees, right? Whatever you’re telling you because you don’t know better. You need to listen, so you can improve. This is how this creates a culture like a positive and strong culture and that has psychological safety and then they can, you know, they can be adaptive as well. And more importantly, you need to lead by example, you can’t just, I can’t ask you to behave a certain way if I don’t behave that way, right? And you know, usually when I talk about it, I close this in presentation, I close with that, because this is the most important thing. Like, leaders need to actually be at the top of the culture. They can’t promote a culture that they’re not part of it.
Kovid Batra: Absolutely. When you talk about the psychological safety and taking care of the team, building the right culture, when all this is in place, I think teams are really motivated, like, innately to work on things, be more creative and deliver better. But at the same time, I always feel that when you scale, you lose that visibility in the team to understand if Teams are really performing or not. Of course, culture is one part, but you really need to understand how efficient they are. And you, of course, have to take care of the overall developer experience also in the team, so that they can move fast. You have to create that environment. So, how do you ensure that they are efficient, they are performing right? How do you exactly do that?
Giorgos Ampavis: So, I’m not going to talk about developer productivity because actually you can’t measure it. McKinsey says they can, but I don’t think you can’t. Like, we established now from Kent Beck and, ‘The Pragmatic Engineer’ that actually we shouldn’t talk about developer productivity. But you know, we do know we do have DORA metrics, like, you know, industry-standard DORA metrics, which they’re great, they cover one part of it because you can still be great at DORA metrics and your team is burned out. You know. So, that’s not enough. So now, we looking into adding a few more things that have to do with developer experience. Obviously we also have the product metrics, like, you know, for our products, the metrics, so all of them combined, they give you like a really good idea about your product engineering teams, how agile they are, how’s the business agility, how happy they are, you know, developer experience, and also are we building the right products, like with the product manager. So I think, that’s all of them together. You can’t look at them in isolation anymore. You need to look at them like holistically, if you want to have a really good health picture.
Kovid Batra: Right. Of course. So can we just deep dive a little bit into this? Like, let’s start with developer experience. What exactly would you try to gauge when you are trying to understand the experience of a developer in your company?
Giorgos Ampavis: So I think the interpretation of what is a good metric on developer experience is different. I think SPACE, there’s a new framework called SPACE, which I think does a really good job. So I have people in the team now looking at this. But ultimately developer experience is self-explanatory, right? It’s about, you know, how happy and productive are your developers? Like, you know, how happy actually mostly, and if they are, that can translate to being productive as well, right?
Kovid Batra: Yeah.
Giorgos Ampavis: So, if you have unhappy people, they’re not going to be productive, we know that. So I don’t want to, I don’t want to, I haven’t looked at it myself. Like, I know about SPACE, but I’m looking at the outcome that I want to achieve. And for me, any metrics you have on the developer experience has to be about the actual people themselves. It’s not about the product anymore. It’s not about, definitely about your releases or deployments, it’s actually about the people. Now, what makes an engineer happy? God knows! Like, who knows what makes engineers happy? We’re a bunch of people, we are.
Kovid Batra: No, of course. But I think, with this approach or this intention of keeping them happy, you will be able to understand that and also maybe work on things that you really want to do for them. So, it totally makes sense.
Giorgos Ampavis: Maybe I’m using happy as an umbrella because happy, you know, it’s like I said, like I tried to imply basically by saying that what engineers need, right?
Kovid Batra: Yeah, yeah.
Giorgos Ampavis: Happy for whatever makes you happy is probably different than what makes me happy. So, I think it’s not just simple as saying like, you know, a simple questionnaire, like, are you happy or not? Like, how happy you are? Like, because we do that as well, right? That I like the pulse…
Kovid Batra: Right. Yeah, we do that.
Giorgos Ampavis:…every week and it gives you..It’s beyond that. It’s not just that. So, I don’t want people to take out that, “Oh, if we ask people if they’re happy, that’s DevEx metrics.” No. There’s a good framework base. They do a lot of work. I’m just simplifying things.
Kovid Batra: No, it totally makes sense. Totally makes sense. So yeah, perfect. I think that answers a lot about how you are leading teams at this time. So I am totally in line with this thought, but, coming to this DORA metrics piece, like those four metrics or maybe a few more metrics which you might want to look into to understand how teams are doing. Do you do that at your organization?
Giorgos Ampavis: Yeah, so we do. Not personally me, but we have a team looking at DORA metrics. Now, we have one of the Directors of Engineering who’s actually looking at holistically as an initiative, like how to get to the next level. Yeah, we do.
Kovid Batra: Oh, so it’s kind of critical for like large-scale organizations at this scale. You think it is important or is it like..?
Giorgos Ampavis: It’s critical if you want to improve, you know. If any company at any size needs or wants to improve, they need to know how they perform, right? As a, at least as a company, forget about developer experience, but at least as a company, they need to understand how they perform. Usually, companies have the KPIs, like the business side of the company has the KPIs, you know, growth, how many users they acquired, ARR, like Annual Recurring Revenue.
But then, you know, for product engineering, going for a tech company, I think it is important to understand how, you know…
Kovid Batra: These people are doing.
Giorgos Ampavis: How basically are you working like?
Kovid Batra: Yeah, yeah. So, I think you touched on a very good point here where success of these tech teams cannot really be defined with just the metrics. I think that there is more to it, right? You have to like, probably build some alignment with the business and help them improve. So, how do you do that at Tide?
Giorgos Ampavis: I mean, think of it this way as an example, right? They’re going to have, like a perfect engineering team, and they’re building all the wrong products that nobody uses. But then, you look at DORA metrics, all four of them, they’re great. Like, you know, great. They deploy like multiple times a day, no bugs, no defects in production, no hot fixes. You know, we respond really fast when we do find one, but we keep building the wrong products nobody uses. So, are we successful as a company? No. I was successful at engineering? I’d say no, because engineering and product doesn’t separate, like they go together, right?
Kovid Batra: They’re together, yeah.
Giorgos Ampavis: You can’t. Like, that’s why we call technical debt. We don’t call it technical debt at Tide, we call it product debt, because it’s one, it’s one product we have. We don’t have a technology, and then a product. Product is one. So, Tide works together as one team, like work together with product, together with our business stakeholders, which, you know, I’m considered one of them as well, like, because we’re part of the business. Again, business is one, right? It’s not separate. We shouldn’t… it’s not us and them. And I think we work together. We have the OKRs, company OKRs, you know, quarterly OKRs. And then these OKRs that translate to initiatives and outcomes we want to achieve. And then, you know, obviously the OKR is not missed, and then we go and deliver them.
Kovid Batra: Great! Great, Giorgos. I think that was really amazing, really interesting. Uh, thank you so much for sharing so many insights and hands-on experience. Any parting advice for our audience?
Giorgos Ampavis: Advice. I’m not really good at advice. I know actually, I’m not bad actually. I’d say, I go back to, especially for new people, right? Like, less experienced people. I don’t want to call them juniors or anything because it’s about experience, right? I’d say don’t, do not be afraid to try, like new technologies. You’ll be surprised of what you can actually see there. Don’t be dogmatic. Like, one thing that I’ve learned early in my life, and actually I paid the price for it, is like, you should not be dogmatic. I actually moved to like, so that’s a funny story, I’m gonna close with this.
I was actually a hardcore Flash and Flex developer, back in 2009. Like, I was doing a lot of Flex, a lot of ActionScript 3, and I hated Apple because obviously it didn’t allow Flash to go into the iPhone, like back then. And then in 2010, January-February 2010, Steve Jobs released this nice email letter, whatever, that killed Flash basically. I decided to drop class and start learning iOS. So, you know, don’t be dogmatic because, you know, you limit your options. So, always continuously improve and always learn new things. That’s the advice.
Kovid Batra: Perfect. Perfect. Thanks a lot.
Giorgos Ampavis: Cool. Yeah, Kovid.
Kovid Batra: Yeah. See you. See you. Thank you.
Giorgos Ampavis: Very nice. Really nice chatting with you.
Kovid Batra: Same here. Same here. Thank you.
In the recent episode of ‘Beyond the Code’, Host Kovid Batra engages in an insightful conversation with Serdar Mustafa, Tech Startup Advisor and Founder of Phoenix Software Consulting. He is also known for lending his expertise to Twilio and Wise. The central theme of the discussion revolves around leading dev teams towards product-market fit.
The episode kicks off with a fun fireside chat which serves as an entrée into his journey and experiences. Moving forward to the main section, Serdar delves into the framework for startups to discover a product-market fit. He shares insights on striking the right balance between thorough user research and the 'fail and learn' approach. He also imparts valuable wisdom on effectively managing technical debt and the right way to use engineering metrics.
Lastly, Serdar leaves audiences with essential advice to navigate this journey effectively.
Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. Today with us, we have an interesting, inspiring guest. He has moved from sales to medicine, and eventually, to product and engineering realms. He has had 8+ years of engineering and leadership experience, currently serving as a fractional advisor to multiple startups. He has been ex-Twilio, Wise, contributing to their product and development. And that’s not all. He’s an author of an interesting growing newsletter on Substack, ‘From Code to Boardroom’. Welcome to the show, Serdar. Great to have you here today.
Serdar Mustafa: Hi Kovid! It’s an absolute pleasure. It’s nice to be on here, on your show today, and speaking about topics which are really close to my heart. So, looking forward to the discussion.
Kovid Batra: Perfect. Perfect. So, we start off with a quick fireside chat where we would love to know more about you personally, outside the scope of work. So, are you ready for it?
Serdar Mustafa: I will do my best and, and try to be agile, as they say.
Kovid Batra: Great! So, let’s get started. First thing – I am fond of people who write. So, I would love to know what made you move towards writing and becoming an author of ‘From Code to Boardroom’.
Serdar Mustafa: It’s an interesting one, actually. It’s really interesting for me because going back to my youth, I was very much a reader, I love to, to pick up books and always kind of add new knowledge, but I was never much of a writer. And, I actually put that down to my ADHD, I have a neurodiversity, I struggle to focus. But then, throughout my working career, I actually turned that into a bit of an ADHD superpower. I realized that my scattered thoughts in the early days were better when condensed then and put into writing. When I started documenting the things I was doing each day, keeping logs and journals, and documenting, kind of various technical operational aspects of my roles, it made everything better, not just for me, but for the teams I worked with. And, I brought that into the product engineering roles. I’m sure we’re all familiar with the type of documentation that we get in the industry. By me starting the blog fairly recently, I was able to kind of put down my thoughts in one place where I could kind of gather them and reflect on them and keep them updated as things changed, but also share them with my peers, try and help other people with the knowledge that I’d gained over the years and help them excel at what they’re trying to do.
Kovid Batra: That’s really cool. And I really am inspired already from the kind of journey you have started with. And it’s really amazing to see you contributing back to the community. Kudos to you, man, for that.
Serdar Mustafa: Thank you. Thank you.
Kovid Batra: All right, moving on to the next one. I think now I know the answer to this, but love to hear more from you. What gives you the energy to overcome those roadblocks that come your way?
Serdar Mustafa: I guess I was always a competitive person as a youngster. I was an athlete. I was practising martial arts, gymnastics, parkour, and naturally these things had various challenges. And, I guess when I first started out both in sport and then in work life, there was always some prescribed way of doing something to get the job done. And it was only really when I came into tech businesses that I found this relationship between what I had done as a youngster with my sports, and the way software development teams work with the need to kind of pivot and change on the fly, adapt to what we’re doing. I really related it to my martial arts, my parkour in particular, when I had these obstacles or roadblocks, as you say, which didn’t always have a predefined way of challenging them. There was no script. You couldn’t always plan in advance. You could try and prepare for them as much as you could, but there was always these unknown unknowns. So, I learned to be able to stay agile, I know a bit of a cliché word in our industry. But, I learned to adapt and do things in different ways. And, this mentality that I developed, when I installed that into the teams I was working with and, and saw other people excelling and doing better in their roles, it really gave me this huge motivation. As someone that’s been coaching in sports and coaching and mentoring in business, seeing other people succeed has been that catalyst to me, that’s been the fuel to my fire. And, I love seeing that success from the people I work with. So, that’s what led to the blog and that’s what led to me going back into leadership and why I’m here today.
Kovid Batra: That’s amazing. Amazing. That, that feels really intense to me, and this is quite a journey, I definitely feel so. Let’s tone it down a little bit and let me understand from you, like how do you unwind your day? How do you end your hectic day? What’s your way out there?
Serdar Mustafa: Definitely a challenge for me. It’s one of my weaknesses, if ever there was one. Wearing the multiple hats that we do in startups, it’s hard to kind of press pause or stop and unwind. But, when I eventually do I’ve got two ways, really, if it’s something I need to do on my own and just clear my head, I’m a motorcyclist, I jump on my bike, I live near the countryside. So, I just go for a blast and pitch-up somewhere and just stare at the sky, stare at the trees, anything that’s not work-related.
But, other than that, it’s my family. I’m a father, a husband. I’ve got 3 beautiful daughters, and we love going out hiking and cycling. And, that’s enough for me to re-energize and reset before the next day.
Kovid Batra: Perfect, Serdar. I think that was great knowing you and there is more to come. That would be in the main section that we have. So, let’s get started there. Are you ready for it?
Serdar Mustafa: Yep. Let’s do it. Let’s do it.
Kovid Batra: Perfect. So, in this piece, we would love to know your experiences, your success and failures at different point of time in your career. So let’s just start with something like your journey, which has been across different departments of a business. How does your experience across different departments of a business impact your leadership style? Because you have been into sales, medicine, product ops, and then engineering, and then engineering leadership. I am really interested to know how does that make you different?
Serdar Mustafa: See, what most people see is the difference in job titles, job roles and industries, but there’s one similarity in most of the things I’ve done throughout my career that people often overlook, and that’s the people leadership.
Kovid Batra: Yeah.
Serdar Mustafa: It’s soft skills, it’s learning to collaborate and communicate with people to help boost their success and their achievement. So, I’ve never focused on being the best martial artist, being the best programmer, or being the best leader in isolation. It’s more about being an accelerant and, and lifting others up. And, by having this kind of experience in other roles and teams, I’ve looked at the different ways people do things. And then, when I look at the circumstances I’m in, any given role, I try to get the best bits from each of them and combine them to find new solutions or discover new problems that need to be solved, and look at how we can welcome them together.
Once upon a time, the manufacturing and car industry worked in a very rigid way. They were set in their, the way they did things, and then we started getting kind of lean principles and things from Japan, the way that they did these things. And, I’m sure they were laughed at initially. They were told that, no, you can’t do it. Like, there’s this way that we do things, and that’s it. But eventually, things called on and people adapted. And, we all know where we went from lean to agile and all the various methodologies. It’s been diverse and I have, I guess, a great variety of diversity across different roles and types of teams and working with different people in different countries, I’m just able to filter that down through the funnel and find a mix of things that helps the team that I’m in the best.
Kovid Batra: Makes sense. When you have been dealing with different teams, of course, the core motivation for people at work, most of the times remains the same, even when you’re in sales or in tech. So, just tell me one thing that you took from your, probably the sales experience or the medicine experience that you are able to apply here in engineering, and that has really helped you.
Serdar Mustafa: So, I mean, the sales experience, there was something that we used to do when I was a General Manager at Phones4u, a company that sadly doesn’t exist anymore. They were the largest retail mobile phone company in the UK for many years. We had this way of selling that was unique. We used to sit our customers down and establish their demands and needs. They would come in with their problem statement. They would say they need a new phone, and they would already have an idea of what phone or tariffs and things it was that they, they thought they needed. But, by sitting down with them and understanding their problems, understanding their budget and the other variables, we were often able to find them a better combination of these products that suited their needs more. When I relate that to Product Engineering, when we do user interviews and do all this user research, users often tell us what they think the problem is. But, unless you know what kind of open questions to ask and really understand what the problem is they’re trying to solve, what you can end up doing, and it’s common problem for even the largest of companies is building the wrong thing or building it in the wrong way. So, by using the kind of techniques that we developed in my previous sales background, we’ve been able to enhance the engineering teams that I’ve been working with.
And, slightly shorter story, but similarly with the medicine aspect, it was biomedical science that I studied which is a lot more research-driven than clinical medicine. But, the things I learned that really help is about hypothesis testing, statistical analysis, and understanding the context when you’re looking at raw data, we see so much data in our industry, all these developer metrics and user data, but what did it actually mean? When we look at a line graph or some pie chart or something, it’s usually presented in a positive way with certain colors and points on there to give a certain perspective to a certain audience. But, what I’m able to do with my medical knowledge is apply context to that to show are we really working towards our acquisition, activation in the way that we need, or is there something hidden in this data? Are there kind of outliers and things that we can analyze further to make better business decisions? So, that’s where that experience in those two different industries has really helped me in my roles over the last few years.
Kovid Batra: Cool, yeah. That’s, that’s really interesting. And I think very insightful. Perfect. Perfect.
Moving on to the next piece, what do you think it takes for a startup to find a product-market fit? Like, you have been working with multiple startups as an advisor, as a fractional advisor. I would like to know from you, like this initial journey of zero to one, this is really interesting. I have been into that multiple times, but I would like to know your perspective. Like, what does it take? What are those core things or maybe a framework that you have in your mind people follow?
Serdar Mustafa: I mean, at this stage, when you’re looking for product-market fit, whether you find an SLG approach or PLG approach, I think the key thing is to keep things simple. It doesn’t matter if you’ve got a complex product, the way users find it and your approach to development and things should not be complicated. They should be in the simplest form possible to help you build… instead of an MVP, I prefer to call it an MLP, a ‘Minimal Lovable Product’. Ask those questions, do the right type of research to really understand who your users are, how they’re going to use it and what problems it’s solving for them. And, a key example of this is, with our kind of empty state screens and things that we get on our loved SaaS products, one of the first things that you usually see is, “We can save you money.” “We can increase your profits.” “We can increase your brand recognition.” And all these kinds of things. But, that’s not actually the solution to the problem statement a lot of the time. They are usually commercial targets or objectives people are trying to reach. You need to really dig in your product to understand who these people are and how do they use it. Once you’ve provided and advertised that solution, word of mouth will do the rest. And there’s even businesses out there which have relied solely on word of mouth with no marketing and advertising budgets. Once you do those basics, you’ll establish product-market fit.
It’s a complex multivariable equation that requires a nuanced approach. There is no, kind of one t-shirt that fits all. There’s no point reading the latest blog on PLG or any of these strategies and try to apply it universally to what you’re trying to do. You need to really look at the intricacies of what you’re trying to achieve and, and adapt things. And you can only do that successfully by keeping things simple. If you start exploring overcomplicated technologies, overcomplicated system designs and architectures and things, just because they’re cool or that they’re the latest fad, you’ll often find yourself spending too much money in development and in hiring things before you’ve established that product-market fit.
And, bear in mind the climate changes as well. What you’ve identified now may be slightly different in six months time. So, as long as you’re not overcomplicating things, you can adapt faster. Hence, why I use the word agility a lot.
Kovid Batra: That’s, that’s totally bang on, I think. I have a question on this. Like, while being on this journey, multiple times myself too, I have always struggled to strike a balance between doing this user research, coming up with insights and then implementing something. And also at the same time, where I had my Co-founders, who believed in doing and failing and then learning from it, and then iterating. So, there has to be a balance between the two where you just go on the research journey, find out something, and then you execute, fail, and then learn from it, and then improve. Which one do you prefer, and how do you strike that balance?
Serdar Mustafa: I mean, it really depends on the nature of your business and the kind of people that you’ve got behind you in leadership or as Co-founders and things like that. One thing that’s imperative is that you’re all agreed. You should have one North Star metric that you’re focusing on at a time. Any kind of OKRs or whatever goal-setting methodology that you’re using should be aligned to that North Star, and everybody should be working towards that at the same time. As far as the approach to get there, it doesn’t matter if you’re following some kind of growth engineering type reports, some experiment-driven design or development, and you should always rely on as much data as you can get practically, and within a reasonable period of time.
It’s about changing direction. I mean, the quote from Bruce Lee, “Be like water.” Water can… I’m not quoting this verbatim, by the way. So, any Bruce Lee fans, please don’t shoot me, and… Be like water. Water can flow hard. It can flow fast. It can be soft, and so on and so forth, right? It adapts to its environment, and that’s what you should be doing. So, if you choose on day 1 to follow some kind of data-driven development and you’re looking at stats and you’re looking at all this user research focus groups and things like that, you need to know when to either adjust or mix the method with a different type. I would always advocate for using some kind of mixed methods, some quantitative and some qualitative. Just be ready to change direction as the business sees fit.
Kovid Batra: Makes sense. Great! I think that’s really interesting. And, I think it’s more about being in the situation, having that feeling what’s right in that moment, because you might not always have the data to take a decision on that, but what we can do is actually timebox things to really keep moving fast and change directions, and then experiment with that.
So, cool. I think…
Serdar Mustafa: Mm hm.
Kovid Batra: Yeah, please go ahead.
Serdar Mustafa: No, I was just going to say, you know, you’re absolutely bang on it. It doesn’t matter which kind of goal-setting methodology you use, the age-old smart goals are always relevant. You should timebox things. You should have some mechanism to evaluate and review how things have gone and then make the necessary changes moving forward.
And the other thing I would say on the topic is make sure that you’re getting as much advice as you can from the professionals. If you don’t have those people in the team as you’re starting up or as you’re growing, there’s consultants out there, advisors, and fractional people like myself. There’s all of these different resources available these days. Try some different options, take that advice in. And at the end of the day, you’ve got to make the judgment, which one you follow. So, no one knows the answers for sure. But, they can at least guide you in the way that their experience has shown previously.
Kovid Batra: Definitely. Got it. Well, this is something around the startups and for our audience who are into this journey. We have people across the world who are leading bigger teams, well into the phase or who have crossed the phase of zero to one and are into the growth and scale mode right now. For them, the day-to-day challenges would be around being more efficient, being more productive. So, when we talk of this efficiency and productivity and effectiveness in the teams, how you have been doing it with your engineering teams as a leader to measure the efficiency and finding those inefficiencies and then improving on those, how do you usually deal with that? And of course, when we talk of efficiency, productivity, we really can’t give up on the well-being of the development team or the developers. So, a combination of this. How do you take care of it as an engineering leader, the efficiency and the well-being?
Serdar Mustafa: Efficiency and well-being. I mean, again, specifics depend on the type of business. If you’re a small 5, 10, 20-person startup, it’s going to be very different to a large organization that has a thousand people in engineering. Things scale differently. For me, most of my experience has been on the smaller side of businesses, up to 50-person engineering teams, and they’ve all shared a lot of similarities. I’ve been in the business where they were initially trying to use kind of more enterprise-type approaches to standardize everything they do. They would pick some kind of agile methodology or framework, use well-known engineering metrics, things like cycle time and velocity. And to support that, they would have sprints and story points and things. But, one of the issues I have with this is they’re using essentially qualitative data, and trying to get a quantitative output. Things like measuring efficiency with cycle time and velocity, you’re relying on story points, t-shirt sizes, things like the Fibonacci sequence and that, which are all numbers, obviously. They’re all quantitative, but the source of that number or that, that data point is qualitative. You’re basing something on ‘how much time does it take to do this type of ticket’ or ‘how difficult is it’, ‘how complex’ and stuff like that, right? So, how do you convert something qualitative into quantitative and then standardize it when there’s so many other things which can impact it? There’s people taking time off, there’s people leaving the business, people joining the business, there’s national holidays, there’s unknown technical problems which may occur that divert your resources and attention. If you’re in a young startup, you may even decide to pivot everything that the team is doing or certain teams within. So it’s, it’s hard to plan and measure these things in that way. So, what I prefer to look at is more on the efficiency side of things, the outcomes. What is it that we’re trying to do? Going back to that North Star metric and those OKRs or similar system, what are you trying to achieve? Is it acquisition? Activation? Are we trying to improve customer satisfaction? Reduce the amount of bugs? Pick a thing that is your goal, establish a baseline of where you are and where you want to be, have the measures in place to be able to do that, and then measure it over a given timeframe. So, like you said earlier, you need to timebox it and look at how it’s done, and then you can dissect it, disseminate it, and analyze it afterwards to see the what’s, the why’s and, and things like that, before you improve it.
Kovid Batra: Exactly. So, I think you are completely aligned on the thought where how important the business objectives are, business outcomes are, and I totally second that thought. But the point of measuring efficiency comes in when you face problems in metrics like customer satisfaction, right? Just for example.
Serdar Mustafa: Mm hm.
Kovid Batra: And this customer satisfaction could be going down just because your app is not working right, which ultimately trickles down to the fact that why is it happening and you need to know an answer to it. So probably, what I personally feel is that these engineering metrics could really help you understand that, “Okay, this is the root cause.” So, let’s say the customer satisfaction is going down because of the bugs or the issues that are there on the app. How would you understand that? You would be able to see that in the engineering metrics. For example, if there are very less comments going on the PRs that are being merged to the main branch, just for example, you would know that the teams are probably not having a strong review process in place because of which the quality of the product which is going out is not right. And so, the point is absolutely right in a way which you said, the most important thing is to look at the business metrics, and then from there, if you identify problems, you need to deep dive onto the engineering metrics to understand where things are going wrong. So, what I feel, not to say that you are doing the wrong thing, but to basically put in line that how these things connect with each other, like product and engineering connecting together to ultimately deliver the product, right? So that’s something which I personally feel is important for engineering teams to look at time-to-time that how they’re doing on their bugs rate, how they’re doing on the code review process, how they’re doing on their comments per PR. There are a lot of such metrics that are there into the picture, but yeah, that’s what my thought is. What do you think about that?
Serdar Mustafa: So, I guess it has to work, I think. A lot of what you’ve just said is on the assumption that you’re doing traditional code reviews and pull requests, when there are a lot of ways of working, shall we say, aligned with various agile methodologies, like XP (Extreme Programming), which work in a different way where people are working more collaboratively, either paired coding, group coding, and mock coding and so on, where you’re doing things kind of more proactively, you’re shifting things to the left. And, you’re not writing the code and relying on someone to catch it in a code review after. Even if you’re having regular small commits and small PRs, there’s room for error and there’s certainly room for improvement. But, I think we need to rewind a little bit before that.
Technical debt, huge topic, but actually I think a lot broader than most people give it credit for. Technical debt can cover the product side of business, commercial sales, marketing, so on and so forth, not just engineering and the code that we write. In short, there’s, I believe, two types of technical debt. There’s the intentional technical debt and the unintentional. The intentional technical debt are decisions, business decisions, engineering decisions. Somebody who’s chosen to build something a certain way… now, for that decision to be made, we can discuss another time, the kind of steps that may be involved and peer groups and workshops and things, but let’s say that, that bit’s safe, that bit’s being done well. It’s the unintentional stuff. The unintentional is we had a goal of building something that was going to end up a certain way and it hasn’t ended up that way, whether it’s a defect, a bug, an error, whatever we want to call it, it’s not the way it was intended. Now, a certain amount of this, we have a tolerance for. Technical debt is like a financial or credit card debt. When used responsibly, you can improve cash flow and get you by until you’ve got more income coming in. In terms of the technical aspect, we can introduce a certain amount of technical debt. And, I don’t like the phrase ‘cut corners’, but we can do things intentionally in a way where risk is mitigated, but we are delivering the MVP. We are getting the next iteration out there in a condition that we are happy accepting.
Kovid Batra: Yeah.
Serdar Mustafa: It is when not managed responsibly, that this debt can spiral and accumulate, until one day it bites you in the proverbial bottom. In engineering, that’s when we make out our software and code and things too complicated, unmanageable, unscalable, and too specialist and things like that. We create silos and all these things. What we need to do is focus on making sure that we are building things that are simple and solve problems. We need to keep even the operations and systems and ways of working simple at first. There’s no point investing too much time measuring these kind of metrics in the early stages. And when we do decide to start adding things, we need to do it incrementally and review them to make sure they’re actually providing value.
Kovid Batra: Absolutely.
Serdar Mustafa: I don’t want to say get rid of things like cycle time and velocity and these traditional metrics, but instead, introduce them at the right time, the right amount of them, understand the return on investment from doing this, do it in collaboration with the people that it’s going to impact. So, discuss these things with the engineers, with the product people, QAs, and so on, to see what they think, because this affects the second part of your original question about kind of developer experience and things.
If you introduce these things, they can be misinterpreted. They can be seen as kind of performance management metrics. They can be seen in a very negative light. And ultimately, there’s no point having great developers, a great team building fantastic things of solving user problems, if you’re just going to have a high turnover of stuff, because they’re not happy about the performance management metrics and things.
So, there’s a whole load of stuff in this realm that could be discussed. And I know we don’t have the time today, but, what I’m saying is really think about the kind of metrics and the value they’re going to give your business. Why are you doing them? Is it just because engineering managers typically have these metrics? Who are you showing them to? And, what are they doing with them? I actually asked these questions in a previous role. I inherited a leadership role as I got promoted and someone else left. And, I was expected to continue filling out these dashboards and looking at these metrics, and I actually stopped after the first week and went back to senior leadership and asked, “Why do we have them?” “Who are they for?” And, I actually asked the CEO explicitly, “Is it for you?” “No.” “Was it for the CTO?” “No.” The answer was, “Because your predecessor was doing them, we just assumed that you would continue.” But, they weren’t going anywhere.
Kovid Batra: Got it. I think I totally agree. I think, to conclude on this point, what I would say is that as you scale, you just need to understand the need of the right metrics that you want to introduce, and they have to be introduced with the right culture in place where people are, the developers are feeling psychologically safe and they’re not taking it the other way around, where it is ultimately for the benefit of everyone in the team. So, I totally get that point that with scale, the need of such metrics would come in. And, we have to like, as an engineering leader, we have to figure out which metrics to look at, how they should be deployed and used for the improvement and good for everyone actually.
With this, I think we have exhausted all the things that I wanted to ask on this, on this podcast. And, it was really, really interesting talking to you. I think we can have another podcast on the last question where we left and like, discuss more on that. I really found that piece interesting where you touched on the technical debt part. Would love to talk more on that, but probably on the next show.
Serdar Mustafa: Absolutely. No, I’d be more than happy to. I hope that your viewers and your audience get some value from the discussion today. And, even if there’s one little thing that they take away from it to help them improve themselves or their business, I’d be satisfied.
Kovid Batra: Absolutely, Serdar. So, one last message for our audience that you would like to say?
Serdar Mustafa: Keep your head high and stay positive. I know it’s a, it’s a turbulent industry, but it’s extremely rewarding, if you ask me. The, the satisfaction from seeing yourself succeed, your team succeed, or your product or your business that you’re in is just second to none. So, keep it going.
Kovid Batra: Thank you so much. Thank you so much for this.
Serdar Mustafa: Thank you, everyone.
Kovid Batra: All right, Sid. See you!
Serdar Mustafa: Bye, everyone. Bye, Kovid.
In the recent episode of ‘Beyond the Code, Host Kovid Batra welcomes Marian Kamenistak, engineering leadership mentor & coach, founder of Augment Lab, and a former VP of Product Engineering at Mews. The core of their discussion revolves around boosting engineering efficiency with data and empathy.
The episode initiated with a fun, fireside chat, allowing audiences a glimpse into Marian's personality beyond the professional realm. Moving forward to the main section, Marian delves into the obstacles he faced in his engineering journey and details the strategies for overcoming them. He highlights the significance of maintaining a data-driven mindset as well as underscoring his three core principles: transparency, trust, and prevention. He also elaborates on two distinctive terms - 'Roadmap contribution' and 'Epic Cycle Time’.Wrapping up, Marian imparts valuable insights for engineering leaders, emphasizing key considerations to drive efficiency within their teams.
Kovid Batra: Hi everyone! This is Kovid, Kovid with a K, your host at ‘Beyond the Code’ podcast series by Typo. Today with us, we have an interesting, amazing guest from a really amazing place called Prague. He has 15 years of engineering leadership experience. He has been a former Vice President at Mews. We would love to learn and hear your thoughts today, Marian. Welcome to the show.
Marian Kamenistak: Thank you, Kovid. Thank you for having me. I’m looking forward to run this show.
Kovid Batra: All right, Marian. So, before we get started with the main section of how to use engineering metrics and how to have a data-driven mindset, I have a quick fireside chat to know you more, okay?
Marian Kamenistak: Okay.
Kovid Batra: And you have to be, like very comfortable. Share your real thing, okay? We would love to know, our audience would love to know you. Are you ready for that?
Marian Kamenistak: I hope I’m ready!
Kovid Batra: Oh, no, it’s going to be light.
All right. So, we’ll start with the fireside chat. The first question, which is your best memory from childhood about coding?
Marian Kamenistak: Oh, coding! Yeah. The thing is, like I started coding at age 11 approximately, and it was not really like, it was the oldest PCs, if you know what I mean? So, by that time, if I wanted to play games, I had to, you know, uh, basically run it from the audio cassette. That’s the first thing.
Kovid Batra: Yeah, yeah.
Marian Kamenistak: And the second thing of course is that, you know the graphics was not really exceptional, but I was lucky to have some sort of coding book where I went through the tutorial step-by-step. That was the first like, you know, enlightening of saying like, you, this might be the right thing to do and to play with around. Yeah.
Kovid Batra: Great, great. I think starting to code that early would have been amazing, man! I think nobody at that point of time probably would have known much about it. So, that’s really interesting.
Marian Kamenistak: Yeah. And the thing is, like the computer was not really ours in my family. It was, you know, my father’s gift. He’s somewhat moved it from his office… To home sometimes from time to time. And, I was benefiting from that experience, right? And then I was, like really asking him hard way to bring the computer every single time after he’s back from work, right? So, which was really comfortable in the end.
Kovid Batra: So, now you know how legends are born, right?
Marian Kamenistak: Yeah!
Kovid Batra: Great! Moving on to the next fun question. Now, this is my favorite. Which one’s your favorite Netflix series and why?
Marian Kamenistak: Oh! There’s a couple of them. To be open, I’m not really watching Netflix or, you know, Disney anymore cause I’m really strict when it comes to my schedule. Nevertheless, if I do have some time, I, last time I remember I was watching, I think it’s called ‘The Sandman’. The Sandman is really like, you know, something that I was really astonished to see cause, you know, the story is amazing. Plus, you know, the graphics, that’s something which really caught my eye. But nevertheless, like, you know, the story about, you know, the dreams and the way how to think of some, you know, parallel universe, that’s something what was really mind-blowing in my case.
Kovid Batra: Thanks for sharing that. I think we have got a few more to watch on Netflix now.
Marian Kamenistak: But, I’m sure there’s so many better series than this, but, you know, I’m already out of the current time. Yeah.
Kovid Batra: Perfect. Last question. How do you unwind your day?
Marian Kamenistak: Oh! You know, when I’m usually finishing my day, I’m getting pretty tired, to be open and honest, because most of the time it’s mostly advisory to specific companies or mentoring. And, there is, by the way, one thing I found out, which is I can’t handle more than, I would say 3 to maximum 4 mentoring sessions a day, because it’s as intense as handling interviews and, openly speaking, I’m just moving to my men’s cage, if you know what I mean? And, cry on my shoulders to preserve my energy. But openly speaking, you know, uh, I’m living in a cottage house, so, what I love doing is really to go and walk, you know, around my garden. Plus, I’m a family person. So, you know what it means, you know, having the family and taking care of the kids, and so on and so forth. Nevertheless, as I was saying, I desperately need all the time and each and every day to preserve some of my just private time in my cave for myself with no internet, nothing, just, just, you know, taking a rest and taking a deep breath, right. Yeah.
Kovid Batra: Yeah. Thanks for sharing all this. It was really, really nice knowing you more.
Great! I think now it’s time that we move on to the main section where we talk about how to maintain engineering efficiency with a data-driven and empathetic mindset. So, this is, I think very close to home to you also because you have been a leadership coach and you have been posting a lot about such topics. So today, I have a very, I would say interesting, as well as deep questioning here from you to actually see how you lead engineering teams while you work with them. How do you teach them that data-driven mindset and empathetic mindset to actually improve the efficiency? Yeah, right. I think we’re all set.
Marian Kamenistak: Yeah! We are good. And we’re looking for the topic cause I’m a data-driven person, to be open. So, looking forward for the topics we have ahead of us.
Kovid Batra: Sure, yeah. So, I think I’ll start with your experiences first. You have 15+ years of coaching, being VP, I mean, diverse experience as an engineering leader. You would have seen a lot of challenges, and you would have overcome them. So, let’s talk about something from your experience at Mews probably. Anything that you would love to share with us? Any specific challenge? How did you overcome it?
Marian Kamenistak: Oh, okay. So, putting a little bit more perspective into my last full-time gig, it was the story of Mews where I was working as a VP of Product Engineering. And, now I can say the story was pretty funny and interesting. Nevertheless, when I started at Mews, it was not that funny anymore because it was the COVID time with the C, not with the K, of course. So, there was plenty of the layoffs and you know, the let’s say the atmosphere was not that great, I have to say. By the time I was running around 8 to 10 teams, different product engineering teams, and after almost 3 years, I ended up with more than 30 teams in total, right? So, the experience was that after a couple of years from, you know, running basically, resurrecting, that’s, I would say, the right word, the teams from sort of a poor efficiency into something meaningful, into something that the teams are really considered as an ammunition that can overcome and run over the competitors basically. And, that was what we were after. And, in the end we ended up being successful in Series C investment, which was around 200K, right? Pardon me. 200 million, right? A bit different number here. So, that was really the story of Mews. Of course it was not only my job. It was the job of, you know, other stakeholders, participants, other peers. I wouldn’t be able to basically resurrect and grow the team just on my own. That being said, the important portion of that goes to, for example, product management, and to other departments in the company.
Plus, we had to change the culture and prepare the teams for the goals, right? So, that was one of the things. So, you know, roughly speaking, when it comes to the challenges, it was really, you know, making sure that all the teams are aligned, cause, there was so many different initiatives that we were running. Plus, you know, the focus was not there. I would dare saying that the teams were not really efficient in the end, right? Although we were busy, you know how it goes.
Kovid Batra: Right.
Marian Kamenistak: The productivity was not really there. And I was told that, you know, when I entered the company, I was told by the Chief Product Officer that “engineering is a black box.” Basically, that was the message. And, so turning that into something that works, into something that’s predictable, that’s transparent, and, I would say the keyword here is ‘trust’ to turn the teams to something that is trusted.
That was really, you know, one of the stories that we were after and successfully, we made it work this way. Yeah.
Kovid Batra: Okay. Did you do anything about solving the “black box” particularly? Like, when it was told to you that it’s going to be a black box. And, then of course, when you are leading a team, you just don’t want it to be a black box. You want to know a little in-and-out. Of course, things run on trust. That’s totally there. And I totally believe that’s the core of every good team or a successful team. But still, were you comfortable with that thought or did you do anything about it?
Marian Kamenistak: Well, of course there were some sort of initiatives that, you know, I made live. Openly speaking, I started my first 3 months doing some sort of an internal audit, meaning like, you know, making sure that I understand, you know, the foundation, I understand the product, I understand, you know, when it comes to the teams, to their productivity and, you know, all the different aspects of that, including leadership, of course. And, the second thing is, you know, after the audit, it was pretty clear to me what are the main, you know, most valuable items or initiatives that I should be focused on.
To be more specific, I started observing the teams, the way that I attended their different ceremonies. I was working closely with the product engineering site. One of the issues was, you know, again, openly speaking, the cooperation between engineering and the product as such. And the second issue we were facing was transparency, meaning we wanted to make sure that, engineering, product are both transparent enough in terms of knowing where we are when it comes to sort to, to ongoing initiatives, where we are when it comes to the backlog, and what awaits us. So basically, the purpose of that was to lower down the communication gap. And, once again, the transparency was, is one of my principles that I’m sticking to quite well. That being said, I moved from, you know, spreading the gossips and the hypothesis about the gut feelings to the system that really worked through data. And seeing how things work for us, by, inspecting certain things in reports, basically. I know it doesn’t sound very attractive. But, leading more than a dozen of different engineering teams, you don’t have a much of a choice, because that would go to micromanaging the teams, which is not the right path to go, especially in case you want to scale the teams, right? And give them the ownership. Yeah.
So basically, coming back to your question, I would say ‘transparency’ is the keyword we are looking for. Yeah.
Kovid Batra: Hmm. That totally makes sense.
Great! Thanks for sharing this. Moving on to my next question, which is kind of related to this, when you talk about transparency and not micromanaging right? I have seen different teams, different type of leaders, like ones who are purely data-driven, right? Then, there are teams where leaders are purely, like intuition-based. There are 40 developers working, but they are working on purely the intuition. What’s the productivity? What’s the output? How things are moving? So, people are very intuition-driven. And, I’m not saying that it’s wrong or right, but every situation demands a different balance of both. That’s what I believe. What’s your take on that? Like, you must have seen teams in the similar manner as I have seen. Some are data-driven, some are purely intuition-driven, some have a balance of both, right? So, what’s your take on that? I just wanted to hear it from you.
Marian Kamenistak: Yeah. Well, of course, it all depends. It depends on, you know, what’s the current stage of the company, whether that’s an early startup, the scale-up, or I would say, up to a corporate, you know. The second thing is whether, you know, the company as such is working on projects or products, if you know what I mean, right? That’s a, that’s a huge difference. The other differentiator might be whether the company is a stage of, you know, sales-led vs product-led growth…
Kovid Batra: Yeah.
Marian Kamenistak: And, you know, strategy; that’s by the way, really important because when you are sales-led, then you need some sort of a lead who’s, you know, giving you the direction and who’s sort of almost micromanaging things, which might be the right thing to do at the given time. Nevertheless, if you want to scale, then you should be slightly starting to move towards the product-led organization, right? What I was going to say, there are different aspects that, that might influence our decision process, how much I’m going to lean towards, you know, the gut feeling and empathy vs data. Nevertheless, my message would be, if you are running more than 8 different teams, or I would say 6-8 different teams, then it might be the right time to verify your hypothesis and help the teams with the productivity through the data-driven approach, right? And that was really my path. And, again, I stick firmly with my principles, transparency, and providing this sort of, you know, transparent reports with valid indicators, of course, is, in my case, the right way to go. And it always, sorry to use this word, it, it always saved my ass, right? So, that’s, that’s how I see it, right?
On the other hand, when we have, you know, gut-feeling teams, if we may put it this way, what I see often, there is a big proportion of inertia and a big proportion of complaints and sort of inability to make the right decisions. To be very specific, what I mean is that, for example, if an agile coach tells me, you know, “We have an issue with a specific, let’s say, with velocity, with estimate or with, uh, the quality of the product or with the deployment frequency, or with the confidence when it comes to the sprints completion.”, then, it’s not only to have this gut feeling, but also to look into the data, because since the moment I’m showing some sort of trends based on the figures, then people start to listen to my arguments, as opposed to say, “Okay, that’s yet another hypothesis, and we heard already hundreds of similar hypothesis. So, thank you for sharing your opinion and let’s move on to the next topic.” Right? So, that’s not something that is really helpful. And, the way, for example, how I’m treating data is that, for example, I’m very specific when it comes to fixing or improving the teams. What I mean to say, for example, I want to, I’m really tying improvements to specific measures and here I may say, for example, when it comes to the sprint completion to me, the healthy consideration of the team is I want to see that the teams deliver, minimum 80% of the sprints, right? When it comes to the roadmap contribution, I expect that the teams deliver or spend minimum 60%, for example, generally speaking on the product roadmap, right? So there are different, let’s say thresholds or metrics that I’m using just for the sake of making sure that the team is considered highly-performing and healthy.
And here I want to make some, some sort of a side note, which is often I see that, you know, each and every manager or, you know, owner of the company wants to have highly-performing teams. You can have these sort of teams, but when you are throwing junk into the teams, then you get the junk out of the team, right? So, it’s not only about having the highly-performing teams, it’s also really important to know what I’m asking these teams to accomplish, what’s under their plate, what are the main initiatives and whether these initiatives are the most valuable things that these teams can do as opposed to doing something that goes to the shelf and not being touched by the customer, right? So, that’s something that I see being neglected sometimes, yeah, a bit often than I would wish.
Kovid Batra: I think I personally have felt this that this seems very right with scaling. You have to have this kind of a mindset. You have to bring in that transparency. You have to be little data-driven, in fact, not little, little more data-driven than you think you should be. But, even though it seems right, and most of the engineering leaders I feel are very intelligent, they are well-aware of the situation and they know that this is probably the right thing to do. But why do you think there is a restriction or there is an apprehension towards not adopting such frameworks? I might be wrong here. This might be an assumption, but I talked to a lot of them, but there is some level of apprehension I feel in the engineering leaders usually that they don’t move towards this. What do you think could be the reason here?
Marian Kamenistak: Well, you know, I had a luxury to implement or to help with, with the advisory, implementing, you know, this sort of data-driven approach checks when it comes to the teams in a couple of different companies. Most of the time, this sort of, you know, pushback or rejections comes from the fact that you know, we don’t want to treat our people as numbers, if you know what I mean? So usually that’s the number one thing that I’m hearing. And the second thing is that, you know, data is just part of the song, you know, part of the story, which is absolutely right. And, here the important distinction is, we were talking previously, you know about extremes, which is, you know, either you have the gut feeling based teams or the data-driven teams, of course, the combination of both is the, you know, that’s the biggest “wow factor” that you can obtain. Speaking very openly, you know, I treat these numbers not as goals, but rather as aspirations or indicators. That’s the right word in my opinion, because you know, to be very specific, you might be having a person with the high amount of pull requests or opposites to that. And you might be saying like, you know, “This is the right developer.” Opposite to that, you might be a person, you might have a person with the very low to zero number of pull requests. But, it doesn’t mean that that person is low-performing because instead of you know, individually contributing to the code, he, he might be doing mentoring and code-pairing and doing some more programming, which has a much higher aspect…
Kovid Batra: Absolutely.
Marian Kamenistak: …you know, impact compared to the metrics that we are using. So, there has to be always some reasoning why and some connotation. So, yeah, the thing is that, you know, we shouldn’t be using these numbers, some definitive metrics whether the team is highly-performing or not. There is always some sort of context into that that has to be added there. Yeah.
Kovid Batra: Right, right. Perfect! I think well-answered there. I get your point.
Cool. Let’s move on to something more interesting here.
Marian Kamenistak: Okay.
Kovid Batra: There are different, different metrics, which each team has to look at different scenarios, right? Like when, when you talk about, like cycle time, how many lines of code somebody has written or how many commits somebody has done. There are different metrics that you can look at. I mean, there are 20s of them.
Marian Kamenistak: Yeah.
Kovid Batra: Prominent framework is around DORA and SPACE, but let’s say if we are choosing to work on something in a team, there are a few metrics that one should look at, right? So, how do you choose those metrics? How do you choose which ones to really look at?
Marian Kamenistak: Okay. Okay. Yeah. Exactly as you are saying, Kovid, the basket from which we can choose is pretty broad.
Kovid Batra: Yeah.
Marian Kamenistak: Here, we speak about dozens to almost a 100 of different indicators that we might find useful. You know, before I start diving into specifics, let’s uncover some of the principles that I’m trying to stick to before, before advising specific indicators to which to lean to, right? So, to me, the number one thing is that, you know, as I was saying, these numbers are just indicators. So, it shouldn’t be tied to some sort of any performance reviews or efficiency of the teams and these sort of things, because it’s dangerous. The people will game it anyway, right? If you put it like this, right? So, it shouldn’t be tied to any bonuses or compensation metrics or whatever, that’s a way to help basically.
The second thing that, and I’m pretty radical here, is that I don’t want to see the data being used for the purpose of measuring the efficiency of an individual as a developer, right? So, you know to me, the lowest granularity that I’m looking at is the team itself, right? You know, since the moment you are starting to look into individuals, it’s a dangerous game. Of course, we might be having some underperformer in the team. That usually, that’s what I’m hearing as an excuse why to have it. But in that case, I would rather see the team to deal with that situation on their own, as opposed to teaching them to wait until a manager comes and makes the resolution. So, to me the notion of, you know, self-healing teams is something that is really important. Of course, I might be having a look into specific data about some individual, but I would still be very strict in making sure that it is the team itself that makes that ultimate decision, without using the data, right? Because to be honest, people already in the team know who’s sort of performing, not performing very well and so on and so forth, right? So, that’s the second thing.
So, again, looking at the efficiency or productivity metrics from the perspective of the whole department, the divisions, tribes, chapters, however we call it, up to specific teams, that’s absolutely fine. But, I would be strictly against using it for individuals, on the individual-level, right? The one thing that I learned is that we shouldn’t be diving too deep into, you know, how the sprints work, what’s on the plate, what’s the velocity of the teams, and so on and so forth, because usually it’s, you know, either it’s counter- intuitive, but it’s not as important as, for example, how big of a focus the teams can have and handle, or how much of importance the initiatives that we are throwing to the teams are, right? So, basically it’s more about making sure that the discovery process works right, first and foremost, and only then we can have a look into, you know, the efficiency of the teams. So usually the story is like, you know, a company’s inviting me to do some internal audit, and saying openly, “My teams are not working very well. I don’t have trust in my teams. Please have a look.” Usually, you know, doing the deep dive in the teams, the teams themselves, usually they work pretty well. And of course, we can fine-tune some of the things and increase their efficiency by, I would say 10-15%, right? Might be to 30%, which is quite ambitious already. But, the gem lies somewhere else. And it’s about the discovery, what we are throwing into the teams, what’s on their plate.
And the second thing which I learned is to create synergies. Being more specific, it’s more about synergies between the, for example, an Engineering Manager of a team and their Product Manager. If you create a synergy and the fit and the chemistry between the two, then all of a sudden, your productivity might get increased by 300%. So, that’s yet another message, not looking too much into the data and creating the synergy between and the chemistry. That’s what’s really, like boosting the efficiency like hell. Yeah.
So, being more specific, usually what I would advise is first and foremost, making sure that we are working on the right things, meaning, seeing what’s the, for example, the adoption rate. That’s how I call it. That being said, I want to see that most of the releases and the features that we offer are well-accepted by the final customer, right? So, what’s their satisfaction? And I want to see that, for example, we are working that I would say about 65% adoption rate. That being said, of course, we can’t ask for a 100% because that means we don’t allow any mistakes and no psychological safety. And basically we end up copying the work of the competitors, which is a nightmare to do, right?
Kovid Batra: Right.
Marian Kamenistak: So, that is one thing. The second thing is, I want to make sure that my teams are working or have enough capacity to work on the things that matter the most, meaning the roadmap. So, I call it a ‘roadmap contribution’. If we have, for example, product engineering teams working on the product, then I expect to have this number around 60-80%, right? That being said, most of the time I want to see my teams working on the product roadmap, right? We might have some technical roadmap, or usually people are forgetting about the off-roadmap items, which is business as usual. And usually you would be surprised if you start measuring the roadmap contribution, you might find out that some of your teams are spending 55% off-roadmap, right? Which is sort of alarming, right? So, you know where your focus should be. And that’s already a pretty good indicator to start with, right?
Kovid Batra: Right.
Marian Kamenistak: So, the ‘roadmap contribution’ is number one thing. The second thing is, usually what I see is that if you’re on sprints, then we want to fix, for example, the trust towards the teams. That being said, you know, if you’re on sprints, as I was saying, I want to see that we deliver at least 80%, of the sprint, as I was saying before. That’d be, you know, with the number of the tickets in the sprint itself, right? So that’s basically, you know, the amount of the planned tickets vs the amount of the tickets being delivered in the very same sprint with no, move over to the next sprint and again and again, the carryovers, right? So, that’s yet another thing. And, basically this way, the teams are getting trust, and build the trust on their own. And, moving this number from, let’s say 50% to 80% is already a big achievement, right? Again, we don’t want to have a 100% because it’s estimates, it’s not like some sort of commitments, right?
The other thing that I might be saying is sort of exceptional that I’m measuring is, I call it ‘Epic Cycle Time’. So, what I mean here is that usually, you know, Jira and all the tools, they are great at measuring the cycle time on the level of the tasks and these sort of minor things, which are not really important. I want to see that, the epics, the, the milestones and the increments as they are being deployed to the product are deployed on a regular basis, and the deployment frequency is roughly around a month. In my definition or in my view, in my book, the definition of the epic is that the epic should deliver a tangible value to the customer, right? So, it shouldn’t be some sort of some simple user story. It should be something really tangible as an increment. And, I really want to see the teams sticking to deliver on average one epic per month, right? So, we are talking basically about the art of vertical slicing here, to be honest, right? And the reason why it’s important is that usually you don’t want to see the teams that go dark for 3-4 months, then they move to, you know, they go back from, from the dark ages, after a couple of months and they want, they want to, you know, get celebrated because they achieved something very big, but the product manager says it was not what they meant. The stakeholder is sort of angry at seeing, what they produced. Then, there’s a bunch of, uh, endless bunch of bugs for another 3 weeks. We all experienced, you know, this situation and that’s something we want to avoid. We don’t speak about anything unique here. It’s nothing more than the feedback loop and the frequency or, you know, the… the rapidity of the feedback loop. So, we are in the principle of agility. Agility is nothing more than, you know, the speed of the feedback loop, basically. You can forget these hundreds of thousands of books about agility. It’s nothing more than that, right? And this allows the teams to steer and to adjust, you know, stick back to the roadmap basically, right?
So, you know, and of course, we can speak about the DORA metrics, the deployment frequency, change failure rate, and so on and so forth, the usual or the SPACE metrics, that’s already fine. I know I’m speaking for too long. Nevertheless, there is one tiny metric or indicator that I want to add here.
Kovid Batra: Sure.
Marian Kamenistak: And, I was really surprised how greatly it helps. And that’s the, you know, satisfaction, or employee NPS score. Basically, where you are looking at the productivity and, you know, there’s quite a lot of tools that offer you this sort of functionality, where you can measure, you know, what’s the satisfaction of the teams, what’s their cooperation, what’s the mood, what’s the wellness score, what’s the relationship score, relationship when it comes to their peers, to their team or to their manager. And the reason why I’m talking about it is that I was literally surprised how much it has helped me to save some of the teams, as opposed to see the teams rotting and not handling certain situations well.
If I may put a specific story here, is that I might see that in one specific team or specific department, the communication goes down quite rapidly or the relationship score goes down quite rapidly. So, that gives me a hint that, you know, I’m coming to an Engineering Manager and ask him, you know, “If you run the next 1-on-1s, then please ask your teams about this specific thing, and come back to me with, what’s going on.” And most of the time people say how things are, if the culture is good enough and with no intrigues and they are open to share their views. So, you already have certain hints what’s happening in the team and what your action might be, as opposed to not knowing anything about it, people being silent, your team being disassembled while not being aware of that, and you end up by in a situation that you cannot basically save the team, if you know what I mean?
Kovid Batra: Yeah.
Marian Kamenistak: And you need to rebuild, which ends up, you know, running yet another investment for half a year for usually rebuilding that team, right? A couple of months. And you can, when we speak about the budget, we all know that the biggest cost in software companies are developers, right? So, speaking of the cost, that’s a that’s a huge impact here. So basically what I was going to say or point to is that again, that’s the principle of ‘prevention’ here that helps me quite significantly to make sure that we are still on the same spot and, keeping the tendency high when it comes to the performance of the teams.
Yeah, so hopefully that was a pretty deep list of what we can talk about.
Kovid Batra: No, I think that that is much needed. I mean, I can’t say even for a single point that you mentioned that I, I differ in the opinion. In fact, I’m more now concerned and I want to go back to the same question that it seems so important, it looks very important to follow these things, be it your investment distribution, be it tracking your Epic Cycle Time, which was a very interesting piece by the way. Like, people track the PR cycle time or small things. Tracking the time to delivery of the value is something that one should track. Of course, you can break it and then track individual pieces to optimize different pieces. But yeah, it is very important to track that. So, each and every point seems so interesting and so important for an Engineering Leader, or an Engineering Manager, like imbibe in the team from the very beginning itself. I still find that adoption of such things is very hard right now. Like, people struggle to adopt these things. Any, any piece of advice on that? Because right now, when you are talking to teams, you would have also felt that. What exactly do you think you do that people start looking at it as an important thing to do, as a responsibility, or as one important thing one in engineering leadership should be doing?
Marian Kamenistak: Yeah, that’s a really good topic to uncover cause if we don’t run the adoption of these, you know, engineering efficiency metrics, right? Then, then, you know, we are not in a, in a pretty situation. Usually what I’m saying, what I’m advising, you know, the companies, how to adopt these sort of things is that, you know, the numbers is just a third of the story.
Kovid Batra: Yeah.
Marian Kamenistak: Two-thirds are how we treat these numbers and to create the ecosystem around these numbers, right? If you just, you know, throw the reports on the teams and the numbers, it doesn’t provide much of a value, right? So speaking of the adoption here, Kovid, is you know, again, we can start from the way how, you know, to motivate people and, explaining them the reasoning behind it, right? So, what’s our motivation? Why we want to introduce this sort of efficiency indicators and so on and so forth. And basically to articulate and over communicate the message, what’s the reason why? That being said, you know, I’m always, I’m constantly talking about the principle, we don’t want to, you know look at you as a number. That is one number one thing, and the, and the number one worry we have.
Kovid Batra: Yeah.
Marian Kamenistak: And the principles are we want to be transparent and we want to be preventive, right? So, these are the two utmost principles that I’m looking for, and I’m telling them and explaining that to the teams and to people via using stories. What happened to me when I had no luxury of looking into specific data, right?
Kovid Batra: Right.
Marian Kamenistak: So, that is number one thing. The second thing is that, of course, these things shouldn’t be just run top-down. It should be run, from the very beginning with some sort of a tighter team around and making sure that you choose the right people and you invite them to run these conversations bottom-up, right? So, you can start with specific Engineering Managers, Engineering Directors, Tribe Leaders, Chapter Leaders, whatever you have. And there are people who are actually interested in being better leaders and they are usually the people who raise their hands up and sign up for that, right? So, having these people on board from early-on stage, that’s really vital because if you just throw it to them top-down, it doesn’t help very well, right? So, these are the two, I would say most important things and of course, there has to be some, I would say, activation and adoption period. The activation is, you know, how you start running it. And the second thing, the adoption itself is, it’s not just about, you know, “Here are the reports, and uh, please deal with it.” It’s mostly about, “Let’s run some sort of a continuous workshop about what these numbers mean, what are the situations where they can help you actually identify certain, you know, inefficiency, potential factors, right?
And, also giving them, the ability to provide some sort of a feedback. And say, for example, “This specific indicator doesn’t make sense.” or, “We don’t measure it well.” Because, for example, being very specific, the deployment frequency might be measured in, you know, different ways, or the cycle time might be defined in a different way depending on what stages in the cycle we are considering or not.
So, these are all the different things that we might be able to consider, you know. A good example of that is, again, talking about the cycle time, I wouldn’t punish the teams in the B2B sector, for example, of course, because their cycle time might be too long and up to the deployment. So, there is always a question whether, you know, to include the deployment phase into the cycle time or not, because if you are deploying just to, you know, in the B2B world, once per half a year, then obviously, you know, this sort of metric doesn’t make sense for you, right? So that’s, that’s one, just one of the examples, right?
And, talking about the adoption itself, I would say the most important thing that I found out also was to make sure that you provide some guidelines in a written way into your knowledge base about what specific numbersmean, why we are measuring those, including some How-to guidelines, meaning like, “What are the thresholds?” And if you are in red numbers, what might be the right things to start in to look at, you know. Your focus might be totally broken or you are running too many initiatives in parallel at the same time, or you are having too many ad-hocs, you know, disturbing your sprint. So, let’s start measuring these, or you know, these sort of How-to manuals. They’re really great because from that moment on people can point their finger on to what’s the definition of that measure, without again, trying to be smart and, every person has a different, you know, explanation of how these things are measured.
So again, having specific formulas, the motivation, what’s next or what’s right for us and some sort of How-to manuals, that’s really helpful, right? And the last thing to say, part of these manuals or these guidelines, there should be some sort of the, as I was saying, the ecosystem around. That being said, for example, I want to make sure that an Engineering Manager as a first-level manager-person is responsible for these specific metrics and should be looking on these metrics, let’s say on bi-weekly basis. The Director or the VP-person should be looking on another metrics on department-level, I would say once per month or something similar to that. And, making these sort of measures part of your daily routine, that’s really important. And, ensuring that we are talking about these numbers on our dailies, on our 1-on-1s, just checking whether the health check is fine or not. And eventually trying to, basically distill some situation and you know, moving the teams back on track when some of the indicators might be not showing the best performance ever in the team. Right.
So, these are just a couple of things that, I’m really paying attention to when it comes to the adoption itself and, as opposed just to throwing the numbers on the teams and, “Please deal with that”, it never works. It never works. Yeah.
Kovid Batra: Yeah.
Marian Kamenistak: So I hope that makes sense.
Kovid Batra: Perfect! I think I couldn’t have asked for more. One of the most interesting sessions for me personally. To learn from you and see how things being done. Ggreat, man! I think I would love to have you one more time on the show talking about specific use cases where we can spread more knowledge around these topics to our audience. I think that would be really interesting.
Marian Kamenistak: Yeah, yeah. Thank you. Thank you, Kovid. And, it was a pleasure to have you. So, enjoy. Bye!
In the latest episode of ‘Beyond the Code’, Host Kovid Batra engages in a thought-provoking discussion with Eric Bowman, Chief Technology Officer at TomTom. He is also an advisory Board Member at reputed companies such as Banxware, momox GmbH, and Tradler. The heart of their conversation revolves around leading the way as a CTO.
The podcast begins with a fun fireside chat with Eric, allowing the audience to see his candid side. Later in the main section, he delves into the obstacles faced in his engineering journey and shares strategies for overcoming them. Eric also delves into the 'Team Topologies' approach, a valuable framework for improving team interactions.
Lastly, Eric sheds light on crucial aspects such as developer productivity, well-being, and the holistic optimization of software delivery.
Kovid Batra: Hi everyone! This is Kovid, back with another episode of ‘Beyond the Code’ by Typo. And today, we have an amazing guest. He has 25 years of experience in engineering. He started as a software engineer, moved to a CTO. Right now, he’s serving as a CTO for TomTom, which is providing geolocation services to big companies like Google, Uber, everyone. The journey has been long and exciting, and today, we are honored to have you here. Welcome to the show, Eric.
Eric Bowman: Thank you, Kovid! It’s great to be here. Thanks for having me.
Kovid Batra: Great, great. So, Eric, on the show, whosoever comes, there is a quick fireside chat that we have here to know you more personally, okay? Nothing related to work, but to know you more personally. So, there will be 3-4 questions. Are you ready for that?
Eric Bowman: Yeah!
Kovid Batra: Great, Eric. So I’ll start with my first question. So, that’s related to book reading. Which one is the last book you read and how do you like it?
Eric Bowman: Yeah, that’s a great question! I do, uh, I read a lot actually. The last book I read is called ‘Right Kind of Wrong’ by Amy Edmondson who teaches Leadership at Harvard. She’s quite famous for pushing the ideas around psychological safety. And, ‘Right Kind of Wrong’ is really about how to fail in a productive way. And so, you know, obviously there are certain kinds of failures that are not good, but also, it’s well understood that you have to try things and see them fail and learn from the failure in order to keep making progress. And, it’s actually a superb book. She’s an amazing thinker and writer, and I very much enjoyed that. I don’t read a lot of fiction. I kind of go in and out of reading fiction, but I recently read a book called ‘Afterlives’, by a guy named Gurnah. He won the Nobel Prize in literature in 2021. And, it’s a wonderful book and actually, you know, it reminded me that it’s important to also read enough fiction. Fiction really helps you build empathy for people. And, those are the kind of the two most recent things I’ve read.
Kovid Batra: I think that’s perfect. And from both the books, what I feel, your motivation seems to be more being empathetic and compassionate towards people. Like, that’s what you’re learning from the psychological safety that you need to build an organization. And from fiction also, you highlighted, like, to build more empathy. I think that’s really great. Thanks for both of the suggestions.
Let’s move on to the next question. So, talking about failures and then rising from there, doing good failures, where do you get this motivation? Like, it’s been 25 years into this career and I see that energy, you’re still reading books like those. So, like, from where do you get the motivation to go off to work every day?
Eric Bowman: Yeah. yeah, so motivation is an interesting topic and motivation is often compared to discipline. And some people will say that, you know, “Motivation comes and goes, and so you really need the discipline.” And other people will say, “Discipline is hard to maintain, and so you really need the motivation.” And I find myself going back and forth a little bit between the two. I think, you know, having a certain amount of discipline is absolutely essential, both personally and also professionally, but discipline is not enough. Finding the motivation is where the real drive comes from. And, you know, I think for me… and also for the people that I try to look for to work with, an underlying curiosity is one of the key things that really drives the motivation side. So, curious to understand, you know, “What are like, what are our customers problems really?” And you know, sometimes they tell you one thing and you have to dig through and find out that it’s something else. But being like naturally curious about technology problems, about people problems and organizational challenges. For me, I think that’s a big part of where that motivation comes from. And then ultimately, as I transitioned from being a software engineer into an engineering manager, really, and also getting more involved in the product side, you know, I’m seeing both myself and the team confront challenge, and the struggle of that, and then overcoming that. And, you know, especially as a group, like the idea of having shared goals and supporting each other. I get a lot of, I get more motivation from that than when I was younger, I thought that I would. Like it is, you know, it’s not necessarily about having it’s not fun every day. But, it can be meaningful every day. And that “finding the meaningful” part really comes from having innate curiosity, and then the discipline to really execute and just consistently make progress, constant progress.
Kovid Batra: Totally makes sense. You’ve already started inspiring me already.
Great! Moving to the next question. So, this is related to, like unwinding.
Eric Bowman: Yeah.
Kovid Batra: I hope you like music? I think everyone…
Eric Bowman: Love music!
Kovid Batra: So, which one’s your favorite band? What type of music you like? Something around that.
Eric Bowman: Yeah, that’s a tough one. I listen to a lot of different music. And when I was younger, I was kind of a superfan of certain bands. I listen to a range. I actually love jazz. I love kind of 50s and 60s bebop and I actually like some 70s kind of fusion jazz. I actually listen to quite a bit of classical as well. My wife is Irish and I’ve really gained an appreciation for 80s and 90s kind of Irish and British pop. I go in and out with a band called the ‘Grateful Dead’, which started in the 1960s. Actually, I love reggae. I love dubstep as well. You know, some music is useful for unwinding and some music is useful for focus. And I have a, yeah, quite a deep relationship with music.
Kovid Batra: Perfect. Perfect. That was really nice. And it was good to know you!
Moving on to the main section now. I think the audience is really, really looking forward to this. And, ‘how to lead as a CTO’ is something we are here to learn from you. So, I’ll ask a few questions. And to start with, like I want to start with something that is really, really interesting, which would be closer to you.
Any of the experience where you faced a real challenge in your engineering career? And, how did that challenge come up? How you tackled it? How did you overcome it? Just an open thought, open discussion around that. So, yeah, I think we’ll start with that first.
Eric Bowman: Sure! Yeah, there’ve been a few. If I reflect on kind of recent experience, I think one of the big challenges that I faced over the last couple of years is really around, in an environment where there are significant customer commitments and momentum against kind of a legacy technology solution, and a clear commercial desire to kind of shift into a more product-led approach in an environment where the customers are not necessarily open to that has been quite a remarkable challenge that I’ve faced recently. And it really was kind of a holistic change problem that also very much depended on external forces. What that kind of looks like is, you know, in an environment where you end up making multiple parallel customer commitments, there is a need for quite intense planning and execution. And, there’s not appetite on the customer side for much uncertainty.
But on the other hand, you know, and kind of going back to the work of Amy Edmondson and modern product management, you need a way to be able to perform experiments, to have hypotheses, to try things, to ship value and then understand at least your, what you think is value and then understand you. Your customers really like that. And, for me, it was, it’s been a remarkably satisfying and challenging exercise to figure out how to navigate that with a fairly large team, several 100 engineers, a large legacy code base and quite a modern view of what we would like the software to be and what it has to be for, in some cases for commitments that were made some years before. And, you know, one of the nice things is that a lot of the basic ideas of, say modern product management really work, you know, but it does require both the discipline and the motivation to make them happen. And, I think one of the things that’s been most satisfying for me is seeing how very high-functioning, high-performing team when they kind of understand the goal and there’s a shared North Star, and a kind of a clear vision that we’re working toward, how much that can bring out the creativity of that team to find real solutions to some of the very pragmatic problems that we faced.
And, you know, I have one moment in particular where an engineer kind of found a way to thread a certain needle where we could satisfy a customer, and make a significant pivot to a much more modern product that would be much more appropriate for multiple markets. When I was a software engineer, I loved having those moments. I liked to be that person. But, actually creating the environment where others could do that, and seeing them do that, very, very satisfying. And I’m really looking forward to this product coming out later this year.
Kovid Batra: I think I would want to know more on this. Like, broadly you told us, like there are multiple challenges and you have to do it, and then you get satisfied. Getting the team onboarded on the shared goals and getting them to deliver, being creative, everything. But, can you share one incident, one particular piece, so that our audience actually relates to what they are also doing in their organizations, maybe?
Eric Bowman: Yeah, let’s see. Well, yeah, maybe we can look at some more approachable examples. It’s a bit of a large-scale example. I think one of the challenges that I also faced not too long ago was coming into a situation where a bunch of online services were really not set up for high availability.
Kovid Batra: Okay.
Eric Bowman: And again, there was a fair amount of legacy involved, but there was a missing mindset around, I think you would call it ‘learning through failure’. And you know, the change that I introduced there was to say, “Hey, you know, there’s it has to be absolutely clear that the highest priority for everyone, if there is a some kind of customer incident, has to be not only obviously restoring service as quickly as possible, but also going through the work after that to really understand, “How did this happen?”, “What do we need to change to avoid this happening again?”, and then, doing that work. And, you know, with a fairly large team, that’s kind of a big change effort. But, what I found is that there were certain people throughout the organization who were really open to that, and they could immediately understand the importance of it. Not everyone at the same moment, but enough that we were able to get kind of a critical mass of people supporting and carrying this idea forward, and the change in mindset, because you know, like people are pretty rational in certain ways at the end of the day, but they also have a lot of constraints in their whole life, not just at work. You know, people have things happening at home and personal life, and they’re balancing their energy between these and, and it is a balancing act. And very often, especially if things are if there’s pressure at work, you know, people just want to go faster, get through it. But that’s not how people do their best work. So, really helping people understand the importance of ‘it’s not just about what we are doing today, we have to always be working toward the future’, and that means constantly working to understand, “How will this system behave?” “What don’t we know?” And, “What do we need to know?” And then really creating the incentives and the framework to say, “Hey, when something goes wrong, we really do need to know. And, sometimes you don’t know how long that’s going to take. And it may take a while, but we’re kind of in this for the long haul, and we have to make this investment now.” For me, kind of seeing the difference between that really were sort of two kinds of engineers in that case – some people who totally got it, welcomed it, loved the critical thinking and the clear exposition, and others who really felt that like, “Ah, you know, It’s all okay. It’ll be fine.” You know? And finding that first group and then really kind of empowering them and helping them.
Kovid Batra: Yeah.
Eric Bowman: And you know, I think…
Kovid Batra: Putting them as a benchmark maybe…
Eric Bowman: Yeah, exactly!
Kovid Batra: ..for the other people to look at, yeah?
Eric Bowman: And, sort of changing the mindset of people to understand that actually, you know, making the system more resilient, making sure that governance is covered and making sure that, you know, our ways of working, that how the software is built and deployed and monitored, and how’s the feedback, all of that. That’s actually very often what the most senior people should be working on.
Kovid Batra: Yeah.
Eric Bowman: Particularly, if that’s not under control in the sense that, you know, there’s always some variation, but it needs to be kind of bounded. If it’s not understood what those bounds are, and it’s not well-automated, well-understood, that has to be the priority. Otherwise, you cannot create value on top of it. And so, I think my advice, you know, for more junior software engineers is, always make sure that you understand that that is a huge part of the job. It’s not only about, ‘Oh, I’m working on kind of business logic or just trying to work through features or always trying to build things.’ The deeper problem of understanding the system and improving the system for the benefit of everyone is one of the most high-value things that a software engineer can do, and not all performance models, say, recognize that sufficiently.
Kovid Batra: Makes sense. Makes sense. I think putting the right incentives and the framework, and of course, hiring also helps. But yeah, that’s a great piece of advice, and thanks for sharing your thoughts, Eric.
Eric Bowman: My pleasure.
Kovid Batra: I think while we’re touching the topic of solving these problems at scale, I think ‘Team Topology’ is another topic which I’m really interested to hear from you.
Eric Bowman: Yeah!
Kovid Batra: Like, how do they play an important role in achieving your goals, right?
Eric Bowman: Yeah.
Kovid Batra: So, please share some examples.
Eric Bowman: Yeah, so, you know, ‘Team Topologies’ is a book that came out a couple of years ago and it’s really an excellent piece of work. And, very applicable, and you know, there’s a thing called ‘Conway’s Law’, which has been around for probably around 50 years, which is sort of the observation that organizations that build software, very often the architecture of that software models the communication networks within companies. And you know, when people say, “You end up building the org structure”, that’s kind of what they mean. And it is a real consequence of the system dynamics of development. And it reminds me a little bit, like there’s a thing in physics where if you go into a clock shop and there’s a bunch of clocks on the wall, it turns out all the pendula are perfectly synchronized, and you know, it’s a surprising thing to witness, and that happens through very subtle interactions in the way energy moves through the wall. Like, it is achieving a low energy state and you can mess them all up, and over the course of a couple of days, they will return to perfect synchronization.
Kovid Batra: Synchronization, yes.
Eric Bowman: And Conway’s law is a little bit the same, that even though, I mean, you can fight it for a while, but ultimately those system dynamics will win. And ‘Team Topologies’ is kind of a set of heuristics that leverages Conway’s law, as well as, you know, kind of what has been shown to work, that gives an organizational designer a set of design patterns to apply. And, it’s not necessarily a universal toolkit, but for the kind of companies that many of the people probably listening, it very likely does make some sense. And, it is essentially taking advantage. This is my view of it. The authors might disagree a little bit, but you know, taking advantage of Conway’s law and the importance in the modern age and what is enabled through technology to deliver value to customers sooner. And, it gives you kind of a toolkit for how to set up organizations that can do that. And, we applied that quite successfully, I think at TomTom, where we had kind of two large organizations, one working on SDK & services and one working on map. And, they were somewhat separated for quite a long time as the map company was an acquisition. And, we took our first steps into creating a single org by setting up the value streams, from map data all the way through the online services, to the SDK. We have a new, significant new map product coming out very soon. And, understanding how well that map was working with our services and SDKs was incredibly important to, essentially ensuring that the product is great. And the way the business had worked in the past, that was not a natural organizational pattern that was in place. And, so we implemented that. And I think, you know, one of the key takeaways from the book, and then my experience with those ideas is that the need for collaboration is a tricky thing because it’s very common in companies I’ve worked out in the past at least, that the idea that ‘we got to collaborate’ is sort of a universal good. And, it is true that when collaboration is needed, it has to go well. But, collaboration also comes at a cost. The need to collaborate requires energy, you know, which software engineers are balancing across a number of things. And, the whole point of many organizational structures is to combine people who are working on related things, so that they can create “synergy” between them. And, if you have to collaborate to do anything, it’s hard to go fast.
And so, one of the things that I very much like about the ‘Team Topologies’ approach is that it provides some heuristics for how to identify where is collaboration between teams important and worth it, and where, you know, is it better. Maybe a team, you know, has automation and kind of, what acts as a service. So, the direct collaboration between is not necessary. So, an infrastructure team providing cloud infrastructure, for example, if they have to directly collaborate with several 100 teams in the company for those teams to take advantage of the service they’re supplying, it’s incredibly expensive. It might be sort of fun and some good things about it, but it’s not worth it. Whereas, closer to the customer, and where you really want to kind of innovate and where you are really working to solve customer problems, you want to be able to rapidly work end-to-end, there that collaboration is almost certainly worth it. But again, it is expensive. And so, you need to be deliberate about where you expect teams to work that way and where that innovation is most needed. And I think it’s quite a refreshing view prior to that work. You know we all had, I think a much more simplified and less effective view of how to organize, really to deliver value sooner with as much automation as you can, kind of maximizing innovation. So it’s a very, very nice work.
Kovid Batra: Perfect! I think that was a great summary of what we can learn from the book. I think that’s a good recommendation too.
All right. I think I have one more question in my mind. When we are talking about the advice to the software developers, to the aspiring engineering managers, engineering leaders, one important thing is bringing a data-driven, plus an empathetic mindset to the way they are trying to improve their software delivery, trying to improve their teams, right?
Eric Bowman: Yeah.
Kovid Batra: And there has been a recent article by McKinsey which is trending right now about developer productivity. So, I just wanted to know your thoughts on that. How you have implemented such KPIs and metrics, like DORA in your team? And how to actually implement it at scale? How you’re looking at developer well-being? All this combined. It’s a big, big question, but yeah, I just want to know how you have done it at your organization, and what’s your thought on developer productivity, well-being and overall optimization of software delivery, yeah.
Eric Bowman: Yeah, the McKinsey piece created quite a bit of noise and some of the responses to it are quite excellent. And so I, I don’t think I can improve too much on that, but it is a fascinating, I think symptom of very often what is the challenge between a CTO and a tech team, and the more commercial side of the business. And you know, the McKinsey article is definitely, I think the target audience is more on the CEO side. And I think the criticism of that article reflects how industry-wide it is a challenge for CTOs and CEOs to really find a good way to work together, because ultimately in a modern tech company, the technology part needs to be everywhere and CEOs need to be pretty CTO-like in many of these companies. But, the bigger, the bigger question is very interesting and something that’s, that’s occupied a lot of my professional life in different forms, you know. The DORA KPIs became kind of widely-known with the publishing of the book ‘Accelerate’, I think in 2018. And, for a lot of people who had been working more or less in that way, whether we called it DevOps or not, found some version of that that made intuitive sense. And it was like a bomb going off in a positive way to have that research published and made accessible. And, it reaffirmed some kind of beliefs with a bit of science.
For those of you who don’t know, the DORA KPIs emerged from the research of Nicole Forsgren and others. And it’s basically four KPIs around a team’s productivity, which is essentially how frequently they commit code and how long it takes that code to get into production, how long it takes to restore service in the case of an outage, and how frequently code that gets deployed has to be rolled back or rapidly rolled forward. And, you know, the research demonstrated essentially, I guess it’s fair to say, a weak form of causality or a strong, very strong form of correlation between, kind of excellent DORA KPIs and business success, business health, cultural health. And it’s a very compelling research. It’s like, if you can actually move these KPIs, there is a causal connection, it appears, between the success of your company. Now, how you move them though is left a little bit as an exercise for the reader. And, you know, for people building online services, it’s kind of easy. When you’re building software for automotive, for example, where there is no way to deliver value, it’s a significantly harder, challenge. But of course, one can invent ways around that. And now a few years later, there’s a lot of tooling to help and there’s emerging best practices. There are, you know, common patterns that tools like typo, I think help with.
So the way, you know, you can think about productivity, kind of at a company-level, at a team-level, and at an individual-level. And, DORA is sort of focused on the team-level and then, Dr. Forsgren and others have now worked with the SPACE methodology to really look at individual productivity. And then, there’s still this open question of organizational productivity. But what all of these things have to a certain degree in common is this idea that flow is pretty hard to achieve. And, you know, you’ll find me frequently saying sooner “We want to deliver value sooner, and not faster.” And there’s a few reasons for that. When people are asked to go fast, they frequently make mistakes. But also by focusing on “sooner”, that’s where we find, you know, if like one team does some work and then they hand off to another team, which DevOps, you know, tried to remove that gap, but in a larger organization, there’s always handoffs. You can’t “everything” ops. And it’s those handoffs that end up eating most of the time. And so kind of with SPACE and DevEx, you know, this idea of fast feedback and flow and reducing cognitive load. And that helps people keep moving in the very small. And that like, once you get on a, sort of an intellectual path as a developer, you want to continue, you stay engaged and that allows you to kind of go farther through the sequence of small steps. And similarly with DORA, it’s a similar case, you know. It’s all about, “What is the delay?” If you’re releasing code in sort of small increments and then very quickly going to production, when something goes wrong, you very quickly consolidate it, reducing those delays. Those delays add up over time. And there, time is the only resource which is completely irreplaceable. Once it’s gone, it’s gone. And going faster then is like about, you know, you end up shortening the work times, but the wait times stay the same. This is all about closing the wait times.
Organizationally, then, you know, above DORA, there’s still an unexplored area. Although there, I mean, there are tools and there’s thinking around this, and Lean looks a lot at this, but the tooling is not great. And, the mindset is not there very often for people to really understand, “Where are those delays happening?” And honestly, things, you know, methodologies like scrum really exacerbate the problem. The idea of a backlog introduces delay, it builds it in. And, you know, one of the reasons why, I believe we see kind of a move away from scrum is it’s just not Agile enough. Sometimes, we need to be able to interrupt a team and say, “Hey, there’s a bigger thing going on, kind of in, in the business and we have to do this.” And that’s why Kanban, I think makes more sense, that it doesn’t build in delay. It’s more flexible around delay. And also, the nature of Kanban is on a much stronger, analytical foundation, that you’re able to apply Little’s law, and really understand bigger system behavior.
So, these three things combined, I think, you know, for anybody who’s trying to improve the value creation, which is, I guess, you know, ultimately why we want people to be productive, should really be looking at the individual-level, the team-level and the organizational-level, and always focusing on, “How can we identify where those delays are happening, and where value doesn’t keep flowing?”. And of course, there’s a lot to learn from the Toyota system. And you know, there’s a lot of thinking in the world around this, but it’s still maturing in software engineering. But very interesting moment, and a lot of opportunity, I think, for good toolings.
Kovid Batra: Perfect! Eric, that was really, really amazing. I think this is one of the best podcasts I have personally ever had. I would love to discuss even more topics that I get to hear from my customers, and in day-to-day, I’m meeting so many engineering leaders. So, I would definitely want you to come back to the show sometime.
Eric Bowman: Hey! My pleasure, Kovid.
Kovid Batra: All right, Eric. That’s all for today. Thanks for your time. It was a pleasure.
Eric Bowman: Thank you.
In the recent episode of ‘Beyond the Code’, host Kovid Batra welcomes Anton Zaides, who is currently a development team lead at Taranis and has previously contributed his expertise to Mamram and Golden Zebra Software Inc. Their core discussion primarily revolves around effective strategies for leading development teams.
The podcast starts with a fun fireside chat with Anton, where the audience gets to know his unfiltered personality. Moving forward, he delves into the obstacles faced as a Dev team lead and details the strategies for overcoming them. Further, Anton shares insights into the approaches and methods for delivering high-quality commits on schedule.
Wrapping up, Anton sheds light on transitioning from an individual contributor (IC) to a team lead, a phase that proves to be a significant challenge for many individuals in the field.
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.
In the recent episode of ‘Beyond the Code’, host Kovid Batra welcomes Tobias Mende, founder of Unblocked Engineering and author of ‘DevEx Nuggets’ newsletter. He has previously contributed his expertise to PayOne and Drager. The central theme of the discussion revolves around elevating developer experience and driving continuous performance
The episode kickstarts with a fun fireside chat with Tobias, providing a delightful glimpse into his genuine and unfiltered personality. Moving forward, he shares the obstacles faced in his engineering journey and how he successfully overcame them.
Tobias delves deeper into proven strategies for identifying and eliminating bottlenecks in the development process to enhance the developer experience, while effectively communicating their impact in terms of business value.
Wrapping up, Tobias imparts a valuable perspective on fostering a team culture that places continuous improvement and the pursuit of excellence at its core.
Kovid Batra: Hi everyone. This is Kovid, your host at ‘Beyond the Code’ by Typo. Today on our show, we have a special guest who is really adventurous and interesting, Tobias. He’s a founder of a DevEx consultation firm, ‘Unblocked Engineering’. He’s the author of ‘DevEx Nuggets’, which is a very famous newsletter, which I personally like. He has 10 years of experience in software development and leading dev teams. And on top of that, he loves to travel, he’s humorous and loves to drink whiskey. And, so do I. Welcome to the show.
Tobias Mende: Hi, Kovid. Pleasure to be here.
Kovid Batra: Alright, Tobias. So, you’re aware of the format, I hope. We’ll have a quick fireside chat with you wherein we’ll get to know about you personally apart from work, and then we’ll have another section where we’ll be discussing about how to elevate developer experience and drive performance in engineering teams. We know that you have experience in driving developer experience because you had created a platform in your previous organization to improve developer productivity by impacting the developer experience. So, we’ll be talking more around that in the main section. And, before that, I would just move on to a fireside chat if you’re ready.
Can we go?
Tobias Mende: Yes, sure.
Kovid Batra: Great. Alright. So the first question is, where do you get your daily dose of learning?
Tobias Mende: I’m mostly on LinkedIn at the moment. I’m following a couple of really great content creators. I have subscribed to some newsletters there. So, I get a lot of articles every morning. And in general, I do a lot of reading.
Kovid Batra: Great. I think LinkedIn has become a learning source for a lot of people. Most of my learning also these days is happening on LinkedIn itself.
Great. Next question. What is your preferred mode of learning? So, people do it with experiments. People do it with an online course. What’s your preference?
Tobias Mende: Usually a lot of trial and error. I’m definitely a hands-on person. I like to experiment. And, that’s usually how I understand things the best. I might, like, join a small online course before I skim through some tutorials briefly, but then I need to try things out.
Kovid Batra: Cool. I think hands-on experience is something that really gives that dent in your head, where you learn something. Just doing an online course won’t really help. So yeah, it makes sense. Doing some theoretical learning is great. But then, some experimentation is definitely needed to learn something in a better manner.
Okay, the next question. Can you describe your feeling in one word when your code really works?
Tobias Mende: Yeah, I would say when the code finally works, that I’m definitely, I’m satisfied.
Kovid Batra: Cool. And, this is something I wanted to know, which one’s your favorite brand when it comes to whiskey?
Tobias Mende: Oh, I like Mackmyra, which is a Swedish scotch actually, which is quite interesting and really has nice flavors. And they have one that’s called Vinterglod, which is tasting a little bit like mulled wine from the Christmas market, which I, coming from Germany, definitely like.
Kovid Batra: I think I got to learn a lot more things from you than just engineering and leadership.
Alright. Alright. So, moving on to the main section where we talk about developer experience, leading high-performance teams. This is your area of expertise, but before jumping onto that, you have been into the engineering space from last almost 10+ years. You have been a software developer, senior software developer, tech lead, a DevEx expert, and a founder of a consultation firm now. So, this is quite a journey. And, you have seen a lot of different working styles, different teams. What I want to understand from you is, there have been multiple challenges that you have seen in different teams; give me a few of those experiences where you were into a situation, you faced the challenge and then you actually overcame it.
Tobias Mende: Great question! So, there are a lot of different challenges, of course, as you can imagine. So, for example, one time I was working with a team of tech leads who were collecting technical risks and, technical debt inside of the system, but had challenges to communicate those to other stakeholders in the business. And therefore, it was always a challenge for them to get time and people to work on those technical risks and adapt and removing those. So, what we did there was, first collecting everything that the tech leads had in their head of risks and opportunities, and weighing them according to how much impact would it have and how much effort is needed, on kind of a diagram to visualize that, and then we prioritized that based on that diagram. And then, I coached tech leads and we worked actually together on making clear what is the business impact behind that and communicating those technical initiatives in a way that business people or non-technical people could really understand why is it so important, because sometimes tech leads and engineers in general are really great at finding the risks and the technical things that need to be done, but they are sometimes not that great at communicating those in terms of money and business value. So, once we got that done, it got much easier to plan them alongside all the feature ideas and initiatives that we had from product management. That was one challenge. Also, maybe a bit more related to developer experience, in the last company, when I joined the company, they did not have continuous deployments, even though it was a quite modern company. And what was even worse was that there was a handover in the deployment process from developers to QA engineers, who then did the manual testing, the automated testing, and ultimately, the deployment. So, that caused a lot of pressure on that QA team. And also of course, a very long feedback loop for the engineers. And, in order to shift that to a more continuous approach, people first need to understand why this is a problem, and they need to feel the problem. And at that point, the engineers were okay with not having that direct feedback because they didn’t need to deal with deployments. But once we changed that, they realized how messy the process was. And, that helped us, first of all, to get the pain to the people who should experience the deployments, how that is, the engineers. But also, the benefit was that the engineers contributed too, with their ideas, how to improve the process. And they asked a lot of questions on the process, “Why are we doing this step?” “Why are we doing that step?” And through that, we were able to automate and improve the process, remove some parts completely, and then arrive at continuous deployments, eventually with like 15 teams and 60 people, who then also understood what the benefit of that is. And, even though people were skeptical in the beginning, in the end, they were very happy that we arrived at that part, because it was better than they could have imagined in the first place.
So, that was something really cool.
Kovid Batra: That sounds interesting. On the first experience that you shared, I think having a clarity on what is the outcome of any work that you’re doing as an engineer is very important. And there is no denial, a lot of teams face this challenge. Even the tech leads are sometimes not that well subconsciously aligned with what the outcomes are. And, that is what is much needed when you are working on something. So, it is very important. I want to ask a follow-up question on that. How exactly you communicated it? Was this through standups, meetings? What is the channel you use? Because, I want to communicate real actionables. I want people who are hearing this podcast to know, like how to do it.
Tobias Mende: Yeah. So, with the tech leads, we were meeting once a week to get that clarity. And, we worked on a moral board, in a remote setting where we were discussing in a zoom call, basically these topics and refining those. But then, in order to communicate it to the business, we wrote Notion documents where we wrote down, “This is the initiative.” “These are the reasons.” “This is the risk of not doing it.” “This is the risk of doing it.” “This is what we think it will take us.” And then of course, there was some commenting on those documents asynchronously on, “Okay. Could you please clarify what the business value is?” “Could you clarify if that’s really something that needs to be done now, or if you can push it another quarter?” And then, we had quarterly OKR plannings in that context, in that company. And, we brought those into the OKR plannings. Like the product management would do with their objectives, we brought that in from the technical side as well. Also, to highlight that it doesn’t really matter where the initiatives come from or the objectives, as long as they are aligned with the business goals. Those can be technical objectives, but it could also be, of course, product objectives. And, in the end, we want a stable system, a stable product that will make customers happy in the future.
Kovid Batra: Absolutely. I think this is one very important point that I have been also discussing with other folks around setting goals for the engineering teams. Even I feel that these goals which are being set up, these objectives which are being set up, of course there are a lot of technical objectives that have to be met, but ultimately whatever they are delivering it’s something that goes out to the customer, they’re using it. So, just like product teams, engineering teams should have common objectives, like NPS, customer satisfaction, retention. All these things are something that even the engineering team should look at when they are delivering something. So yeah, it makes sense. Till the time everything is in line with the business goals, where the objectives, where the initiatives are coming from, it should make sense for the business.
Alright, moving on to the next question here. While enhancing the developer experience, what’s usually your go-to strategy for identifying, first the bottlenecks, and then eliminating those pain points and the bottlenecks in the development process? You can take one example, and then explain it, so that we have more clarity on how it should be done.
Tobias Mende: Yeah, okay. So in general, how I do this is by talking with engineers, because developer experience is all about the experience that people have. It can be subjective at times and measurements that we get from metrics like DORA metrics will not give us enough insights on the developer experience. They might show us that we have a problem, but not where exactly the problem is. So, asking people. And, how I usually do this is through surveys because 1-on-1s are great to talk with people and dive deep into some challenges, but it requires that there is a lot of psychological safety and trust in that communication. And, what I recommend to leaders usually is to be careful with that, because as a leader, I might feel very safe and confident in that interaction, but my employee might not feel as safe to tell me what really is a problem, because they might think, “Oh, maybe my leader thinks I’m not capable enough and that’s why I have the problem. So, I rather not tell anything.” But, if you do anonymous surveys, we can ask all kinds of questions around developer experience, for example. Like, “How satisfied are you with the deployment process?” And then, we can have a scale from 1 to 10. 1 is “I’m very unhappy with it.” And, 10 is “I’m absolutely happy with it.” And then, when they click something that is more on the unhappy side, we could add a free text question, “Please tell us a bit more about what bothers you about the deployment process.” And then, people can give also some subjective and qualitative data to that. So, that helps also to get a lot of engineers interviewed, not only the ones that are close to me, because when I’m the leader in an organization, doesn’t matter which role I am in the organization. I have some people who are closer to me and other people I don’t have that much contact. And, we are usually biased towards what the people close to us tell us, or what our own assumptions are. And in 1-on-1s, it’s quite likely that we fall into a confirmation bias, that we just get confirmation for what we already think to know about the developer experience in the organization.
Kovid Batra: Great. I think that’s a good start for anyone who’s looking at knowing the challenges the developers are going through. But, just to like, bring forth the most common problems; what do you think is the most common pattern, or which are those most common areas that you have seen, the developers are blocked, their experience is dented, and that really requires an improvement? Any, any specific things, any specific patterns that you have seen in the people you have talked to?
Tobias Mende: Yeah, something that’s quite common usually are problems or blockers in the software development process. This can be that they need to wait too long for code reviews. It can mean that there are flaky tests, flaky automated tests, end-to-end tests, for example. It can also mean that tests take too long or that there are parts that are manually processed, or it can mean that the deployment is done by another team than the team who actually works on the software, so that they have a hand over anything that blocks the software deployment process, between “I commit some code.” to “It runs in production.” That usually is an issue that is quite close to engineers. And, that’s also what engineers are very likely to complain about the first, because they see it on the daily interactions. Some of the things that have usually a much higher impact even, but, a bit more sensitive are things like company culture. “Do I feel safe in the organization?” “Can I collaborate with my peers and communicate freely what I think?” “Can I raise my concerns?” “Do I know how I can influence my environment when I think something isn’t right?” All those things are also important for developer experience and productivity. But usually, less an issue raised first by engineers because many engineers tend to accept the organizational environment as they see it and as they are in that organization, and don’t question how that could be changed. But for leaders, I know that there’s a lot of potential in changing the organization and the culture and the organization to allow for a better developer experience.
Kovid Batra: Great. I think that was really insightful, and with such kind of services coming into the market, I think it’s already a need. I see a lot of blockers, a lot of things happening. By the way, you mentioned about code review times being high and you might identify that as an issue and then go deep down to understand what exactly lies there. Have you come across any efficient method to identify such problems or is it mostly like, these assessments have to be done or you have to go and talk to them 1-on-1, or you understand these problems first-hand while you’re doing standups and sprint reviews with the team? Have you come across anything of that sort which is more efficient?
Tobias Mende: I mean there are of course a lot of tools who measure parts of the deployment process from the moment somebody picks a ticket, to the moment it moves to done, and all the stages in between, the ‘merge requests’. “How long are they open?” “How big are they?” There are a lot of tools. The problem is that we can get a lot of data, but without knowing where we suspect a problem, it’s difficult to find that out, because maybe the long code review times aren’t actually an issue for the way how engineers work in the organization for whatever reason. Maybe they don’t care about this, but something else is much more frustrating and we only get that by really asking engineers, “What’s frustrating for you?” And they will tell us. And, the good thing is when we work on what frustrates the engineers, that will improve their experience because they see, “Okay, something that frustrated me before is gone now, and we might get other ideas from metrics.” For example, in the last company, we measured all the big jobs and how long they took with data doc and also had some alerts on certain. It’s increased their build time for an unreasonable amount, just to check, “Okay. Why does this not take twice as long?” “What happened there?” And that helped us of course, to improve things even before somebody noticed, and over time, people were like, “Oh well, this used to take an hour. Now it just takes 10 minutes.” Cool that we have this developer experience team. But, for finding problems in the first case, I find that talking with people or getting kind of surveys out, maybe also automated through tooling, are the most effective ways.
Kovid Batra: Great. Thank you. I think this really helps bring forth another important point, which I would want to discuss on this podcast. In pursuit of this high performance, teams are sometimes like, there, there is a resistance to change, like they don’t want to go out and change outright, right? So, how do you overcome those resistances, and drive a team culture that is always on a continuous improvement and towards excellence? So, how do you tackle that?
Tobias Mende: So in general, I think it’s a myth that people are resistant to change in general, because people change things in their life all the time. The difference is that when they do changes in their life, such as getting a child or getting married or any other thing, moving houses, traveling to a place. Those are changes, but why are they not a problem? They are not a problem because people understand why they are doing those changes. So, when we feel resistance in the workplace, then the question is often, “What are people not seeing (why this change is good)?” Maybe they think that the risk of this change is higher than the benefits for them. Maybe they got tired by too many cultural change initiatives in the past that always led to just another culture that has the same problems under different names. All these things are important to understand first.
And then, one thing that I see happens often is when people, leaders normally, see a certain change that they want to see in the company. They communicate that, and why it is a great change and all the numbers and facts and everything to rationalize why this is a great change, but what often completely is missing is the emotional part. We need to connect that to emotions. “How does it feel to work in that new environment after the change?” And, “How does that benefit?” “How would the life look for engineers in that new environment?” And once people can feel that, they are much more likely to support that change because they believe this is actually great for them. I can give a small example. When we introduced the continuous deployments, I already explained a bit about that as an answer to the other question. I showed a slide where I showed them, “Okay, this is the time it takes today from a commit to deployment. And, we have this and this stages and they take this long time.” And I showed them below that, a graph that was only, I think it was roughly a third or a sixth of the usual time. And I told them, “Okay, look, imagine how it would feel if you can get your changes live to production within 20 minutes?” “What would that mean for your database migrations?” “What would that mean for your experiments that you are running with your users?” And so on. And people were like, “Oh, this would be actually quite cool. We don’t need then days anymore to get that life, but we can do it within half a day.” And that was how people got excited, I think.
Kovid Batra: Right. I think you gave a very good analogy here. Like, when we change in our personal lives, whether it is having a baby, moving places, getting married, whatever, things fall naturally to us that, “Okay, this is going to be good for me.” “This is why I’m doing this.” Right? So here, in the personal space, it’s the culture, it’s the society, your personal happiness, your experience, seeing other people, other couples enjoying their lives; you already have that mindset and believe that, “Okay, all this is very positively rewarded.” Whereas in companies, in workplaces, usually, I think resistance to change comes in those companies where the culture doesn’t appreciate the change. They do not embrace failures and ask people to improve on them. Like every time, there should be something that is imbibed positively within the company culture around these changes. So, I think that also can bring a lot of ease when you introduce something new to the system and people take it, and then do it and deliver what is needed. So, this is my thought. I was just thinking on what you just said, so.
Tobias Mende: Yeah. Thank you. Exactly. I mean, the thing is when we focus on developer experience by definition, this is we are caring for the experience of developers and we try to make that better. We are not focusing on performance or making them productive just so that the business can make more money. That is a side effect. A very nice side effect, a very important side effect, but when people truly believe that we care about them and about their experience, their work experience, and that we make it better, then people are far less resistant to the change, because they know, “Okay, the last time the team changed something or the leader changed something for the purpose of improving developer experience. That was awesome. So, give us more of that change. We want more of that.”
Kovid Batra: Right. Great. I think it was a really, really nice talk. We had a good discussion around developer experience, your experiences, your challenges. So, it’s great. Thank you for sharing the experience and the knowledge here. I would love to have you for another episode, talk more around developer experience because I think that is a topic which would be a complete episode to discuss on. So, all the best for your ventures and all the best for your journey in life.
Tobias Mende: Thank you, Kovid. I really enjoyed the conversation with you. And, yeah, whenever it’s the right time, I’m happy to join again.
In the recent episode of ‘Beyond the Code’, host Kovid Batra engages in a thought-provoking conversation with Miroslaw Stanek, who serves as the PL Engineering Site Lead at Papaya Global and author of the newsletter ‘Practical Engineering Management’. He has previously lent his expertise to Azimo. The focus of their discussion revolves around achieving technical excellence while effectively managing tech debt.
The episode starts with a fun fireside chat with Miroslaw, allowing the audience to see his more genuine and unfiltered side. Moving forward, he shares the challenges he has encountered in his role as an engineering director and how he overcame them. Further, he delves deeper into maintaining a harmonious collaboration between CTOs and VPs in order to tackle existing tech debt while concurrently delivering new projects.
Lastly, Miroslaw sheds light on instilling a sense of ownership and collaboration within engineering teams for continuous growth and improvement.
Kovid Batra: Hi everyone. This is Kovid, Kovid with a K, your host on ‘Beyond the Code’ by Typo. And today with us, we have an amazing guest, Mirek, who is an engineering director at Papaya Global. And he’s an engineering leader, he’s very unique in his own ways. He not only loves engineering sprints, but he also loves marathons. He has recently completed his OCR.
Welcome, Mirek. Welcome to the show.
Miroslaw Stanek: Hello, Kovid. Hello everyone. And thank you for having me. Just, you know, small update. I’m not a marathon runner, I’m a trail runner. It’s still, you know, running, but actually I prefer running, you know, uphill and downhill rather than running through city. But, you know, it’s more or less the same.
Kovid Batra: Great. Thanks. I didn’t know about that. The learning has already started. So today, on ‘Beyond the Code’, we have Mirek with us and he is running a newsletter, which I personally love,’ The Practical Management’. I want to give you a kudos for that, Mirek. It’s really nice. I’ve been following it for some time now.
So, keep writing and I really see that passion of writing in you. So please, we need more people like you in the community.
Miroslaw Stanek: Thank you. Yeah. So, if everyone would like to check, just go to www.practicalengineering.management, where I put all of the things for fresh engineering leaders, tech leaders, engineering managers, and others.
I was there. I know what kind of struggles I need to face. So, I hope I can share some of my experiences to make your professional life better.
Kovid Batra: Sure. Alright. So, the format of this podcast is, we have a fireside chat with you where we get to know the real Mirek and then we’ll jump onto the main section which talks about your experiences, engineering, how you handle those challenges, and how you improved on those.
So we’ll move on to that, but a quick fireside before that. Are you ready?
Miroslaw Stanek: Yeah! I am.
Kovid Batra: Alright. Alright, Mirek. So, the first question, it’s something related to reading and books. So, if there is one book that you would want to recommend to all the engineering leaders, what it would be and why?
Miroslaw Stanek: This is actually quite hard question. If I have to pick only one book, I would say it’s ‘Empowered’. It’s written for product managers and product people, but actually it states that engineers, engineering teams are also part of product teams. And, I think that this book explains very clearly what’s your role as an engineer or engineering leader in the product organization. When working with engineers, I trust with the picks for their technical books because they know what are the challenges for them. But, this is the book, which I recommend every single engineer who would like to make great job building, not just the code, but the working product. So yeah, short answer, ‘Empowered’.
Kovid Batra: Great! Alright, moving on to the next one. Do you prefer to jot down your thoughts old-school style with paper and pen, or you embrace the digital era?
Miroslaw Stanek: You know, I think that we can have like another episode only on the notes taking because I don’t have the clear answer here. I like writing in both ways, either with pen and paper, and digitally. It all depends on the context. So, for example, I use note-taking apps. The one I use most often is Obsidian. It’s a note-taking app, which you can, you know, write and mark down. You can have tagging, you can somehow connect the notes. It’s great syncing across different devices. So, basically Obsidian is a place where I put like everything, my daily notes, my notes from work, my ideas, drafts of the blog posts, and tons of others. I love it. I love doing notes in this way because basically, you can use search, for example. If you work on something which actually you touched half a year ago, you just go to search and you can find your note. So, this is why I like using the digital notes.
But, it doesn’t always work perfectly. For example, if I have meetings with people, I prefer not having my laptop during the meeting, if I don’t have to have it. I prefer to make notes on paper, because I don’t want to have this wall between, you know, me and the person I’m talking to. I don’t want to have distractors. I don’t want to have even the screen shining on me or the notifications or anything. Also, I read some interesting scientific papers and actually when you write your notes with pen and paper, it actually puts the thoughts your memory and it roots there. So it’s easier to remember what you were talking about. Also, for me, it’s faster to write, you know, handwritten notes than write something on the keyboard. So, yeah, like I said, no simple answer for the simple question.
Kovid Batra: No, no, it definitely makes sense. I am one of the users of the tool. We are using it for our platform, for typo help docs. We use that. And in general, I really feel the benefit of having something published over multiple devices. Wherever you are, you can update it for yourself. You can share it with them. So yeah, that way is very very productive and helpful. And of course, sometimes you just don’t want to have that barrier of a digital thing in between human and then, paper and pen works best for us. So, totally I think it’s a balanced approach for most of the people.
Miroslaw Stanek: Yeah, definitely.
Kovid Batra: Moving on to the next one. So again, coming to one of your interests, tech and run, right? This is a match which is unique and made in heaven, I think so. So, what is your motivation? Like, what is your mantra of life that fuels you?
Miroslaw Stanek: Yeah. So, there are a few aspects of that. First of all, it’s like very, very practical, because what I’m publishing on social media, for example, you know, photos from my latest trail runs or obstacle races. It’s kind of the end of the story. And this story begins with me having quite big issues with my health. Basically, two or three years ago, I could barely walk because of the problems with my spine. Why? Different reasons. I had the injury, but also I’m the engineer. So, I spend most of my time sitting. So, the practical thing here is that you need to stay healthy physically. You need to do something. It can be running, swimming, or just moving. Currently, when we are talking, actually I’m using the standing desk. Yeah. so, we need to find the ways to keep you moving, yeah? But apart from that, because you know, there are like tens or hundreds of different sports which you can pick. For me, obstacle race is something which there’s always the next level like I can reach, you know. I remember watching races, a year or two years ago and was like, “Oh my God, what are those people?” “How they can do this?”, and today I’m one of those people. What motivates me to that is, mantra, I would say, is, you know, just dream big. Everyone says dream big, but the next thing is make a plan. So, to make your dreams happen, you need to find ways how to make the small steps to accomplish that. And if you have a plan, don’t think about the motivation, but rather about being disciplined, because motivation is when you’re watching those people running and you would like to be like them. Yeah, so this is the motivation. But, when I wake up at 5 a.m. in the morning, I don’t care about that. I’m not motivated at all, to be completely honest. But, I’m kind of disciplined to go to this training like three times a week. It’s not pleasant at the very beginning, that’s why you need to enable your discipline, and motivation comes later. So, this is my kind of mantra for how to make this thing happen.
Kovid Batra: One great investor here from India. He runs a very big fund. He mentioned one very great thing recently I came across related to discipline. So, he said, “Anyone who lives life successfully has to be disciplined.” So, living life successfully means you have to be healthy. You have to be mentally healthy, physically healthy, and achieve a lot of professional goals, personal goals. And, I also have started feeling it very recently that discipline is at the core of everything. When you’re young, when you’re a kid, school teaches you all that. But, I think at that time, people really don’t perceive it so strongly as we do when we reach this point in life. So, it is very important to keep yourself involved in some physical activities, some sports to be healthy and keep going.
Miroslaw Stanek: Definitely. Yeah.
Kovid Batra: I think let’s move to the main section wherein we’ll be talking about the technical excellence while managing architectural debt. So, this is something that is very cool to you. But before we move on to this topic, I specifically wanted to talk about very basic things, core to your journey. Wherein, I want to understand, there have been a lot of challenges that you might have come across during your engineering journey, right? You’re an engineering director at the company, but whatever challenges you have faced as a leader throughout your journey, can you just put a light on some of the key events which you came across and how did you overcome them?
Miroslaw Stanek: So, you’re asking about the key challenges which I faced during my journey? The one that I’ve been facing all the time is connecting the world of product and the world of the technology. From the technical perspective, there is always something you can do. There is another library that you can do some refactoring. You can increase, I don’t know, the testing coverage, whatever. You can hire a big number of people and you won’t accomplish that. So, the important thing is to be sure that no matter if you are the engineer, I mean, the individual contributor or the leader or director, you need to be sure that you do things in order to satisfy your customers. You build features, not just the code, and it touches many areas. Technical debt is one of them. So, I think we’ll go into details into that. Saying no to some particular activities. So, for example, you would like to migrate from one container solution to another one, only because you heard that today everyone is using Kubernetes, and you would like to use it. Yeah, of course you can do this. It’ll take you, you know, a few weeks, few months, depending on where you are with the company. But in the end, you need to understand, “Okay, what’s the real value for the product you built?” Maybe it will be better scalability, better maintainability, or maybe it will bring you some other challenges which will keep you from providing the real value. So, this is the challenge I’ve been facing on every stage of my career. Either when I was, you know, writing the code or leading the team. It was always easy to find something fun to do, but it was harder to find something which is both fun and useful.
Kovid Batra: By talking to other engineering leaders during the podcast and otherwise outside of the series, I think this has been popping up again and again, like the connect between the product and the engineering that the engineers do. So, the purpose of doing something is something that should always be instilled while you are working as an engineer. So, it makes a lot of sense what you are saying. But, any specific advice on how we can instill it in the engineers? Because when everyone is talking about it, I feel it doesn’t come naturally to the engineers, at least for a lot of them. So, what do you think worked out well for you when you faced this challenge and you tried to solve it? Any practical advice there?
Miroslaw Stanek: So, I would say having clarity on the outcomes of your work. I think this is the extremely important thing. So let’s say, you have a project and the deadline is, I don’t know, December 1st, yeah? So, you have two, three months to finish that. And, this is the only message you give to the team. Team is like super focused on delivering feature to production. Period. Yeah? So, you know, November 30th, you launched production. December 1st, your goal is achieved. End of story. And actually, it’s not the end of story for the product. Maybe it’s the end of story for the, you know, very first launch production, but not for the product, because actually, on the December 1st, it’s the very first time when your product reaches your customers. So, this is the moment when you need to understand what’s the stability of it, what’s the adoption, what’s the feedback of customers, what are the biggest struggles and everything. So, you know, if you focus people only on delivering on the deadline, they will put all of the energy and attention into making it happen. And on December 1st, they will be exhausted. While actually you need to be sure that on the December 1st, they are in shape because they should wait for the feedback. They should, you know, continue working. They should continue improving the product. So, months later they can celebrate success. First customers, first paid customers, first conversion, new market open, increased conversion of something. And, if you tell people, “Okay, deadline is important because marketing team is waiting for this deadline.”, “Few other things are waiting for this deadline.” But, the most important thing is, “What’s the value you generate for customers?”, and this is what you should focus on. And how I do that in practice? I try to bring as much data as possible. So, for example, if your work is to enable new market, for example, I’m asking to create a simple chart, which shows me how many new customers signed up in a given country, for example. Another project, if you would like to increase the conversion of your login flow. I’m asking for another dashboard to show you, “Okay, what’s the current conversion?” “How many people open the app or open the website?”, and “How many of them land on the main page after logging in?” And, we can see the percentage. And then I say to people, “Okay, your goal is to increase this conversion by this or that percent, and this will be our success. I don’t care if you release that, you know, this week, next week, this is just first step. I do care what we’ll achieve as the outcome of your work.”
Kovid Batra: Yeah, this is really, really helpful, Mirek, because accompanying product and engineering goals together would really bring a big change in the mindset how engineers operate. As a product manager, my goal for a particular release is to have that conversion or that retention, right? Whereas for engineers, that doesn’t come directly. But, if the same goals are set up, same key results are set up, then of course, we can see that change, and engineers can also start thinking in the direction of an outcome-based deliverable, not just delivering something. So, it makes a lot of sense. And thank you for this. This really is a practical advice which resonates with your newsletter name also.
Perfect. Moving on to the next question in your area of expertise, which is bringing the technical excellence while managing the architectural debt. So, how do you collaborate the CTOs and VPs to address the existing architectural debt while ensuring that you’re delivering new projects also, right? So, at that time, this is the hardest call to take, I feel, that what to do right now. Whether you’re a startup, or let’s say, a mid-sized company, somewhere or the other, you have this question and how to take a call on that. I would love to hear your thoughts, your experience on this.
Miroslaw Stanek: Yeah. So, when it comes to addressing tech debt, I think that we need to make, you know, a few steps back, and tell very clearly what the tech debt is, yeah? Because let’s say we have monolithic systems. Is that the tech debt? Sometimes it is, because it blocks the multiple teams working on a single product. Sometimes it is not, because if you are a startup and you have only one engineering team, like let’s say three engineers in the company, actually it’s beneficial for them to have a monolithic system, because they can go live very quickly, they have like a single monitoring system and everything, yeah?
So, first of all, what’s a tech debt, yeah? I would say that tech debt is, it’s something what stops you from reaching your product or business goals. And obviously, some companies are more major than others. In some companies, you have, you know, KPIs or OKRs, like very clear information, what you would like to achieve. In others, you know, fresh startups, you’re still, finding this product-market fit, pivoting a lot.
So, when thinking about what’s the high-level goal here is that there are four essential things all of the businesses or product companies to succeed. One is growth. Another one is expansion. The third one is customer satisfaction. And the fourth one is profitability. If you understand what’s your current goal. For example, if you do optimization of the login funnel, it’s probably something about growth. If you fix some of the most common problems of your customers, it’s probably customer satisfaction. If you are, I don’t know, migrating from one database to another because of the optimization, probably it is about profitability. If you open your app to another market, another continent, probably it’s about expansion. And if you have this in mind, you can identify, “Okay, what are the biggest obstacles in order to, for example, launch our product?” Let’s say, you are a European company, “What’s the biggest obstacle to launch your product in Asia, to launch your product in the U.S.?” And if you know that, it’s easier to identify what are the moving parts, in terms of, you know, software architecture, for example. Which of the things should be generalized enough so you can start launching to other countries? For example, let’s say you have the sign-up flow, yeah? And, in one country, you just take the name, and first name and last name. In another country, you need to take, I don’t know, the postal code because of compliance rules. Which means, that your sign-up flow needs to be more generic, which gives you some idea that, “Okay, this part probably needs to be quite dynamic.” You need to bring dynamic configuration, whatever. While other parts, a particular screen, like, showing you something. This can be static for all of the countries. So, maybe it’s not the right time to generalize this kind of domain. So, if you have clarity here, you can tell your management, “Okay, if we would like to launch to another country, maybe we can use our current infrastructure, but if we are planning to launch to another 10 countries, those are the moving parts we need to optimize, the technical debt we need to fix, the domain we need to extract, whatever, in order to reach our business goals.” If we want to increase customer satisfaction, we need to invest more in one, bug fixing, but another one may be better SDLC. So, we reintroduce less bug fixes. If we would like to increase the growth of the company, maybe we need to optimize some things. And, what means optimizing? Probably it means launching to production like every day, every week, whatever, yeah? So, you can do quick experimentation. If your SDLC doesn’t help you with launching like every day, this is tech debt, because your company cannot, you know, iterate quickly over the product.
Kovid Batra: What I understood is that there could be different situations where you have to like, evaluate multiple moving parts and then take a call on how you should move forward, so that you don’t end up creating more technical debt or whether you should handle technical debt right now or just focus on time to market first. One thing that I felt is that it is always, or it should always be driven from the business goals. Like, technical debt, first thing when you’re thinking, “What is your business goal?” And then move on to the next step of thinking what you need to move in your system. So like, maybe clear the technical debt, or maybe at that point you should not care about it much. Just focus on launching for that particular country and that would be sufficient for now. Like, move fast there. Yeah. That’s great insight.
Perfect. A follow-up question on this. So, this is something when you are in a position where you have to like take a call, like whether to handle it or not. But, when you’re building something, at that point, engineers are writing code, which could be optimized or highly optimized or not at all optimized. What things should be taken care while building things in general, to not have a lot of technical debt for the future?
Miroslaw Stanek: Well, you know, it would be good to know what’s the kind of long-term roadmap for the company, because it will give you at least some clarity. “What are the important technical things, which not addressed now will block us in the future?” But it’s not easy, yeah? Especially early, the startup. They simply don’t know. They don’t know what they will do in next three years. They can have vision, mission and all of the values, but market will check it anyway. I think that another good thing to keep in mind is that one of the book I mentioned is ‘Accelerate’, it’s a set of good practices, mostly in software delivery processes. And, you know, it is with us for quite a long time. And simply there are good practices which we should follow rather than reinventing the wheel. Just see what are the recommendations for the biggest, most successful companies and those recommendations are, how fast you can deploy to production. Because it will tell you how fast we can iterate over product. If you cannot deploy to production every day, I think this can be the sign of the technical debt. And I’m not telling you that this has to be your goal. Your goal should come from product, and being able to deliver like every day is just kind of tool for reaching your goals.
So, rather than telling, “This is our goal to release every day and let’s say in a half a year from now, I would like to see you guys launching every day”, I prefer checking if we can release every day, if our SDLC process is capable of doing that. So, I don’t care if you release like 50 times this month. I do care if this is possible to release when it’s needed, yeah? So, there you have weeks in which you will release like 20 times a week and you will have weeks when you release just one thing, because this is how it is. And I would focus on this, yeah? Releasing very quickly. Automate as much as possible. So, don’t do manual work at all or very little, including testing, for example. Obviously, you need to also try your, you know, core metrics, the usage, the cost of your infrastructure, so you can see how it goes up or down. And yeah, I think it should give you some early indicators in order to learn where is the technical debt of yours.
Kovid Batra: This is a suggestion. This is an interesting topic actually and it can take a few more questions for me to understand and for audience to understand what calls to take when. Can you write something in your newsletter about this, like particularly this topic? In startups, “What to do?”, “What are the best practices to not let any technical debt accumulate over a period of time and simultaneously managing to deliver fast?” That’s just a recommendation because I find it very interesting.
Miroslaw Stanek: Oh, yeah, I really love feedback. So, thank you for that. For sure. I will. I will try to write something about it.
Kovid Batra: Great. Thank you. And, moving on to the last question of this episode. As an engineering leader, you face a lot of challenges, but one thing that remains common in a lot of teams, which I would definitely want to understand from your experiences that how do you instill a sense of ownership and collaboration within your engineering teams so that they’re always growing and they’re doing that continuous improvement? How do you build that culture?
Miroslaw Stanek: It’s a good question. If you want people, teams to own something, you need to be very, very clear about what does it mean. So, I put a lot of effort, especially now when I’m the director of engineering and I’m not doing the day-to-day code, I try to bring as much clarity and transparency as possible. So, one of the things is obviously being transparent about how we are doing as a business, what are the core things discussed by management, and so on. Those are like less technical things, but I also try to bring as much data as possible, either from the product, which I mentioned earlier. So, conversions, number of customers, maybe number of issues, but also, technicalities. Because, let’s say I tell people, “You own the quality of your product.” What does it really mean, the quality of the product? Some people will care only about the quality of the code, the performance of the code. Others will care about the full picture and number of bugs, especially the ones faced by customers. So, I try to bring those numbers to light. And I try to discuss them as often as possible. So, if I talk to the team responsible for, let’s say, the website. I try to discuss, “Okay, what’s the crash rate?”, for example. “What are the errors in console?” “What are the issues with the performance?” And by discussing that, I’m also presenting, “Okay, what are the practical aspects of the ownership which I expect from you?” So, this is one side of the ownership. Another one, it also touches the transparency and the clarity. It’s celebrating small accomplishments, because very often, especially if you are like super busy in delivering feature after feature, you don’t have time to stop. So, you have no idea if you did a great job. So, depending on the situation, I do a few different things. So, for example, I write monthly newsletters to the entire company or the entire product organization, which highlights, “Okay, in this month, we achieved this and that. We achieved those product goals, but we also built this part of architecture.” “We implemented this technical thing”, and so on. I try to approach as many people as possible and tell them clearly, “Okay, you did great presentation on performance testing. Thank you for that, because thanks to you, others will know or will have some kind of inspiration how they can do this.” And by that, by simply saying “thank you” and “great job”, you’re showing people, “Okay, this is a very important thing.” And, I think that you need to do this quite often, either publicly or on one-on-ones, you need to keep reminding people what’s important. You know, when you have CEO or CTO, they often focus on the mission and the vision of the company. It is important because this is something which gathers all of us, the employees of the company, under one goal, but sometimes it’s hard to capture that, especially if you are individual contributor. if you, for example, write the pieces of the infrastructure or you do the database optimization, it’s quite blurry to understand how your work commits to the 5, 10 years vision from CEO.
So, my job or job for every single engineering leader is to ensure that every single person knows how his or her work connects to this high-level vision, and you need to do this as often as possible, to keep reminding people why their work is important.
Kovid Batra: Totally. I totally feel that and bringing transparency, bringing clarity on what they are doing and how things are moving around that, setting up the right goals, celebrating the outcomes. I think all of this makes a lot of sense when you connect it. And, one thing that I feel is that it should be done very often.
Miroslaw Stanek: Exactly.
Kovid Batra: You’re doing your work. You actually tend to lose the bigger goal, the vision, and you really don’t connect to what you’re exactly doing. As you mentioned, if you’re doing some infrastructure change, then you don’t know how it is contributing to the mission which was mentioned by the CEO in the last meeting. So, it is the job of the engineering leaders and the engineering managers to come in and communicate that and celebrate every small achievement that contributes to the journey.
Miroslaw Stanek: I would say like one thing for every single engineering leader, if it feels weird to tell your people, “Great job, thank you.”, you need to do much, much more often, until it feels natural for you. And people don’t look at you like, okay, we’ve some kind of, you know, suspicious, okay, what this guy wants from me.
Kovid Batra: I read one of your newsletter issues, which mentioned about having frequent one-on-ones and I couldn’t get a sense of this, that this is in the DNA of the engineers, probably, or the engineering leaders, that they’re kind of introvert, right? They really don’t open up easily. It might not be true for a lot of them, but I feel that comes in the DNA of an engineer. We’re sitting in front of a laptop, 10 years of coding and then suddenly you’re meeting people. It seems a little weird. It becomes difficult. It’s, it’s a barrier. Right?
Miroslaw Stanek: Exactly.
Kovid Batra: And I think, the engineering community will embrace this and they’ll learn and probably have better teams and better culture of continuous improvement.
Great, Mirek. I think that was a great session. A lot to learn. Looking forward to more newsletter issues from you. Thank you so much. Have a great day.
Miroslaw Stanek: Thank you, Kovid. Thanks for having me and yeah, have a great day to everyone who is listening to this.
In the recent episode of ‘Beyond the Code’, Host Kshitij Mohan, founder of Typo, welcomes Anemari Fiser, a Tech lead trainer. Her vast experience also includes valuable contributions to renowned companies such as CodeOp, Thoughtworks, and Waterford. The focus of the discussion is on navigating tech success with an emphasis on Career Goals along with Team Relations.
The episode initiated with Anemari sharing her inspiring journey - transitioning from a software engineer to a tech lead trainer, followed by an engaging fireside chat. Afterward, Anemari dives deeper into creating a growth plan setup for team members. She also underscored the significance of conducting one-on-one meetings to gain a deeper understanding of team members and to provide them with constructive feedback.
Lastly, Anemari highlighted the core principles that every leader should be well-versed in: self-awareness, reflection, and embracing vulnerability.
Kshitij Mohan: Hello everyone! I’m Mohan, your host, back with another exciting episode of ‘Beyond the Code’ by Typo. Today’s guest brings a very unique perspective on navigating tech success. From being a software developer herself, today, she helps software developers build a successful career in engineering. She has completed the entire loop. Today, she acts as a career coach where she helps engineers get what they need to reach to the next level. Please welcome, Ane to the show.
Hey Ane, thank you for your time today.
Anemari Fiser: Nice to be here and to meet you, Mohan. It’s a pleasure.
Kshitij Mohan: Thank you so much, Ane. I think before we start with anything, we are already amazed by the kind of career progression, the evolution that you have had. And I think to begin with, we all would love to understand about these career choices that you’ve made that helped you reach where you are. And now, you are helping the entire community with it. Would love to understand your experiences, Ane.
Anemari Fiser: Sure. Well, a quick overview over my trajectory, let’s say. So, I started as a software engineer. I had what you would call a straightforward path to software engineering. I’d done my four years of university, got my degree in computer science, and then I started playing different roles as a software engineer in different companies, different industries. And, I loved that for a while until at some point, early in my career, I got really curious on all the other problems, like the product side “Why are we doing the things we’re doing?” “How do we make sure we’re more productive together as a team?” And, that’s how I got into leadership. And once I switched to that part of focusing on people and focusing on what exactly we’re trying to build, it became clear to me that that’s the type of impact that I want to have. So, I started my role as a tech lead. I’ve been a product director. And, at some point, some years ago, I burned out in the tech lead role that I loved. So I had to change the trajectory a little bit. So, I started working with people individually, in tech leadership positions in different roles, helping them identify when they are close to burnout, but also identify how to move forward in their career. And this is what I’ve been doing for the past three years. I’m also running trainings, like with tech leads into helping them building high performing teams, and individually supporting their individual struggles. So, yeah, I think that sums it up.
Kshitij Mohan: You know, I think that’s such a great initiative, Ane, that you’re working on. And as you mentioned, burnout and how do we help build teams sustainably. If you would be okay, would love to understand this entire ecosystem of burnout, When do you start feeling? How do you start experiencing? How did you realize “Hey, this is something that we need to address and then move on to the next journey?” I think that would really be valuable for all of us.
Anemari Fiser: So, I think for me, it was pretty obvious given the fact that I couldn’t be productive anymore in the day-to-day. So, I was feeling overwhelmed all the time. I reached like the final step in which I wasn’t able to function day-to-day at the level that I was expecting from myself at that point.
So, I do believe there are signs earlier. And, if you’ve been through it, you start to identify them sooner. And also for people that didn’t get to that point, I think there are some signs that you can identify before getting to that point and you can address it. So, that means you can address this with a way better approach than me, which is quitting your job. I think the signs are clear, but we just ignore it. Tiredness, it’s demotivation, it’s exhaustion, it’s not being able to sleep. You know, like just kind of feeling unable to show up every day to the level that you expect from yourself. So, I think those are the small signs.
Kshitij Mohan: Right. And just talking about a bit more, Ane. So, these sometimes are phases also, right? Sometimes there is a phase where you experience this and then after the phase, you are back on with the same energy. So, is it like a cycle that you constantly are on, or any specific things to consider about?
Anemari Fiser: So, definitely can be cycles. I think it’s depending on how intense the cycles are and how often do they repeat, in order to get to that burnout phase. I definitely think if you identify the signs earlier, you can address them earlier and then you can be in this period, like you say, “Okay, they are temporary.” “I know how to address them.” “I know how to get back on track.” but, I think it depends from individual to individual, and from the level of exposure to stress they have.
Kshitij Mohan: Right. This is really great. Before I jump on, I just read your LinkedIn profile and there was one thing that I was really curious to talk about. So, you mentioned that you help quit your job without guilt and leave a door open. This is a very interesting statement that you have written. I think we’d love to understand what’s the perspective behind this.
Anemari Fiser: Yeah. So, I mean, quitting your job is a normal thing to do, mostly in the world today. And it doesn’t have to be like a door closing. It’s not like I’m not going to talk with these people again. It’s not like I’m not gonna maybe even come back at some point. So, I think it’s important to normalize quitting, just as normal as it’s become now firing people. Unfortunately, it’s just the world we’re living in. And so, normalizing quitting and just understanding that it’s about moving to something else, looking for different opportunities. It’s okay. At the same time, while understanding that you never know, and trust me, i’ve seen it. You never know where life takes you. You never know when you’re gonna start or meet those people again or that company or their product. So, it’s always important to just act as people and to treat it as an adult. All of this, it’s like separation, situations and just approach it like that and, leaving that door open, so you can come back, so you can work with those people in the past.
For me, definitely that happened and I’ve seen it firsthand. The world is very small, even if we think it’s really big and you never know when they will need you or you will need them. So, there’s this level of professional friendship that I think needs to just be there as a base. But for that, it’s important to have a clear understanding on why you’re quitting your job, and to not basically get to that point of full frustration, when you’re just slamming the door. I think it’s just a more healthy approach for your development, but also for the industry’s development.
Kshitij Mohan: I think it definitely takes a mature set of conversations to end things on a good note, other than just making it anything on the personal front. Perfect, Ane. So, before we begin with anything, we would love to have this quick fireside chat with you, where we would love to ask some questions to know more and then just go about it. So, if you’re ready, I’ll just shoot those three questions for you.
Anemari Fiser: Go for it.
Kshitij Mohan: Perfect! Question one. After a demanding day of work, which I’m pretty sure most of your days are, how do you unwind yourself?
Anemari Fiser: With a good thriller book. That’s my escape from the work, brain.
Kshitij Mohan: Oh wow! So now coming to who’s your favorite thriller writer? And any specific book that you would like to mention?
Anemari Fiser: Yes, so I don’t remember the writer, but the book is called ‘The Silent Patient’. That’s my favorite thriller book.
Kshitij Mohan: ‘The Silent Patient’. So guys, ‘The Silent Patient’ has to be on our next reading list.
Perfect. Question 2. What does it take to bring a smile on your face even in the toughest of the times?
Anemari Fiser: I would say reggaeton music. There’s nothing that puts me in a good mood more than a reggaeton. Very, you know, classic reggaeton song that completely shuts down my working brain.
Kshitij Mohan: Whoa! Nice. Gets you in your zone.
Last thing, your most triumphant moment as a leader?
Anemari Fiser: My most triumphant? Well, there are a couple to choose from. I think the most triumphant, the moment that I’m most proud of as a leader, was actually the moment when I failed miserably, and I let my team down. But I think the comeback from that experience was something that I’m really proud of as a leader.
Kshitij Mohan: Totally! Any specific situation that you would like to talk about there?
Anemari Fiser: Yeah, I mean, it’s pretty simple. I basically made a decision that wasn’t in line with what the team was going for. And I had to stand behind that and work together with the team to build back that trust that I lost in that moment.
So, it was early in my starting days as a tech lead. And I learned my lesson definitely. I would not like to be in this situation again.
Kshitij Mohan: So, thank you so much firstly for this. This was really fun and exciting. Now, getting to the real stuff, the expertise that you have seen and evolved over time. Navigating into this entire dev ecosystem, dev journey. And, when we talk about growth and scaling and all other aspects in your career. The first important aspect that comes in that, how do you identify who needs what set of things to grow on. That need gap analysis. How do you identify which set of members need what set of support to grow, and all this has to be balanced while you are doing what you are doing in your daily flow of work?
So, how do you do that? Any specific ways that you have done in your career that could help us?
Anemari Fiser: So, I think every person, every individual in the team needs some sort of growth plan set up. And I think that’s part of the responsibilities of a tech lead, of a leader in the team to make sure that they have that. That means helping them develop it. Personal growth plan, and identify areas for improvement by asking for feedback. Maybe just taking an assessment on their skills and seeing where they are, based on the expectations of the company and seeing what they have to work on. So, I think it’s a key expectation of a leader in the team to make sure everyone has some sort of roadmap for growth in the area that they need to develop, which is aligned. And that’s where again, the role of the leader comes, to make sure that’s aligned with the needs of the team or the needs of the company.
So, I think that those are the main things. It’s about working together with the individual to identify areas of growth, and then helping them find opportunities, and in the day-to-day work, so they can develop those skills.
Kshitij Mohan: Right. And what I’ve realized is that the folks, for example, the developers are also not aware of what they need to be, or how do they fit in the bigger picture of the growth journey and roadmap.
So, how do you actually make them also buy in and realize, “Hey, this is something you should also be focusing on”, because most of the times it looks like just a one-way conversation, right? You, as a leader say something, developer thinks, not thinks, ignores and then you just keep on going about it. How do you ensure that these folks also buy?
Anemari Fiser: I think everything comes from the culture that you set up in the team. So, how do you develop that culture? If it’s a culture of growth, then definitely it’s gonna set in. For example, I’ve never been in a situation like the one that you’re describing, where I actually had to push someone at that level to do something and feeling like I’m not being heard. And so, at least in the companies that I’ve been there was a default expectation of constant growth. Not even that, but people were very aware of the value that personal growth brings. They all wanted to grow. So, coming back to your question, I think what’s important and what tools you have as a leader is to identify people’s motivation.
So, it might not be growth in certain tech skills, but it might be going to the next level in their career and for that, it’s your role to point out, “Okay, in order to get there, you need to develop these skills.” or “You need to get better in this specific area”. And that’s basically you connecting the needs of growth with their personal motivations. I think that’s where the key is.
It’s not about making people do something, but it’s about working with them, understanding where to find that middle ground, in order to align. Like, the needs of the company or growth with their personal motivations. I think that’s definitely something that can happen. And, I’ve seen it happen by using different tools.
Kshitij Mohan: Sure. I think you mentioned a very critical aspect, identifying their motivations. And, this is where I think most of the managers or leaders fail. Especially, while being a new manager or a leader. We are all in that black box and we don’t know how to actually proceed with this process.
Any specific thoughts around how do you actually achieve them in a practical sense?
Anemari Fiser: So, how do you get to actually understand people’s motivation, is that the question?
Kshitij Mohan: Exactly.
Anemari Fiser: I think first, you have to show real interest and curiosity about their day-to-day, the things that they care about, like, “Okay, tell me what motivates you?” that’s a fair question, right? And it can get you something, but it’s definitely not going to give you the information that you need in order to move them forward. And so, I think it’s one of those situations that takes a little bit of time and the main part that it requires is for you to build trust with those people.
So, I think the best way to build trust in my opinion, is to have those 1-on-1s where you build rapport and you build a relationship with that person. So, before you get into the motivation, it’s a matter of getting to a point with that person where they can trust you enough to share with you. There are struggles, what they care about, where do they want to go, and also understand that you can help them, right?
So, I think that the key part is when you show them that you can find opportunities that you can delegate things to them, that can help them go in the direction they want to go. That all only makes it easier for them to come to you, instead of you kind of trying to drag the information out of it. So, once you have that trust, you don’t have to do that much work, because people will come to you.
Kshitij Mohan: I think it makes sense. So, basically again, everything comes down to the right setting of trust, the culture that you are setting out in these conversations, right?
Anemari Fiser: Exactly.
Kshitij Mohan: And, talking about these conversations, It’s easier said than done, right? When you talk about these 1-on-1s, these conversations, the critical aspect of this entire growth is this constructive feedback that you just talked about. Let’s talk about what I need, what I don’t, what do you think I need to grow on?
And, this has to be on some levels of trust, as you mentioned. And still, in general, we are also skeptical to give feedback, receive feedback, while we know how critical it is. How do you cater to this in this entire coaching process that you do? How do you ensure that the right practices and processes are being set around this?
Anemari Fiser: I do agree with you that if you set up a culture where feedback naturally develops, then you have a base for all of this. And so, how do you ensure that? Well, first it comes back to that trust, to that psychological safety that I was mentioning before. I think once you have the trust in the team, a correct culture, or the culture that you want is gonna naturally develop. Now, in order to do that, I think there are simple tricks. Like, you can just make it part of the expectations that feedback happens. So, that means creating the opportunities for that to happen.
There was this thing that we used to do in one of my previous teams, they were called ‘speedbacks’. So, basically you would put people together, the whole team. Each pair would have like five minutes where they would have to say three things that you are doing well and three things that you have to improve. There wasn’t any follow up conversation. At that point, it was just a quick thing. Now, the idea of that was to trigger conversations after. So, there was no value in it in just throwing some things at people, but it was about triggering them to go after and talk between themselves on examples and how to take it further from that point. So, that’s one thing.
Second, it’s about showing the value that it takes to do that. So, one thing that I used to do before these speedbacks was to block half an hour in everyone’s calendar to make sure everybody has time to prepare for that. So again, it’s not something that you do in-between or in breaks or whatever. It’s something that you actually have to put effort on. So, giving people the opportunity to do that and actually saving time shows them how valuable it is.
And last, but not the least, the best tool any leader has in order to create the culture, in this case, the feedback culture that they want, it’s them, by acting as an example. If you provide people useful feedback, if you put effort in it, if you react to it when they give it to you in the correct way, then I believe and I’ve seen it, that is going to have the biggest effect. So, it’s about you acting in the way that you expect them to act and them seeing the value of that. I mean, you’re the one that has the tool, that you have the most control over. So, I think change happens one person at a time. So, that’s how you basically start to move things around.
Kshitij Mohan: Sure, great point. And, just to add onto this, while doing all these sessions with engineers, leaders, what’s that common mistakes that you feel, “Hey, we generally tend to make, where we are able to go beyond these blockers in order to unlock”, right? As you mentioned, your biggest tool is, us.
Where do we lack on in understanding this aspect?
Anemari Fiser: So, first thing and one of the main mistakes I’ve seen, it’s not even having the 1-on-1s. I’ve seen a lot of leaders that don’t see any value in the 1-on-1s. The reason for that is because they don’t do it right. The problem is not with the 1-on-1s, it’s how they do it. So, I think they expect people to kind of just see that as an opportunity and take it. That doesn’t happen. You have to show people what is the value in them. You have to show them consistently and explaining to them, and helping them understand that that’s for them and how it can move them forward.
And so, I think one main thing coming back to your question is not even having 1-on-1s, deprioritizing them, which I think is worse than not having them in the first place. When you have that call with your tech lead, scheduled every week, and it keeps getting moved around. For me, that’s the clear sign that whatever you’re doing, it’s more important than talking to me, right? That’s definitely a message you don’t want to give people. So, that’s one mistake.
Second, it’s about prioritizing results over people. So, it’s more keeping your eyes on “What is it that we have to deliver?” “When do we have to deliver?” “What’s happening?”, instead of trying to actually understand, ‘Why are people struggling with this?” “Why are we taking so long?” like, kind of doing that switch between “Why is the system not working?” to “Why us as a team, allow the system to keep working like this in this not desired state?”. So, this is the second mistake that I’ve seen.
Kshitij Mohan: I think keeping results above people. I think that’s a great point that you mentioned, Ane. I think, totally aligns to what I think every leader or manager should be thinking about. In the end, it’s the team that drives those results and not the other way around, right?
Anemari Fiser: If you have a happy team, results just happen.
Kshitij Mohan: Definitely. Now, so just coming to the last part, which you have personally experienced, and you talk a lot about is this entire burnout and well-being part. As a leader, as a manager, as a coach, you must have had so many experiences around identification, firstly, of, “Hey, this is the wrong stage here where you are at.”, and then helping them to overcome that part in some way or the other. Any specific instances or any specific experiences that you can share with us around this piece?
Anemari Fiser: I guess it’s about you as a leader, identifying when someone in your team is struggling and helping them deal with that.
Kshitij Mohan: And the other way around as well, right? Some key advice, insights for every developer should also be a part of it, right? I also need to be aware of what’s happening with me as an individual and then kind of driving those conversations most of the time. So, would love to understand these spectrums.
Anemari Fiser: Yes. Okay, thank you for clarifying that. So I think, first it’s about self-awareness. Identifying whatever individual that is struggling, it’s about identifying that in that point, you are struggling. Now, that self-awareness can come from different sides. It can come from you, like feeling like you’re getting close to burnout, feeling like you’re not well.
Second, it can come from the outside. And, this is where the leader can play a good role. If you’re noticing that someone is struggling, tell them, “Hey, I’ve seen you’ve been working over hours.” ” Is there something?” “What’s happening?” “How are you managing all of this overwork?” “How does it affect you, the fact that we have this big deadline?”.
So, it comes from both sides. You can be self-aware or people can make you aware that you’re struggling. Sometimes, we don’t see it. It’s just that. Third, even if people are not telling you, you can actually ask for feedback. For example, for me, a good awareness when someone in my team goes, “Hey, I feel like you’re not doing well.” they just told me that, right? Like, I feel, “Are you okay?”. Someone just asking you, “Are you okay?”, it’s a sign that something is not right. So, I think it’s about whoever comes to you and asks you, “Are you okay?”, I think that’s a sign for you to start asking, “Why are you asking me this?” “Is there something that is showing you that I’m not okay?” so, I think it’s about just paying attention to what people are telling you and what’s happening with you and with people around you to understand if you’re in a good state or not, and taking action, right?
And the best way to do that, it’s reflection. So, if you want to develop self-awareness, or if you want to understand where you are, or how people feel around you, it’s reflection. That means just taking a moment out of your very busy life and week and understanding, “Hey, what have I been doing?” “How am I feeling?”. Getting some feedback of people around you to see if it’s aligned with the signs you’re giving out. I think that’s the best indicative to understand where we are and then taking action. I think that’s a different point because once you get aware, you can take action. The simplest thing is just making people aware around you that you’re struggling. Even as a leader, I did this. I went to my team and I said, “Look, I just need help.” it’s as simple as that. So it’s kind of working from that point. One word, and being vulnerable. So, one thing that I’ve noticed is that it’s magic.
When you show vulnerability, something happens. Even the people, their first instinct is like, “Oh, what’s happening?” “Why is she telling us this?” but then over time, they start sharing also. So, I don’t know, I feel this for me, has been a magic tool. The more you share, the more people share. I think that’s the place where you want to be as an individual, as a leader. And that’s where the solutions are.
Kshitij Mohan: Definitely, this was so insightful. I think you touched on very core principles – self-awareness, reflection, and being vulnerable. And, this is what I think most of the leaders we have heard talk about, and it’s just about how you start reinforcing them in your everyday of work and talking more and more about it.
And that’s how you guys are trying to build a community around it as well. So, thank you so much, Ane. I think this was really wonderful. We were really impressed by the kind of experience and wisdom that you’ve shared with us, with our all viewers.
Thank you for being on the show, Ane. This was really great, thank you.
Anemari Fiser: Thank you for the invite, it was a pleasure. Nice meeting you both. Have a great day!
And, thank you again for the invite. It was a pleasure being here.
In the recent episode of ‘Beyond the Code’, our new host Kovid Batra welcomes Mihai Valentin who thrives in various roles i.e. mentor, tech lead, principal engineer, and author of the newsletter “How Did I Get Here?”. He has previously contributed to reputed organizations such as Meta, Datadog, Adobe, and more. Their conversation revolves around building your own tech vs. leveraging third-party solutions.
The episode begins with a fun fireside chat during which Mihai shares his personal favorites and the guiding principles that shape his life. Afterward, he delves into the challenges he encountered while leading teams and provides insights into how he tackled them. He then takes a deeper dive into the scenarios where the choice between building own tech or leveraging third party solutions becomes pivotal as well as maintaining a balance between addressing technical debt and keeping pace with the fast-paced tech world.
Wrapping up, Mihai provides an intriguing glimpse into the inspiration behind naming his newsletter, "How Did I Get Here?".
Kovid Batra: Hi everyone. This is Kovid, Kovid with a K, your host for another show of Beyond the Code by Typo. And I'm today really excited to have Mihai on our show, who is a very humble, very renowned newsletter writer and author of the book, and really loves to give back to the community. He has had 15 years of software experience in leadership, leading tech teams. And he has worked with organizations like Facebook, Datadog, and whatnot. And right now, he's a mentor, he's a contractor with an MNC. Over to you, Mihai. Really happy and excited to have you on the show.
Mihai Valentin: Hi, Kovid. Thanks for the introduction.
Thanks for hosting me on this podcast. I'm really happy to be here. And a big hello to all your viewers.
Kovid Batra: Thanks a lot, Mihai. Thanks for taking out time for us. So, you have come to the show for the first time. I'll quickly tell you about the format. So we are going to have a quick fireside chat. wherein we love to know about Mihai personally and other aspects other than work. So there will be quick two to three questions that we're going to ask here, and then we will move to the main section where we will be understanding how to lead tech teams better, and then we'll have that section for around four or five questions.
Is that cool?
Mihai Valentin: Yeah, absolutely. Let's get going.
Kovid Batra: Great. Great. So Mihai the first question from the fireside? Which is your first tech gadget that you ever owned?
Mihai Valentin: Oh, that's a good question. So let's go a bit back down the memory lane in my childhood. I got my first ZX 80 computer. It was one of those computers that didn't have a screen So you'd need to connect it to your TV set and you would connect it to a cassette player as well because you would use audio cassettes to load and save programs or games. And whenever you would load stuff or save stuff, it would make this noise like kind of the dial up noises from the 2000s, but like 10 years earlier. So that was an amazing gadget because that's how I learned to program at first. So the ZX80 had BASIC as a programming language. It was a very simple language comparing to what we had today, but nonetheless amazing for being able to learn as a first programming language.
Kovid Batra: Perfect. Perfect. That was unique actually. I haven't spoken to someone who has had that gadget ever. Great. So your love for tech has been like from your childhood itself then, right?
Mihai Valentin: Exactly. Like when I got this computer, I was spending most of my day in front of this computer. But I think it definitely paid off because that helped me learn programming and then that basically started my tech career.
Kovid Batra: Great. Okay. All right. Moving on to the next one. What kind of a person you are, like, are you an early adopter of things? Or you really love to wait and see if things are proven and then you try your hands on that. What kind of mindset do you have?
Mihai Valentin: So I'm always aware of what's new. So in our industry, all the time there's going to be a new technology, a new version of technology and so on. I'm trying to keep up as much as I can with what's happening. However, when it comes to actual implementation, I'm a wait and see person. However, the way I think about technology Is I don't look that much into the hype, right? Because if you look at every technology at their marketing page, you will see a lot of hype. And sometimes a lot of technologies are marketed as if they solve all the problems in the world. That's not actually the case, right? Because in the end, they're just here for solving a specific business problem. So this is more like a rule of thumb of how to judge a technology is what is possible now using this technology, but it was not possible before. So I'm trying to understand the reason behind this technology existing. And if this reason is clear enough, or if this reason gives me a definitive reason for adopting it right now, I will adopt it. But in most of the cases, I don't adopt it right away. I wait and see and I go with something that's fairly known. And this might also be the case because I've been working in large and very large companies. So, adopting new technology right off the bat can also pose a risk for stability, for governance, for security and for other things. But being aware, I think it's super important because if you are aware, then you can, you can adopt, but if you are not aware, then you won't be able to, to adopt it.
Kovid Batra: Correct, correct! So I think it's, it's more like that you analyze and research at your own level. And if the problem, which the technology solves is pressing enough for you, you give it a early try. And if it is not, of course you are a late adopter for things.
Mihai Valentin: Yeah. Yeah. Of course. Yeah.
Kovid Batra: Love that mindset. Great, Mihai.
I'll move on to the next question. This is a funny one. Which is your most used keyboard shortcut?
Mihai Valentin: Hmm, okay. I would make a joke like maybe 10 or 15 years ago, it would be control+C, control+V for copying and paste code. But that is no longer the case. The most used key that I have today is command+shift+F. I find and search a lot. And the reason for that is in any tech organizations I work with, I don't work on a specific project. I work across the whole business, so this requires me to have an end-to-end understanding of all the moving parts of all the services of how data flows and so on. So most of the times I find myself going from repository to repository from understanding how data gets from here to there, where is something used, how many times is it used, where is it used from, so that requires an extensive search. So I'm searching and reading a lot of code on a daily basis to understand how things are going.
Kovid Batra: Great. I thought when you said earlier, 15 years back, it was controls+C, control+V and now it's not there. I thought you were going to say chat GPT or something like now I don't code. I asked chat GPT. What's the code?
Mihai Valentin: No, chat GPT is super, super useful, but you need to give it a lot of context if you want for the answers to be really helpful, because if you don't know what you're asking, then yeah.
Kovid Batra: Great. And I think we'll move to the last question of our fireside chat. Which is your favorite mantra that you live by?
Mihai Valentin: Okay. So, my favorite mantra that I live by is a combination between life and career. And I would call it something like live your best life so you can do your best work. And the reason I live by this mantra and it's always on the back of my mind is because I met so many people who unfortunately postpone living their best life until they get to retirement. And they are hoping for one day they say, like one day I'm going to live in that beautiful place. One day I'm going to do what I want to do. And the truth is that you can actually enjoy life while working eight or nine hours per day if you live in a place you love and if you have a role that you love and for some people, sometimes this seems hard to grasp because it seems complex, but all you need is a remote role. You need a Airbnb in a place you love, and then you just work during the day and then enjoy your evenings, enjoy your weekends. And if you do this for a couple of weeks in places you've always wanted to visit, this should be extremely beneficial for you. And you'll see that the quality of life will increase and then also how you see work and how you see the future will definitely change.
So, yeah, live your best life so you can do your best work.
Kovid Batra: No, I totally relate to this and it takes years for people to actually to arrive at this position. So, like Einstein used to say people know things, people understand things, but believing in them and living by them is something that really takes time. So, I'm really happy to hear that, that you believe in this, and I'm sure you're living your life like this. Would love to give this thought to everyone in the world and not just dev teams but everyone because this is the crux of life according to me also. Great. Mihai. I think we'll move on to the main section and main section is all about leading dev teams and today we'll be specifically talking about your area of expertise, your area of interest, which is more around whether you should build or you should like buy, making a decision there so that you can reduce cost, improve the time to market, do all those things. And a lot of engineering leads, engineering managers, find it tough to make that call. But before we jump onto that area of expertise, I just wanted to understand a few things from you. You have been working with companies like Meta, Datadog, and you are currently working as a mentor and contractor with MNCs. There have been a lot of challenges which you would've faced while leading these teams, right? Can you just bring up certain experiences of yours, like one or two, which would be really helpful for other people to learn from you because every time you come across a challenge, you solve it. And when you look at it in retrospect, you have a good perspective on how actually that problem could have been solved. And in fact, in that situation, you would have done extraordinarily well. So any of those examples would really, really help our audience to understand how to actually lead teams like pros.
Mihai Valentin: Yeah, definitely. So one thing I've seen how it works and how it fails. Because if you want to understand, how to do something, you need to see it working, and you also need to see it failing. So only after you see both sides, you know, what would be the best way to do it. So one such thing is consistency. So for example, if you as a small company, let's say of 20 to 50 engineers, if you build your tech organization in a consistent way, then you would be able to ship faster. You will not have to waste so much budget on operational tasks and so on. And what I say by consistency is using a single stack, for example. Unfortunately, there are so many companies that use, let's say, react and javaScript for the front end, then they do some Python and maybe some go on the back end and then they make a microservice in rust and then they use some other language for some other microservice. And the truth is it can be exciting. Like it is exciting for engineers to build all these new services in all these technologies. But then when they need to manage when they need to be fast in them, they will not be able to do it because first, it's very hard to move one engineer from a team to another to be able to help because they know different languages and different tech stacks. Second, there's always going to be some corner cases or very weird bugs in each of the tech stacks. So if you have three or four tech stacks, you're going to have three times more, weird bugs or situations that require debugging and lose time. And down the road, like immediately you won't notice it. But down the road, it's going to be so slow because you're not working as a single team. You're working as three or four or five different teams that are trying to solve a problem. So what I've seen works incredibly well is using a single tech stack, meaning here javascript or typescript depends of how you prefer. I personally prefer typescript and then use it for the back end. Use it for the front end and then also if you're a company has a mobile app, use it for your mobile apps, and then you'd be able to build in an Android and build in an iOS. So it's one technology that you need to know, one build system, one test system, one knowledge of corner cases, like understanding what are the subtleties of the language. Um, and once you do that, you can move your whole company with the same speed. Otherwise, you would every time need to go from one thing to another. And the speed at which you develop will not be the same. And one other thing that I love about this approach is that you can do a lot of code sharing. So if you have code that's in multiple languages, it's going to be very hard to reuse a part of functionality from the back end to the front end and vice versa. So for example, validation, right, you do validation on the front end, but you also need to do it on the back end for security, of course. So in case you don't use the same language, you'd need to write the code once in JavaScript, and then once in Go or Python or Rust or whatever. But then if you have a single language, you write it once, And then you import it in front end and you import it in back end. And validation is not the only thing. It can be any sort of business logic that can help you.
Kovid Batra: Great. this is interesting. Just a quick follow-up question on this. Most of the times, when you are in a situation, you have to take a call, you choose a stack and you start working on that, right? You're saying that we should have a consistency here to have speed to not waste time on fixing bugs or catching corner cases for each of those stacks. So what do you think motivates the people to take the wrong step at the very initial stage itself? Like, can we inhibit that itself? Any thoughts on that?
Mihai Valentin: Yeah. So I believe it all starts from the engineering maturity. So the more mature an engineer is, the more their focus will be towards solving problems and less towards a given technology. So it this is kind of normal, because at the early phases of their careers, engineers are super excited to learn, to grow, to see how various languages work, like to see, oh, how is Go working, how is rust going? And it's totally fine. Like all these languages have their use cases, but unless you're using them for their strength, for their specific use cases, like for example, for high concurrency, which could be Go or like for high performance, which could be rust, for example, or for Python, which is fast development and also a bit into this whole data science, machine learning and so on, unless you're using them for the strength, then it might be better to actually use something like TypeScript, which is more like a general language that you can do a lot of things, even though you can do something like very specific, like I said earlier. And one way to prevent developers from going down this route of adding technology after technology in the team is to make sure you hire mature engineers and that you always talk to engineers about the fact that it's the results that we ship that pays our salaries and the customers don't care so much about whether you're using this technology or the other one, but they care about results. And the fastest we can go to get to those results, the better for us, the better for the team and for our iteration speed.
Kovid Batra: Perfect. I think that really helps in understanding how we can actually avoid this problem. They should be mature engineers. mature leadership who is taking call on that stack at least. And of course, learning is one good aspect, which engineers should be enthusiastic about, but it should be put right. Not at the cost of company's velocity.
Mihai Valentin: Exactly, exactly! Yeah.
Kovid Batra: Coming to this point of velocity getting impacted. This is a very important metric for every engineering team. How fast teams are moving, where are the blockers? So from your experience, as you said, that having a consistent tool stack solves this problem and of course impacts the velocity of the team positively. How in the initial phase itself, you are able to identify that, okay, teams are moving slow and this is the root cause. I just want to understand, like if this problem exists in a big team, how would you realize, let's say you come from outside the system. And now you see teams are moving slow or what is that indicator that tells you, okay, this is the problem.
Mihai Valentin: Okay, that's a very good question and I've been doing this many many times. So first I try to talk with engineers on the team. I try to grab them, have a coffee with them maybe, a very informal chat and trying to understand how they work, what they have achieved so far. And what they feel is currently blocking them. So this is the first thing to get the perception because sometimes perception is different than reality. But in order to make these two converge, I need to understand both point of views. So after talking to engineers and figuring out what's slowing them down or how their process looks like, I spend a bit of time seeing how the normal development workflow takes place. And one place I clearly look at is a PRs and code review because in some companies, code review takes so much time to complete. And for example, for a very small PR, there is a lot of back and forth comments. And, while this is extremely useful for the code quality, if that company is growing and it's very likely to rewrite that code in three months or so. Then it wouldn't matter so much if people are going above and beyond to make a perfect code review for that PR. As I said, I'm trying to look at metrics, like how much does it take a PR to get landed? How many comments usually take, like how detailed are these comments? Do people want to solve all the existing problems or people are just looking for things that would, I don't know, break or cause an issue in production if landed? then I also look at the pragmatism and the focus of engineers, like are the engineers talking about what to build? Or are they more talking about how they build it? Do they know the requirements? Do they know how their company makes money? Do they know what's the biggest cost of their company? So this again comes into the maturity of engineers, because the more mature an engineer is, the more they understand that It's the results that we ship that pays our salaries at the end of the month and not that the technology, the 100 comments on PRs and, and other things that really matter in this picture.
Kovid Batra: Great, Mihai. Thanks for this. We'll move on to the next question, which is interesting to you, to me and I think for our audience also. It is about building versus leveraging existing technologies. And it's a very hard call to take when you are on the go, you need to deliver fast, you need to take care of the technical debt and long term shots also. So how do you take that call in which situation it is good to build in which situation it is good to leverage an existing technology. Throw some light on that and give us some great examples like the previous one. I think people would be able to relate it better.
Mihai Valentin: Yeah. Yeah. Okay. So whenever I have to take these decision and I've had to take the decision many, many times, I always look at two things.I look at the cost and the time to market, like these are the only variables that matter in this equation. Nothing else like things like feelings, things like emotions over a given technology. Okay, they might bring up some discussions, but they are not actually, real data. And, for this costs and time to market, there's also another dimension, which a lot of the people don't look into is the first order costs. And the second order cost. So, for example, the first order cost is I decide to build from scratch, and I know it's going to take me three months, and I'm okay, this is the time. But if then it takes me two people, two engineers to maintain the solution every month, this can quickly add up to the cost. And this usually is a second order cost that people don't see it. So it's very rare that you can just build something, keep it in place, And require no maintenance, no bug fixes, no further developments and so on. So, that's something I really look into. Then, I usually go for a building or using a third party integration in case, the available SAAS's are extremely expensive or if they pose a vendor lock-in risk and there are no alternatives that would be easy to replace down the line. So for example, if there are two SAASs and they have similar APIs or similar ways of functioning, then I don't see this as a vendor lock-in risk because you can go from one to another fairly easy. But if they're not, then it's a bit risky to have the whole business rely on a single SAAS.
And on top of that here, coming more from the development point of view, every SAAS I integrated with, I don't integrate with it directly. I make an intermediary service, which is like a proxy, so to say, so that, the application communicates with that service using a very clearly defined protocol. And that service communicates to the SAAS through an API so that when I change the SAAS I don't need to change my application. I just change the service in the middle to know how to work with a different SAAS. So in this way, if my SAAS is being used from, let's say, 10 places throughout my code base and, requires some changes, then I just change in one place instead of changing in many other places.
So this is a very useful tip for development. Now I do also look into building or third party whenever what needs to be done is a strategic decision for the company. So for example, if a service is of strategic importance and we know that we're going to use it for the next, I don't know, 10 years or so, because it's like Core business functionality, then it might make more sense to build it because then you can build exactly the features that you want to have rather than try to adapt a SAAS, which is not going to have all the features you might want. And it's also going to be difficult to negotiate with a SAAS company to add various features that you might need because they need to serve hundreds or thousands of clients and not just you.
Kovid Batra: That makes a lot of sense. Great. I think, moving on to the next question, which is about moving fast. So moving fast is very crucial in this tech world and it also sometimes lead to technical debt, right? So what's your approach towards maintaining this momentum and managing the technical debt alongside that? How do you usually take a call on that?
Mihai Valentin: Oh, that's a good question. So technical debt, all these things are always correlated with the maturity of engineers. So I see technical debt as good technical debt and bad technical debt.
So it's like in finance, you can get a mortgage to buy a house, which is a responsible thing to do. But if you get the mortgage for consumer, which is of a higher rate, that's not ideal to do. And by splitting this technical debt into two things, like good technical debt and bad technical debt. I see the good technical debt as a way to move faster for shorter amounts of time. And for example, If you're applying this rule for a small company and, you need to release things very fast, then that code will definitely be refactor or rewritten completely in a few weeks or in a few months as you grow. So then you need to move there as fast as you can. Even if you add a bit of technical debt because at the end you just delete the code and rewrite it again for the next phase of growth, because usually as you grow in terms of scale, let's say 10 X to 1000 X, it's not going to be the same code. Because it's not going to be the same scale because things change and it's natural to change. So if you spend so much time crafting this code in a perfect way, then you spend a lot of time and then you just deleted that entirely. The debt will simply disappear when you rewrite the code. And then I keep mentioning this, but the more senior the engineers, the less technical debt will produce because what is the technical debt is a way to cut corners to achieve something fast and good, but if you are a senior engineer, you will not do a horrible hack. You will just do something that helps you move forward with a little expense. And if you understand what can break there? What are the limitations of what you did? Then that's absolutely fine. So it's okay to create technical debt, as long as you know what you are doing. You know how things are fail, you are okay with them failing at some point and you have a process in place to mitigate or to fix it. I noticed that also a lot of technical depth gets created when Teams and engineers aren't able to take decisions. So, for example, let's say an engineer works at a feature and the communication in the team is not perfect. And then the one engineer needs to take a decision. And if that decision is not the right one, that can create technical debt. However, if the whole team works together and is able to take very quick decisions on a certain topic, then technical debt is less likely to happen. Why? Because, think about it, you need to implement a given feature, and if you are able to let's say, write on Slack, make a poll, say, here's our context, here's our problem, here are the three solutions I propose for fixing this. Hey folks, please vote until, let's say 3 PM. So you give people time to choose and if they haven't choose, you go with whatever choice you prefer. And then if the culture in your team is to tackle these things immediately, to vote, to express opinions and so on, it's very less likely to end up in a situation where you create technical debt. So taking quick decisions together as a team reduce technical debt.
Kovid Batra: Makes sense. I'll not take much time on this, but just because I found it very interesting. Let's say I'm a junior developer and I'm working on a problem. I am sure to make certain mistakes, which could be from the scale of horrible to be okay with them. With every junior developer in the team, how will you ensure that whether they're writing the code piece right or not? Of course, code reviews are one good way of going about it. But when you say that teams should be looking at it together, and these are the solutions which would propose to avoid such technical debt. What should be done for the junior developers who are working, how their code should be reviewed, how they should be looked into so that they don't create that problem.
Mihai Valentin: Okay, that's a very good question. So I think, you need to treat juniors, not as juniors, but as people who will at some point be mid level developers, senior engineers, and even higher. And why I'm saying this is that instead of just giving a task with very brief specification, you would need to give a bit of context. Why are we doing something? How did we solve this in the past? So help juniors to make the right choice. Don't leave juniors isolated. Don't leave juniors without, let's say a mentor or without a buddy. Keep juniors in the loop with the whole team. Of course, as you said, code review is a very important step because when the juniors will put up a PR, everyone will come to review. And also here's a very important thing, not to do critical review. So don't say this is bad, this is wrong. Because you will demotivate the person. And, if you do this, you're lacking self-awareness that you've been in their shoes at some point, not long ago, most of the time. Exactly. But then help them and try to feel them welcome to ask questions because if they are not feeling welcome to ask questions, they will not ask questions and they will be afraid of doing this, and maybe they will take some decisions which can hurt the team. So, the most important thing here is to acknowledge that juniors are juniors. Juniors need help for development, for learning. And it's your responsibility as a team or as a senior engineer to make sure that they are growing a bit. Because the seniors today will be the senior software engineers of tomorrow. So, there no other way it's going to happen anyway, but at least make it happen in a way that everyone benefits from it. The junior engineer, the company, the team, everyone.
Kovid Batra: Yeah. I think this is a good way to go about it.
We should just always keep the junior developers also in the loop in terms of the context, in terms of taking decisions. And of course, reviewing is one good way of going about it, but assigning a buddy or a mentor would really, really help. Great. Mihai great thoughts. I know you are leading the best team. And people in your team would be happy. So I think, the last thing that I just want to know, the name of your newsletter- "How did I get here?" So what's the reason for putting out this name? It's a very interesting one. I have recently subscribed to it and I'm loving reading it. So what do you have to say about it?
Mihai Valentin: Thank you. Thank you. I started writing on LinkedIn for the past one year and a half, I guess. And initially I started writing like once per week and then I ramped up to write many times per week. And as I wrote, as my audience grew, people came to me, messaged me and told me, Wow, Mihai, you have such a, such an impressive profile and CV. And I'm like, No I mean, everyone that puts in the work, everyone that takes the right steps, everyone that's open-minded and wants to get things done, will be able to, to get in these companies to get this experience. And so on. It just takes the work. So then I thought, what if I instead of just talking about what I know, I'm talking about, how did I come to know the things that I know and how my mindset go to be the mindset that I have today? So then I thought, it doesn't make much sense if I just throw things like out from a position of someone who has a lot of years of experience, but then show what were the steps, like what were some key moments of my career in which I learned something that has made me challenge my assumptions and drove me further up the growth slope. So I called it, how did I get here? Because I'm interested in sharing not only what I know now, but also what were the steps that I took to, to get here and not only the steps, right? Because the steps are fairly easy, right? Like you interview, you get into Facebook, then you interview, get into another company, and so on. But no, What was the toughest thing when interviewing? How did I view interviewing before or after? What was my biggest fear? How did I overcome it? Who did I learn from? What did I read? So all these things that create a context around what happened rather than just saying it happened. Right?
Kovid Batra: Makes sense. Interesting. That brings us to the end of the show. It was a really nice talk and would love to have you again.
Mihai Valentin: Likewise. Kovid. I really enjoyed talking to you and looking forward to talk to you again.
In the recent episode of ‘Beyond the Code’, Host Kshitij Mohan, founder of Typo, engages in a thought-provoking discussion with Jordan Cutler, Senior frontend engineer at Qualified. He has also contributed his expertise to reputed companies such as Twitter, Dolomite, and Gusto. The heart of their conversation revolves around Metrics, strategies, and burnout prevention for tech teams.
The episode kicks off with Jordan recounting his inspiring journey, followed by a fun fireside chat. Following that, he imparts valuable wisdom on achieving a balance between team dynamics and leadership roles as a senior engineer. He delves into the effective utilization of metrics and new tech tools along with addressing the critical issue of developer burnout.
Wrapping up, Jordan leaves the viewers with valuable advice on continuous learning and nurturing personal growth.
Kshitij Mohan: Hello everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by Typo. Today’s guest is a young gun of the engineering ecosystem. Within a short span of eight plus years, he has evolved from being a software developer to an engineering coach, to an author of a newsletter. He has worked with teams at Twitter, dolomite, Gusto, and so on.
Please welcome Jordan to the show. Hey, Jordan.
Jordan Cutler: Hey, how’s it going? Super happy to be here.
Kshitij Mohan: Thank you so much for sharing your time with us. Means a lot.
Jordan Cutler: Yeah, thanks. I’m super excited to chat more and get this going.
Kshitij Mohan: Definitely Jordan. I think before we start with anything, right? First, we would love to understand your amazing journey, right? And the kind of mission that you are on today to help fellow engineers achieve their career goals faster. I think this is really interesting. So to begin with, please share some light on the journey that you have been on, Jordan.
Jordan Cutler: Yeah, totally. So I started off interning at Twitter. At the same time, I was actually working at Dolomite, which is like a crypto startup by a couple alumni at the same university that I went to. So I was kind of working two jobs. That’s kind of what helped me like catapult a little bit, to be honest. But I wouldn’t recommend anyone to do it. It definitely like got me to the point of burnout. But it definitely also helped me get a really good start to my career. Know a lot. I got kind of the mixed bag of experiences between working at a well-established company Twitter.
And then having no code at all and going from no code to 80,000 lines of code and mentoring the other engineers on the team. And when I started at Gusto, it was a really awesome experience because it was kind of in the middle ground. So I kind of have like this very wide, you know, range of like small, middle, large, and Gusto was super awesome too. It was like a startup within a startup was the team that I was on. It was like a financial products team that essentially helped people, get access to their paycheck before their normal payday, their biweekly payday so they could get their paycheck a week in advance.
And it helps people in like, you have a car breakdown, get in a hospital situation and a lot of people live paycheck to paycheck. So, it was like an entirely new product we were working on. So it was almost like a startup with the security of a bigger company behind you.
Kshitij Mohan: Yeah
Jordan Cutler: So it was really awesome, man. And I loved the experience there. That’s how I ended up getting to the senior level pretty quickly. I got back-to-back promotions up to senior and then now I’m working at Qualified and I’m here doing mostly like front end development, infrastructure, platform platform-related work. And it’s just been awesome. So that’s kind of the journey.
Kshitij Mohan: Awesome. And how did you land on to this thought of running your own newsletter, supporting other folks in the career journey? This is a really interesting part that we’d love to know about.
Jordan Cutler: Yeah, a hundred percent man. I think what happened was at Gusto, I did this thing where I gave a lot of the advice that I give on LinkedIn, but in Slack, and it kind of blew up into like this channel that was just kind of typing notes out to myself, like writing my learnings and it got to the point where I think there was like 60 people in the channel and I wasn’t really like advertising it that much or anything. And I was like, oh my gosh, people actually really enjoy some of this stuff. And so I think eventually I thought, wait, what if I like put this out there into the world? And I just started with like one LinkedIn post. It did pretty well, and I was like, wait, let me just keep this going. And so kept on going and then eventually turned it into a newsletter. And now, yeah, we’re up to 7,500 subscribers. I think like 25 paid subscribers, which is more than I could ever imagine having got, it’s so awesome. I’m so thankful. And, the LinkedIn growth has been really awesome too.
Kshitij Mohan: Yeah. It looks like your content is read, shared. I think you must be doing something amazing that the community is loving you, Jordan.
Jordan Cutler: Yeah, I appreciate it, man.
Kshitij Mohan: Perfect. So, I think before we get started with anything, I think we would all love to have some quick fun fireside questions with you to know Jordan as a person more. So if you’re ready, let’s get started.
Jordan Cutler: Let’s do it, man.
Kshitij Mohan: Perfect. So question one, Jordan, if you were not a coder, which alternative career path you think you would’ve chosen?
Jordan Cutler: Yeah, this is a good question. I think like a while ago I, it probably would’ve been like accountant or you know, finance or something like that. But I know that’s like a classic answer for engineers to think if I were to go like the more creative, like fun route though, it would probably be like photographer.
I’m definitely like, I love photography. I love getting into taking pictures and taking cool stuff.
Kshitij Mohan: Great. So is it like more of a, a nature photography or some abstract?
Jordan Cutler: I think like just in general. I like taking pictures of animals for sure especially cats. I got like a couple closeups of my outdoor cat the other day, so that was really, really nice.
Kshitij Mohan: Perfect. Question two for you, Jordan. What’s the favorite tech gadget that you use daily?
Jordan Cutler: Okay, so I think for this one I’m gonna give you like, the most unique answer you’re probably ever gonna hear is my blinds. You know the window blinds. I got these automatic blinds where it’s like the smart blinds and they go up and down at sunrise every single day automatically. And I think it’s like the best thing ever. It’s like just totally automated. You don’t need to worry about it. The light is kind of the same every single day.
Kshitij Mohan: Definitely, this is one of the craziest answers, Jordan, that we’ve ever heard. So kudos to you for doing this. Perfect. So last question, right, so about this high growth engineering newsletter that you write, So what’s that one piece of advice that you think every engineer should know in their career progression?
Jordan Cutler: Yeah, definitely. I would say there’s a lot of focus on code. But as you get higher and grow to the more senior levels, you’re gonna see that focusing on code can only get you so far. And it’s really like the relationships and building that strong bond between your teammates and your manager, that is gonna get you further and further. And it’s good to focus on that.
Kshitij Mohan: This totally makes sense. I think it’s always the people skills that take you longer than any other aspect of your work. Perfect. Perfect Jordan. This was cool. So, now getting to the real stuff, right? So just to give you a quick context. So we have been having these, interesting, insightful conversations with a lot of engineer leaders, senior engineers of the ecosystem, but we thought, Hey, how would a perspective of a senior engineer would look like, right? How do they fit in because they are always stacked between the senior leadership and the team that they’re supporting with, and that’s how they’re kind of building the entire ecosystem. So we believe this is the toughest phase of any journey, right? Where you have to balance work, relationships, teams. And I think this is what we would love to more talk about with you today. And I think to begin with, the first aspect comes in how do you build this balance, right? You manage teams as well as you manage the expectations of your leaders as well. So, would love to start with these thoughts, Jordan.
Jordan Cutler: Yeah, definitely. I’m trying to think. One thing that typically comes to mind that a lot of ICs want to get done compared to management is like cleaning up tech debt, right? Management is typically like, Hey, we need this new feature. We need this quickly and all that. And I think a lot of times it can be up to the more senior ICs or tech leads to try to help bridge that communication to help management understand better. You know like, hey, we need to focus on the stability aspect here and one good way to do that is to literally show examples of where the stability has failed and say, like this last feature rollout, it went bad because we didn’t have our stuff together in this area of the code and we had to take shortcuts or, we didn’t do proper testing all that and help them understand a little bit better that like some of these things are gonna take a little bit more time.
Kshitij Mohan: This totally makes sense. I think a very good thought, Jordan, that there is always discussions around tech debt. You would want to, but again, you are pulled back, no, hey, this is what you wanna focus on. And I think talking about this itself, so as you mentioned, right? You would want to show some things to the engineering leadership to believe, Hey, this is where we are at today, right? For example, a feature failure that you mentioned, right? So, in your experience, have you seen using any metrics or any sort of visualization that kind of helps everyone understand- hey, this is where we are at, this is what we need to focus on, any other things that you have used maybe in your experiences so far?
Jordan Cutler: Yeah, yeah, definitely. A couple things that come to mind are one thing we’ve done is track issues in bug snag. So, it’s like a kind of like your standard error reporting tool where you could see how many errors are occurring. And you could point specifically to that. There was one point where I think we were able to show that there was like 5,000 user errors occurring like every month. And you know, show exactly like, hey, these are all the different areas. It’s normally like, you know, because. This stuff is not in TypeScript or we don’t have our proper error-handling patterns in this area. And from that you could say, Hey, we need to focus on this a little bit more. The other thing I like doing too is you could track specific metrics at CI time. So one thing like we’ve done before is track how much of a percentage of the code is in like the new system versus the old system and we could say like, Hey, you could see like this part of the code here is just not entirely this. And for some reason when you put it on a dashboard versus just saying it, it makes it that much more like impactful.
Kshitij Mohan: Exactly. Things does go serious as soon as you put it out on a dashboard.
Jordan Cutler: Exactly. Yeah. So I’d say in short, if you can get it on a dashboard, that’s the ideal situation.
Kshitij Mohan: That’s the idea. Perfect, perfect Jordan! This is great. And while you talk about all this, right, we talked about managing teams. In this aspect, there is a very critical aspect that every devs get kind of very excited about introducing new tech in the team part, right? There is always something or the other evolving, and then there is learning curve also. And then there are expectations of your teams also that, hey, we need to balance this stuff out, right? So any specific thoughts around how do you manage those introduction of new tech in the teams, and how do you generally go about it?
Jordan Cutler: I feel like I’ve had a lot of experience with this ’cause there’s so many different tools. Like, I’m always trying to find that next best thing to try to bring to the team. And that honestly, just taking a side, I would say, Something to be careful of. But also one of the best ways that you could like try to enhance your growth like earlier on, is if you can find ways to take the initiative and level up the team in ways that they didn’t even know that they could, then that that’s gonna be awesome. One thing that I’ve brought to the team at both Gusto and Qualified is like storybook as an example. Storybook is like a tool where you could document like all the existing components, that exist in the front-end app and it helps people see like, oh, this is how you use it. It shows code examples and you could just copy and paste into the code and it just works. And then you can also use it as a prototyping tool. So one thing that I would say whenever you introduce a new thing, try to make it as easy as possible because people don’t like change and try to show the value right away as well. So if you could like, do like a small little prototype, like what I did was I put together a little storybook mini app showed a couple of the code examples that we have existing and showed just like how you can copy and paste and be like, oh, you know, boom, it’s done. And the code, the new component is there and everything is like visible on the left side. And so having that like prototype and easy one command that you just run either to turn it on or run it, is I think like one of the best ways to make things easy. The last thing I would say is just making sure that it’s being communicated in multiple channels. Because if you just do it in one, people are gonna miss it. And even if you do it in multiple, people are still gonna miss it. But at the very least, you tried. Yeah. So not just Slack, but like Slack plus a team meeting, plus your all engineering meeting or documentation and like Confluence or notion or something like that, right?
Kshitij Mohan: I think this is how people evolve also, right? You need to keep on identifying the new ways in order to optimize the entire team structure, and this is what gives you that extra set of learning as well that keeps you ahead of the curve. So I think this totally aligns with it and while talking about this new tech, right? And I’m pretty sure you are right in the midst of everything that’s happening with AI around, the dev productivity, and all right, there are so many tools. I think every day a new tool is being launched today, powered by something or the other to ensure that teams, especially dev teams are being more productive, right? So, Your thoughts on these? Have you been using some? How do you feel what exactly is happening in this ecosystem for the devs?
Jordan Cutler: Yeah. It’s a great question. I am big on AI for sure. At the same time though, I am cautious about introducing so many new tools. I feel like there’s kind of a balance that you need to find between introduction of new tools and the value you’re getting out of it. Because if you have like 20 tools to manage and you’re introducing a new one every day, no way you’re gonna be able to keep up and balance everything. I personally use a co-pilot and Chat GPT the most and I think eventually I’ll probably integrate with maybe Chat GPT plugins or maybe some wrapper around Chat GPT. But I know, like exactly kind of what’s happening under the hood and, I think like copilot is, honestly, it’s been a huge productivity boost for me, for sure.
Kshitij Mohan: What do you like most about the copilot? Right? So what really helps a dev in a GitHub copilot setup?
Jordan Cutler: Copilot is so much fun for testing for sure. Because like what I do is like I’ll name the test. And then I’ll just hit enter and then tab. And then hit enter and then tab and it just keeps on filling in exactly what I would’ve wrote pretty much. So that is pretty fantastic. It just saves me so much time typing and all that. And it just makes us be able to get so much better test coverage because you’re incentivised to just add more. It’s so much easier to do. I think that’s probably one of the biggest things. I think it’ll be interesting how copilot, changes the dynamic for more junior engineers because I do suggest people, like junior engineers use it because it’ll help them understand more of the language features and like what is possible at the same time. Sometimes it does give bad suggestions. So, I think there’s nothing still that like can trade having like that hands-on, like in-person mentor that has like been through it and very experienced type thing.
Kshitij Mohan: Right. So there is always this debate going on, right? And specifically for folks who are just starting off, especially in the dev ecosystem. There is so much on auto mode right now that they might even miss on learning an important aspect of the entire engineering part. Right?
Jordan Cutler: Yeah.
Kshitij Mohan: So I think how will you even ensure that there’s a balance that’s been maintained?
Jordan Cutler: Yeah. One thing is to try to like, from, especially like managers, should try to do like matching as much as possible to ensure that a junior engineer has a mentor that is more senior that they could go to. And then similarly it’s just as important for the senior engineer to find someone to mentor because that’s how they can grow as well. You know, get into the next position, whether it’s, you know, staff or go into management or something like that. And so making sure that they have that support on projects that they’re working on or just in general, having some that, that they can talk to and help learn how to grow and create a growth plan with I think is hugely important.
Kshitij Mohan: Yep. No, no this is really good, Jordan. Now, I think coming to the most important aspect, right, where everything just culminates together is ensuring that as a developer, as a senior engineer, that you feel you are not burning out, right? You are kind of able to balance. Your work, your life, your success goals, everything that comes along. So what’s your take on this here? You must have, you already mentioned that you would have been in that state at some point in time and then you kind of reflect back, Hey, no, no, this is not the state that we should be in. So what’s the developer’s perspective over here?
Jordan Cutler: Yeah. It’s a really good question. I think that you definitely can work a lot and still not burnout. But you have to be very self-aware and you have to understand if the work that you’re doing is draining your energy consistently or if it’s helping you get your energy back because I’m sure you’re aware you’ve been in the industry like there’s certain tasks, right? Nobody wants to do.
Kshitij Mohan: Exactly.
Jordan Cutler: It drains your energy.
Kshitij Mohan: We hate test cases, we hate documentation. We hate the review budget.
Jordan Cutler: Exactly. Yeah. And if you spend, you know, like you’re 60 to 80 hours and you’re overworking yourself doing those types of tasks well yeah! You’re gonna burn out but if you essentially let’s say you do a portion of it and it’s those types of tasks that do drain your energy, but then you do something that you’re super excited about and you have been looking forward to, and your manager allows that space for you to do some of that.
Then that allows you to keep your head up and not burn out and, you know, maintain your energy. So I think it’s kind of about managing your energy more than anything else.
Kshitij Mohan: Oh, got it. I think you have to ensure that your creativity juices also keep flowing along with every other thing that you’re working on.
Jordan Cutler: Exactly. Yeah. And you know, I can also give like some advice like for Managers, and I think like tech leads as well, you know, try and watch out for their ICs burning out. I think one thing is they should make sure that there’s like weekly one-on-ones, or biweekly, probably weekly with your manager and then maybe biweekly with like teammates or something like that. And use that like as a time to catch up, you know, the person that you’re talking to is genuinely being honest with how they’re feeling or what’s going on. Then they’ll tell you like, things are not that great. And you can always start too from like the manager side, you could start with like, Hey, gimme like a score. Red, yellow, green. Where are we at? What do we need to do? Because I think if you start that way, it really shows that you’re caring about what score they give and that’s what the whole meeting is about. The meeting is about making sure that we get you to a green. What do we gotta do to get there? And hopefully, they’ll, you can have a conversation.
Kshitij Mohan: Right? But I believe here, Jordan, it’s very important that the leaders should ensure that basically, they have to show that they are vulnerable as well. And that’s how kind of your developers start opening up, right? Unless and until they don’t see you taking a step forward saying, Hey, I might miss out on few things. Hey, I know things are going hard these days, but okay, let’s just talk about it. I think that’s a very critical aspect that every leader, manager should be first taking out, right?
Jordan Cutler: Yeah, definitely. Some of the times that I’ve opened up the most have been like, after my manager says that they’re not feeling that great. Because it’s hard because sometimes you need to always act as things are good because at the end of the day, your manager is the person that does rate you on a performance scale. And so, if you do come to a every single meeting and you’re saying, well, things aren’t that great, I wouldn’t recommend that to an IC to be a hundred percent honest, you should try and like maybe use your mentor for a little bit more of that and try to figure out how you can not do that with your manager a hundred percent of the time. Definitely should, sometimes for sure. But at the same time, yeah, if your mentor is more vulnerable, then it does open you up to feeling more comfortable doing the same thing.
Kshitij Mohan: Perfect, Jordan. This was great. Any parting thoughts, Jordan? Any key advice that you would like to give our viewers who are watching you, learning from you? Any specific thoughts on anything that you would like to share Jordan?,
Jordan Cutler: Yeah, it definitely sounds kind of cheesy for sure. But, I will say that as we grow, it sometimes we stop focusing on learning, and I think there’s always room to improve no matter what level you’re at. And so just keep that drive going. You know, focus on growth always. There’s always room to improve and if you’re not getting feedback from your manager or your mentor, when you say like, Hey, are, are things going, okay, push harder because like there’s always something that you can like be working toward.
Kshitij Mohan: Beautiful. Keep that hunger alive.
Jordan Cutler: Definitely. Yeah.
Kshitij Mohan: Perfect, Jordan. Thank you so much. This was such a great conversation. Thank you so much for your time today. We’ll definitely see you sometime around again. Thank you.
Jordan Cutler: Yeah, for sure. Thank you so much, Mohan.
In the recent episode of ‘Beyond the Code’, Host Kshitij Mohan engages in an insightful conversation with Richard Donovan, director at RD Coached. The central theme of the discussion revolves around helping leaders and developers balance well-being and success.
The episode starts with Richard recounting his inspirational journey, followed by an engaging fireside chat. Afterward, Richard imparts valuable wisdom on managing the 'Not knowing everything' mindset as a leader and effectively delegating tasks. He takes a deeper plunge into developer mental and physical well-being and the challenges associated with it.Lastly, Richard leaves developers and engineering managers with essential advice to navigate this journey effectively.
Kshitij Mohan: Hello everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by Typo. Today’s guest has had an amazing journey of evolution while being in the software engineering space for more than 22 plus years. Right from being a software developer to a leader, to a mindset coach today.
He has a very unique perspective on helping leaders and developers balance well-being and success. And this is what we would be talking to him today about. Please welcome Richard. Hey, Richard, Welcome to the show.
Richard Donovan: Thanks for having me, guys. Looking forward to it.
Kshitij Mohan: Thank you so much, Richard. This is really great. We are so happy that you could find time for this. So thank you so much for being here. Perfect. I think before we start on anything, Richard, and as I mentioned, we saw a lot of content about you, what you write, what you post. I think we are just so amazed by the kind of journey that you have had. Right? And you talk a lot about mental well-being, emotional well-being, physical health, and while combining all these aspects with the engineering piece as well. So I think. Before we talk about anything, I think we would love to understand and just get a quick glimpse of how your journey has been.
Richard Donovan: Well, it’s been a long journey as you’ve already pointed out, and it’s been an interesting one. So for those that don’t know, I’m a self-taught developer, so I don’t have a degree. I didn’t go to university. In the first job that I had, I was pointed at a stack of books on the shelf and a few people kind of said, “Look, read this one, read this one”. And I took them all in the evenings. I read them. I start to build things and six months later, that company took a chance on me as a junior developer. I did that for a little while, and that company decided to rewrite their entire software suite in the .NET framework, and that was in .NET 1.0 so…
Kshitij Mohan: The beginning of time!
Richard Donovan: I’ve basically been working with .NET since 1.0 and I still work with it now. So it’s been the biggest part of my career. After that I’ve worked in all different levels, I’ve been a junior, I’ve been a mid, I’ve been a senior, I’ve been a manager. I’ve been a software architect. I’ve been a contractor. So I’ve really kind of explored so many perspectives and I suppose one of the things that led me to move into mindset coaching is when I actually reflected on my career. I remember particularly early on being extremely introverted. I hated speaking up in meetings. I hated meeting new people. I used to just get so embarrassed and hot and bothered and all of those things. I didn’t like sharing my ideas in meetings or when we’re estimating. I didn’t really contribute to the conversation. And also, even though that stuff was going on and that was really holding me back, one thing I did always do was fitness. So that’s carried me through when other things were maybe holding me back. So I’ve historically got a lot of confidence from going to the gym and, and my fitness journey.
And then later I started to work on my mindset. I started to realize that it was actually holding me back. And when I started to work on that, I realized that the value that I was bringing to businesses and my role was actually a lot more about me and how I communicated with other people and how I shared my ideas, all these things that I wasn’t doing before, and it was a lot less about the code that I was writing and you can probably imagine that that leads quite nicely into leadership roles when you kind of get that realization that actually it’s you as a person that is the value and not the code. So that’s a kind of a fairly brief summary of a very long journey, shall we say.
Kshitij Mohan: Oh, amazing. Richard. I think that’s definitely inspiring to a lot of us and most of the things I think we all can relate to and so glad that you found your way to keep going, and I think that’s what kind of made you what you are today. So glad to hear this, Richard. Perfect. I think before we get, and I think this is what we are gonna talk about a lot more today evolution in this journey, growing from the starting aspect of NIC to all the way around.
But I think before we do that, Richard, we would love to ask a few quick fireside chat questions that we have for you. Just to add some fun element to your already amazing journey that you’re on, and while on this, what you learned is what you would love to hear. So if you are all set, I’ll just get started with that.
Richard Donovan: Go for it.
Kshitij Mohan: Perfect, Richard. So first question, what’s your most favorite podcast that you listen to these days?
Richard Donovan: I would say the Huberman Lab podcast.
Kshitij Mohan: May we know what was that about, Richard?
Richard Donovan: It’s a guy called Andrew Huberman and he goes into neuroscience of all kinds of topics including sleep, focus, motivation, you name it. He goes into massive detail and into the neuroscience of how the brain works. And it’s quite detailed and, and they’re often quite long episodes, but it’s really, really interesting.
Kshitij Mohan: Perfect. And I think we have found something to share it with everyone after the podcast. So this is something I think then we all should just get hooked to. Perfect. Question two Richard, the best non-tech book that has unexpectedly impacted your coding mindset as well?
Richard Donovan: I would say “Atomic habits”
Kshitij Mohan: Oh, Atomic habits.
Richard Donovan: And it’s not only impacted my coding mindset, but it completely impacted my mindset for life as well. Yeah.
Kshitij Mohan: Oh definitely that’s a great book on building habits, breaking things down and helping you move ahead. Oh, lovely book by the way. Yeah. Perfect. One last thing, Richard, what’s the motto of your life or your entire thought process that you have been working on, and what resonates you today?
Richard Donovan: I think it’s actually, it’s a bit self-indulgent, but it’s one of my own now, and it’s, there’s nothing more important than your own self, and your own well-being.
Kshitij Mohan: Definitely. And I think you are speaking from your practical experiences to say the least.
Richard Donovan: Absolutely.
Kshitij Mohan: Perfect. Perfect. Richard, this was really nice. Thank you for being so candid and sharing your honest and lovely opinions about the things that you have been doing in your personal space. I think moving forward, just picking up from where we started, right? Talking about your journey and how you kind of evolved and how fitness kind of helped you during this entire process. One quick question here, right? So, while being on this journey, you never realize at that instant in time, right, what’s happening with you, and it’s generally the hindsight reflections of what’s happening and what’s not. Right? And while being on this journey this is I think, the most challenging aspect. And when you put this into the dev ecosystem, this really becomes a lot of things to balance and work out. Right? Any specific thoughts on how you were able to figure this out while on the go, or any specific thoughts around that?
Richard Donovan: Actually for a long time, not really, so much of it was actually navigating the struggle and I think at a certain point in time, I don’t know where it came from, but I had a little bit of a realization. Maybe some of that comes with age. At the time I was getting closer to 40, so we might call it a midlife crisis. I don’t know, but I had a moment. I was sitting at work and I just had a thought and it’s a little bit morbid, but it was about time and I thought if for whatever reason, I was laid on my deathbed and I was looking back at the time that I’d spent here and how I’d spent it, and I thought if I continue to spend it how I was, which was sitting in front of a computer and tapping a keyboard. I just asked myself, would I actually be happy with that? If that was all the time I had. Perhaps it is, perhaps it isn’t. But if it was, would I be happy with it? And the answer was no. And in that moment, kind of just decided to myself that actually what I want to do, if I look back, I want to be able to have had an impact on other people around me. And, that was because I just felt like I could do that. And I spent a lot of time not doing that.
Kshitij Mohan: Hmm. No, I think that’s definitely the ultimate realization of changing the way you work and changing the way you live. So this is great, Richard. Now bringing these things to the dev ecosystem part of it, right. Working and how the things evolve in this entire dev chain. So, there are a lot of pressures while you are going ahead, building, leading, right? And one of very critical pressure that we have all felt is a pressure to know everything, right? And in this kind of competitive world this just surpasses everything. Your thoughts on how to balance this stuff, how, how the managers, leaders, and because that’s where, as soon as you keep on growing up the ladder, I feel this is what keeps on growing, along with you as well, that hey, expertise and, and you should be knowing it all thoughts, right? So your take on this Richard.
Richard Donovan: Yeah. I think the ultimate take on it is to stop thinking that because it’s not necessary. But you know that being said, I’ve been in a couple of leadership roles where that is exactly what I thought, and to be honest with you, I didn’t deal with it very well. I dealt with it badly, and those jobs didn’t work out very well for me and for the team. We might have got some software out the door, but we probably didn’t feel very good doing it. These days I don’t carry that with me. I don’t believe that you need to know everything to be able to lead. And I try and share that with my teams as well. And I openly share that, you know, I don’t have all the answers, and software development is a team game and, you know, contributions come from all sides.
Kshitij Mohan: Right! And I think this is really important, right? How do you keep on telling yourself, Hey, this is fine, right? You just need to pass on better. Maybe you just need to delegate better in order to drive the ultimate outcome that you as a team are trying to achieve. This is where I feel we lack a lot of, as leaders and managers, the right art of delegating things well, right, because. Other than that, this is a great way of myself also relieving a certain pressure of knowing everything to actually making people, push up the ladder and say, Hey, now let’s just start distributing more, driving more. But I think this is definitely an art to learn and go by it. So your take on this, Richard, you must have had certain experiences to live by this.
Richard Donovan: Yeah. I’ll probably repeat myself a little bit during this, but again, in a few of my earlier roles, I just didn’t do this very well at all, and I tried to take responsibility for everything and I tried to do everything right and I tried to go to all of the meetings and I tried to do so much of the work and eventually, I got to a point and I realized I can’t do all of this, and I wasn’t sure whether some of the developers that I was managing could step up and do a bit more than just the code. But it got so much that I had to try and trust someone with that. And I did that in this instance, I handed over a project to one of my developers. I didn’t know if he could do it. But he stepped up, he delivered technically, he communicated really well with the business, which was really important because at the time I was failing to communicate with the business ’cause I had so much on and they couldn’t see progress on this project. And when I handed it off, actually this person communicated really well. The business started to see the progress. And actually, it was quite a, quite a lot of stress off my shoulders, to be honest. And you know, that was a bit of a defining moment for me to realize actually I can’t just do it all. I can’t keep hold of everything I’ve got to let go. And, also to trust and as a leader, that’s a really important message to give to your team as well, that you trust them and that you’ll just back them and help them. And you know, that for me it’s a really important message and again, something that I didn’t do in my probably first couple of roles really.
Kshitij Mohan: No, definitely. And I think what we have seen over time and again is that in such circumstances people do shine. You just need to give them the right information, the right platform, and they can just make everyone’s life better. Definitely.
Richard Donovan: Yeah. Absolutely.
Kshitij Mohan: And while doing so, right? Talking about all this a circle of pressure, keeping things to yourself, right? Not delegating and thinking, Hey, it’s me who just has to solve it all. This is what eventually leads to burnout and maybe not the right state of this mental and physical well-being, right? And. luckily over the past few years, we have started seeing this wave of leaders, engineering ecosystem talk about developer well-being, burnout, developer experience, right? Would love to hear your thoughts on these aspects, right? Because we definitely have seen along with your journey, this is what, the closest thing that’s close to your heart when this is what even you are trying to achieve in what you are doing today. So we’d love to hear your experiences on this aspect, Richard.
Richard Donovan: Yeah, so well-being in software development, I think it’s so big and it’s something that over my career, I think it’s been massively neglected. I didn’t ever feel like I was supported with my wellbeing at any time and there are a couple of reasons for that. So, one, I didn’t really feel like I could talk about it. So when I had imposter syndrome, when I suffered with burnout, I didn’t really talk to anyone. And I didn’t think anyone would understand. And so it becomes difficult for people to then help you if you don’t ever tell them. So, you know, that’s on me. And, but as an industry, I think we find it hard to talk about these things, so we need to make that more acceptable and we need to understand more that people are dealing with these things. So I think that’s really important. What I also found is that how we think plays such a massive role in how we feel. And ultimately our well-being and the perspectives that we take, and recognizing that we choose how we think and realizing that we have the power to change even our belief system if we believe a certain thing, we have the power to change that and believe something different if it’s not helping us. And that for me has been a huge realization and it’s obviously a really big part of my mindset coaching. And those areas really feed into things like imposter syndrome and burnout in particular, and achieving, you know, work-life balance. We kind of touched on it earlier, but as I say physical well-being as well. We sometimes talk about them in isolation, but they’re so intertwined. Physical activity, whether it’s workouts or walking, yes, there are obvious physical benefits of doing those things and health benefits from doing those things, but it also has such a massive impact on your mental well-being as well. And not just your mental well-being, but we can take it further into the realms of performance. It has massive impacts on your focus, your motivation, probably your morale, and it’s absolutely huge. So I am actually as well as a mindset coach, I’m also a personal trainer, so I really do kind of bring them all together in, in under that well-being banner, so……
Kshitij Mohan: Oh, perfect. Richard, and but Richard, in these entire experiences, do you feel there is any specific practical processes or something that managers/ leaders need to keep on working towards, need of implementing so that everyone feels that, hey, at a very first step, you can just open out and say what you’re feeling. I think that’s what the first biggest challenge is and as even you mentioned, right? People just don’t speak up and most of the people don’t even realize that it’s happening with them. So how do you ensure that you are able to create that ecosystem around it?
Richard Donovan: Yeah, I think it comes from the people at the top, it comes from the leaders, and, you know, if our leaders never show vulnerability and they never talk about the times that they maybe failed or they got something wrong, then without seeing it, everyone who works for them can almost read between the lines and think that they can’t talk about that either, because if they show it, then they’re not as good. So I think it really does come from the top when the leaders can share their own vulnerability, share their own feelings, and ensure that’s okay. And especially in my experience when I have done that my teams seem to feel more comfortable doing it as well, and, and it leads to a lot of things, but it tends to lead to a lot more trust with within the teams and also general morale seems to be better when that is the case.
Kshitij Mohan: Yeah, I think that that’s totally the case. We all need to ensure that we are working together, break those silos, and then I just talk about the stuff that’s going on. This is great, Richard. One last thing, you have seen it all, learned it all, definitely reflected so many times on your past journeys. What’s that one piece of advice that you would like to give today to your all the viewers, listeners, EMs, developers? How do you build the right balance between success and well-being?
Richard Donovan: It starts with self-leadership and you don’t have to be a leader to practice self-leadership. You can be at any level whatsoever, but you want to reflect and work out what it is that on a daily basis, What do you want in your day? How do you want to feel? How don’t you want to feel? What are you prepared to put up with? What are you not prepared to put up with? On top of that, you probably want some goals to work towards, and bringing all that together, it’s a really powerful concept is to work out and get clear on what your own core values are. Because your core values are the things that are gonna strike up whatever it is that you’re doing, you are gonna kind of move towards them. And what happens a lot of the time when people haven’t reflected on them, they don’t really know what they are. They kind of know, but they’re not totally sure. And what can happen there is they might find themselves in a job or in a situation and they kind of feel like it’s not quite right but they can’t put their finger on it. And what’s happened, as a coach, when I’ve gone through this process of helping someone define their core values, when they realize what their core values are, suddenly they go back to this situation and they realize, I know why this isn’t right now. It conflicts with what I’ve got here. It doesn’t sit well with me and this is why. And suddenly things just seem so much clearer and it just makes. I think it makes it a lot simpler to navigate life. Nevermind work.
Kshitij Mohan: Definitely. Perfect. Thank you so much, Richard. All I can say is this has been such a mind-blowing conversation and we are glad too, that you could talk about openly about challenges, the learning, the journey, and we just can’t be more happier about.
Thank you so much, Richard, for your time today. It was really nice having you. Thank you so much. Have a good day.
Richard Donovan: Cheers. It’s been a pleasure.
In our recent episode of Beyond the Code, host Kshitij Mohan, founder of Typo welcomes Isabel Nyo, Head of Engineering, Atlassian Australia. The focus of their discussion is on growing development teams in a sustainable way.
The podcast begins with a fireside chat with Isabel Nyo, providing us a glimpse into her personal journey. She places valuable insights into building engineering teams that foster a culture of transparency and excellence. Isabel also shares specific metrics she utilizes to gauge her team's velocity and satisfaction. Further, she delves deeper into the framework - C.A.R.E. explaining how it plays a pivotal role in instilling a product-driven mindset among engineers.
Lastly, Isabel addresses the challenges faced by women in the tech industry and how individuals and the industry as a whole can work collaboratively to break down these barriers and create a more inclusive, equitable, and diverse tech ecosystem.
Kshitij Mohan: Hello everyone. I'm Mohan your host back with another exciting episode of Beyond the Code by Typo. Today's guest needs no introduction in the engineering community. She is the head of engineering at Atlassian Australia. She has been a part of the engineering ecosystem for more than 20 plus years, and believe it or not, she has authored six books.
She actively speaks about winning a positive change for women in tech. Actually, she has done it all. She's her. She is Isabel. Hello Isabel. Welcome to the show.
Isabel Nyo: Hi. Thanks for having me, and thanks for the really nice introduction about me.
Kshitij Mohan: Thank you so much, Isabelle. It's an honor to actually host you here, so thank you for sharing your time with us.
Isabel Nyo: No worries.
Kshitij Mohan: Perfect. So before, before we start, I think this is one question that has kept me intrigued since the time we started doing this podcast with you. How have you been able to author six books, Isabel? How have you been able to find this time of doing everything while you have been doing a lot?
Would love to hear your experiences around that.
Isabel Nyo: Yeah. This is the question that I get asked often, and the thing is that it's not like I was writing all the six book at once. So my first book was written. In 2018, and the last one was written in 2022, so just last year. So it's more about the incremental improvement and incremental delivery, so to speak. In software development, you know how we have got like the HR and incremental development, so if you look at things after a while, you think that people are doing a lot of things at once, but that's not really the reality. It's more about taking time, taking step by steps, and after a while you feel like you have reached the top of the mountain and that's what it's, in this case.
Kshitij Mohan: Well definitely, but Isabel still four years and six books.
I think a commendable job. Definitely. So kudos to you! Perfect. So, in your entire career span, you have seen it all. You have built teams, scale teams, and I think while doing all this, the biggest challenge is how do you do it in a sustainable way? So I think today we would love to talk about, growing dev teams in a more sustainable way. But I think before we do that, we would love to have this fun fireside chat with you where I'd ask this quick series of questions. And we would love Isabel to answer this for us and so that we get to know you better and feel free to be as candid as possible Isabel. So if you're ready, we can get started.
Isabel Nyo: Yeah, let's go for it.
Kshitij Mohan: Perfect. Let's go for it. So question one, what do you like more Isabel coding or leading teams?
Isabel Nyo: So when I was a developer, and this was about 15 years ago, I really liked coding and I couldn't imagine being a manager and I didn't become a manager for a while because I really enjoy building things from nothing or solving complex problem. However, throughout those time, I found myself mentoring other developer and teaching them on how to solve problem and stuff like that. And I found that I was quite good at it and slowly I took into the management career part. And now I can honestly say that I enjoy management as well. I like that I am able to make positive impact on the professional and personal development of people through being their manager. I find that I am able to have more impact, and this is my personal opinion. It doesn't mean that if you are a software engineer, you don't have as much impact. It's just for me, I find it really rewarding to be able to steer the ship in the right direction and help them grow.
So I like both, but right now I'm very happy in my role as a Manager.
Kshitij Mohan: Question two, What's your source of energy that gets you through the tough days?
Isabel Nyo: I like to go for long walks, so I usually have like a 10,000 or 15,000 steps a day. And when I'm going for a walk, I like to listen to music or podcast. So I will definitely be listening to this one as well, actually helped me clear my mind and it helped me to be more productive.
So that's where I get my source of energy. Perfect. So that's!
Kshitij Mohan: That's how you find your zone basically.
Isabel Nyo: Yeah. Yeah, that's right.
Kshitij Mohan: Perfect, perfect. Next question. You have written six books now, so which one's the one that you feel has shaped you most as an author?
Isabel Nyo: So I actually thought about this question a little bit, and I have to say, honestly, there's no one single book that has shaped me to be who I am as a writer, because as I said earlier, every time I write a book, I learn a lot from it.
And I'm feeling that I'm improving it incrementally improving the craft of writing. And one of the central theme and the central reason for me to write is to share my knowledge and insight with other people. So, I feel that I'm getting that from writing, and it doesn't matter how many books that I have written, I still feel this sense of satisfaction and responsibility, and purpose with what I'm sharing.
Kshitij Mohan: Definitely. So every book holds a special value in your heart. Definitely. Right? Perfect. Next question, Isabel, what's that one tech myth you wish people would stop believing?
Isabel Nyo: This is a good one. So I wish people were believing that innovation has to be big and disruptive. There's a lot of time where you can innovate based on incremental improvement or making things better or easier. It doesn't have to be groundbreaking or something new and disruptive all the time. And this is a myth that we have in the tech industry, and we believe that innovation is only one. You create something that nobody has thought about. That's not true.
Kshitij Mohan: Oh this is sweet Isabel! So even small changes can lead to bigger impact, so definitely. Perfect. One last thing. What's that one most memorable eureka moment you feel in your career?
Isabel Nyo: So I think it was when I was a developer, so I was working for this company and we were doing a very challenging and complex project, and I was only with the company for about a few months. So I wasn't the most senior person or most tenure person in the company, but I found a lot of people who are not developer were coming up to me with their questions or giving me their feedback, and I found that my approach to collaboration has really helped bring people together. And when there were problem, I was able to be the voice for them. So this has really helped me understand having a diversity of voice, really bring people together and make the outcome of the collective better.
Kshitij Mohan: Perfect. So that's where the leadership journey of Isabel started, I guess.
Isabel Nyo: Yeah. You can say that. Yes. So that's my approach to how I collaborate and how I work as well.
Kshitij Mohan: Perfect. Thank you so much, Isabel. This was, this was really fun, and thank you for being so candid. Now let's get into the real stuff. Right? So, given the kind of vast, amazing experience you have had, you have held multiple positions, right? From CTOs engineering leaders, I think today what we would love to start with is your experience as a CTO, right? So, what do you think is that interesting reality about building dev teams as a CTO that's kind of counterintuitive for others. What do you think has been that key insight for you while building your engineering teams?
Isabel Nyo: So earlier in our conversation you were talking about how to build sustainable teams, right? Yes, right. So I think one of the counterintuitive fact for engineering leader is that we need to understand that less can sometime be more so in a world where we always think about having a lot of PR or lots of codeship or lots of code written. As technology leader, we need to understand that sometimes small things can actually lead to big results. And let me explain what I mean by that. So for technology leaders, we should focus on quality. Rather than quantity. So rather than pushing for a large volume of code or a large number of feature, we should encourage team members and engineer to take the time to write clean and maintainable code, make sure that there's enough trust in it, and think about reliability and scalability as part of the development and this will lead to actually sustainable process. And this is just one part of it. And second part of it is around how we work and our way of working. So often CTOs or tech leader are the people who are very smart and they are problem solver. So when they become manager, it takes them a while to really understand what leadership is all about and they need to take a step back and actually, speak less and listen more. So this is where speaking more is actually detrimental to their success as a leader. And less is actually more so when it comes to way of walking. They also need to take a step back and give room and space for people or engineers on the ground to grow to really help them achieve success in their team and to to have great result as a team, not just from one individual, but a collective. So these are the counterintuitive belief that I have around less is actually more and more is sometime less.
Kshitij Mohan: No, definitely and while you talked about, although this is very close to building the right and fostering the right set of culture as well in the, in the dev teams, right? So this culture of transparency, culture of excellence, and I'm pretty sure you must have faced certain set of challenges while building that culture because its not easy to set the right foundation for everyone to grow and evolve from there. Right? So any thoughts on that? How have you been able to do that?
Isabel Nyo: So when it comes to creating a culture of engineering excellence or culture of continuous improvement, I have found that setting this culture or instilling this culture, take a while. And it might.. It's often very hard to reverse the culture. So let me give you an example. A while ago I inherited a team that was looking after a large code base, and this team was under a lot of pressure all the time because they have a huge tech debt. They were always busy firefighting, and they had no time to do like innovative project or feature development. And this actually impacted their velocity as well as their satisfaction. And this is the result of not having a continuous improvement culture. And they were too focused on shipping things quickly and not taking into consideration the impact that it has on the technical infrastructure and the platform. So, In this case, what I did was, and what I would advise all the senior engineering leader to think about in terms of fostering a continuous improvement and continuous engineering excellent, is to have an understanding of the current state. How is the infrastructure like what are the bottlenecks that the system has got? And once you understand the current state, you might need to make decision around what are the things that you need to fix immediately and make room for it. In product development, we often have roadmap, right? Like you have roadmap with things that you need to ship, and we need to have the same from the technology perspective as well.
You need to have a technology roadmap and it needs to have a plan and the vision and strategy so that we can have this continuous improvement culture in the technology as well.
Kshitij Mohan: Right. Perfect. And while talking about this, so you mentioned two critical aspects, right, that every leader talks about, about this velocity, the satisfaction part, right? Any specific metrics or any specific way that you have been using to understand, Hey, how my current team's velocity is, , or how my team satisfaction levels look like? Any specific thoughts on that? Have you been able to kind of objectify this entire approach?
Isabel Nyo: So, in terms of how do we gauge the satisfaction level as well as the stability of the platform, so to speak, or the engineering excellence I recommend two kind of metrics. The first metric is the Quantitative metrics and you can use Dora metrics for that. So how like number of incident, what is the change failure rate and things like that are really good way to gauge the number around how things are going. And you can see the trend as well. So for example, if you see the trend of number of outages increasing over a few months, then you can see it clearly that something needs to be done. So that is the quantitative. The other side of it is qualitative metrics, and this is where you need to have conversation with engineers and speak to their engineers to find out how things are going for them, because sometime things may look rosy on the outside, but engineers may be feeling like they are not being productive or they don't understand what they're doing. They don't understand the big picture. So this kind of information can be gained by having survey or speaking to engineers on the ground.
So I would recommend not looking at just the quantitative metrics.
Kshitij Mohan: Quantitative level. Yeah. We're bringing things together. Yeah, totally. Totally. This makes sense and by talking about culture, it would be so not good without talking about the Atlassian culture. I think you have been in that culture for too long. So any specific things that you really love about being a part of the Atlassian culture?
Isabel Nyo: So we, Atlassian, one of the reasons why I joined Atlassian about five year ago was because of the value. So we have a few value for Atlassian and one of the values that really resonate with me is be the change that you seek. So Atlassian really encourages people to take ownership of whatever area that they are passionate about, regardless of who they are or what kind of role they play. So for example, I'm a head of engineer, but if I feel that there's some process improvement that need to be done, even though I'm not a program manager, I am more than welcome or encouraged to bring this, bring about change in that area as well.
Kshitij Mohan: Whoa. This is so cool. Perfect. And so just moving forward to it, right? Recently there has been a lot of talk about product-driven mindset, right? Experimenting, innovating. Everyone continuously talks about, Hey, how do we actually are more focus on this so in order to evolve more, right? But I think the biggest challenge that would be is how do you translate this thought from the leadership team till the actual engineering level, like every engineer feeling and aligning with the same mindset, but what's your thought on this entire process and approach?
Isabel Nyo: So I actually have a framework that I use in, in terms of bringing about product-driven mindset to engineer, and you are absolutely right in this world where we are always creating something, whether it's a platform product or the product that consumer use, we need to understand how to bring about this change and how to instill into the engineers.
So the framework that I use, I tell you an acronym, so it's called C.A.R.E. And each acronym or each letter stand for something. So C, stand for clarity. Clarity means everyone in the organization or every engineer, every product manager, they understand, what is the success that they are working towards. Oftentimes, I see a disconnect between what the business is trying to achieve and what the engineer are asked to. And this is very important to provide this clarity because once people understand the big picture, they can actually make changes or they can actually ready for things to be done. So clarity is very important and my job as a leader is to provide this clarity to people that I work with. The second letter is A, A is autonomy. And earlier I was talking about one of the value that really resonate with me is be the change that you seek. So giving autonomy to people means that you give them what is the success criteria, or you tell them what are the guide rate that you have. They can decide on the how or they can even decide on the initiative that they are gonna work on to meet the details or to achieve the goal. So autonomy is really important. And autonomy also bring about engagement when people feel like they are allowed to make decision that impact things that they are doing. Whether it's the technology choices or how they would solve a particular problem, it really motivate them and provide them with the sense of ownership. The next one is, so we talked a little bit about the product driven mindset. When it comes to product driven mindset, we need to understand who we are solving the problem for, and we are solving the problem for customer, but we might not know how to solve these problems. So it is important to take calculated risk and measure as you go. So this is where experimentation come in handy. You might need to do small incremental improvement, and you might need to learn from it regularly. And this require everyone to be comfortable in taking risks and the way my role come in as a leader is to make space for people to feel comfortable, to take risks, and also not only to celebrate successes, but also failure as long as we learn from the mistake that we made. So R is risk-taking. And the last one, the last letter is E, and E stands, for example. So leading by example, and this is the fundamental trait of any great leader. They need to lead by example. So it is not enough to tell people what to do. You need to show them the way and you need to demonstrate the principle and value that you want people to embody. So when it comes to the product thinking mindset and product development, this mean as a tech leader, I'm engaging closely and collaboratively with my product managers and product conduct because this is what I would like to see from my engineer as well. And this also mean me being curious about. What are the pain points for customer, how they are feeling, what they're using, and what problem they have, and also understanding what are the business metrics that we need to meet in order to be successful as a company. So these are the things that I really try to do and I do in order to foster a continuous improvement and product thinking mindset in engineers. So I think gones were the day where engineers do engineering work, do their own craft and designer do design. This day everyone needs to be aware of each other craft and has empathy for each other expertise and knowledge.
Kshitij Mohan: Wow, Isabel. So you kind of transformed this entire approach into C.A.R.E. So C is for Clarity, A for Autonomy, R for Risk taking, and E for Example, leading by example. Wow. This is mind-blowing, Isabel. Perfect. Thank you for sharing this, actually. So I think this definitely is highly insightful for each and every engineering manager trying to foster this culture. Perfect. I think lastly, we'd love to talk about a topic that's really close to your heart, right? You have been actively writing, speaking a lot about women in tech trying to bring a positive change, right? So we would love to understand your experience and what do you think could be done to change the entire narrative around it?
Isabel Nyo: So I've been in the tech industry for about 20, 21 years, or more than 20 years, and in this journey I've had both good and bad experiences, but good experiences are where I have worked with people who are very inclusive, who celebrate diversity of voices and who would make room for me or who would make time for me to hear my point of view. However, on the other hand, I've also faced situation where people would dismiss me because of who I am or how I look, or the way that I think. And sometime I had to prove myself twice or three time as much in order to get the same respect or in order to get the same level of treatment as my male counterpart in the tech industry.
Regardless of all this, I think we are improving in terms of being more open, being more accepting, and being more appreciative of different kind of people and their thought process and the perspective that they bring to the group. So personally, I have a daughter and she is 11 year old and she is in her last year of primary school. And in about maybe a decade, in 10 years time, she will enter the work phase, and what I will hope is that she is treated equally as her male counterpart, regardless of whether she wants to take a job in technology or science or not, or medicine or whatever. And in order to do that, you ask a question about what we can do to change the narrative. I think there are a few things that we can do right now. Firstly, we need to educate other, we need to educate everyone and we need everyone to be aware of the problem that we are having or challenges that…
Kshitij Mohan: So the folks don't even know that they're doing it. No, exactly.
Isabel Nyo: That's right. So sometime there's this subconscious bias and people like people who look like them. So if you have a room full of male developer, they might think whatever they are doing is okay, but it could exclude certain people who are not like them. So education and awareness is really important. So there are a lot of trainings around unconscious bias. You can read books about what are the different.. How different gender thinks, different perspective, not just gender, by the way, it's also cultural as well. So people try and educate themselves and have awareness around these differences. Then there should be sponsorship and advocacy. I say this because sometime we tend to promote or celebrate people again who are like us. So unless you have some conscious effort to try and celebrate, People or different voices, then there will not be enough representation in this industry.
So representation matter and sponsorship in order to have enough representation, sponsorship and mentorship matter. And lastly, I would say we need to come together as a group. It is not about us versus them. I'm doing this podcast with you and it's not... We're like, we are trying to make a change together.
So it's important for everyone to come together and make a change as a collective rather than saying, okay, you, the problem is with female. So the female representative group should be doing something and male don't need to be involved, or female shouldn't feel like they should be the one pushing for change. It should be on everyone responsibility to bring about change because we can be better together.
Kshitij Mohan: Well, definitely I think that this is, thank you so much, Isabel. So this is a really important lesson for I think each and every one of us. How do we come together and build this inclusive culture?
Because that's how we can all grow and evolve together. And definitely we all hope Isabel, that pretty soon as you mentioned, right? I would say not even a decade, let's just do it as fast as possible and to just make this world a better place for everyone to work. So definitely thank you. Thank you so much Isabel, this was a really nice conversation. We're kind of humbled to have you here and thank you for being so candid and opening your heart out with us and for all of viewers. So thank you so much, Isabel. Have a good day.
Isabel Nyo: Thank you. Thanks for having me. It has been fun. Bye.
Kshitij Mohan: Thank you.
In our recent episode of Beyond the Code, Host Kshitij Mohan, founder of Typo, engages in an insightful conversation with Mateus Viegas, Engineering Manager at Luxclusif. The central theme of the discussion revolves around fostering innovation and well-being in dev teams.
The podcast starts with a fireside chat with Mateus, providing us a glimpse into his personal background. The conversation then takes a deeper dive into dealing with challenges when transitioning from developer to managerial role. Further, he sheds light on the ways to get a bird's eye view of the team’s dynamics and operations. Mateus also imparts a valuable perspective on enhancing the experience and well-being of developers.
Wrapping up, Mateus provides thoughtful advice to fellow engineering managers in the field.
Kshitij Mohan: Hello, everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by typo. Today’s guest comes from the football Frenzy Nation of Portugal. He is a renowned engineering leader, a published author, an ex-CTO, and what not. He brings a unique mix of creativity, engineering, and leadership. Please meet Mateus. Hello Mateus. Welcome to the show.
Mateus Viegas: Hi Mohan! Thank you so much for the nice compliments. Just a curiosity, I, I have actual dual citizenship. I was born in Brazil and live in Portugal nowadays.
Kshitij Mohan: Basically you belong to both the Ronaldos? I think so lucky
Mateus Viegas: Yeah, exactly.
I wish I had their abilities, but that’s okay.
Kshitij Mohan: Perfect. Thank you so much Mateus for sharing your time with us. This really means a lot. Perfect. I think before I get started with anything mateus, this is one question that I can’t just stop myself asking from. How did you get time to publish a book while doing everything else that you have been doing?
Mateus Viegas: I mean, it was in the pandemics. We were locked in the house and the opportunity came by. So I can’t deny that it was like quite a big challenge because, I mean, it took a long time and a lot of back and forth. But yeah, basically the pandemic have to be inside the house, so nothing else to do, yeah!
Kshitij Mohan: Perfect, I think you grabbed the opportunity with both hands definately. so man, Congrat to you Mateus!. By the way, how does it feel to be a published author? Like, anything changes or is it all the same and all?
Mateus Viegas: I mean, I did it most for personal experience, you know because I always struggle as a person to commit myself to long-term projects. And I knew that the book was going to be like a really long-term project, like two two-year project.
So it’s really like an exercise for me, for discipline. And that was the thing that I was searching the most, like really to commit to long-term things. And for me, it was played really, really nice in the sense, in that sense, I didn’t think about money, about reach, about nothing like that was more like a personal experience.
So yeah, that’s it.
Kshitij Mohan: Perfect. I definitely, that’s, that’s great Mateus. So Mateus, given the kind of experience that you bring in, I think today we would love to talk about how to drive innovation and well-being in dev teams. But again, before we do that, there is always a fun fireside section that we do with our guests.
I would ask a quick series of questions and we would love to know the personal Mateus to go about, and then that’s all how it goes. So if you’re all set, I would love to get started.
Mateus Viegas: Yeah, sure. Let’s go.
Kshitij Mohan: Perfect. So let’s get started. We know from your profile that you visit a lot, you like love to drive in nature, take photographs.
So I think the first question would be that what’s that one most breath-taking place that you have visited? That you just loved and you just can’t stop yourself taking pictures from?
Mateus Viegas: Well, I mean, that’s a tough question. Being born and raised like in an ocean country, in a coastal country like Brazil, I’m from Rio originally, I was always amazed by mountains and by how huge they are in this kind of thing, right?
So every place that, every place where there are like these big mountains are pretty places that mesmerize me. But there, there’s one place that, I mean, it’s my dream place because it looks really like another planet, which is Iceland. I went there like almost 10 years ago and it just can’t get off my head since then. But there are a lot of places and mountains in general.
Kshitij Mohan: No, definitely. I think Iceland is definitely one of the most naturally gifted countries to be with. Like definitely. Perfect. Question 2, This is for the developer Mateus, What’s your favorite Algorithm or data structure?
Mateus Viegas: I am thinking of this right now and I think that, I would call it the merge sort. Because it really forces me into like thinking of breaking down a problem, like to that divide and conquer approach. You know, it’s like really breaking down bigger problems in chunks of smaller ones. So I think, and it’s quite fast actually as well, so definitely. But mainly because of the reasoning of like breaking things down and I really like this, this kind of approach.
Kshitij Mohan: So question three, what’s that one favorite tech gadget that you can’t live without?
Mateus Viegas: I have to see my camera. I mean I have a tiny camera. The Fuji Film three. It’s not a new one, but it’s the one that I carry around all the time, so that’s my tech gadget.
Kshitij Mohan: Yeah. Perfect. Question four, What’s that most inspiring quote that you live by? What inspires Mateus?
Mateus Viegas: I like to say that I’m a pretty sentimental guy and there was this cult, from an American out of college that I heard like years ago that says, “Nobody has ever measured, not even poets how much the heart can hold.” And it’s something that really inspires me in living with my family and living with the people that I love and doing the things that I love.
So I think that is my motto, I would say.
Kshitij Mohan: Thanks, Mateus. This was real fun. Thank you for being such a sport. I think now getting to the real stuff, getting to pull out some insights from your experience. Right? So you have seen this entire journey from a developer to a manager, to a leader. You have seen it all. And I’m pretty sure this must not have been easy, right? You must have faced certain set of challenges that you, you must have felt, Hey, this is something that I need to deal with. I think we would love to understand those set of challenges that you think, Hey, this is what made me to the next level of where I am today. And, how did you kind of overcome those situations?
Mateus Viegas: Yeah, I think that coming from a software engineering background of being a developer, I think that one of the biggest challenges that I personally faced, it was like the feedback loop is different. So when you’re a developer, you’re like writing code and you have test suites and you can iterate and fail and try again the red-green refactor kind of thing. But when you’re like leading teams, It is like a change of mentality because it’s not so much the output that matter, but more the outcomes. And the outcomes usually take a little bit more time to compound. So one thing that I’ve tried to do is like, well, I’m a manager. I’m not seeing any result, I have to be totally hands-on again. So I started being hands-on, but that just got things worse because I took enough space from the team, I took autonomy from the team. I was actually being more of a blocker than a blocker removal. So I mean, really to making this switch was something that was a huge mistake that I did. And my team surely had paid the price at that time. And thank you folks for understanding and for making me improve as well publicly to them, because I mean, was my biggest challenge at all. It was like to change the motto, you know, to change like this perspective. Okay. Now I’m not more like the guy who codes, but I have to try to make the guys who who are actually coding do their best, so empower them. So really make them shine and understand how can I help more as a support than as an another operational team, another operational folk. So I think that was one of the biggest challenge that I have faced.
Kshitij Mohan: Right. So basically moving from this mindset of doing it yourself to enabling teams, how to do that is really what the biggest mindset shift is. Definitely!
Mateus Viegas: Yeah. Yeah, exactly. And that, that was something that one really nice manager that I had told me, he said to me, because I said to him I have too much, I can’t do this leading thing anymore. And he said to me, of course, you’re having too much. You’re coding! Why you’re coding? And that, and that just triggered me because, I mean, I can surely help the teams with my technical background in architectural review with things, these kind of things. But I was like taking too much time trying to do both things, wear both hats, and it just doesn’t work. So also a big thing to my manager at the time who shined the light on me because was it really helpful
Kshitij Mohan: Right. No, definitely. And any specific practices that you followed to change your mindset? So basically before jumping on to saying, Hey, let me, let me finish this up. You were in a mindset, Hey, how do I actually define things for others? Right? So how did you balance this out and like gradually shifted to where you are?
Mateus Viegas: Yeah. I think that for me one thing that really motivated me I didn’t like to see my team struggling. So I think that by coding I will remove the struggle from them, but I was also removing the learning from them.
So it was really like a mind treat for me to say that they have to go through it as well. They have to struggle sometimes. They have to face this challenge in order to know how to overcome them. So, it was really like. Really making a switch in my mind to say, okay, let me step back. Let me see a little bit of chaos. And if needed, I can step in.I can step in somehow. But sometimes it is good to have a little bit of chaos. Sometimes it’s good for the teams to good character and to learn.
Kshitij Mohan: No, I think definitely this totally is the right way but one thing in doing that Mateus is, right. So while doing this, how do you balance this act that, hey, till this time, let the team figure out on its own and, and from a time, Hey, no, no, this, this is not happening. I have to step in and kind of figure those things out. So how do you do that?
Mateus Viegas: Yeah, I think that is really like, about something about defining expectations.
You know, when building teams, one thing that I always had in my mind in I have to, to hire the best guys that I can afford this role. If I hire them, it’s because they are more than good enough. They are really like pros in what they do. They know what they’re doing. So it was really like, okay guys, you know what you’re doing, we have to reach there. So my goal was really to provide alignment and give them autonomy, because autonomy without alignment, I mean, it just doesn’t make sense, right? But it’s really like, okay, we are aligned that we need to get there. I don’t know how you guys tell me how, how do we get there? What do you think that is the best way? What do you think that are the challenges that we might face? What do you think that are the risks that we might have to take together? But that is the place, or it’s really that the place do you see? So it’s really about like fostering them, this sense of autonomy so that they can really be accountable for how they get there. And my role is really to provide direction, provide alignment, and try to remove any noise that might be in between. And was mostly is really like making a step up, step out, and doing more like a bird eyes view of the thing, the perspective, like really elevating the perspective and empowering the teams. I think that was mostly really a changing of mindset.
Kshitij Mohan: No. Perfect.. And I think as you mentioned, right, getting this Bird eye’s view, so any specific tools or any specific kind of dashboards that you were using maybe to get this entire picture? Or was it more of a conversational-driven way where you were setting up meetings and trying to understand what’s happening?
Mateus Viegas: I really like a dashboard too called the Google Sheets. Just kidding.
Kshitij Mohan: That’s the master of all.
Mateus Viegas: Yeah, exactly. But basically one thing, that I really like to do with my team is like, one process that I really enjoy do is the goal setting. You know, so we have, for instance, the goal setting as a company, one desire outcome and we discuss as a team, what are the team set, the team’s objectives, the things that we need to reach as a team, the deliverables that we can contribute with. So it is really like to compounding goals, right? So we have this team goals that we have to compound and individually with each, each team’s member. What are your goals that you think that you can set for yourself that might help us to compound into this one. So one thing that I really like to do is to track with them these goals. Like they have their own spreadsheets with their goals. We have a template as of now where they do the tracking and we do kind of bimonthly check-ins and we see the things compounding in a way. And if all these goals are compounded, we are like, It’s not certain that we get there on the main goal, but we are closer. So it’s something that really like to use to track this.
Kshitij Mohan: Definitely, Mateus. So, this is great now coming to this team-building part, right? So I think as you also mentioned, autonomy and alignment. It’s also important that how do the teams communicate, collaborate, right? And in order to ensure that the entire development process is smooth and efficient. I think that’s the foundation of every, high-performing dev team, I would say, right? So how did you foster that? Any specific things that you worked on to ensure that’s in the right place?
Mateus Viegas: Yeah, first thing I think that is important for everyone to know their roles and their responsibilities within a team. So regarding the responsibilities, one thing that I really like, to have clear for everyone, and I really like to have a document, is what I call the engineering playbook, where basically we say what is our way of planning. Where is like the software development life cycle that we had. Where is the approach to code reviews? Where is our approach to monitoring? What is our approach like to considering something done? So really defining this playbook of like more like a basic common ground and starting from there. So we know how to work. I don’t think that is also set in stones in different teams. Like you have kind of different playbooks, but having this engineering playbook of like standardizing the basics of the software development lifecycle for that team, it starting there, this is our process. So mostly within this process, letting everyone compound. One thing that we started to wait like more one year or so with, with the teams that I really started to see in the results was for instance, like their RFCs and the proposals of implementations and where basically we had a lot of times different people, different backgrounds, different experience, different opinions, different personal tastes. So one thing that I really like to drive consensus within the team, within the planning process, are RFCs, because someone proposes something, everyone’s puts their comment in and we get to have like, More rational trade-offs of the pros and cons of each alternative. And at the end of the day, try to remove the emotion a little bit, even though I’m emotional guy. Try to remove the emotion of the decision process by really facing, we have these on our hands, these object pros and cons. So which one’s the best? And when we are not able to decide, we vote and move on. So it’s really like having a standard ground of rules and basically driving consensus. Try to remove emotions and be as rational as possible with the decision-making.
Kshitij Mohan: Right, So basically setting the right processes and then ensuring everything is aligned to that is what it takes to set the right processes. Makes perfect sense Mateus, I think, the last topic is very close to my heart, and I would really love to know your thoughts around that. Right. So developer experience and wellbeing. I think this is the next buzzword, I would say, in the entire tech industry. And I’m pretty sure you must be aware of it. Right? And this has specifically, the entire scenario has changed. We all know after the Covid scene, and that’s when a lot of, more and more people have started talking and writing and printing stuff around it. So I think first, to begin with that, I’d love to understand your perspective on this entire developer experience aspect, which in the end, everyone talks about translating into productivity, right? Your thoughts on that Mateus?
Mateus Viegas: Yeah, I think the developer experience is a quite broad term, you know? I mean, we can extract a lot of things from it, but the way I see it, I see it from two perspectives I see from a qualitative and from a quantitative perspective. I see the quantitative one as metrics that we can capture through surveys or softwares that express something like how long does the team take to ship something? How long does this team take to fix something? May provide some signals of let’s say, the technical health of the team. Right? But for me, those quantitative things are more like signals. And what about the qualitative things? How can we extract them? I’m not a DevX expert, so I really don’t know about everything about it, but I think that One thing at least the developers that I work with, really, really enjoy is really like having feeling that they have a say in what they are doing. Feeling that they have a say in what they are deciding. So really like providing them with the big picture, providing that the reasoning why we are doing this. So first questions. First question is why are we doing this? Do folks understand? Why? Do folks understand? Also, what are trying to solve the main goal, right? And basically empowering them. So I think that empowerment will be the one word that I will use, to give like, not to give, but to translate, not a better developer experience, but to try to give the developers a better experience. So, I mean, really empowering them with enough context, empowering them with the decision making, empower them with the abilities that they, they bring to the table, you know? So, and that comes from the truth. That is more this, let’s say the qualitative thing, the subjective thing, and comes to being close to them. So like tightening the feedback loop, having one-on-ones. In the one-on-ones, we would talk eventually about work, but the first question shouldn’t be about work, but how you’re doing. How are things going for you? How are you feeling? So it’s really about understanding the people that you have with you. Understand their wishes, understand where they want to be, and giving them enough power to do the best job that they can do. So, That’s why I say that my perspective’s a bit subjective.
Kshitij Mohan: No, no, definitely, I think everyone is trying to figure out the right developer experience, what it means, how do you create it. So I think that that definitely helps. Mateus, and I think just before we close our discussion, one piece of advice that Mateus would like to give to all the EMs out there, right? One critical piece that they should be very much focused out while driving everything, while managing all the chaos that’s around there.
Mateus Viegas: Yeah, but that’s a hard one because I don’t see myself in position to give advice to so many brilliant people out there. I think that one thing really important is that I just said, like, I mean, being close to your team. Know that they are before developer human beings and try to develop a relationship with them. I think at least for me, it changes that lot in the way that we can approach things, that we can really conquer things. So stay close to your teams, know how they’re doing, know their challenges, and yeah, just stay present.
Kshitij Mohan: Perfect. This was great, Mateus. Thank you for sharing all your insights and experiences with us.It had been such a fun, fun conversation. And again, all I can say is you are so lucky to have both Ronaldos working with you. So I think that’s all wanted is, that’s how we can summarize this for you.
Mateus Viegas: Yeah. I can’t say my personal preference of the ones. Because I play.
Kshitij Mohan: I can’t even go there and ask you about it. That won’t be a fair question. Thank you for your time today. It was such a great conversation. Thank you. Have a good day, Mateus. Take care.
Mateus Viegas: Thank you, folks. You too bye-bye.
On our recent episode with ‘Beyond the Code’, Host Kshitij Mohan, founder of Typo engages in an enlightening conversation with Andrey Adamovich, CTO at VLAVI Group that focuses on the impact of collaborative dev practices on software delivery.
The episode begins with a candid chat with Andrey where he talks about his love for Copenhagen, Italian cuisines, and coding.
Further, he delves deep into building the right team topologies and how collaborative programming practices can increase the speed and quality of the overall development process.
Lastly, Andrey emphasized the ‘specific’ metric that is best suited for all the development teams.
Kshitij Mohan: Hello everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by Typo. Today’s guest brings a very unique perspective on software delivery, automation, and excellence. He has been a part of the engineering ecosystem for more than 24+ years. His masterclass on DevOps has been delivered more than 150 times across the globe.
He is none other than Andrey. Hello Andrey. Welcome to the show.
Andrey Adamovich: Hello Mohan! Thanks. Thank you very much.
Kshitij Mohan: Thank you so much for sharing your time today with us Andrey, really means a lot.
Andrey Adamovich: Thank you.
Kshitij Mohan: Perfect. So we all know the kind of experience, the expertise, Andrey, that you have on software delivery, excellence, automation, tooling, GitOps a lot more.
But, we would love to today talk about the impact of the collaborative dev practices in the software delivery. But before we jump onto that, we would love to have this fun fireside section with you where I would ask a quick series of questions. Would love to hear your answers in quick so that me, the audience, you all get to know the real Andrey.
So if you’re ready, we can get started. Andrey?
Andrey Adamovich: Yeah, I’m ready. Of course, I’m ready.
Kshitij Mohan: Perfect. So here goes my first question. Andrey, we all know you have been to so many places in the world. Which one’s your favorite and why?
Andrey Adamovich: Yeah, good question. I think I like Denmark. I mean, of course, I like my own country because I live in Latvia, but, if we think about, you know, the way things are organized and the things are neat and nice, I think I like Copenhagen a lot.
Kshitij Mohan: Ah, Copenhagen makes sense. Perfect. Second question, Andrey. Europe is full of delightful cuisines, right? So which ones your comfort food?
Andrey Adamovich: I think Italian.
Kshitij Mohan: Italian. And, and what exactly? In Italian. It covers from pizzas, pastas, lasagnas. Which ones your fav?
Andrey Adamovich: Well, everything actually, everything because Italian is not just pizzas.
It’s a lot of other things. But when you experience the full Italian dinner, that’s awesome. That’s cool.
Kshitij Mohan: Perfect. And I’m sure, uh, that goes along with the Italian wine, right?
Andrey Adamovich: Absolutely, absolutely.
Kshitij Mohan: Perfect. Next question. You are so much into teaching, delivering experiences, right? So what, apart from teaching, what else brings you joy Andrey?
Andrey Adamovich: Yeah, of course. I like coding.
Obviously, I’m a developer in my heart, so.
Kshitij Mohan: So you’re still coding, Andrey, you still love to code sometimes?
Andrey Adamovich: Yeah. I mean it really brings joy when I can be alone and, code for like, maybe, a day that’s awesome. Of course. I like traveling apart on that. I like spending time with my family. but yeah.
Kshitij Mohan: Yeah. Perfect Andrey! Next question so what do you think people love about your teaching, your coaching style?
Andrey Adamovich: I dunno. But I think it’s honesty because I’m always honest about the technology, about the facts that, about my experience and that’s I think what buys attention. And then, loyalty after that as well because people come back to my coaching
Kshitij Mohan: No, definitely works. And one last thing, and this is definitely just for fun. So when do you plan to retire and what do you plan to do then?
Andrey Adamovich: Good question. I dunno, I guess I’ll still be coding. I’ll still be coding. It’ll never stop.
Kshitij Mohan: Oh, perfect. So basically your love for coding surpasses everything, so,
Andrey Adamovich: Yeah.
Kshitij Mohan: Perfect. Thank you so much, Andrey. This was, this was fun, and thanks for being candid and on bringing honesty in this discussion as well. So this really helps. So now getting to the real stuff, Andrey. So, we have seen you, hear, talk a lot about building right dev teams. How do you set the right processes, excellence, everything around it, right? I think, while doing this, the foundational part comes in that how do you define the right team topologies? What topology works in what scenarios, and what could be the right fit for them? And I think given your last experience, would love to hear any specific practical use cases that you must have seen and thought, Hey, that’s the right way to go about it.
Andrey Adamovich: First of all, I think the size of the team really matters because you cannot really be successful with a team of 100 developers working on the under one manager. It has to be like a team of smaller teams, smaller team leads, and it’s the only way to deliver value. Because the more people you have, the more communication channels you have, and the harder it is to deliver anything, and then these kind of chaos. Of course the size matters, but in this case, maybe a team of five to maybe eight people is an ideal team. And then of course, you as a manager, as a delivery lead or some other profession, you should set up the communication channels very well between the first of all, communication channels and second, also the boundaries. Define the responsibilities for each team and define how they communicate. What is the, basically the human API sort of between the teams. So that they work effectively. Maybe you’ve heard this book called team Topologies, and it defines different types of teams that exist. It’s super important to understand whether your team is value stream delivering team, or your team is like enabling team. They are the one that is supporting the other teams. And sometimes, especially in the big companies and big organizations, you have to have one or two enabling teams that will make sure that other teams are working smoothly. So if we go into the direction of DevOps, there’s really a trend now that people are talking about platform teams. The teams that are delivering platform for developers do their job. And well, it’s working. I’ve seen it’s working, first of all, and, it’s a really nice way of organizing, especially the big company that you have somebody who is working on a product- let’s say an application and somebody who is actually helping them to deliver infrastructure, deliver, monitoring and stuff like that. And, it’s important that this enabling team, they also should work as a product team. But it’s like the customers are not external customers, but internal customers. And, that’s super important to have.
Kshitij Mohan: Okay, perfect. So basically size and how do you define the right roles and responsibilities as what it leads to the right balance in setting topologies. Makes sense. Makes sense. Andrey, okay. And then coming to the another aspect, right? So while building all this, you and I think every other leader talks about doing this collaborative programming practices, right? Pair programming, mob programming. What’s your take on it? Right. So how do you think of their impact is on the actual velocity, quality of the overall process?
Andrey Adamovich: Actually I think there’s a lot of resistance despite of the practices of pair programming. They exist for like 20, 30, 40 years. Still there’s a lot of resistance in the industry because many people don’t really get that, you know, the pair programming in one programming is actually a learning tool. It’s a tool for spreading knowledge. The usual argument against pair programming is that two programmers doing job of one programmer at the same time. And of course, it’s not true. ’cause the other thing that happens is like you, you’re actually sharing knowledge, you’re sharing understanding, you’re sharing some ideas you’re brainstorming at the same time. And that’s very valuable. And of course, you probably shouldn’t do pair programming all the time because there are some of the tasks, actually the super simple. You don’t need another person. But quite often, a development process is a discovery process, and having another person nearby is actually quite a nice thing to have because you discover something and at the same time they discover the same thing and you have feedback and you actually are becoming more efficient in the long term because you get that knowledge at the same second you discover that knowledge and that knowledge stays with you forever. If you don’t use pair programming then you may discover something when you’re alone, but then in order to share that, you need to probably spend another hour or maybe a lot of energy explaining that thing to other person. And that’s not as efficient as pair programming as such. So many people don’t see pair programming as knowledge-sharing tool, and that’s why they oppose it. But I really like it. Of course I don’t do it all the time, but I really like sometimes to do pair programming sessions or mob programming sessions with people. And after that everybody knows everything. There’s no need to document anything basically. And you just, because everything is already there. Yeah.
Kshitij Mohan: Oh, totally makes sense. But does this also somehow brings a fear of judgment in depth? Is that the case also, do you feel so?
Andrey Adamovich: Of course. Yeah. It’s hard. It’s yeah, actually, I met people who were really nervous during pair programming. They didn’t really like it at first because and I’m personally, I’m also I’m an introvert. I also, I don’t like talking to people too much. But when you realize the value, when you realize that it’s the person nearby is just another professional and they have the perspective, that makes things much easier. But of course, some people can start it like without problem, but, some people it could be a problem to sit with another person and do something. But at least try to do that, it’s really rewarding after that.
Kshitij Mohan: No, definitely. And I think if you take the approach, as you mentioned about more of the knowledge sharing other than actually trying to find something that would add more value to it definitely. Perfect. Andrey, this helps. Now coming to one important thing that we have seen you talk about a lot and we have seen being followed is also a test-driven development practice, right? This is something that a lot of leaders today are also talking about. How do you think that TDD impacts the real code review process and I think to begin with would to understand how do you see TDD in whole and what are thoughts on this practice going about it?
Andrey Adamovich: First of all, TDD really works. That’s another misconception that some of the leaders, some of the engineers actually still have. I would say it’s not easy to start with that it’s, of course, the framework itself is very simple. It’s red, green, refactor, it’s no brainer. But, The actual depth in that idea is so cool. Not many people realize that and until they really start doing that, of course I’m not doing TDD all the time, but when I’m starting a new product or when I’m actually doing some refactoring of legacy code, then TDD is probably the default method. I’m going to look into because that allows me to go with small steps and allows me to discover the problem as I go. And at the same time, I write tests at the discovering the problem and that’s really nice journey. Of course, many engineers, all are smart people and, they make this mistake because they’re smart, they can understand the whole problem at once, and then they basically become drown and they’re drowning in all the details and they spend a lot of time, like days, sometimes weeks, analyzing the problem. But if you use the real TDD with red green refractor approach, when you define a small subset, a very small subset of the functionality you want to understand and write code for, you first write the test. That sort of defines your idea of what, how the code should work. Then you write this small piece of code and then you implement the test, or actually the other way, write the test and write the code. And then you do refactoring and this small staff, small bits approach, that’s what makes a lot of a difference for even large problem. And I’m teaching to do this myself and I usually give this, task, the bowling game. I’m asking developers to write a simple algorithm to calculate the score for the bowling game. And I mean, everybody who is familiar with bowling more or less, and they think they know how to code this problem like in 30 minutes and everybody fails. Nobody can code bowling-coded bowling scoring rules in 30 minutes is impossible. And after 30 minutes without using TDD, folks cannot tell me whether, how much time is left for them to be done, how much time is left to implement the problem. But if they use TDD and if they split the problem into smaller bits and it’s possible, then they at least can have this feeling of progress because we didn’t finish in 30 minutes. That’s obvious, but at least we have like five or six test cases that actually pass. And that’s another thing that’s good about TDD it gives you the sense of progress much faster than any other deep-level analysis that you can do with the problem. And that’s amazing.
Kshitij Mohan: No, definitely. And what do you think why people just have this first level of resistance in doing this TDD?
Andrey Adamovich: Because they quite often confuse it with unit testing and if you have lots of code yes. And, then you have to write unit tests after that, then of course it’s hard to enter and reanalyze the problem to understand what is the acceptance criteria for the problem? And actually, write the tasks. The entry criteria is much higher than it is with TDD because with TDD you write the task first. Very small one then small code, then small test, then small code, and so on. But many people think that TDD is just about unit tests and one they are forced to write unit tests for the code already exists. Of course, they think, oh, TDD sucks. Of course, they do, but it’s not TDD that’s unit testing.
Kshitij Mohan: No, Perfect. This is really great, Andrey, and, coming to bringing everything, all these pieces together, right? We talked about this collaborative programming and TDD and you totally believe that these are the right practices that helps in impacting and increasing the overall efficiency. But I think, one piece of resistance also comes in because people are usually not able to see the value it delivers. Right? They’re not able to measure the value and the overall impact on their efficiency levels. So is there any ways that, that you can suggest, so that you have seen implementing where these practices, the impact can actually be measured? Any thoughts on that front?
Andrey Adamovich: The best way to measure that is the happiness of the team.
Because when they realize that these techniques, they actually work and they give them the sense of progress. They give them the sense of actually delivering value you see happy faces. That’s probably the best way to measure the performance of that. Yeah.
Kshitij Mohan: That’s the heart. That’s the heart of a European that’s speaking now. In the end, it all matters too. The real happiness of the people.
Andrey Adamovich: Yeah, exactly. Exactly.
Kshitij Mohan: Perfect. And any specific metrics that people can track and look at while doing so, or any major impact that could be seen around that?
Andrey Adamovich: Yeah, it’s a good question because I mean it, I think it really depends on the team, what kind of metrics you use. And also personally I prefer not using metrics because especially when you start using metrics and I’m the team realize is that you’re using metrics on them. Then they, psychologically they start sitting on those metrics. They may not do it like on purpose, but psychologically they become like, aware of the being measured and then they start doing things slightly differently. So I think the success should be measured by the value we deliver to the customers. So if we deliver nice features to the customers, and customers are happy, like with those features, Then we’re a good team, then we actually have a good velocity and we are delivering value. And the way you can measure that is probably, by understanding, first of all, How many nice things you released into production. And maybe also, try to measure how these things actually being used by your customers. And then compare the numbers, right? And if you have growth there, then it’s good If you don’t have growth there, any other metric doesn’t matter.
Kshitij Mohan: Oh, no, definitely. This all makes sense. Andrey, I think this almost sums up our conversation, so this has been really insightful. Just one last thing before we sign off, we recently saw that you do a 10k run as well. You are a runner who has been competing. So would love to hear about that experience.
Andrey Adamovich: Just starting. I’m just starting.
Kshitij Mohan: No, no. Perfect. Perfect. Andrey. So this was really great. Thank you so much for sharing your time and wisdom today with us. We definitely would be seeing you sometime again in near future, talking about some more experiences and insights
Andrey Adamovich: Yeah. Thank you. Thank you very much for having me.
.png)
In the recent episode of ‘Beyond the Code’, Host Kshitij Mohan welcomes Leonardo Andreucci, an esteemed Tech Advisor and Fractional CTO. The central theme of the discussion revolves around - How does the culture & dynamics of high-performing dev teams look like?
The episode kicks off with a fun fireside chat which serves as an entrée into his personal journey and experiences. Moving forward, the discussion takes a deeper plunge into shifting to the customer approach and solving the right problem.
Further, Leonardo delves into the leadership dimension, highlighting the significance of offering autonomy to team members and cultivating trust in their abilities.
Wrapping up, Leonardo imparts a valuable perspective on what constitutes the right team culture within the developers' realm.
Kshitij Mohan: Hello everyone. I'm Mohan your host back with another exciting episode of Beyond the Code by Typo. Today's guest is special and unique in his own ways, right from being a VP of people to VP of Engineering, he has seen it all. He has been in the engineering ecosystem for more than 20 plus years and currently acts as a technical advisor and fractional CTO to organizations.
Please meet Leonardo. Hey Leo, welcome to the show.
Leonardo: Hey, Mohan. Great to be here. It's a pleasure. Thank you for the invite and yeah, I hope we can speak about interesting stuff for the audience.
Kshitij Mohan: Definitely, Leo, your experience speaks the volume, so Definitely. And thank you for sharing your time today with us really means a lot.
Leonardo: Great, great pleasure. My pleasure.
Kshitij Mohan: Perfect. So, given the kind of this unique experience of people, culture, and engineering that you bring, Leo. So today we would love to talk about how to build the right dev dynamics and culture in the right teams. But I think before we get started, we have to go through our fun fireside chat with you. That's when us and the viewers would love to know the real Leo, and that's what it aims to be. So if you're ready, let's get started.
Leonardo: Sure. Let's go.
Kshitij Mohan: Perfect. So let's go. So question one for you, Leo. Since you come from this beautiful Brazilian country, which has its own unique cultural heritage, how do you celebrate this heritage in general? What's the fun way to do that?
Leonardo: Yeah, there are lots of traditional, parties celebrations, holidays, and everything. ,I think the most famous one is Carnival. It's four days holiday in February or March. And each region, celebrates it in a different kind. The one you probably know you'll see on TV is from Rio de Janeiro . So it's a huge avenue and they're actually groups that they compete against themselves. Right. So it's a competition for the best samba school, the best parade, so to speak. And this is huge and people prepare all year for that. I actually prefer smaller environments, so I have some friends that do it, and, it's very popular in Rio and Sao Paulo nowadays too. So you have people going through the streets, a group of, I don't know, 20, 30 people playing instruments and people just moving around in streets, singing, dancing, having fun, having a few beers.
Kshitij Mohan: Haven't you been doing samba, Leo?
Leonardo: I actually played when I university for a year or so, but I prefer the listening and drinking part.
Kshitij Mohan: Drinking part, obviously. No, perfect. I think this leads to the second question that how do you unwind yourself? What's your favorite way of yours to do that?
Leonardo: For the last two or three years I've been playing a sport called Footvolley which is very interesting. I'm addicted to it. It's like beach volley, like two people in each side of a court in the sand. But you cannot use your hands. So it's feet, shoulder, chest, and head. And it's the same as beach volley. Like you have three passes in one side. Then you attack on the other side. And it's super interesting. I've been doing it for a while and. I wanna play it every day. It's great.
Kshitij Mohan: Whoa. That's fun, isn't it? Tough not to use your hands and like, do all the other stuff.
Leonardo: It's, but it's why it's so fun.
Kshitij Mohan: Oh, perfect. I think now coming to the third part of gadgets, right? Android or iPhone, which one are you?
Leonardo: This is gonna surprise you, but actually none. I'm not a huge fan. You know, I have an iPhone, but I use a Windows on a Dell notebook. So for me, it's just a tool and whatever gets a job done.
Kshitij Mohan: Whatever suits you better.
Leonardo: Yeah, I used to be bullied by my software engineer colleagues. Because everybody had a Mac and I was on my windows, and they would make fun of me. But yeah, whatever.
Kshitij Mohan: Perfect. Now coming to the fourth question, Leo, what's your favorite Portuguese saying that you live by?
Leonardo: Yeah. it is not actually in Portuguese. I've heard in the Manager Tools podcast. This is a great podcast. I highly recommend it, and it's something that I've tried to live by my whole life, and then they summarized it. It's "you must not lie or cheat or steal, nor tolerate others who do it" and it's so funny because it's so difficult to not tell little lies in our day-to-day lives. So even to our kids and everything. So I'm really trying to speak the truth at all times.
Kshitij Mohan: Ah, beautiful. Beautiful, Leo. Perfect. I think then one last thing coming to these advice is that what's that one piece of advice that this calm experienced Leo of today would love to give his younger version of selves. So what was that one piece of advice that you'd like to share?
Leonardo: Yeah, I don't think I'm gonna stop at one, but please stop me if I go too far. But the first thing that really changed me a lot is having scheduled weekly one-on-ones with each member of my team, this increases trust and you'll get to know people on a personal level, and for me, it's the basic stuff when you lead people. The second would be not to go into desperation modes like things will go wrong. You will have tough days, you will have tough weeks. You'll have tough challenges and everything, but man, it is part of the job and it's part of life actually. So just take it easy, keep working, and know that it'll pass, you know, you'll overcome the challenge that sometimes we'll overcome you. Things might go wrong. You might lose your job, or, I don't know but then there's a lot of learning opportunities when things go wrong. So even if they do go wrong, there's a still learning to have. And especially when you feel stressed about work, I don't know, one year from now, will you remember why you were so stressed about it? Probably, probably not. So just try to take things easy. And the other thing I've seen people in companies that sometimes they're really restless and I think I am one of these people that I always trying to improve things and move things forward and this not good, this not good. Not exactly perfection, but moving in the right direction, right? And I've seen people say, oh, maybe I shouldn't be doing this and I always say, yes, you should, because these are the people that move the company forward. So if you're a restless person, keep trying to improve things and never be satisfied with the status quo, like things can all go, or, things can always improve. And actually, if they're not improving, they are getting worse. It's hard to keep flat, yeah. So you either improve or you worsen.
Kshitij Mohan: No. Perfect. I think this truly is insightful and I think this totally resonates to what I personally believe that this too shall pass. So what you mentioned, right? So it's good or bad. If it's good, it'll pass. If it's not good, it'll pass. You have to just keep moving. So, perfect. This kind of really helps Leo, thank you for being so candid and being true to us. So thank you so much. Now I think getting to the real stuff, right? So you have scaled, seen the entire growth journeys of startups, right? And while building these dev teams, I think the first biggest question that everyone has is how to do more with less, right? You are always short on resources, but you would always want to do so much. I think your given experience, your thoughts on that Leo?
Leonardo: Yeah. So I think this is not the answer you want to hear, but I wouldn't worry about doing more with less. I'm worried about doing less, like how do we do less?
But we do the right thing it's having laser focus on what you really want to achieve, what you really need to do right now. And for me, this goes through talking to customers all the time. It's something you've heard before, but go out of the building and talk to customers. Understand what you're really trying to build and sometimes in a software product, it's better to have fewer features, but features everybody really uses than have feature creep and other things that nobody uses. And then it gets so complicated, then you don't know where to start. And also to do things that don't scale. Because when you're doing things that don't scale, you are learning a lot and you're doing things manually. So if you're doing things manually, it's much easier to change things right, it's easier to learn and easier to change. If you want to start with an Excel spreadsheet. Go ahead. If you want to start to type form or the low code or no code or just a lead form, and then you call your customer and try to solve their problem offline, that's fine because then you are learning and you're actually working on the thing that really matters, and okay. When you get to the point that you cannot, you have so much demand that you really cannot do things manually, then you have a very good problem you start thinking, you start to focus on engineering and scaling and everything. So that's my point. And I think not that many companies and products are at this stage that, oh, we need to scale to millions of users. So let's focus on solving the right problems.
Kshitij Mohan: Oh no. Perfect. Rather than doing more with less, think of doing less, but with the right set of attitude and things coming together,. Great perspective view. I think this totally aligns, right? So while doing all this, while being in that mode of building and doing everything together, there are two values that I think everyone talks about is autonomy and agility. Because this is what when the right combination fit in is what leads to high-velocity teams. But your take on that, because that's what the biggest challenge is, how do you balance this stuff together?
Leonardo: Yeah. So I've been studying a lot about self-directed and self-managed teams. One important thing to clarify is like a self-directed team is a team that the team defines where to go and this is not the reality of many people, right? When I talk about self-managed teams, what you usually have is somebody defines a direction, probably the CEO or the board or the stakeholders or whomever and then the team organizes themselves towards that goal. So these are self-managed teams and what I think really works is like having boundaries for action. So let's agree as a team or as a company, what can the team do by itself? What does he need to ask for permission? What are the things, like, what are the values? What are the things that we should be working in which way should we be working? And this needs to be aligned, right? So I always say to have alignment between the team and leadership and what should the team do by themselves or not. And another thing that really strikes me is that I've heard it recently, and it's treating adults as adults. So you are hiring a very knowledgeable people. You are hiring knowledge workers. You're hiring people that have studied a lot to be where they are. So you don't know that much. If you have these people, why not trust them to do the right thing? So I really believe in autonomy and having people decide on how they work. How do they approach problems and how do they get stuff done? Because after all, they're the experts here, so this is important for me. Yeah.
Kshitij Mohan: But I think, as you mentioned while doing all this, there is always this difference of opinion, right? People coming with different perspective, different thoughts. And then I think that the biggest challenge becomes in that how do you make people agree to disagree or commit to one cause? And then just moving and going about it? How do you think is the right way to go about it?
Leonardo: To have people agree or to decide the way to move forward?
Kshitij Mohan: Exactly. Because everyone comes with their own set of thought processes. They think, oh no, this could be the right way, or this could be the right way to build, the right way to move. How do you bring those thought processes in line?
Leonardo: Yeah, I think the first perspective that not everybody really thinks about is how much time do we have to make this decision? What's the deadline? If the deadline is five minutes, I would decide right now and we'll not talk to anybody because there's no time. So, it's not common, but it might happen. Okay, so assuming it's not a five-minute decision, how much time do we have? And then, I need to decide which people are gonna be involved in this decision, right? So it's my direct reports or is the whole team, or is the whole company? And this, depending on the decision could be more people or less people, right? If you have more people, you have more, buy-in from everybody. But probably the decision takes longer to be made. So I have to balance this. And then another part is, Okay. If we know the people and we know the timeline, how are we gonna reach a decision? Is it majority through voting? Is it consensus? Is it give information? But I decide or give information but that person decides. So there's actually two decisions should be made. How are we gonna risk the decision? And then the decision itself. And I like consent-based. So somebody would bring up a proposal and say, okay, here's the decision I wanna make. Is anybody strongly opposed to this? I'm not asking would you do it differently? Maybe you would do it differently. But are you strongly opposed as the way I'm proposing or anybody's proposing? 'cause that's the way we move forward a little faster, right? It is not, I wanna have it my way, but it's this way is fine with me. I like the good enough for now, safe enough to try approach. So this is good. And I also like to stress the solution with questions. And to think if it can evolve, because we probably won't get it right this time, right now. But can it evolve? Or if we uncover new perspective or new things or new challenges and the environment's gonna change, right? Things are gonna change, technology is gonna change, our customers are gonna change, but can this definitely decision architecture or whatever, can it evolve? And if we have a path forward, great. The problem is making a decision, if we uncover it was the wrong decision, then we need to throw it away and start all over again. So these a bad one. But if you can evolve, that's fine.
Kshitij Mohan: Sure. I think, but you must have been, in a situation where, hey, you thinking X, but the consensus comes on y then any specific experiences that you had on this? So was it my way or highway then?
Leonardo: Yeah, but I've been proved wrong many times by my teams. So I usually trust the teams and if I have some people that I really trust that I know are very confident and, and they're telling me the other way to go is the way to go. And if I cannot have a strong argument against it, I'll go with the team. And also depends who's gonna be accountable for the outcome of this decision, right? If the team is responsible, is accountable for it, okay, let's do it. It's trusting their people. Treating adults as adults
Kshitij Mohan: Exactly. Coming to the autonomy. So that definitely has to be, has to be felt in. Perfect. I think one last question, Leo. So we've been talking about people in engineering and everything together. So what's the Leo thought of that Utopian or the right culture for dev teams and every role that a stakeholder has to play in building that piece up? So your thoughts on that, Leo?
Leonardo: Yeah. So the first thing I like to think is what's a good software engineering teams, right? In terms of skills so I like to have, I don't know, five people in teams. They should all be great software engineers, great in writing code and everything. But, I like when they are great software engineers and they have an additional skill. So imagine a team of five that one person has good product skills and the other has good cloud skills. And the other is very keen on agile processes. And the other one's very good on metrics. And the other one's very good on quality. Man, this is a dream team for me, right? So
Kshitij Mohan: Yeah, that's a dream team!
Leonardo: Everybody will, everybody will write great software, but they'll get this adjacent skills, would be very helpful to the team. And then when I think about leadership and managers and everything. I really believe in servant leadership. I think the manager is more of a facilitator, right? So I don't think the manager is any better than the rest of the team. He or she just has a different role and this is very important. Like, I'm not superior. I might have more experience sometimes not I might have a broader view of some things, sometimes not. But I have a different role, so I'm not any better than anybody on my team or on my company just because I'm a manager, a director, or a C-level or whatever, right? My role, my position does not define me. So this is important, and I like the manager or the leader also managing the system, not the people, and then reducing the information asymmetry and reducing the power distance, because sometimes you're a manager, but you have more information than your team and then you wonder why is your team not making the same decisions as you would,? Man, because they don't have the same information as you have. So maybe if you give them all the information, they'll get you to the same decision or to the same thinking. So always try to give us all the information I can, I really am super transparent, and I believe this is a core value in any company- to be super transparent and also listen to the team, right? Most of the time, if you ask your team what are the problems they have, they know the problems. And they can tell you what the problems are. They need help solving the problems, but it's not rocket science. You know, like talk to people and they probably know 10 things they need to get to improve. So yeah, let's discuss about it and see how myself as in a leadership position can help the team overcome these problems.
And I think this helps solve the basic stuff. If you do resolve all the problems in the team, you get to a very good position. And then the second part is, okay, let's raise the bar and team. We're in a very good position right now, but it's very different in a retrospective meeting, you ask "Hey, do you think we work together?" And people say, yeah, we work together. Well, our team's good. We get along fine. We achieve great results. The product's going, this one kind of question. But then you ask, "Are we the best software engineering team in the world?" Probably not. So how could we be the best team in the world, right? And then people will start to think like, how to go further along and how to be much better than they are right now. So yeah, it's all about how to frame the question to invite or incite people to be better than they are right now. So,
Kshitij Mohan: Right. So let's pass the right information, push boundaries, I think that's what collectively builds the right ecosystem.
Leonardo: Yeah, exactly.
Kshitij Mohan: Perfect. Perfect. Thank you so much, Leo. Thank you for your time today. This was great, insightful. Thank you for summarizing all your 20+ years of experience in these fine bits of conversations. So thank you so much for your time today, Leo.
Have a good day. Thank you.
Leonardo: Yeah, no, you're welcome. It was my pleasure. I hope it's been useful. Super, super happy to contribute.
Kshitij Mohan: Thanks, Leo.
On our third episode of ‘Beyond the Code’, Host Kshitij Mohan, founder of Typo engages in a thought-provoking conversation with Denis Čahuk, a Tech leadership coach that centers around implementing a human-centered approach for building efficient dev teams.
Denis imparts valuable wisdom on fostering psychological safety within teams and achieving faster delivery of the products. He also delves deeper into event modeling and the role of visualizing the entire impact and leading dev teams.Lastly, Denis sheds light on why software engineers should prioritize developing soft skills; beyond their technical proficiency.
Kshitij Mohan: Hello everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by Typo. Today we have a very special and unique guest with us. Although being a part of the startup ecosystem for more than 15 plus years, Denis brings a different set of expertise into this entire ecosystem. He has evolved his abilities and now helps mentors, engineering leaders to develop this growth mindset. He has a very unique approach, which he calls as a human-centered approach that he brings into the ecosystem and helps build efficient dev teams.
I think we are all fascinated by this concept and would like to hear from the man himself. Hey Denis, welcome to the show. Thank you for your time today.
Denis: Hey, Mohan. Hello to our listeners, to our viewers.
Kshitij Mohan: Oh, yes.
Denis: Thank you. Thank you for inviting me.
Kshitij Mohan: Perfect. I think, firstly, Dennis, we are all fascinated by the concept that you are trying to bring in, and we love, by the way, your detailed insights that you share in crafting tech teams, so that’s really helpful.
And secondly, we have seen that happen. We just love this style of yours, the beads that come in, and I think a few words, we would all love to understand the significance of this and how it adds to your persona.
Denis: Well, I’ve always been a recovering left brainer. You know, I’ve always been very analytical and there came a time in my life where I can no longer solve problems by analyzing them. So I had to experience something outside of my comfort zone and on my way of personal growth and personal development. I sought out yoga and yogic and Ayahuasca retreat, here in Italy, Europe. And that was possibly one of the hardest and, and not just hardest in the sense that it was hard.
There was something challenging, but prior to going it seemed that I am signing up for something that is impossible. That’s gonna be impossible, that’s gonna be for whatever reason, challenging and very difficult. And I just had a lot of irrational fear from it. And I carry it as a reminder that I did it.
That even though I thought it would be impossible, very challenging, that it’s way outside of my capabilities. I’m still here and I’ve grown a lot from that experience.
Kshitij Mohan: Oh. So I think great story Denis. It’s a reminder of you did it and I think. That’s how I think you might have added this aspect into your entire approach of building the teams as well.
Denis: Absolutely.
Kshitij Mohan: Perfect, Dennis. I think, to get started with this entire theory and the concept that you bring in, right? I think the first foundational thing that always comes in is psychological safety, right? How do you ensure that you are able to impart or set this psychological safety within teams that fosters productivity and transparency?
I think that’s the most challenging part that most of the teams face today. How do you do that? Or what processes do you think you follow around that?
Denis: It is one of my core, let’s say the aspects of why I’m not just calling myself a trainer or like an agile coach. I don’t like labeling myself an agile coach.
The coaching that I bring is life coaching. But it’s specifically targeted to a tech audience. And I like to separate that out because I’m not here to coach you on how to use Jira, What one story point means. I don’t particularly care about that nuance of, let’s say, methodology or just tooling.
What I care about the people who use this and one of the aspects of my coaching, the life coaching aspect is that whenever I’m working with a team, I’m also working behind the scenes one-on-one, privately with the team lead. I might instruct them okay, I have a feeling if I ask them, they’ll remain silent.
That’s your feeling as well. And that’s usually the first signal, the deadly silence. That’s usually the first signal that the team doesn’t feel safe to speak up. So it’s very hard to ask a team, Hey, is there anything that we could improve? And they’re silent.
They don’t say no, it’s just silence, right? So it’s not true or false. It’s true, false, and null right? And, you want the process to come to a Yes. And then follow up with, okay, where should we start? Usually, leaders get stuck in getting null back and they don’t know what to do with No.
So, one of the first things we do is even check if that’s a problem. Usually, it is, but it’s not on the surface. So usually I get to know a team before we even get anywhere close to it. But I can sense that there’s emotionally, psychologically, some boundaries, right?
So maybe they’re stressed out, just maybe they don’t have the cognitive load to even be thinking about showing up for the training calls. Maybe there’s just something super urgent going on in a company. And one of the things we do is because I’m working on the team from both sides, with the leader, and with the team. Right. We are working on the team from the outside and from the inside at the same time. And one of the things that I might ask, once we know that psychological safety is something that we wanna work on, I might ask the leader privately, Hey, can you like model a behavior of saying you don’t know?
Or could you model a behavior? Could you do me a favor? Could you just, you know, whenever you encounter something that you don’t know about, just speak up and say, Hey, I don’t understand this. Could you explain it to me, Right? So that the leader models the behavior by example, immediately in front of the team because it’s possible that they, that if the team doesn’t feel psychologically safe, that then patterns start emerging.
And then the leader also doesn’t feel psychologically safe, to be vulnerable with the team, right? ’cause they, they might be playing off of each other to no fault of their own. Maybe it was left there by somebody who hired the original team and then they left and then that culture stuck and then everybody just got replaced one by one.
And then nobody knows really why that feeling is there. And nobody really set it up, but nobody’s really working or understanding of, is this a problem? Is it okay? Like, is this normal? And then the teams usually get accustomed to just thinking this is okay by default. And I come in to say, Hey, well, do you want it to be this way?
It’s like, no. But I don’t see what we could do to improve. Right? And that’s then the first step. Okay, what if we could improve on it? Wouldn’t it be better if we could do this and this and this instead?
Kshitij Mohan: And based on your experience, you have found a breakthrough with the leaders easier or breakthrough, the dev teams easier.
So, because I feel that has to be somehow top to bottom driven, right?
Denis: It’s complicated. You know, like when I’m talking to the leader, he’s also not on top right. I’m not talking to the most technically savvy founder, right? I’m talking to the leader of the team, so even they are not on top.
So they might be experiencing this also as a downstream problem with their leader. So I can’t really go to the source all the time. Sometimes it’s, I’d rather bring in another, Another coach who does executive level coaching or like founder level or board level coaching, depending on the type of the company.
And I just focus on the team and I essentially give a commitment to the team of improving the team without really, ’cause I can just get lost going down a rabbit hole, traversing the entire vertical of the company. And, the further away I get from the team, the harder, you know, it just gets at some point, it just gets organizationally.
So, such a large network of communication issues that change just becomes exponentially harder and harder to impact back down to the team.
Kshitij Mohan: Another perfect use case of human emotions are simple, yet complicated. So I think we totally get where you’re coming from.
Denis: But I don’t wanna dodge your question.
You know what’s usually the simplest is speaking up about it. I will speak up, it’s like, Hey, I realized that you and I decided that this was a problem and, you didn’t speak up. Like just now, would it be okay if we talked about and then I sort of model that to sort of weasel it out, but then if I know that if I leave the room, they won’t continue that behavior, right?
Because the safety isn’t permanent. I might bring it in temporarily so that we can discuss it, but it won’t establish itself permanently. Usually what we do is I would then go talk to one of the team members one-on-one to even see whether they want to improve on it. Right? Because you can always solve it from a different direction.
We can solve it from the direction of, if you’re working in a team where you don’t have that, you can sort of model that behavior bottom up. Not to the CTO level. But at least with you and your immediate peers and with your leader because as far as we as human, as employees are concerned that is your immediate impact radius. Your leader, your manager, your supervisor, your team lead, your tech lead, your engineering manager. They are the one human being other than yourself, who has the biggest impact on your career at this company.
Kshitij Mohan: Exactly
Denis: Right. So at least with them, That’s fully in your control, like how you respond to them and what kind of behavior you model yourself that we can solve on an individual level.
But usually, I’m not hired to then coach each engineer individually as well. We sometimes do that outside, of the company program then if they also hire me individually. I even just now had a, a few months back, had a case where I was coaching an engineer. For a very long time, one-on-one and then the team I was working with, they were hiring and I suggested, you know, they’re like, I have someone here I know they’re really good, they’re vetted. And I happen to know that they’re a cultural fit because I’m a fit with them and we are a fit. So I think if you just met in a meeting, you could, you could decide on whether to hire or not within 45 minutes.
Right. And then they ended up hiring that person, you know? So even that, you know, connecting the dots, playing, sometimes I’m playing matchmaker. And then we continue it from that route because then it’s also easier because if I had worked with them, the employer also knows what to expect because I might have trained them in exactly the same ways that I’m training the team on.
So they have, not only do they know the curriculum, they didn’t even miss out on anything. And they have a head start because we’ve been doing it for a lot longer.
Kshitij Mohan: Perfect, perfect. Interesting. Dennis. So, coming to the point of two spectrums, right? So one is where this entire behavioral part comes in, whereas the other aspect is where every team, every company today is in the kiosk of releasing things fast, right?
So in turning into somewhat feature factories, I think that’s a term that’s going on today, right? Yeah. So how do you suggest to balance this out, how CTOs and the leaders could actually stay away from this trap?
Denis: I think staying away from the trap is not a good strategy. I think you should be able to go into the trap, realize that you’re trapped, and then safely get out.
Right. Because if you wanna avoid it and then accidentally step in, you still need to know how to get out of the trip. Right. So I think if you’re talking about it strategically, you would need to know it is like a first aid kit. Like we are not only doing prevention, but we are also gonna teach you what to do if it does happen. And because you know how much energy you need to invest to do, I don’t know, to revise someone or to give them first aid. When you understand how complicated and dangerous that is then you’ll do everything in your power to avoid that being necessary. Right. But it requires both components.
Right. So if I use this sort of first aid parallel to the feature factory, all you need to know a feature factory is a cost center. A feature factory is a subunit, a department, or even just a team or maybe just part of the team that is organized in such a manner that it is optimized for process.
It is not optimized for outcome. Because it is being perceived as a cost center. So if it has a high cost, we want as much output as much as possible from that unit, from that team, from that sub-department, squad, whatever it is drive whereas a profit center is pushing business KPIs.
And so they know that the salaries are fixed and the other fixed, you know, the other cost of goods and services provided is server costs, license fees, and anything else that might be necessary for data movement or security or just ongoing development as a sort of stable, but unpredictable cost, let’s say.
It is important to emphasize that first, you need to know what a profit center looks like and what a cost center looks like. And then you need to be really honest with yourself, which one you are. If you are a cost center and you don’t want to be, that’s important.
Like you want to, you, there has to be some motivation for you to want to become a profit center. Then we can talk about what you asked me, how do we make a profit center out a cost center?
Kshitij Mohan: What’s important aspect is realization that you are a call center and not the profit center.
Denis: Yeah, yeah.
Kshitij Mohan: No, definitely. And, in your experience, so generally how do you ensure or what process you follow that where people actually believe in this. Hey, we are not at all measuring the impact. We are just kind of running behind releasing it. How, how do you do that?
Denis: It depends.
I think we can’t look at it specifically from the outside, you know? And say, Hey, oh, profit center, cost center bad, and you just go around the company and cost center bad, you know, and just point the finger and just like, you’re a cost center and you’re a cost center.
Everybody’s a cost center. No, it’s really important to not look at things as revenue streams, but as value streams. You know, hotels, luxurious hotels really understand this, that, you know if they hire a driver to pick you up from the airport, that person is part of a value stream. They provide value.
They might not immediately provide revenue, you might not even exchange money with them other than giving them a tip. Right. So they’re not an immediate revenue center, but they are part of a value stream of a bigger profit center. So it’s important that when we’re talking about a profit center, it’s usually not a unit. It is a network of collaborative strands of value streams that are sort of branching out from a core revenue stream, and it’s important that, the profit center who is sort of embodying that revenue stream, owns that revenue stream. So if this is a engineering team that builds a product, they own the business KPIs for the product being profitable.
So if you have a product department and the engineering department, These two teams or units of organization are divorced, right? So it’s like I have a task and on weekends you take care of the task. And on weekdays I take care of the task then that, that’s a divorced value stream, right?
So if the product team owns the value stream, the revenue stream and the engineering team just provides a value stream where they just minimize the cost of the engineering team because the cost engineering team is also being used for other product revenue streams, and then that’s defacto a cost center that cannot become a profit center. Right.
Kshitij Mohan: Definitely
Denis: It is the, it is the product team that needs to absorb the engineering team into itself. Right. You can’t make that engineering team in isolation and just say, Hey, you know, create new networks where you no longer when, when you’re working with this product owner, you’re always a cost center just because of the nature of the relationship. So the only way to get out of that is to fire the product owner, you know, in the context of I will no longer service your tasks. Not fire as in leave from the company, but fire as in, okay, I’m now setting up a vertical. I’m vertically assimilating this engineering team into the company by giving it a dedicated product stream or value stream that they own. Right. And usually, this happens on the wrong end. Usually, this first happens on like DevOps or DevSecOps. You know, when they, they become the owners of security and certificates and how much we’re paying AWS and then they own that and then they actually become a profit center because they might actually optimize, hey, if we, instead of, you know, having three sales ops people who are also engineers, we can just promote them to actually be just full-time engineers and do it to the cloud and do this and do that. Then they become a profit center in that space. But in the context of the company, if they don’t control the entire KPI of providing value to the users. And then understanding how the value is then being captured as revenue, and then measuring that and optimizing that.
You need a small team for that. Yeah. And then a small team that’s part of a big organization. That team, even though it’s really flat, needs to be very high up. You can’t have seven managers above them because that is exactly what will diminish the capability of becoming a process.
Kshitij Mohan: You contextually need to get into the details and then find out how exactly the system works. You know that definitely works. And just going one level deep. So by talking about this, efficiency, understanding the impact of, let’s say, what we were talking about, right? So there is this interesting approach of doing releases with event modeling, right? So then try to understand, uh, all the events and then design and define our information systems.
I think that’s something we would also love to know more about, right? So you have been doing that and you know, where the challenges come in, what the effectiveness looks like, and then that’s something. I think we and the users would all love to understand this piece.
Denis: So how much do you know about event modeling? I can talk about this ad-lib for hours, but it would be we practical to know how do you see event model? What do you think it’s?
Kshitij Mohan: Yeah. So I think the simplest way would be for us, as well as just to keep us context in the conversation, would be that, firstly, how simplistically do you see when modeling, and then obviously second how do we design and implement it, which comes with the second.
The first part, what I see, is as a very simple understanding, the events that happen. And planning so that they happen and fall in the right piece. That’s what very simplistically, I would say event modeling is, but yeah, what your thoughts would be.
Denis: That was what I thought event modeling is, so that was my sort of version 1.0 understanding of what event modeling is until I met the person who discovered event modeling Adam Dymitruk.
I was set up three hour podcast episode with them ’cause we just went deep on event modeling and then I realized that event modeling is a sort of upgrade over typical agile processes. Right. So it’s not so much about designing a spec for events, event schemas as much as it is managing a project that has data flow.
Right. So event modeling is more the idea of rather than if, let’s say Kanban is the flow of tasks through a team’s pipeline then event modeling is the flow of data through the lifetime of creating a software project.
Kshitij Mohan: Got it.
Denis: So like if I have a data point that needs to go from point A to point B, how does that data flow in version one?
How does that, and then when I release version two, how does the flow change? And when I release version three, how does that flow change? Okay. We have a new feature now. Does one of the flows split? Is it a new entry point? You know, are all features just essentially. Are we a feature factory? And you can tell from the event model because it feature factories have a very specific structure of a event model. You can spot that a feature factory is a feature factory, which is by the, the topology of the, of the event model because every stream is being completely isolated. There’s very little overlap. And you can essentially build seven features in parallel, independent of everybody else’s, data flow, except for maybe Feature flags and identity management, authentication, security. Yeah, the common modules. Right. So if you see that like it’s completely separate like this data flow is completely separate UI and that data flow is a completely separate UI. And this one has, and this one has, this one has. And then we just piggyback on synchronizing this, these two data points at the very end there because it’s user related as a feature factory. If we can decide to just not build six of those seven features, focus on one, determine if it has market value, if it has market demand at first, and then if it’s actually valuable to us, if we can then, if it’s valuable to the users, and then if it’s valuable to us, if we can capture revenue based on the value that it provides to the user.
Right? And then you can flip it from an event model, just a typical agile. And what it helps with really is the slice, to do vertical slices across planning, because you’ve probably seen this before, where if there’s a typical like let’s say Scrum -esque Scrum inspired story and you put it in Jira you have this idea of, well, what does this look like when it’s finished? But the tasks and the specs are talking about how to create it. But there’s nothing, there’s no communication. Very rarely you might, the good teams have goals and acceptance criteria. The great teams don’t even use stories. Right. So it’s not an upgrade you use something completely different. It’s this idea that if you’re planning your tasks with user stories, well, the story doesn’t say how it’ll evolve. If you’re doing continuous delivery, it doesn’t specifically specify how it’ll end up on production.
It just says what it looks like when it’s done and how, what are the technical details to complete it. But what we should really care about is if I add this feature, what data flow that’s already there, is it piggybacking on, does it interrupt the data flow? Does it augment the data flow? Does something that was previously atomic now become a saga? If this crash is conducting crash independently, you don’t see that flow because you, in a typical story system, you might just be adding things, but you are not actually adding them so that the old code is…
Kshitij Mohan: Together to reach that one common outcome.
Denis: Exactly. Right. So, it’s as if your source code repository was also event sourced. Scrum creates that illusion that if I add seven features then I add the eighth one. I won’t touch the source code of the other seven, and I’ll just append right to the source files.
That’s not the case. Usually you go back and you start touching stuff. That’s what usually. But like badly managed non-modular, like big ball of mud monoliths are every feature you add, you need to keep touching something from the other features that are already in the system. It’s not an append-only source code repository.
Kshitij Mohan: Definitely.
Denis: And that’s what the event modeling tries to sort of highlight. It’s like, hey, if you’re building this feature and you need to touch a line of code in these nine other things, this is probably not the best way to go about it. But usually, this is not visualized. Right. And it’s only visualized partially, very temporarily in one engineer’s head, and only when it’s too late to course correct. When they’re already working on it and they’re stuck on something that would be the correct time to course correct in order.
Kshitij Mohan: But it’s to realize that you would have to have the context of the entire system. And I think that’s where biggest challenge comes.
Denis: And the engineer has that when they’re writing the full end-to-end or integration test. So at least one person at some point will have that, but it’s usually too late in the project. Event modeling brings that further forward, but there’s a trade-off. The trade-off is you can’t really use it well with other project management methodologies. Like the event model has to be the main management methodology. Because the thing is that I really recommend beginner teams to start adopting is, well, now you see what it looks like, and an event model doesn’t just have events on the diagram. It has a historic flow of data. When the user logs in, here’s the user’s credentials, and then here is how the user’s credentials flow to the system. They appear temporarily here, they get transformed, their own account. Then that other piece here, that becomes a session and then this session at some point dies, and then they have to go back and do that thing again in a different kind of flow, and then that’s visualized. And this can also be the case for a bank account or an order or you know, it might go into the system and then we determine that, hey, actually we didn’t fulfill this order, but we forgot that we didn’t fulfill this order and now it’s been two months. Now it’s inappropriate to fulfill the order. So actually we need to go through a different flow but this is hard to express if you don’t think about your features as a data stream. Usually, features are a stream of development focus of, okay, where should we put engineering focus this month? Rather than, how are we adapting the data flow? And what I recommend teams do the, you see the entire diagram, the events are not, the only thing on the diagram, what’s in the diagram is the dependencies between the event streams, the consequences of the event streams, the side effects of the event streams, and for each UI element you can see on the subcutaneous level. So it’s that invisible stuff just beneath the UI, non-technical stakeholders usually call that long darkness of backend stuff that you guys do that we can’t see.
Kshitij Mohan: The black box.
Denis: It’s exactly expressed on the diagram. It’s like it becomes visible. Here it’s under the surface. This is the backend stuff, and you can see it because what we’re building is the flow of the data.
We’re enriching the flow of the data. And what we you can do with event modeling is because you have them left to right sliced on a timeline, following the age of the data stream, you can decide not to start the project from the left side. Usually what teams do they start the project from the left side of the timeline of the data. So if you have a new greenfield project, you know, day one for data points are user registration and login. And then that’s where they would start the project following the age of their data. Whereas that’s usually the most commoditized part of the system that not the engineers should really be wasting time on. But then with the event model, we can say, well this is how it’s gonna end up. That young data age stuff where we are registering people, we’re not gonna waste time on that. Let’s start on the right side. Let’s start on the right side where I have a UI element that shows something really important to the user. You know, if I’m building Instagram, that might be the users feed. And when they come up they need to see a new feed every time. Let’s start with that. And on the subcutaneous level, let’s just fake that. Let’s just serve them random images until we connect the dots on the data pipeline behind the scenes. And let’s make that version one and let’s deploy it. And you can explain that to somebody who is non-technical by just visualizing the event model. But saying here’s the UI updates when this, what I call a projection, which could be and if you saw. Now that Twitter X whatever, twitter’s code was, the algorithm was published on GitHub. And you can see that, they have this sort of same similar system where they’re creating they’re not computing your feed as you log in. They just have it ready as a projection. So if I told you this is what the projection, this is the schema of the projection, looks like if I create a fake UI with a fake instance of that schema, I can create a prototype, no problem. I can create that prototype, possibly even using low code or no code solutions temporarily while the backend team is solving that really complex issue that where the, you know, the seven streams of data meet and then they, something complex happen.
You might actually have something to show and then the project manager can say, well, you know what? For every UI element that we need to update, I want us to at least fake a lot of non-important stuff while you guys are working, like cracking the nut on this really big important thing. I still want us to see progress so that I can, you know, run tests or give it to the users or I wanna know how far away we are from the point where the users notice that we are faking data and that the next valuable step is giving them the real data.
Because if you’re saying no to all that, if you’re building software products, especially as a startup but you’re not even considering that option where version one is a feature Complete, fully blown enterprise-level version of the product. You are a year, 18 months behind the market.
Kshitij Mohan: Yeah. Definitely. I think this kind of helps into detailing, breaking it down, visualizing the right way.
Denis: The breaking down is still, you know, it’s still here. The model doesn’t break down the problem. You still need to ask a lot of questions, so you still need another process.
Event storming, you can still do naturally. And then just instead of leaving it on a board, that then becomes maybe an architecture diagram. You continue storming and you just continue it into the event modeling flow. It’s like, okay, well we are in event storming, but rather than just talking about events, well show me what UI disappears on and then what do we, what do we call the data set that the UI is using?
And okay, who can possibly cause this data set to refresh? Okay. How can the user cause this data set to refresh? How often does that happen? Does it really need to refresh every time the user does this? And then that’s how you have these kinds of conversations on a completely non-technical jargonistic level.
And then you can decide to, you know, There are two, like Miro is great for this ’cause you can just zoom out, create a frame for it, and you can zoom in. And then when the non-technical stakeholders leave the room, the engineers can just zoom into one of them and then add the, the JSON Fields and the schemas.
And then I’m gonna have an entity direction diagram in here. And then when they come back into the room, you can zoom back out and it disappears.
Kshitij Mohan: Perfect. Perfect. Dennis, I think this really helps. Super insightful on how visualization can definitely help and that leads to I think, one last aspect that we would love to talk about is these, the soft skills that you bring in this entire game, right?
And one of the important aspects that helps you grow and progress over time as well. So, quick thoughts on what do you think are the right set of things a leader, a manager should be focusing on, on the software scale aspect?
Denis: I like to think that engineers are very intelligent people that everybody really understands that this is really important. So the question isn’t so much, you know, what should they be working on? And should they be working on their soft skills? I think the really tough question is figuring out instead of what, right?
Right. Because people might be thinking, oh yeah, I’ll learn soft skills if that’s replacing some of my boring meetings or if it’s replacing some of my annoying one-on-ones with my manager. I will learn soft skills if it gives me a little promotion. If the, instead of what is really benign, And sort of passive and on the side.
But I think if you really wanna take your tech career seriously and if you wanna take your, as a leader, as an engineering manager, as a tech leader, uh, or even just a product manager, if you wanna help your team hold themselves accountable, then if they’re behind on soft skills or if they think that that’s the biggest step forward and usually it is.
Then the soft skill training has to happen at the expense of technical specialization, and that’s the tough decision. It’s like, no, don’t learn the new framework. Leave zig and rust alone. Don’t do that new greenfield project. It’s like whatever technology we’re using, it’s good enough like to just use boring commodity software.
And better yourself as a human being. You know, rather than following, trying to follow the trend and getting really anxious about, oh, the AWS has a new certification
Kshitij Mohan: Yeah, everyone worried about the new tech being released every other day
Denis: And, oh my God, and ChatGPT and, now it’s no longer considered private and secure.
So now I need to learn link chain and what’s length chain and. What is it like? Like what I need to catch up on seven years of linear algebra and calculus. It’s like, no. It’s like those tools can wait, but soft skills can’t. Soft skills are your highest predictor of movement in any kind of organization.
Soft skills can help you land positions in FAANG companies, even if you’re technically not really competent. Like it is that impactful. Like, okay, the FAANG companies might be a little bit stretching it ’cause they, you know, if they have nine rounds of interviews with you, they might call you out on something that you actually don’t know.
But you might learn it on the interview. If you know how to prepare, you might, because a lot of engineers just going into interview and they get asked a question and they just freeze. They try to think themselves. Whereas with somebody who is not engineering savvy or didn’t spend a thousand hours on leet code, it’s a huge waste of time if they’re have very good soft skills.
You know, they might call out on the interview, Hey, like this is really awkward, but I don’t really know how to solve this. So I think that’s it for the interview, but could you gimme some pointers on what I should look up or where I could learn more about this and they might actually give them immediately material to look up and learn.
It’s like, do you mind if somebody who is sort of well versed in soft skills might ask, okay, well actually would you consider it cheating or would you mind if I just looked it up now and see where we can get to and like 20 minutes, right? Because that might be a much more. Warm and charismatic and likable approach to just having the interview.
If nothing else, it calms down the interviewer and you should get them on your side and that can go over a very long way. But now I’m talking about this from sort of a freshman sort of intern level for a team that’s has been through all this and there are professionally decoupling has already happened.
You know, the team is now part of this team. The team has this manager, it has this tech stack. So there aren’t as many reversible, malleable decisions anymore. That team also has a lot of cultural depth. So the real question is not should they train soft skills. The question is obviously yes should they train soft skills?
But even if I, even if a team member like really goes up and wide on soft skills, is there anything on the team that prevents them from applying it? That is what I would focus on as a leader. It’s like, is there anything in our culture that prevents somebody who is well-spoken, who is very friendly, who is very open and helps everybody?
Is there anything in our culture that prevents them from embodying that? Like would they be attacked for doing that? Would they be mistreated or ridiculed or, you know, I come from the Balkans where we have this sort of, proud view of, you know, if you don’t know something, you should have a plan.
If you don’t know how to make a plan, you’re probably incompetent, right? So you should hide. You should rather than talking about your problems, about your incompetence, you should just read up on it and prepare for the next meeting. It’s sort of Spartan approach to a more competitive kind of collaboration.
Whereas, you know, the, one of the hardest things that I do with like C-level coaching or just, senior management is I’ll just keep asking them questions until somebody says, I don’t know. And often times people can just, just spend hours running in circles and they will not say, I don’t know.
Right. And then I might even call them out as a coach and I say, look, I’m already asking you these questions because I wanna come to the point and I’ll say it out loud to them to their face. I just wanna get to the point where the answer to the question I’m asking is, you don’t know.
I’m just waiting where we have to go so that people will talk about that. And usually, it’s talking about engineering with somebody from product. Hey, Mr. Product, how long do you think your engineering team needs to build this? And then they will say, I don’t know like they know.
And then once they say that, I might ask them, okay, well what do you think, the revenue estimate is once they finish this feature and implement it? Like you’re head of product, you should not revenue estimate. It’s like, what do you mean? They might have never done that before. They might have only done it in one way. It’s like, figure out what the next product cycle is and then just try to motivate the engineering team so they deliver it. But it gets in the way if that prevents the other arrow from pointing out upwards, which is okay, well we need to have an estimate for how much revenue it’ll provide. cause if you don’t have that, we don’t know what the upper bound of how much cost we can, we can endure building it.
Kshitij Mohan: Yeah. So I think in this example, you touched everything that we talked about, right? From the psychological safety to visualizing the entire impact, and I think coming to the soft skills.
So I think this really sums up our discussion, Dennis. This has been really interesting to hear a totally different perspective on building and leading efficient dev teams. So thank you so much for your time today, Denis, lovely having this conversation with you.
Thank you so much.
Denis: Thanks for inviting me. I really enjoyed it. Great questions.
On our second episode of ‘Beyond the Code’, Host ‘Kshitij Mohan’, founder of Typo welcomes Gregor Ojstersek, CTO at Zorion, Singapore. The focus of their discussion is on establishing strong foundations for engineering teams.
Gregor places significant importance on creating an effective hiring process and highlights the value of assessing soft skills in potential candidates. With remote work becoming a norm, he provides valuable insights on cultivating the right team culture to ensure successful collaboration and productivity.
Lastly, Gregor shares his profound advice for leaders aspiring to guide their team members along the right career paths.
Kshitij: Hello everyone. I’m Mohan your host back with a new episode of Beyond the Code by Typo. Today we have a very special guest with us, Greg.
Greg is an engineering leader, has had almost 10+ years of engineering experience across the startups. Today, he works as a CTO at Zorion, Singapore. The best part, he’s highly passionate about sharing his knowledge, his experiences, and runs his own newsletter, engineering leadership.
Welcome Gregor to the show. Thank you for being here.
Greg: Thanks a lot for having me. I’m excited for this.
Kshitij: Perfect. Thank you Gregor. So Gregor, given your kind of experience and your expertise today, we would love to talk about how to set the right foundations for engineering teams. And when we talk about foundation, I guess the first aspect always is hiring.
We would love to understand from your experiences that what’s the right set of assessments, challenges, what do you think are the right ways? In order to hire right. Engineer into a team. Your thoughts on that, Greg?
Greg: Yeah. Creating a good hiring process is always, a work in progress, right?
It’s never going to be okay, we reset it like this and then it’s always going to work, right? It’s always about putting something in place and learn from it and adjust it and, try to make it better. I have a good kind of a process now that I’ve been interviewing more than about, let’s say more than 200 engineers in general.
And, what works really well for me is to have, for example, a first kind of initial call with engineers that, for example, does like a recruiter, or hiring manager. And, just to check if there’s an overall fit right? For us. On the both sides… And then once, once we have that, we move to, a hiring manager interview.
And that’s where I like to talk about all kinds of things in terms of soft skills, and technical skills as well. Behaviors and things like that. And, once we have that, obviously technical assessment is, where it’s, where we can stop a little bit more and we can talk about, some fine details there.
And because I think, if technical assessment is done correctly, it’s really a good kind of indicator of how successful is the candidate going to be in a particular job. Right? And I always suggest to do a great preparation for a technical interview, that means that you need to understand what kind of skills are you looking for and what kind of aspects of the role do you want to do, they want to fill. Right. And I always suggest creating a scorecard before doing a technical interview. And, don’t just put there any kind of technical skills, but also some soft skills as well skills like collaboration. Is a person team player? Is a person keen to take ownership in general, right? Those are really important aspects of an engineer as well. And once we have that, it’s good to understand what type of technical interview you wish to do. I prefer myself personally, I prefer to ask a lot of open-ended questions.
And then, we drill down to find details later on. Things like, Hey, what have you worked on a previous project? What task was the most, and the hardest task that you worked on a previous project? And then we talk about it and then we drill down to find details on certain queries, certain endpoints, and things like that, that tells me, like gives me a lot of insights of, what is the thinking process of a particular engineer. Right? And, if in case you need to do any kind of coding tasks on a technical interview. I found out that, we all know in bigger companies like all of the main companies, they do algorithmic interviews, right? That’s the best way to go with the technical interview. And that’s because, in most jobs that we do, we don’t actually work on algorithms on a daily basis. Right. So I would try to suggest if you need to do like a coding task like we would give a simpler task and we would ask a lot of follow-up questions on that particular task. And in order to make it more collaborative, not just, okay, hey, here’s a task, you have 20 minutes to solve it. Okay, here’s the solution. If you believe it or not, you know, it’s not that much important that the candidate actually solved the task a hundred percent. But what’s more important for me is that the candidate is asking a lot of clarifying questions. He’s trying to understand the expectations and trying to assess different options and not just immediately trying to jump in the implementations. Those kinds of things, I value quite a lot.
Kshitij: Basically, approach is more important than the actual outcome.
Greg: Yeah, exactly.
Kshitij: Perfect. And like when you talked about this process, right? So I could hear that there is a very clear indicator that soft skills also are an important aspect to do that. And it’s always tough to actually, gorge the right set of soft skills. Right? So any specific practices on that, how you have been doing so?
Greg: Yeah. As I mentioned, things like responsibility and ownership and teamwork and team mentality, and helping others. Those things are really important. And whenever you’re having an interview, you try to assess that kind of a previous experience if the person has shown that experience in some previous roles or previous projects. That’s why we like to talk about what was your role in the project. What did you do here? How did you help the team? How did you help others? Did you mentor any of the engineers? Did you do onboarding as well, did you do any kind of presentations to share your knowledge with others? Things like that are really helpful to trying to assess and overall, how does a personal approach to problem-solving? Do they immediately just jump to implementation or they’re trying to really understand what is the pain point behind it? What is the business value that we are actually trying to resolve here, those kinds of things we need to always keep in mind.
Technical skills can be learned quite fast, especially in a good environment. But, being a good person to work with and a good teammate, those skills are a lot harder to learn.
Kshitij: Perfect. Makes sense Greg! Moving forward Gregor, so you have always been an advocate of remote work, right? And you yourself have been working remotely for so long. So this is what the biggest question that has always been running around is, right, how do you get developers give the right onboarding experience to them, especially while working remote? How do you help them assimilate in the team, get the right info, set up things in? So any thoughts on that, Greg?
Greg: Yeah. In remote work, you’re trying to get better at it. I think we’re still not there yet where we can have a fully-fledged process that well in place. For a successful remote work. But, it’s important that we strive towards getting better at it all the time. You know, for any kind of onboardings, it’s really important to have good documentation in place. And, what I really like to do is if we bring a new engineer to the team, I like to appoint an onboarding buddy, one or potentially two. And they would really be helping that engineer, in general, to get onboarded – a lot easier, a lot faster. Because, if you’re starting and joining a company, you don’t potentially know a lot of people. And if you already have one person that you can go to and that any kind of questions, yeah, I can just ask and learn about a lot of different things from that person, right? So, yeah, documentation, onboarding buddy, and also, good processes in place in terms of like a daily meeting. And, I try to focus a lot more on goals and not so much on tasks and details. That means what we try to do is to create sprint goals. And that is two weekly or weekly sprint goals. And, that means that we are all trying to focus on delivering these goals after the end of the sprint, right? So it’s not about the details of particular tasks, but hey, I know we are all professionals here. I know we are all great engineers. We all love what we do. You know, results are what matters and if you define the outcomes that should be successful, then, you don’t need to go in details in every task in order to make sure that everything is going according correctly, especially in a remote environment, right? You’re not working with people directly and you don’t have a person by your side all the time, right? And the best way is to define goals and hold people accountable, define ownership, define responsibility. And, people are going to do well if they’re assigned ownership and they take ownership themselves and they try to do the best job as possible. Often times you get surprised on how well do they actually perform doing that.
Kshitij: Basically empower them more, and they’ll definitely perform the way even much more than your expectations.
Greg: Yes, exactly.
Kshitij: Perfect. And Greg, Are you completely relying on Slack as a communication channel or any other channels that you feel are really effective in communicating across teams?
Greg: Yeah, we use Slack a lot. And Slack is obviously probably the number one go-to tool for any remote company. And, yeah, it’s good to do some automations on Slack in terms of like, let’s try to put some action items, for our daily meeting. What could be done? What are we trying to do? And so on. Also tools, for example, What works really good, for me in a lot of, different examples was collaboration tools such as Miro or Figma. Right? And, that works really well because you can do collaboration on these tools together, like a brainstorming session or a good pros and cons list altogether. Everyone jumps on this tool and, we’re collaborating on it and we all are able to put things in there. Right. So it’s really good to proactively do it together as a team to brainstorm ideas, to define pros and cons. Maybe we try to define a technical specification or a design decision together on this. So yeah, mirror or Figma, those tools are really important. And obviously, any kind of video meetings or any kind of tools where you can jump on a call anytime are really great. I’m a big advocate for having a camera on and not just jumping on a call because it feels a lot more personal. And, I feel like I’m connecting a lot better with people when I actually see them. If you’re just, speaking about things and just talking without a camera, then it’s similar like being on a phone, right?
But you don’t get to see any kind of nonverbal communication, right? But you get to see a lot of nonverbal communication from being on a camera and, it’s a lot better way to get to know people a little bit more.
Kshitij: Let’s share raw emotions, basically.
Greg: Yeah.
Kshitij: Perfect. And, while building all this, so there is always an important aspect of culture, right? How do you set the right cultural practices even when you are not together? It’s so important to ensure that everyone stays together, aligned, follow the right set of values. I think that’s the biggest challenge.
How do you cater to that in these remote scenes today?
Greg: Yeah, it all starts with the mindset of the team and, you know, having people in the team that understands that software development is a team sport and only great teams build great software. That’s really important to understand. When speaking about mentality, I always like to have driven and motivated people that always like to learn new things. That kind of mindset is contagious and everyone benefits from it, right? Understanding that software development is a constant evolving industry and that we all need to learn is obviously a great mindset to have. And then, it’s important to understand for great teams. Great teams are autonomous. They don’t need or want to be micromanagement. They don’t want micromanagement, therefore, they’re not afraid to take ownership and responsibility of their tasks. And, customer is at its core of what they’re focusing on. Great teams should always think of ways of how to find out what the customer wants, and then prototype and deliver the functionalities that customer needs.
Kshitij: Sure Greg. I think while building remote teams, there is always an important talk about how do you set the right culture, when people are not together, working remotely. So there is always a concern on how do you set the right cultural practices so that everyone’s aligned with common set of values, collaborate better. Any thoughts on that? Greg? How do you set these culture practices right?
Greg: Yeah. It all starts with the mindset of the team and having the people in the team that understands that software development is a team sport. And, only great teams build great software. And, when speaking about mentality, I always like to have driven and motivated people that always like to learn new things.
That kind of mindset is very contagious. Right. And, everyone benefits from it. And, understanding that software development is a constant evolving industry. And that, we all need to learn is a great mindset to have. And, then it’s important to understand that the great teams are autonomous, right? They don’t want to be micromanagement. Therefore, they’re not afraid to take ownership and responsibility of their tasks. And also customers always on their minds. Customers is at its core of what they’re focusing on.
And, great teams should always think of ways of how to find out what customer wants and then prototype and deliver the functionalities that customer actually needs. Another thing that, I found out is that for individuals to focus solely just on their task, that does not do well in a great team. Great teams are always trying to help each other in making sure that if someone is stuck, others are there to support. And, good teams also enjoy doing things like pair programming, more programming because first of all, it’s fun. Second of all, you can resolve problems a lot faster doing it this way. And at the same time, you also focus just on that particular task. And, especially like if you have any juniors on the team doing kind of any pair programming is really a good way to onboard or just share knowledge with a more junior engineer in general.
And, the last thing, what I would say regarding this is that we as engineers, we are here to provide as much business value as possible to the company, that is our focus why we are here. Therefore focusing on that how to provide that value should be the number one motivation for a great team. Not just focus on building great technical solutions, but finding out, what pain points does a business have and how we as a team can resolve some of this pain points. That’s really what is really important for a great team.
Kshitij: Fair point! I think in the end, we are all trying to serve to our customers. So business impact is what matters the most. I think, one question here Greg, so I think the biggest challenge is how do you keep on imparting this thought process right back and forth again and again to the team members, any specific processes that you have been following that, Hey, you know, let’s just stick to what the common goal is.
Greg: Yeah. We talked a little bit about sprint goals, but also I think, what is really important here is to, me as a manager, it’s important for me to have one-on-one meetings with my reports that means, and engineers, right? And, it’s important to make sure that, we always are trying to focus on these values, right? And whenever we see that potentially, like someone is maybe doing something differently or is not focusing on these values, you know, you need to give feedback as soon as possible to that particular engineer. 99% of the times engineers is going to really appreciate giving that feedback because it’s not only for him or her to get to do better on the job, but also they grow a lot more as an engineers. If they’re focusing on these values, because a lot of times people don’t actually understand what do they need to do in order to be successful in a position, right? Whenever someone starts, you need to set the expectations correctly, like hey, these are our core values, is that we’re following, and things like that. And then you need to assess and need to give constant feedback on. I love to give feedback on one-to-one meetings. I don’t like to wait for performance review meetings. We should give them more frequently. It’s a lot better than less frequently.
Kshitij: Perfect. Greg, this is really insightful. I think just one last thing that we all viewers, as we would love to hear from you. So what’s that, Gregor’s magic sauce or what’s that Gregor’s advice to the leaders to learn how to help their members shape their right career path?
So they go more towards the, EM focus, the management part, or they’re more aligned towards the tech, the architect part. Your thoughts on that, Greg?
Greg: Yeah. That is the number one hot topic when I’m talking with any of the engineers and, there’s a lot of uncertainty like we just, which is the direction that a certain engineer wants to grow and that’s perfectly fine, right?
And what I suggest to engineering leaders, it’s really important to have conversations with engineers and talk about their career progression in general and, try to give them options in which direction they wish to grow, give them more insights and, they should be discussed frequently on one-to-one meetings. And, a manager should provide different options. And, an engineer should try to put themselves in that particular position and see how they would actually see themselves in that position.
What I like to see here as well is that engineers also show their motivation and drive and already do like a research. Particular roles and different paths ahead of time. So they already show I’m motivated and driven. I wish to grow. I wish to progress as an engineer. I wish to move to another path.
Hey, what do you suggest? And then, the conversation is a lot better and a lot easier when the engineer actually shows the motivation and drive. You already know that engineer is willing to grow. And it’s a lot easier to help that person.
Kshitij: Definitely. But I think, it would be more tough for, from an engineer aspect, hey, what could be that right path for me? I think that’s always a yeah. And right. So any specific thoughts on how I, as an engineer gets to evaluate myself better?
Greg: Yeah. That, that’s a good point. I’m a big fan of trying and see how it goes.
I like to say trying is the best way of knowing, right? If you don’t try, you don’t know how it actually feels. What does it feel for you? In general. And, does this work actually fulfill you? I would suggest for every engineering leader to provide like opportunities for engineers to take on a role like a manager or architect for at least some time to see how it feels if they enjoy it in general. Right.
For example, would be like a give an engineer like a week or two to be a team lead for that particular team and, just see how it feels for you and, maybe for an architecture path, maybe give an assignment to an engineer to create a design specification that would be focused on a particular functionality.
That’s how an engineer can actually see how does it feel to actually be doing the work of an architect, obviously. Put some mentorship in place and give some guidance for maybe a more senior person that would be really and you mentioned that engineers don’t know yet in which direction to grow most of the time.
That’s also been one of my findings as well. And what I always like to suggest is that if you don’t know in which direction to grow, focus on leadership skills because in every path you are going to grow, leadership skills are going to be needed. And the reason for this is that, the more you grow, the biggest impact they have on the organization and, on the business in general. And, you can’t have a big impact without having good leadership skills.
Kshitij: Perfect. Greg, this is insightful.
Thank you so much for your time today. It was an amazing conversation with you. We would love to keep on supporting you in this entire journey of helping managers, leaders be better at their work. So thank you so much, Greg. Thank you for being with us.
Greg: Thank you for having me.
On our very first episode of ‘Beyond the Code’, Host ‘Kshitij Mohan’, founder of Typo welcomes Francisco Trindade, Director of Engineering at Braze to discuss ways how to lead engineering teams efficiently.
Francisco provides valuable insights into the obstacles faced by engineering teams. He emphasizes that technical challenges are not always the main hurdles; instead, it's often the lack of clear communication and well-defined goals. He also addresses the challenges encountered by engineering managers, highlighting the importance of behavioral aspects in leading teams effectively.Moreover, Francisco unveils his secret sauce for maintaining team efficiency, further enriching his insights on successful team management.
Kshitij Mohan: Hello everyone, I’m Mohan, your host, back with a new episode of Beyond the Code by Typo. Today, we have a very special guest with us, Francisco. Francisco has been an amazing engineering leader for the past 15+ years. He has donned multiple hats across his entire journey. He has been a founder, a manager, and a consultant, right from startups to enterprises.
He had seen it all. Currently, he’s an engineering director with Brace in New York. Welcome Francisco to the show.
Francisco Trindade: Thank you, Mohan. Really happy to be here. And thanks for the lovely intro.
Kshitij Mohan: I think that definitely speaks of the work that you have done, Francisco. So thank you so much for being here with us today.
Perfect. So Francisco, given your amazing experience across the entire journey from a developer to a manager, to a founder, to everything that a leader would want, I think all of us, all of our viewers would love to understand what inspired you? How have you been able to do so much in such a less time?
So would love to hear your insights on this journey part, Francisco.
Francisco Trindade: Yeah, thank you. Well, it took a long time, and I guess I just kept doing one thing after the other. It was interesting. I think I started as a consultant, I think where this idea of being a manager or leader comes from. I started as a consultant back in the day. my first job in my career. And our approach, when consulting, I was an engineer, of course, I was writing code most of the time and being placed in projects and engineer, but a lot of the perspective that we had was how to, and the things that we asked to do was how to improve teams, asking how to improve how teams worked.
And a lot of that was based on process and process. Not just like how to write cards, but how do you the testing, how do you automate the testing, how you write code, the technical and kind of like technical and non-technical systems that are around the team.
And so a lot of what I did for many years was being an engineer but trying to help other engineers and teams to become more efficient. And in that kind of process, I think I noticed that throughout my career a lot of times, the technical challenges weren’t the things blocking the teams, right?
So we used to have a quote that we used to say, that was just like, I’ve never seen a team fail because the engineers were incapable enough, right? So because they didn’t know what they wanted to do like they needed to do. But I think I’ve seen many teams fail because, communication was broken because, the goals were like, is a line because nobody was talking to each other.
So there was a lot of around teams that made things complicated. And I think, and also throughout the process, I felt that I could, because I understood both sides, I was able to work on both sides of that equation of being an engineer and being technical, but also helping organize teams.
And so that was the, so did that. And, At the same time, I started being very interested in startups, and at some point, I stopped being a consultant to then like, join, didn’t start a company which I did in Australia for six years. And that was my first experience trying to prove, almost like trying to prove that I could do it myself or how can, can I?
Okay. Nice. Seems the way that I think they should be.
Kshitij Mohan: That’s how every founder starts with this biggest question of, can I do that myself?
Francisco Trindade: Right. So can I just instead of trying to convince someone else how to run their team, can I just run it the way I want it and, the way I think is correct and see how that works?
And so that was a good experience. And then five years ago is when I moved to the US it was when I first got my first job as an engineering leader that was an engineering manager and then I’ve been doing that for the past five years and did a few companies.
And then I guess in this past five years, I’ve been, of course, applying those principles, applying those things, but also iterating and understanding. Trying to understand more and more about this role that’s relatively new, which is the idea of an engineering manager that and how that could work how can that be done to work well, but to make sense work well?
Kshitij Mohan: Perfect. Definitely Francisco. So one quick question, what was more difficult to you trying to convince yourself or trying to convince others now?
Francisco Trindade: It’s definitely a thing when you are doing it yourself. I think there’s nobody to ask for advice and there’s nobody to talk about, like mostly there’s nobody to ask for advice.
Kshitij Mohan: You just have to figure out everything on your own.
Francisco Trindade: Yeah. You have to. I think you understand a lot that there’s no certainty. When you’re doing your own thing, you have to believe in something and try it and then see the result much later.
So a bit is just like trying, it’s just.
Kshitij Mohan: So this really helps Francisco, I think, in this journey. One question that always comes up, right? So what do you think has been the biggest challenge or the biggest transition phase of your career that you feel was something that was really tough to move on, but yeah, somehow you put it through?
Francisco Trindade: Yeah. I think like moving from I got my first engineering manager, so I was a senior engineering manager, in a few roles a few years ago, when I moved to the US. The first time I was formally doing that because before I was consulting, which was kind of way indirectly try to help teams and then I had my own company, which of course, you’re doing yourself, there’s no one else telling you like what to do, but also there’s no one else that you have to convince, right?
You just can do things that you want. So then moving as a senior manager within a larger, like a midsize startup. It was challenging for a while, because it was a different perspective, right? There’s like, yes, you’re managing a team, but you are within an organization.
There are existing policies and existing beliefs. So how do you find your space within a larger, larger place and find alignment and buy-in for your ideas. I think that’s something that was definitely a kind of thing and adaptation that I have to go through and I think it was a challenging part.
Kshitij Mohan: Definitely. I think we can all relate to Francisco. So now coming to, I think what you have built your expertise in, right? How do you build these effective dev teams? What take to scale these teams sufficiently? So I think any specific thoughts, Francisco, any specific processes that you think you followed by ensuring, Hey! the team stays aligned.
There is enough motivation to encourage for innovation, creative problem-solving, and anything that you could share Francisco.
Francisco Trindade: Yeah. I mean, I definitely don’t want to. I don’t think there’s a recipe for make teams work. I think that’s why it’s an interesting area.
You have to adapt to the situation and companies are different, industries are different, the needs that you have a different but I think most of the principles, I think that I keep going back to is aligning people to the problem.
So more you can align the team to a problem instead of a solution that they need to build, the more they have to, they become experts in the problem. And that’s of course they have product managers and you have people their role is to do that.
But I think you shouldn’t take engineering out of the equation. I think the combination of that and having engineers be part of understanding the problem and understanding the solution and helping frame the solution. I think that is one thing. So alignment seems so problem and then short and feedback loops, right?
And the more you can reduce the loop from like across the spectrum, of course, ultimately like the loop from idea to delivering something that I’m sorry, having the problem to deliver a solution. That’s the main loop, but within that, then you start thinking about where is the planning loop.
Where is the testing loop? Where is how fast can you trade in writing software and you know, automated testing and all these things that you kind of have to, you can try to reduce to them, ultimately. The faster you can get, the more that your team understands the problem, the more and the faster they can get from like having a specific thing needs to do to then deliver something to market or the customer, the better they’re going to do.
Right. Because the more chances they’re going to have to get it right. That’s basically what it boils down to.
Kshitij Mohan: I think perfect. And so you talked about, right, there is so much of this behavioral aspect also while building these fast-moving teams. So I think this is a question that always the first-time managers feel, right?
So since coming directly from maybe someone who writes and leads the stuff to actually leading and managing teams, right? This is definitely a very difficult transition for someone who gets into the shoes. So, what could be those, or what are the things that, from a behavioral perspective, right? A first-time manager should be looking at?
Francisco Trindade: I think the main thing that I keep when I talk to people, that I try, I’ve been trying to do more and more recently is just like help engineers become managers within kind of teams that I lead. And I think like the organization that I lead, and I think the thing that I keep getting, going back to is just like understanding two things, one is that you, you are kind of impact now is the team’s impact.
So you’re kind of like, you know. It’s not about how much you deliver, delivering being how much you write code or how much you write documents or whatever that is but it’s about how much your team does right. And that includes your participation but includes everyone else.
Right. So that’s how you are up to what, that’s what you should be optimizing for. And I think the other challenge, I think that all the other thing that I tried to talk about that I think is a common challenge is the idea that you can, you should actually lead your team, right? There is a thing, a comfortable path of love becoming a manager that I think sometimes is taken, people take, which is like.
I’m just going to listen to what people are telling you. Engineers are telling me and let them decide everything, decide how to work and how to do things. And, that’s my job, right? My job is just making kind of people be heard but I think there’s a lot of that you have to apply of being a leader, you have to just kind of be actively aligning the team and making sure they’re like.
What kind of like grabbing all these ideas that are coming and kind of propositions and ideas and suggestions and actually create something that makes sense, right? Because I think the problem, otherwise we end up with a patchwork of opinions, right? You say, Oh, like every project is team runs differently because it depends on whoever is running it.
Oh, whoever is the, and that becomes confusing and becomes efficient for everyone working around them. So this is just an example, of course, but it’s just the idea of you have as a manager to apply, active leadership to your team and, you are responsible for deciding how the team works.
And it doesn’t have to be that you do everything or that these are all your ideas, but you have to be able to raise the right ideas and kind of combine these perspectives to create a system that works right and create a team that works.
Kshitij Mohan: Definitely. And Francisco, while thinking about this behavioral aspect of leading teams efficiently, right?
Have you ever felt the need that while building all this, there are a certain set of data points that a manager should be wary of, or there is some data-driven things that they should be looking at while building these teams that support and building this entire thing cohesively? Any specific thoughts on that, Francisco?
Francisco Trindade: Yeah, I think ultimately I think again different teams vary and different situations vary, but I think in general, what I try to think about in terms of metrics is roughly like what are you, what amount of time your team is spending in non-value work.
Right. So well, if you think about it if you look at your team. For example, how much time are you spending, like fixing bugs or doing, or improving the code or doing anything that’s not something that the customer or whoever the target market is paying for and of course not only paying. Nobody wakes up in the what amount of time are you working on things that are not driving impact?
Then and people, I think most teams don’t think about that, but I think, and it’s normal for most, for teams to just spend half the time or sometimes more than half the time, just doing things that are not really driving impact. Yeah. And then I think that feedback loops, just like thinking about how has a feedback loop in your team, you can look so how often you release the customers.
How quickly you call the cycle time for your stories? How quick you do PR reviews, anything that you can optimize and make that streamline. So that work moves quicker from beginning to end like that’s a benefit.
So that would be the two main things I would like to look at.
Kshitij Mohan: Sure, Francisco, I think great pointers there. So Francisco, before we end our conversation, one interesting aspect that I, viewers, everyone would love to know. What’s that Francisco’s way of building efficient dev teams?
What’s that magic sauce that people can relate to, listen to, and start implementing in their teams?
Francisco Trindade: Yeah, I don’t I don’t know if there’s a magic sauce, but I think it’s kind of a bit of what I said here before, I think the main thing is just to understand there is a system, right?
Your team is working through a process, right? So and if you’re doing nothing about it, so if you say, okay, you just join a team and just they were working already. There’s a process there and the process might be an informal process, right? It might be they just work the way they work because they’ve been working like that for like, 10 years.
That’s fine and maybe it’s not written, but there are rules, right? I think so as a leader, the more you can understand how the work works. So how you just can observe that and say, okay, this is how engineers write code in my team, this is how requirements are built in my team.
This is how we do testing. the more you become an expert on that and you understand that deeply, the more you can start to think about, okay, now there are problems that I see, okay there’s a problem that’s been raised and I understand how the system works. I can start acting on it to say, okay, if this problem is this, then I can tweak something here to, or I can suggest something here to make sure that problem improves.
And you need to understand how your team works. I think it starts from there.
Kshitij Mohan: I think a million-dollar question. How does your team work? This is great, Francisco.
Francisco Trindade: There is, I mean this is just like, as an example, there is, of course, this is not possible in software, but like when you look at like one thing.
I’ve read a lot and said a lot in the past, the idea of lean production systems. And there was the idea of the person who started that was the Toyota system. He has this idea that he’s like this train manages by like drawing a circle on the factory floor and saying, you have to stand in the circle.
And at the end of the day, you tell me what’s wrong with this process, right? Just observe how people, just stay here the whole day, observing how people are, what people are doing, and then tell me what we can improve by the end of the day. I think that’s a lot of thinking that you should have as a manager, observe how people are doing things, and observe, pair with engineers.
And this read the code. Think about like how to look at the tickets, talk to everyone, and just really become an expert on how that’s done. And then you’re going to naturally start seeing ways to improve it because the thing does always improve like a team or a system.
Kshitij Mohan: Perfect. I think a super, helpful piece of advice, Francisco. Thank you so much for joining this candid conversation today with us, Francisco, and opening your heart out. I’m pretty sure we’re going to get a lot of valuable insights for us as well as for the viewers. Thank you so much.
Francisco Trindade: Thanks so much for having it.
Kshitij Mohan: Thank you! Good day, Francisco.
The field of software engineering is constantly evolving. Engineer leaders and developers need to keep an eye on recent trends and best practices. But, this is not always possible. Since they have been already piled up with their roles and responsibilities.
This is how software podcast comes to the rescue. They are a great way to learn about software engineering on the go. These podcasts are hosted by industry experts and leaders. Hence, allowing you to get much-needed knowledge and insights about this field.
Although, there are hundreds of podcasts out there on a topic. We have curated the list with the best software podcasts you can listen to. Have a look:
This podcast is hosted by Coding Sans, a software development agency. It includes experts who talk about the real-world challenges of engineering managers and how to address them. It includes management tips and tricks, effective recruiting, boosting productivity, fostering positive work culture, and much more.
Hosted by Patrick Gallagher, the weekly podcast covers leadership and management stories. It aims to empower the growing community of software engineering leaders. It also involves quality information about modern software engineering trends and best practices.
This podcast is presented by Plato, Engineering, and the product leadership mentorship program. The podcast episodes deep dive into various topics related to engineering. A few of them include the latest trends in this field, software engineering best practices and challenges faced by engineering communities, and much more. The host also interviews industry experts who offer a wealth of practical advice and insights.
Aydin Mirzaee’s podcast is geared toward engineering managers and leaders. It includes interviews with industry experts that talk about how to lead teams, thought patterns, learnings, and challenges, improving productivity, and so on.
This podcast is hosted by Adam Axelrod and Slava Imeshev who share their insights gained through an experience of 25+ years. It includes tips for developing strong management skills, establishing an effective software development lifecycle, and so on. Besides this, The podcast also sheds light on team building, performance reviews, One-on-One, and project management.
This podcast dives into the dynamic world of software engineering leadership. The host Kovid Batra interviews seasoned industry experts and successful engineering leaders who have mastered inspiring, guiding, and motivating their teams. The topics include fostering a culture of collaboration and transparency, implementing agile methodologies, and team productivity.
This podcast is a round table discussion between three hosts – Allen Underwood, Joe Zack, and Michael Outlaw. They talk about a wide range of engineering design topics. It includes software design patterns, software architecture, database design, and many more. The podcast also comprises videos, informative articles, episode summaries, and newsletter links to make it easier for developers.
This podcast is hosted by Adam Stacoviak and Jerod Santo. They discuss recent open source technology developments and a wide range of development tools. The podcast also covers almost all programming languages, communities, and platforms. The hosts deep dive into these topics by interviewing experts in their respective fields.
This is one of the programming podcasts that discusses how Python applications are used in the real world. The host ‘Michael Kennedy’ interviews guest speakers from the finance, engineering, and software industries. It also includes tips for machine learning, AI startups, Machine learning ethics, running programming language - Python in production, and much more.
Hosted by Jonathan Cutrell. This podcast is for all the newbies and experienced developers out there. It covers recent trends spanning from technology and communication to human psychology. This software engineering podcast is hardly 10 minutes long and can be listened to between busy schedules.
Hosted by Dave Smith and Jamison Dance. This weekly podcast focuses on soft skills for engineers and developers. It includes various topics like career development, communication, conflict resolution, and collaboration. In other words, it comprises the challenges and problems developers face in their day-to-day life.
The Stack Overflow podcast is hosted by Paul Ford and Ben Popper. It is one of the programming podcasts that covers comprehensive topics such as software development, coding, and computer programming. The podcast also brings industry leaders to share interesting insights and answer the queries that are trending in the developer community.
These software engineering podcasts include a wide variety of topics. It includes continuous integration, software testing, deep learning models, and much more. These tech podcasts usually invite guest speakers and industry leaders to give valuable insights about these diverse topics. Hence, making them a great resource for software developers and engineering leaders.
These software engineering podcasts provide valuable learning opportunities to engineering leaders and developers. It keeps them informed of the latest industry trends and innovations. A few of them are artificial intelligence, machine learning, and blockchain. These podcasts also share practical solutions to common engineering challenges and offer tips for optimizing workflow.
Software engineering podcasts are convenient for software engineers and developers. They can listen to them anytime, anywhere as they are available on-demand. This makes it easy to fit into their schedules. It also caters to their personal development as well. As it offers a wide range of topics that would align with their specific interests and career goals.
Software podcasts aren't bounded by geographical locations. Software developers can gain valuable insights and perspectives from professionals across the world. This includes staying informed about worldwide developments in the software development lifecycle, programming languages, software security, and much more.
While technical skills are important, soft skills play a crucial role too. Engineering podcasts also include the importance of soft skills such as time management, problem-solving, decision-making, and communication. Hence, helping developers become effective team members.
Apart from engineering podcast episodes, there are various other resources you can take note of:
These blog posts are written by industry experts, thought leaders, and software development companies who share various aspects of engineering and software development. They share valuable insights, practical tips, and best practices ranging from coding to software testing.
DevOps influencers share their perspectives, insights, and tips on various engineering topics on social media platforms such as LinkedIn and Twitter. They shed light on important software development topics and share their first-hand knowledge.
Tech YouTube channels are another great resource for learning and gaining valuable insights on software development topics. These channels share tutorials, tips and tricks, best practices, and other important information related to engineering.
Engineering newsletters are one of the resources that many developers and engineering managers rely on. These are written by industry experts and thoughtful leaders and include case studies, first-hand knowledge, and their perspectives on engineering topics such as clean code, open source projects, and data science.
There are countless books that cover various programming languages, developer methodologies, and in-depth insights on various topics. It includes front-end development, artificial intelligence, coding, and many more.
The above-mentioned software engineering podcasts are rich sources of knowledge and awareness. They can help you to stay up to date with recent trends, best practices, and other important insights.
Happy listening! :)
Sign up now and you’ll be up and running on Typo in just minutes
