In this episode of the groCTO by typo Podcast, host Kovid Batra speaks with Sheeya Gem, Director of Engineering and Product Strategy at ShareFile, about her experiences leading dev teams through mergers and acquisitions.

‍

‍

Sheeya discusses the importance of building collaborative relationships with stakeholders, maintaining effective communication, and fostering a shared purpose among teams. She emphasizes the significance of continuous learning, adaptability, and leveraging tools and processes to keep projects on track. The conversation also touches on managing cultural transitions, supporting teams through change, and ensuring successful integration post-acquisition. Finally, Sheeya shares valuable parting advice for engineering leaders, promoting trust, shared purpose & continuous learning.

Timestamps

• 00:00 — Introduction

• 00:55—Meet Sheeya Gem

• 02:31—Sheeya's Background and Early Influences

• 04:23—Navigating Mergers and Acquisitions

• 07:52—Leadership and Team Dynamics

• 20:12—Building Collaborative Relationships

• 28:56—Ensuring Team Alignment and Progress

• 32:28—Parting Advice for Engineering Leaders

Links & Mentions

• Sheeya on LinkedIn

• Kovid on LinkedIn

• Watch this episode on Substack and Youtube

• Listen on Spotify, Amazon Music, and iTunes/Apple Podcasts

Episode Transcript

Kovid Batra: Hi everyone. This is Kovid, back with another episode of the groCTO by typo podcast. Today with us, we have a special guest who has 20+ years of engineering and leadership experience. She’s not just a tech leader, but also an innovator, a business-minded person, which is a rare combination to find. Welcome to the show, Sheeya.

Sheeya Gem: Hi, Kovid. Thank you for inviting me. It’s a pleasure to join you today.

Kovid Batra: The pleasure is all ours. So Sheeya, guys, uh, let me introduce her a little bit more. Uh, she’s the Director of Engineering and Product Strategy at ShareFile. So ShareFile is a startup that was acquired by Progress from Citrix and, uh, the journey, uh, I was talking to Sheeya, was really interesting and that’s when we thought that we should conduct a podcast and talk about this, uh, merger and acquisition journey that she has gone through and talking about her leadership experiences. So today, uh, the, the main section would be around leading dev teams through mergers and acquisitions, and, uh, Sheeya would be taking us through that. But before we jump onto that section, uh, Sheeya, I think it’s a ritual. This is a surprise for you. Uh, so we get to know our guests a little more, uh, by knowing something which is deep down in their memory lane from their childhood or from their teenage, uh, that defines them today. So give us an introduction of yourself and some of those experiences from your childhood or teenage that define who you are today.

Sheeya Gem: Oh, you got me here. Uh, um, so my name is Sheeya Gem and, um, I am, I, I’m from Bangalore and, uh, grew up in Bangalore. This was when Bangalore was, was, was much smaller. Um, it was, uh, it was considered a retirees paradise back then. And, uh, growing up, my mom was a very strong, um, mentor and, and, and, and a figure in my life. She’d read to me when I was very young. Um, lots of stories, lots of novels, lots of books. So she was an English Lit major. And so, so she’d have all these plays. So I grew up listening to Shakespearean plays. Um, and, uh, one of the books that she’d read and it still sticks with me, and, and actually there’s, I actually have a little frame of this at this time. And it says, “She believed she could, so she did.” And it’s powerful. It’s powerful. Um, I’m sorry. I lost her a few years ago. And, uh, it’s, it’s defined me. It’s a big part of who I am, um, because at every stage in your life, and, and this has been true for me, um, at every stage I have challenged myself, and it’s, it’s my mom. It’s that voice. It says, “You can do what you need to do because you believe in it and you know it’s going to be true.”

Kovid Batra: I’m sorry for your loss, but I think she would be resting in peace and would be happy to see you where you are today and how she has inspired you to be who you are today. Uh.

Sheeya Gem: Thank you. Thank you.

Kovid Batra: All right, Sheeya. Thank you so much for sharing that and it means a lot. Uh, on that note, I think we can move on to the main section. Uh, yeah. Uh, so I think, uh, your journey at, at Progress ShareFile, uh, starts from the acquisition part, right? Uh, so tell us about how, how this acquisition happened and, uh, how things went at that time, some stories that would be, uh, lessons for the engineering leaders and engineering managers sitting out there listening to this.

Sheeya Gem: Yeah. Yeah. Um, so for most leaders who are part of an acquisition, you kind of are part of the conversations as you lead up to the, to the acquisition. And for ShareFile, this journey really started a few years ago. I’m just going to really quickly go through ShareFile’s story. ShareFile is a startup from Raleigh, North Carolina. Um, and it’s, it started up in the early 2000s and was bought by Citrix in 2012 and was part of the Citrix suite of products for, uh, for about 10 years, 10–12 years. And at that time, um, uh, a private equity group called Cloud Software Group acquired Citrix and as part of their portfolio, they have several other products as well. And that’s when ShareFile’s really acquisition journey started and as part of our strategy, ShareFile decided to go back to its roots and the roots of ShareFile was a vertical market strategy. And so for the past 2–3 years, um, and, and this was a fantastic ride because we got to innovate at a scale that we never could. CSG gave us the backing and the financing, the funding and the support and ShareFile had the right amount of talent to make things happen. As leadership, we knew that an acquisition was going to be our, our exit. So we were aware of that and we were very transparent with our, with our entire teams, everybody knew that an acquisition was on the radar. And as such, when Progress started talking to us, um, and ShareFile started sharing our financials, you know, how we do our business and all of those things, we, we knew it was, it was coming. So as such as leaders, you’re part of the journey that makes a successful exit. So the acquisition was a successful exit for us. And then it also starts the next part of your journey where you’re now with a company that has acquired you because they believe in your fundamentals, they believe in your team; and as leadership, it becomes important for us to make sure that that transition is successful and that merger goes as it needs to go.

Kovid Batra: So when you joined, uh, Progress, this was basically a new team coming into an existing company and that experience itself could be a little overwhelming. I haven’t gone through any such, uh, experience in my life, but I can just imagine and trying to relate here. That can be a little overwhelming because the culture completely changes. Um, you are in a setup where people know you, there is defined leadership which you are a part of, you’re part of the overall strategy and then defining, giving directions. But suddenly when you move here, things can change a lot culturally, as well as in terms of the goals and, uh, how things operate. So when this happened with you, was this an overwhelming experience or it came easily? And in either of the cases, how you handled it?

Sheeya Gem: Uh, was it an overwhelming experience? Um, not necessarily. It is an experience. It is different. And, and most humans coping with change and dealing with change is, is hard. And, um, and I think it’s important to recognize that different people are going to handle that change differently. And in many ways, it actually is almost the grieving of the loss of one thing before moving to the next thing, and as leaders, it’s important to make room for that, to give people a chance to, to absorb the change that’s happening, but to continue to be there to support, to provide that clarity, be transparent in what’s happening, where we’re going, and, and just knowing that, you know, some people are probably going to bounce right back. The two days they’re back, they’re okay. And some people are going, it’s going to take longer. It’s, it’s almost like those seven stages of grieving, uh, you know, and to make room for that and to know that, that kind of change from what was, people were comfortable with that, people probably excelled in that, going through the uncertainty of what is to come is a normal human reaction, and I think that’s where leaders shine, to know that this is a normal human reaction. I recognize it. I respect it. And I’m here for you when, when you’re ready to move to the next step.

Kovid Batra: Makes sense. So when you moved here, what exactly was your first initiative or what was that major initiative that you took up after moving in here that made you, uh, put down your feet and get back to work and outshine that, uh, outshine that particular initiative?

Sheeya Gem: Um, are you talking about post-acquisition, the steps that we took? Is that what you’re thinking about? Okay. So, all right. So maybe I could frame it this way. A company exists pre-acquisition. It has a set of goals. There’s a vision. There’s a strategy, right? Everybody is comfortable with it. You’re probably talking about it in your all-hands, in your small group meetings and every leadership meeting that you have in any kind of ‘ask me anything’. The leadership team is talking about what you’re saying. This is our vision. This is our goal. This is the strategy. Once the acquisition happens, you’re now looking at the goal, strategy, and vision of the new company. Now, likely they’re related because there was a reason that the acquiring company went ahead and bought this company. There’s a relationship there, but there’s also likely things that are going to be different. As an example, it’s possible, in our case, this is the situation, Progress has a heavy enterprise footprint. And so some of the strategy and goals are going to be a little different compared to, um, an SMB market where ShareFile continued to, uh, to excel. So, but are there commonalities? Yes. And, and I think this is where, again, leadership comes in where we say, “Hey, this is what we were pursuing. This continues to be our plan and our strategy. This is where ShareFile, Progress’ strategy comes in and in order to manage the transition and have success on both sides, we talk about what needs to happen next. And often what happens is in a mature acquisition, and this is often the case, there is a, there is, there’s plenty of time for companies to say, “Okay, I’m slowly going to bring in the new set of goals that we need to work towards.” Some companies don’t change at all. As an example, when IBM acquired Red Hat, for five years, Red Hat did what they always did. There was no change. Eventually, right, the goal started shifting and changing to align more with IBMs. So different companies have different trajectories. However, what’s common, what needs to happen is communication. Leaders need to be talking to their teams all the time, because without the communication, this is where that uncertainty creeps in. People don’t have the answers, so they start looking for answers and those answers may not be right. So at this time for leadership, it’s important to double down and say, “This is our strategy. This is a strategy for Progress. This is a transition plan to move towards a new strategy. Or it could be that for the next six months, guys, it is business as usual. We’re going to continue with our existing strategy. And over time, we’ll start bringing in aspects of the, of the acquiring company strategy.” So key thing here, support your teams, keep communicating.

Kovid Batra: So at that, during that phase, uh, what was your routine like? Every, uh, board meeting you had, after that, or every leadership meeting you had, you used to gather your team, communicate the things that you had with them, or you waited for a little while, uh, thought through things, how it should be put to your team? Because it’s, it’s a question of, uh, how you communicate it to your teams, because you understand them better, in what state they are, how they’re going to perceive it. So I’m just looking for some actionable here.

Sheeya Gem: Yeah.

Kovid Batra: Like how exactly you did that communication because having that communication definitely seems to be the key here. But how exactly it needs to be done? I want to know that.

Sheeya Gem: Yeah, yeah, you actually almost answered the question here. Uh, so you’re 100% right, right? You don’t necessarily come out and throw little bits of information here and there because that’s not a coherent strategy. Yes, the leadership is continuing to meet and it’s okay to tell your teams that the leadership, leadership teams are continuing to meet and are working through this. But yes, eventually, when we are in a place where we have a handle on how we’re going to do things, that’s when the communication comes up. Like I said, it’s important for teams to know, yes, we’re working with you, we’re thinking through things and then set a clear date, call the meetings, it’s usually like an all-hands kind of situation and then plenty of time for Q&A, gather your teams and present in a format that’s, that’s most comfortable for that culture. And, and sometimes it’s, it’s an ‘ask me anything’ kind of format. Sometimes it’s a chat by the fire kind of, kind of informal thing. And sometimes, and we actually did this year. We did an all-hands, had plenty of time for Q&A, and that evening we took our teams to the closest hangout place that we have. We usually gather there Thursday evenings for beer, and leadership was there and we answered questions. It was an informal setting and sometimes it’s important to, to, you know, go to a location that’s not your usual place of work. So a good restaurant, um, a place where you can maybe just, just chill a little bit, right? And, and, and have those conversations and there you’re able to meet people where they are and then connect with them on that 1-on-1 level and, and maybe answer questions a little bit more deeply.

Kovid Batra: One thing if I have to ask you, which you think you could have done better during that phase, uh, would be?

Sheeya Gem: What could I have done better? Um, it’d be terrible to say we got everything right. Uh, so here’s the thing. No matter how well you manage this, because remember I said that everybody’s going to go through those different stages of change, you will always see people where somebody is, is more agitated, feeling a little bit more anxious than other, right? And, and by, just by the reality of communications, where we say, “Okay, a month from now, we’re going to address this.” There are some people who are going to hit that stage of ‘I need to know now’ two weeks before that. And in that situation, it’s hard, but maybe what people can do is if you’re close enough to that, to be able to just reassure people a little bit more. Um, I think that’s something that, that I certainly could have done a little bit more of, but it’s also one of the situations where you’re kind of like weighing it. How much do I, should I be talking about this where not everything is clear and how much should I just hold? Um, so, so there is that balanced conversation that happens.

Kovid Batra: And in that situation, do you think is it okay to come out and say that I am in a phase where even I am processing the information? More like being vulnerable, I would say. Not exactly vulnerable, but saying that we are in a phase where we are processing things. I don’t want to say anything which, uh, maybe makes you more anxious instead of giving you more certainty at this phase. So making statements like this as a leader, is it okay?

Sheeya Gem: I think it is. I think it’s important to your point. Vulnerability is key where you trust your teams and you’re expecting them to trust you. So showing that vulnerable side, uh, builds empathy and helps people, uh, relate to you more. Um, what I would be careful though is some people could perceive that differently. Oh, leadership doesn’t have all the answers. So yeah, know your audience, know your audience.

Kovid Batra: Makes sense. Yeah, all right. I think, uh, this was really interesting. Anything, uh, Sheeya, uh, that you think had really driven you and made you who you are as an engineering leader in your whole career, not just at ShareFile, but in general I’m asking, what are those few principles or frameworks that have really worked out for you as a good leader?

Sheeya Gem: Yeah, um, I think it’s learning. For me, I, I have this desire to learn and, um, and I believe that no matter a situation, right, you can have a good situation or you could have a bad situation. No matter the situation, though, where you win is learning, learning from the situation, no matter what that situation is. So when you exit that situation, you have learned, you are a better person because you have learned from that situation. So, so that’s, that’s a big takeaway for me and, and something that, that I, maybe your audience will enjoy and that is for humans, you know, there are some things that are going to go really, really well and some things that are going to be downright awful and I think that’s life. But in each of these situations of the mindset is, “Hey, I’m put in a situation that I haven’t dealt with before. What can I take away from this?” You exit that situation as a winner, no matter what the situation was. And I’ve applied that through my life where, um, I’ve, I’ve, I’ve had the, uh, the good luck to work at some fantastic companies and, and be mentored by, by amazing people, um, from Etrade to eBay, uh, Citrix, several companies along the way. And at each of them, uh, when I changed jobs, I went into a job that was just a little different from what I did, and it kind of like opened up things for me. Um, and it helps you learn. So that would be a good takeaway where every time you go into something, try something just a little different. Uh, it changes your perspective. It, it builds empathy. When you do a little bit of marketing, you now have empathy for your marketing department a little bit more. When you do a little bit of work that, that’s not just pure engineering, it helps you see things in a different light and gives you a different perspective.

Kovid Batra: Touching on the marketing bit. I think, uh, the last time when we were talking, you mentioned that you have this urge, you have this curiosity all the time, and I think it’s driven from the same fact, learning, that you work with different teams to understand them more. So do you have any experience, like very specific experience where you had a chat with a sales guy or a marketing team person that led you to build something, like engineer something and build something for the customers?

Sheeya Gem: Yeah, yeah. Uh, that’s a good topic. Um, a part of leadership is besides guiding your teams, it’s about the collaborative relationships you build with other stakeholders. And a lot of people, when we hear the word ‘stakeholder’, we kind of like mentally take a step back. But what if we consider all of those stakeholders, people who are in that journey together with us? Because ultimately, that’s why they’re here. Um, it’s to be successful. And to define success in a way that resonates with each person is the concept of building collaborative relationships. It goes to the heart of shared purpose. Um, so as we were building some new innovative products, um, and, and I, ShareFile is a tech company and which means the product is tech. Who knows more about the product and the tech than the engineers who are building it, right? They are the builders However, all of the other stakeholders that we’re talking about are instrumental to making the product successful. That’s why they’re all here. So for me, it started becoming a case of saying that “Hey, we have uncovered this new way to do something and we believe there is an audience for this. There is a market for this.” Then the first set of people that we start talking to is being able to work with product management to say, “ What do you see? What have you seen in the field? You’re talking to customers all the time.” And it becomes, starts becoming this, this little bit of a cycle where they feed information to you and you’re feeding information back and it’s a loop. It’s, it’s becoming this loop that’s continuing to build and continuing to grow. Um, so there is a, there’s a fantastic book. Um, I think it’s called ‘Good to Great’. Um, and in that the author talks about the flywheel effect and that’s exactly what this is. So as you’re talking to product and you’re building that, that, that coherent thought of, “Okay, I have something here. I may have something really, really big.” The next step is talking to sales because sales tends to be the biggest cheerleader of the product in the market. They’re selling. This is their whole goal. They are your cheerleaders. And so then the next step of building that relationship with sales and saying, “Hey guys, what are you seeing? If I were to build something like this, what do you see, um, in the way it plays out in the market?” And you put that early version of the product in front of sales. Give them a prototype. Ask them to play with it. And most companies don’t tend to do this because sometimes there are walls, sometimes there’s a little bit of a, does sales really want to look at my prototype? They do, because that’s how they know what’s coming next. You’re opening that channel up, right? Similarly with marketing, to be able to say, I have something here. Do you think we could do some marketing spend to move this forward? And just like that you’ve built shared purpose because you’ve defined what success looks like for each group.

Kovid Batra: Right. That’s really interesting. And the, the last word ‘shared purpose’, I think that brings in more, uh, enthusiasm and excitement in individuals to actually contribute towards the same thing as you’re doing. And on that note, I, I think, uh, I would love to know something from you about how you have been bringing this shared purpose, particularly in the engineering team. So just now you mentioned that there could be, uh, walls which would prevent you from bringing out that prototype to the sales team, right? So in that exact situation, uh, what, what way do you think would work for teams, uh, and the leaders who are leading, let’s say, a group of, let’s say, 20 folks? I’m sure you’re leading a bigger team, but I’m just taking an example here that how do you take out that time, take out that bandwidth, uh, with the engineering team to work on the prototype? Because I’m sure the teams are always overloaded, right? They would always have the next feature to roll out. They would always have the next tech debt to solve, right? So how do you make sure that this feeling of shared purpose comes in and then people execute regardless of those barriers or how to overcome those barriers?

Sheeya Gem: Yes. Um, to have something like shared purpose work, you absolutely need the backing of your entire leadership org. And I’ve been very, very lucky to have that. Uh, from the Chief Product Officer to the CEO, to the Chief Technology Officer, we were aligned on this, completely and totally aligned on this. And so what this translate then, translates to then is investments, right? You talked about tech debt and how teams are always loaded, but if your entire leadership team is bought into that vision, then the way you set the investment profile itself is different, where you might say that, you know, half of the org is going to totally and completely focus on innovation. We are going to build this. Right. Then you have that, that organizational support. Now as leadership, as we are building that, when you start talking to your teams about the level of organizational support that you have, and remember, engineers want to build things that are successful with customers. Nobody wants to build something and put it on a shelf in their house. They want it on the market. That is the excitement of engineering. So to then be able to say that, “Hey! We believe in this. Our leadership believes in this. Our stakeholders are excited about this.” It’s the kind of excitement and adrenaline adrenaline pump that happens that nothing else gives that cheer. And that’s what we saw happen with our teams, that getting behind a vision, making that strategy your own, knowing that you are a key contributor to that success of the product and hence the success of the org, that is a vision that sustains and feeds itself. And, and that’s what we were able to build. Um, that’s something that I made the time for every day. You talk to your teams, you connect with your teams, you’re talking to your engineering managers, you’re talking to the principal engineers, and every time there is, there is concern, and there will be many, many concerns along the way, and I’m not going to have all the answers. That’s normal. I should not have all the answers, because if I have all the answers, then the thinking is limited to the max of my thinking, and a group’s thinking is always greater, right? The sum of that group’s thinking is always greater than any one individual’s thinking. So then it starts becoming a case of, this is the problem that we’re trying to solve. How best would we solve it? And when you put it in front of the brightest people in the room, the answers that you get to that problem, the solutions that you get, breaks through every bound that you can see.

Kovid Batra: So do you usually practice this? Like, uh, every week you have a meeting with your team and there are some folks who are actually working on the innovation piece or maybe not every week, maybe in a month? I, I am not sure about the cadets, but in general, what’s the practice like? How, how do you exactly make sure that that is happening and people are on track?

Sheeya Gem: Yeah, we actually meet every week and then any number of informal conversations throughout the day, right? You run into someone in the elevator, you have two minute conversation. You run into someone in the hallway, you have a two minute conversation. But yes, as leadership, we meet, uh, every week. And when I say leadership, and this is where my definition of leadership may be different from maybe some parts, some others. And, and, and to me, leadership is not just a title that’s given to someone. A lot of people think that one year, once you’re a manager, you’re a leader. The truth of it is, you’re going to see leaders in engineers, people who think differently, people who, um, who can drive something to success, people who can stand behind something because they know that area and know what to do next. They’re all leaders. So in my leadership meeting, I actually have a mix of engineering managers. I have principal engineers. I even have some, a couple of junior team leads because they are that good. And that group meets every week. And we talk about the biggest problems that we have and it becomes a group problem solving effort. We draw action items from that and then smaller groups form from there, solve, come back to the meeting next week and they talk about how they are, how they are going about it. So it is very much a team environment and a team success, um, metric the way we go behind things.

Kovid Batra: Makes sense. Um, one last thing that I would want to touch upon is that when you are doing all these communication, when you are making sure you’re learning, your team is having a shared purpose, everyone is driven towards the same goal, one thing that I feel is it is important to see how teams are moving, how teams are doing on different parameters, like how fast they’re moving, how good quality code is being produced there. And you mentioned, like you lead a team of almost a hundred people where there are few engineering managers and then engineers out there. As a Director of Engineering, there is no direct visibility into what exactly is happening on the ground. How do you ensure that piece, uh, in your position right now that everything which you think is important and critical, uh, is, is there, is on the tack on the track?

Sheeya Gem: Yeah, yeah, this is where tools come in. Also, very clear processes. Um, my recommendation is to keep the processes very lightweight because you don’t want people to be caught up in the administration of that process. But things like your hygiene, it’s important. You closed a story, close the story, right? Or let us know if you need help. Uh, so that becomes important. Um, there are lots of project management tools that are available on the market. Um, and again, like I said, lightweight, clear process. Uh, the ability to be able to, um, demonstrate work in progress, things like that. And that’s something else that we have. Um, we have this practice called show, tell and align and, um, we meet every week and this is all of engineering, and just like the title says, you show whatever you’ve got. And if you’re not in a position to show, you can talk about what you’ve got. And the purpose of it is to drive alignment and it’s, it’s, it’s an amazing meeting and we have a fantastic manager who runs that meeting. There’s a lot of energy there and we have no rules about what you can show or where you can show it. You know, some, some, some companies have rules like, oh, it needs to be in production for you to do. No, no, no, I want to see it if it’s on your dev laptop. I want to see it. Your team leads to want to see it. Uh, so we keep it very, very easy. And in that meeting, every senior leader who attends that meeting is encouraged to come in as an engineer and as an engineer only. Uh, they’re supposed to leave their titles at the door. It’s, it’s, it’s, it’s, it’s a challenge. It’s a challenge, but no one can come in and say, “Hey, I didn’t approve that!” Because you’re coming to this meeting as an engineer, which means if, if, and sometimes we’ve had, you know, directors and VPs who have something to share because they’re able to leave the title at the door. Uh, so it’s, it’s been a great practice for us, this ability to, to show our work in progress. Um, “Oh, look, I got this done.” Uh, “Here’s a little notification tab that I was able to build in three days. I’m going to show this to the team.” Or, or “Here’s a new framework that I’m thinking about and I found this. I’m going to show this to the team.” Uh, so this is a regular practice, um, at ShareFile and now at Progress.

Kovid Batra: Perfect. Perfect. Great, Sheeya. I think, uh, this was a really, really interesting talk, uh, learning about communication, learning about learning all the time, having a shared purpose. Show, tell, and align, that was interesting on the last piece. So I think with this, uh, we, we come to the end of this episode. It was really, really nice to have you here and we would love to have you again. Is there any parting advice for our audience that you would like to share? Uh, most of us are like engineering managers, aspiring engineering leaders or engineering leaders. If you would like to share, please go ahead.

Sheeya Gem: Um, we covered a lot of topics today, didn’t we? Um..

Kovid Batra: Yeah.

Sheeya Gem: Uh, what do I have for our, um, for our engineering managers? Trust your teams, but trust and verify. Um, and this is where, you know, some of the things we talked about, things like OKRs, things about lightweight process comes in. Trust, but verify. That’s important. Uh, the second part of it is shared purpose. You want to build that across your, not just your teams, but all of the stakeholders that you’re interacting with. So people are driving in the same direction, uh, and we’re all moving towards the same success and the same set of goals and every opportunity is a learning opportunity.

Kovid Batra: Great! Thank you, Sheeya. Thank you so much once again. Great to have you today.

Sheeya Gem: It was a pleasure. Thank you for inviting me on your show.

In the second session of the 'Unlocking Engineering Productivity' webinar by Typo, host Kovid Batra engages engineering leaders Cesar Rodriguez and Ariel Pérez in a conversation about building high-performing development teams.

‍

‍

Cesar, VP of Engineering at StackGen, shares insights on ingraining curiosity and the significance of documentation and testing. Ariel, Head of Product and Technology at Tinybird, emphasizes the importance of clear communication, collaboration, and the role of AI in enhancing productivity. The panel discusses overcoming common productivity misconceptions, addressing burnout, and implementing effective metrics to drive team performance. Through practical examples and personal anecdotes, the session offers valuable strategies for fostering a productive engineering culture.

Timestamps

• 00:00 — Introduction

• 01:14—Childhood Stories and Personal Insights

• 04:22—Defining Engineering Productivity

• 10:27—High-Performing Teams and Data-Driven Decisions

• 16:03—Counterintuitive Lessons in Leadership

• 22:36—Navigating New Leadership Roles

• 31:47—Measuring Impact and Outcomes in Engineering

• 32:13—North Star Metrics and Customer Value

• 32:53—DORA Metrics and Engineering Efficiency

• 33:30—Learning from Customer Behavior and Feedback

• 35:19—Scaling Engineering Teams and Productivity

• 39:34—Implementing Metrics and Tools for Team Performance

• 41:01—Qualitative Feedback and Customer-Centric Metrics

• 46:37—Q&A Session: Addressing Audience Questions

• 58:47—Concluding Thoughts on Engineering Leadership

Links and Mentions

• Ariel Pérez on Linkedin

• Cesar Rodriguez on Linkedin

• Kovid Batra on Linkedin

• Watch this webinar on YouTube and Substack

• Listen on Spotify, Amazon Music, and iTunes/Apple Podcasts

Transcript

Kovid Batra: Hi everyone, welcome to the second webinar session of Unlocking Engineering Productivity by Typo. I’m your host, Kovid, excited to bring you all new webinar series, bringing passionate engineering leaders here to build impactful dev teams and unlocking success. For today’s panel, we have two special guests. Uh, one of them is our Typo champion customer. Uh, he’s VP of Engineering at StackGen. Welcome to the show, Cesar.

Cesar Rodriguez: Hey, Kovid. Thanks for having me.

Kovid Batra: And then we have Ariel, who is a longtime friend and the Head of Product and Technology at Tinybird. Welcome. Welcome to the show, Ariel.

Ariel Pérez: Hey, Kovid. Thank you for having me again. It’s great chatting with you one more time.

Kovid Batra: Same here. Pleasure. Alright, um, so, Cesar has been with us, uh, for almost more than a year now. And he’s a guy who’s passionate about spending quality time with kids, and he’s, uh, into cooking, barbecue, all that we know about him. But, uh, Cesar, there’s anything else that you would like to tell us about yourself so that, uh, the audience knows you a little more, something from your childhood, something from your teenage? This is kind of a ritual of our show.

Cesar Rodriguez: Yeah. So, uh, let me think about this. So one of, one of the things. So something from my childhood. So I had, um, I had the blessing of having my great grandmother alive when I was a kid. And, um, she always gave me all sorts of kinds of food to try. And something she always said to me is, “Hey, don’t say no to me when I’m offering you food.” And that stayed in my brain till.. Now that I’m a grown up, I’m always trying new things. If there’s an opportunity to try something new, I’m always, always want to try it out and see how it, how it is.

Kovid Batra: That’s, that’s really, really interesting. I think, Ariel, , uh, I’m sure you, you also have some something similar from your childhood or teenage which you would like to share that defines who you are today.

Ariel Pérez: Yeah, definitely. Um, you know, thankfully I was, um, I was all, you know, reminded me Cesar. I was also, uh, very lucky to have a great grandmother and a great grandfather, alive, alive and got to interact with them quite a bit. So, you know, I think we know very amazing experiences, remembering, speaking to them. Uh, so anyway, it was great that you mentioned that. Uh, but in terms of what I think about for me, the, the things that from my childhood that I think really, uh, impacted me and helped me think about the person I am today is, um, it was very important for my father who, uh, owned a small business in Washington Heights in New York City, uh, to very early on, um, give us the idea and then I know that in the sense that you’ve got to work, you’ve got to earn things, right? You’ve got to work for things and money just doesn’t suddenly appear. So at least, you know, a key thing there was that, you know, from the time I was 10 years old, I was working with my father on weekends. Um, and you know, obviously, you know, it’s been a few hours working and doing stuff and then like doing other things. But eventually, as I got older and older through my teenage years, I spent a lot more time working there and actually running my father’s business, which is great as a teenager. Um, so when you think about, you know, what that taught me for life. Obviously, there’s the power of like, look, you’ve got to work for things, like nothing’s given to you. But there’s also the value, you know, I learned very early on. Entrepreneurship, you know, how entrepreneurship is hard, why people go follow and go into entrepreneurship. It taught me skills around actual management, managing people, managing accounting, bookkeeping. But the most important thing that it taught me is dealing with people and working with people. It was a retail business, right? So I had to deal with customers day in and day out. So it was a very important piece of understanding customers needs, customers wants, customers problems, and how can I, in my position where I am in my business, serve them and help them and help them achieve their goals. So it was a very key thing, very important skill to learn all before I even went to college.

Kovid Batra: That’s really interesting. I think one, Cesar, uh, has learned some level of curiosity, has ingrained curiosity to try new things. And from your childhood, you got that feeling of building a business, serving customers; that is ingrained in you guys. So I think really, really interesting traits that you have got from your childhood. Uh, great, guys. Thank you so much for this quick sweet intro. Uh, so coming to today’s main section which is about talking, uh, about unlocking engineering productivity. And today’s, uh, specifically today’s theme is around building that data-driven mindset around unlocking this engineering productivity. So before we move on to, uh, and deep dive into experiences that you have had in your leadership journey. First of all, I would like to ask, uh, you guys, when we talk about engineering productivity or developer productivity, what exactly comes to your mind? Like, like, let’s start with a very basic, the fundamental thing. I think Ariel, would you like to take it first?

Ariel Pérez: Absolutely. Um, the first thing that comes to mind is unfortunate. It’s the negative connotation around developer productivity. And that’s primarily because for so long organizations have trying to figure out how do I measure the productivity of these software developers, software engineers, who are one of my most expensive resources, and I hate the word ‘resource’, we’re talking about people, because I need to justify my spend on them. And you know what, they, I don’t know what they do. I don’t understand what they do. And I got to figure out a way to measure them cause I measure everyone else. If you think about the history of doing this, like for a while, we were trying to measure lines of code, right? We know we don’t do that. We’re trying to open, you know, we’re trying to, you know, measure commits. No, we know we don’t do that either. So I think for me, unfortunately, in many ways, the term ‘developer productivity’ brings so many negative associations because of how wrong we’ve gotten it for so long. However, you know, I am not the, I am always the eternal optimist. And I also understand why businesses have been trying to measure this, right? All these things are inputs into the business and you build a business to, you know, deliver value and you want to understand how to optimize those inputs and you know, people and a particular skill set of people, you want to figure out how to best understand, retain the best people, manage the best people and get the most value out of those people. The thing is, we’ve gotten it wrong so many times trying to figure it out, I think, and you know, some of my peers who discuss with me regularly might, you know, bash me for this. I think DORA was one good step in that direction, even though there’s many things that it’s missing. I think it leans very heavily on efficiency, but I’ll stop, you know, I’ll leave that as is. But I believe in the people that are behind it and the people, the research and how they backed it. I think a next iteration SPACE and trying to go to SPACE, moved this closer and tried to figure it out, you know, there’s a lot of qualitative aspects that we need to care about and think about. Um, then McKinsey came and destroyed everything, uh, unfortunately with their one metric to rule it all. And it was, it’s been all hell broke loose. Um, but there’s a realization and a piece that look, we, as, as a, as a, as an industry, as a role, as a type of work that we do, we need to figure out how we define this so that we can, you know, not necessarily justify our existence, but think about, how do we add value to each business? How do we define and figure out a better way to continually measure? How do we add value to a business? So we can optimize for that and continually show that, hey, you actually can’t live without us and we’re actually the most important part of your business. Not to demean any other roles, right? But as software engineers in a world where software is eating the world and it has eaten the world, we are the most important people in the, in there. We’re gonna figure out how do we actually define that value that we deliver. So it’s a problem that we have to tackle. I don’t think we’re there yet. You know, at some point, I think, you know, in this conversation, we’ll talk about the latest, the latest iteration of this, which is the core 4, um, which is, you know, things being talked about now. I think there’s many positive aspects. I still think it’s missing pieces. I think we’re getting closer. But, uh, and it’s a problem we need to solve just not as a hammer or as, as a cudgel to push and drive individual developers to do more and, and do more activity. That’s the key piece that I think I will never accept as a, as a leader thinking about developer productivity.

Kovid Batra: Great, I think that that’s really a good overview of how things are when we talk about productivity. Cesar, do you have a take on that? Uh, what comes to your mind when we talk about engineering and developer productivity?

Cesar Rodriguez: I think, I think what Ariel mentioned resonates a lot with me because, um, I remember when we were first starting in the industry, everything was seen narrowly as how many lines of code can a developer write, how many tickets can they close. But true productivity is about enabling engineers to solve meaningful problems efficiently and ensuring that those problems have business impact. So, so from my perspective, and I like the way that you wrote the title for this talk, like developer (slash) engineering. So, so for me, developer, when I think about developer productivity, that that brings to my mind more like, how are your, what do your individual metrics look like? How efficiently can you write code? How can you resolve issues? How can you contribute to the product lifecycle? And then when you think about engineering metrics, that’s more of a broader view. It’s more about how is your team collaborating together? What are your processes for delivering? How is your system being resilient? Um, and how do you deliver, um, outcomes that are impactful to the business itself? So I think, I think I agree with Ariel. Everything has to be measured in what is the impact that you’re going to have for the business because if you can’t tie that together, then, then, well, I think what you’re measuring is, it’s completely wrong.

Kovid Batra: Yeah, totally. I, I, even I agree to that. And in fact, uh, when we, when we talk about engineering and developer productivity, both, I think engineering productivity encompasses everything. We never say it’s bad to look at individual productivity or developer productivity, but the way we need to look at it is as a wholesome thing and tie it with the impact, not just, uh, measuring specific lines of code or maybe metrics like that. Till that time, it definitely makes sense and it definitely helps measure the real impact, uh, real improvement areas, find out real improvement areas from those KPIs and those metrics that we are looking at. So I think, uh, very well said both of you. Uh, before I jump on to the next piece, uh, one thing that, uh, I’m sure about that you guys have worked with high-performing engineering teams, right? And Ariel, you had a view, like what people really think about it. And I really want to understand the best teams that you have worked with. What’s their perception of, uh, productivity and how they look at, uh, this data-driven approach, uh, while making decisions in the team, looking at productivity or prioritizing anything that comes their way, which, which would need improvement or how is it going? How, how exactly these, uh, high-performing teams operate, any, any experiences that you would like to share?

Ariel Pérez: Uh, Cesar, do you want to start?

Cesar Rodriguez: Sure. Um, so from my perspective, the first thing that I’ve observed on high-performing teams is that is there is great alignment with the individual goals to what the business is trying to achieve. Um, the interests align very well. So people are highly motivated. They’re having fun when they’re working and even on their outside hours, they’re just thinking about how are you going to solve the problem that they’re, they’re working on and, and having fun while doing it. So that’s, that’s one of the first things that I observed. The other thing is that, um, in terms of how do we use data to inform the decisions, um, high-performing teams, they always use, consistently use data to refine processes. Um, they identify blockers early and then they use that to prioritize effectively. So, so I think all ties back to the culture of the team itself. Um, so with high-performing teams, you have a culture that is open, that people are able to speak about issues, even from the lowest level engineer to the highest, most junior engineers, the most highest senior engineer, everyone is treated equally. And when people have that environment, still, where they can share their struggles, their issues and quickly collaborate to solve them, that, that for me is the biggest thing to be, to be high-performing as a team.

Kovid Batra: Makes sense.

Ariel Pérez: Awesome. Um, and, you know, to add to that, uh, you know, I 1000% agree with the things you just mentioned that, you know, a few things came to mind of that, like, you know, like the words that come to mind to describe some of the things that you just said. Uh, like one of them, for example, you know, you think about the, you know, what, what is a, what is special or what do you see in a high-performing team? One key piece is there’s a massive amount of intrinsic motivation going back to like Daniel Pink, right? Those teams feel autonomy. They get to drive decisions. They get to make decisions. They get to, in many ways own their destiny. Mastery is a critical thing. These folks are given the opportunity to improve their craft, become better and better engineers while they’re doing it. It’s not a fight between ‘should I fix this thing’ versus ‘should I build this feature’ since they have autonomy. And the, you know, guide their own and drive their own agenda and, and, and move themselves forward. They also know when to decide, I need to spend more time on building this skill together as a team or not, or we’re going to build this feature; they know how to find that balance between the two. They’re constantly becoming better craftsmen, better engineers, better developers across every dimension and better people who understand customer problems. That’s a critical piece. We often miss in an engineering team. So becoming better at how they are doing what they do. And purpose. They’re aligned with the mission of the company. They understand why we do what we do. They understand what problem we’re solving. They, they understand, um, what we sell, how we sell it, whose problems to solve, how we deliver value and they’re bought in. So all those key things you see in high-performing teams are the major things that make them high-performing.

The other thing sticking more to like data and hardcore data numbers. These are folks that generally are continually improving. They think about what’s not working, what’s working, what should we do more of, what should we do less of, you know, when I, I forgot who said this, but they know how to turn up the good. So whether you run retros, whether you just have a conversation every day, or you just chat about, hey, what was good today, what sucked; you know, they have continuous conversations about what’s working, what’s not working, and they continually refine and adjust. So that’s a key critical thing that I see in high-performing teams. And if I want to like, you know, um, uh, button it up and finish it at the end is high-performing teams collaborate. They don’t cooperate, they collaborate. And that’s a key thing we often miss, which is and the distinction between the two. They work together on their problems, which one of those key things that allows them to like each other, work well with each other, want to go and hang out and play games after work together because they depend on each other. These people are shoulder to shoulder every day, and they work on problems together. That helps them not only know that they can trust each other, they can trust each other, they can depend on each other, but they learn from each other day in and day out. And that’s part of what makes it a fun team to work on because they’re constantly challenging each other, pushing each other because of that collaboration. And to me, collaboration means, you know, two people, three people working on the same problem at the same time, synchronously. It’s not three people separating a problem and going off on their own and then coming back together. You know, basically team-based collaboration, working together in real time versus individual work and pulling it together; that’s another key aspect that I’ve often seen in high-performing teams. Not saying that the other ways, I have not seen them and cannot be in a high-performing team, but more likely and more often than not, I see this in high-performing teams.

Kovid Batra: Perfect. Perfect. Great, guys. And in your journeys, um, there have been, there must have been a lot of experiences, but any counterintuitive things that you have realized later on, maybe after making some mistakes or listening to other people doing something else, are there any things which, which are counterintuitive that you learned over the time about, um, improving your team’s productivity?

Ariel Pérez: Um, I’ll take this one first. Uh, I don’t know if this is counterintuitive, but it’s something you learn as you become a leader. You can’t tell people what to do, especially if they’re high-performing, you’re improving them, even if you know better, you can’t tell them what to do. So unfortunately, you cannot lead by edict. You can do that for a short period of time and get away with it for a short period of time. You know, there’s wartime versus peacetime. People talk about that. But in reality, in many ways, it needs to come from them. It needs to be intrinsic. They’re going to have to be the ones that want to improve in that world, you know, what do you do as a leader? And, you know, I’ve had every time I’ve told them, do this, go do this, and they hated me for it. Even if I was right at the end, then even if it took a while and then they eventually saw it, there was a lot of turmoil, a lot of fights, a lot of issues, and some attrition because of it. Um, even though eventually, like, yes, you were right, it was a bit more painful way, and it was, you know, me and the purpose for the desire, you know, let me go faster. We got to get this done. Um, it needs to come from the team. So I think I definitely learned that it might seem counterintuitive. You’re the boss. You get to tell people to do. It’s like, no, actually, no, that’s not how it works, right? You have to inspire them, guide them, drive them, give them the tools, give them the training, give them the education, give them the desire and need and want for how to get there, have them very involved in what should we do, how do we improve, and you can throw in things, but it needs to come from them. If there were anything else I’d throw into that, it was counterintuitive, as I think about improving engineering productivity was, to me, this idea of that off, you know, as we think about from an accounting perspective, there’s just no way in hell that two engineers working on one problem is better than one. There’s no way that’s more productive. You know, they’re going to get half the work done. That’s, that’s a counterintuitive notion. If you think about, if you think about it, engineers as just mere inputs and resources. But in reality, they’re people, and that software development is a team sport. As a matter of fact, if they work together in real time, two engineers at the same time, or god forbid, three, four, and five, if you’re ensemble programming, you actually find that you get more done. You get more done because things, like they need to get reworked less. Things are of higher quality. The team learns more, learns faster. So at the end of the day, while it might feel slow, slow is smooth and smooth is fast. And they get just get more over time. They get more throughput and more quality and get to deliver more things because they’re spending less time going back and fixing and reworking what they were doing. And the work always continues because no one person slows it down. So that’s the other counterintuitive thing I learned in terms of improving and increasing productivity. It’s like, you cannot look at just productivity, you need to look at productivity, efficiency, and effectiveness if you really want to move forward.

Kovid Batra: Makes sense. I think, uh, in the last few years, uh, being in this industry, I have also developed a liking towards pair programming, and that’s one of the things that align with, align with what you have just said. So I, I’m in for that. Yeah. Uh, great. Cesar, do you have, uh, any, any learnings which were counterintuitive or interesting that you would like to share?

Cesar Rodriguez: Oh, and this goes back to the developer versus engineering, uh, conversation, uh, and question. So productivity and then something that’s counterintuitive is that it doesn’t mean that you’re going to be busy. It doesn’t mean that you’re just going to write your code and finish tickets. It means that, and this is, if there are any developers here listening to this, they’re probably going to hate me. Um, you’re going to take your time to plan. You’re going to take your time to reflect and document and test. Um, and we, like, we’ve seen this even at StackGen last quarter, we focused our, our, our efforts on improving our automated tests. Um, in the beginning, we’re just trying to meet customer demands. We, unfortunately, they didn’t spend much time testing, but last quarter we made a concerted effort, hey, let’s test all of our happy paths, let’s have automated tests for all of that. Um, let’s make sure that we can build everything in our pipelines as best as possible. And our, um, deployment frequency metrics skyrocketed. Um, so those are some of the, uh, some of the counterintuitive things, um, maybe doing the boring stuff, it’s gonna be boring, but it’s gonna speed you up.

Ariel Pérez: Yeah, and I think, you know, if I can add one more thing on that, right, that’s critical that many people forget, you know, not only engineers, as we’re working on things and engineering leadership, but also your business peers; we forget that the cost of software, the initial piece of building it is just a tiny fraction of the cost. It’s that lifetime of iterating, maintaining it, managing, building upon it; that’s where all the cost is. So unfortunately, we often cut the things when we’re trying to cut corners that make that ongoing cost cheaper and you’re, you’re right, at, you know, investing in that testing upfront might seem painful, but it helps you maintain that actual, you know, uh, that reasonable burn for every new feature will cost a reasonable amount, cause if you don’t invest in that, every new feature is more expensive. So you’re actually a whole lot less productive over time if you don’t invest on these things at the beginning.

Cesar Rodriguez: And it, and it affects everything else. If you’re trying to onboard somebody new, it’ll take more time because you didn’t document, you didn’t test. Um, so your cost of onboarding new people is going to be more expensive. Your cost of adding new people, uh, new features is going to be more expensive. So yeah, a hundred percent.

Kovid Batra: Totally. I think, Cesar, documentation and testing, uh, people hate it, but that’s the truth for sure. Great, guys. I think, uh, there is more to learn on the journey and there are a lot more questions that I have and I’m sure audience would also have a lot of questions. So I would request the audience to put in their questions in the comment section right now, because at the end when we are having a Q&A, we’ll have all the questions sorted and we can take all of them one by one. Okay. Um, as I said, like a lot of learning and unlearning is going to happen, but let’s talk about some of, uh, your specific experiences, uh, learn some practical tips from there. So coming to you, Ariel. Uh, you have recently moved into this leadership role at Tinybird. Congratulations, first of all.

Ariel Pérez: Thank you.

Kovid Batra: And, uh, I’m sure this comes with a lot of responsibility when you enter into a new environment. It’s not just a new thing that you’re going to work upon, it’s a whole new set of people. I’m sure you have seen that in your career multiple times. But every time you step in and you’re a new person there, and of course, uh, you’re going as a leader, uh, it could be overwhelming, right? Uh, how do you manage that situation? How do you start off? How do you pull off so that you actually are able to lead, uh, and, and drive that impact which you really want?

Ariel Pérez: Got it. Um, so, uh, the first part is one of, this may sound like fluff, but it really helps, um, in many ways when you have a really big challenge ahead, you know, you have to avoid, you have to figure out how to avoid letting imposter syndrome freeze you. And even if you’ve had a career of success, you know, in many ways, imposter syndrome still creeps up, right? So how do I fight, how do I fight that? It’s one of those things like stand in front of the mirror and really deep breaths and talk about I got this job for a reason, right? I, you know, I, I, they, they’re trusting me for a reason. I got here. I earned this. Here’s my track record. I worked this. Like I deserve to be here. I’m supposed to be here. I think that’s a very critical piece for any new leader, especially if you’re a new leader in a new place, because you have so much novelty left and right. You have to prove yourself and that’s very daunting. So the first piece is you need to figure out how to get yourself out of your own head. And push yourself along and coach yourself, like I’m supposed to be here, right? Once you get that piece, you know down pat, it really helps in many ways helps change your own mindset your own framing. When you’re walking into conversations walking into rooms, there’s a big piece of how, how that confidence shines through. That confidence helps you speak and get your ideas and thoughts out without tripping all over yourself. That confidence helps you not worry about potentially ruffling some feathers and having hard conversations. When you’re in leadership, you have to have hard conversations. It’s really important to have that confidence, obviously without forgetting it, without saying, let me run over everybody, cause that’s not what it means, but it just means you got to get over the piece that freezes you and stops you. So that’s the first piece I think. The second piece is, especially when moving higher and higher into positions of leadership; it’s listening. Listening is the biggest thing you do. You might have a million ideas, hold them back, please hold them back. And that’s really hard for me. It’s so hard cause I’m like, “I see that I can fix that. I can fix that too. I’ve seen that before I can fix it too.” But, you know, you earn more respect by listening and observing. And actually you might learn a few things or two. I’m like, “Oh, that thing I wanted to fix, there’s a reason why it’s the way it is.” Because every place is different. Every place has a different history, a different context, a different culture, and all those things come into play as to why certain decisions were made that might seem contrary to what you would have done. And it helps you understand that context. That context is critical, not only to then figure out the appropriate solution to the problem, but also that time while you’re learning and listening and talking to people, you’re building relationships with people, you’re connecting to people, you’re understanding, you’re understanding the players, understanding who does well, who doesn’t do well, you’re understanding where all the bodies are buried, you’re understanding the strategy, you’re getting a big picture of all the things so that then when it comes time to say now time to implement change, you have a really good setup of who are the people that are gonna help me make the change, who are the people that are going to be challenging, how do I draw a plan to do change management, which is a big important thing. Change management is huge. It’s 90% people. So you need to understand the people and then understand, it also gives you enough time to understand the business strategy, the context, the big problem where you’re going to kind of be more effective at. Here’s why I got hired. Now I’m going to implement the things to help me execute on what I believe is the right strategy based on learning and listening and keeping my mouth shut for the time, right? Now, traditionally, you’ll hear this thing about 90 days. I think the 90 days is overly generous if you’re in a really big team, I think it leans and skews toward big places, slower moving places, um, and, and places that move. That’s it. Bigger places, slower places. When you join a startup environment, we join a smaller company. You need to be able to move faster. You don’t have 90 days to make decisions. You don’t have 90 days. You might have 30 days, right? You want to push that back as far as you can to get an appropriate context. But there’s a bias for action, reasonably so because you’re not guaranteed that the startup is going to be there tomorrow. So you don’t have 90 days, but you definitely don’t want to do it in two weeks and probably not start doing things in a month.

Kovid Batra: Makes sense. Makes sense. So, uh, a follow-up question on that. Uh, when you get into this position, if you are in a startup, let’s say you get 30 to 45 days, but then because of your bias towards action, you pick up initiatives that you would want to lead and create that impact. In your journey at Tinybird, have you picked up something, anything interesting, maybe related to AI or maybe working with different teams that you think would work on your existing code base to revamp it, anything that you have picked up and why?

Ariel Pérez: Yeah, a bunch of stuff. Um, I think when I first joined Tinybird, my first role was field CTO, which is a role that takes the, the, the responsibilities of the CTO and the external facing aspects of them. So I was focused primarily on the market, on customers, on prospects. And as part of that one, you know, one of the first initiatives I had was how do we, uh, operate within the, you know, sales engineering team, who was also reporting to me, and make that much more effective, much more efficient. So a few of the things that we were thinking of there were, um, AI-based solutions and GenAI-based solutions to help us find the information we need earlier, sooner, faster. So that was more like an optimization and efficiency thing in terms of helping us get the answers and clarify and understand and gather requirements from customers and very quickly figure out this is the right demo for you, these are the right features and capabilities for you, here’s what we can do, here’s what we can’t do, to get really effective and efficient at that. When moving into a product role though, and product and engineering role, in terms of the, the latest initiatives that I’ve picked up, like there, there, there, there are two big things in terms of themes. One of them is that Tinybird must always work, which sounds like, yeah, well, duh, obviously it must always work, but there’s a key piece underpinning that. Number one, obviously the, you know, stability and reliability are huge and required for trust from customers wanting to use you as a dev tool. You need to be able to depend on it, but there’s another piece is anything I must do and try to do on the platform, it must fail in a way that I understand and expect so that then I can self service it and fix it. So that idea of Tinybird always works that I’ve been picking up and working on projects is transparency, observability, and the ability for customers to self-service and resolve issues simply by saying, “I need more resources.” And that’s a, you know, it’s a very challenging thing because we’ve got to remove all the errors that have nothing to do with that, all the instability and all the reliability problems so that those are granted. And then remaining should only be issues that, hey, customer, you can solve this by managing your limits. Hey, customer, you can solve this by increasing the cores you’re using. You can solve this by adding more memory and that should be the only thing that remains. So working on a bunch of stuff there on predicting whether something will fail or not, predicting whether something is going to run out of resources or not, very quickly identifying if you’re running out of resources so there’s almost like an SRE monitoring observability aspect to this, but turning that back into a product solution. That’s one side of it. And then the other big pieces will be called a developer’s experience. And that’s something that my, you know, my, my, my peer is working internally on and leading is a lot more about how developers develop today. Developers develop today, well, they always develop locally. They prefer not depending on IO on a network, but developer, every developer, whether they tell you yes or no, is using an AI assistant; every developer, right? Or 99% of developers. So the idea is, how do we weave that into the experience without making it be, you know, a gimmick? How do we weave an AI Copilot into your development experience, your local development experience, your remote development experience, your UI development experience so that you have this expert at your disposal to help you accelerate your development, accelerate your ability to find problems before you ship? And even when you ship, help you find those problems there so you can accelerate those cycles, so you can shorten those lead time, so you can get to productivity and a productive solution faster with less errors and less issues. So that’s one major piece we’re working on there on the embedding AI; and not just AI and LLMs and GenAI, all you think about, even traditional. I say traditional like ML models on understanding and predicting whether something’s going to go wrong. So we’re working on a lot of that kind of stuff to really accelerate the developer, uh, accelerate developer productivity and engineering team productivity, get you to ship some value faster.

Kovid Batra: Makes sense. And I think, uh, when you’re doing this, is there any kind of framework, tooling or processes that you’re using to measure this impact, uh, over, over the journey?

Ariel Pérez: Yeah, um, for this kind of stuff, I lean a lot more toward the outcomes side of the equation, you know, this whole question of outputs versus outcomes. I do agree. John Cutler, very recently, I loved listening to John Cutler. He very recently published something like, look, we can’t just look at outcomes, because unfortunately, outcomes are lagging. We need some leading indicators and we need to look at not only outcomes, but also outputs. We need to look at what goes into here. We need to look at activity, but it can’t be the only thing we’ll look at. So the things I look at is number one, um, very recently I started working with my team to try to create our North Star metric. What is our North Star metric? How do we know that what we’re doing and what we’re solving for is delivering value for our customers? And is that linked to our strategy and our vision? And do we see a link to eventual revenue, right? So all those things, trying to figure out and come up with that, working with my teams, working, looking at our customers, understanding our data, we’ve come up with a North Star metric. We said, great, everything we do should move that number. If that moving, if that number is moving up into the right, we’re doing the right things. Now, looking at that alone is not enough, because especially as engineering teams, I got to work back and say, how efficient are we at trying to figure that out? So there’s, you know, a few of the things that I look at, I obviously look at the DORA metrics. I do look at them because they help us try to figure out sources of issues, right? What’s our lead time? What’s our cycle time? What’s our deployment frequency? What’s our, you know, what, you know, what, what’s our, uh, you know, change failure rate? What’s our mean time to recover? Those are very critical to understand. Are we running as a tip-top shop in terms of engineering? How good are we at shipping the next thing? Because it’s not just shipping things faster; it’s if there’s a problem, I need to fix it really fast. If I want to deliver value and learn, and this is the second piece is critical that many companies fail is, I need to put it out in the hands of customers sooner. That’s the efficiency piece. That’s the outputs. That’s the, you know, are we getting really good at putting it in front of customers, but the second piece that we must need independent of the North Star metric is ‘and what happened’, right? Did it actually improve things? Did it, did it make things worse. So it’s optimizing for that learning loop on what our customers are doing. Do we have.. I’m tracking behavioral analytics pieces where the friction points were funnels. Where are they dropping off? Where are they circling the wheels, right? We’re looking at heat maps. We’re looking at videos and screen shares of like, what did the customer do? Why aren’t they doing what they thought we thought they were going to do? So then now when we learn this, go back to that really awesome DORA numbers, ship again, and let’s see, let’s see, let’s fix on that. So, to me, it’s a comprehensive view on, are we getting really good at shipping? And are we getting really good at shipping the right thing? Mixing both those things driven by the North star metric. Overall, all the stuff we’re doing is the North star moving up into the right.

Kovid Batra: Makes sense. Great. Thanks, Ariel. Uh, this was really, really insightful. Like, from the point you enter as a leader, build that listening capability, have that confidence, uh, driving the initiatives which are right and impactful, and then looking at metrics to ensure that you’re moving in the right direction towards that North Star. I think to sum up, it was, it was really nice and interesting. Cesar, I think coming to your experience, uh, you have also had a good stint at, uh, at StackGen and, uh, you were mentioning about, uh, taking up this transition successfully, uh, which was multi-cloud infrastructure that expanded your engineering team. Uh, right? And I would want to like deep dive into that experience. Uh, you specifically mentioned that, uh, that, uh, transition was really successful, and at that time, you were able to keep the focus, keep the productivity in place. How things went for you, let’s deep dive into that experience of yours.

Cesar Rodriguez: Yeah. So, so from my perspective, the goals that you are going to have for your team are going to be specific to where the business is at, at that point in time. So, for example, StackGen, we started in 2023. Initially, we were a very small number of engineers just trying to solve the initial problem, um, which we’re trying to solve with Stackdn, which is infrastructure from code and easily deploying cloud architecture into, into the cloud environment. Um, so we focus on one cloud provider, one specific problem, with a handful of engineers. And once we started learning from customers, what was working, what was not working, um, and we started being pulled into different directions, we quickly learned that we needed to increase engineering capacity to support additional clouds, to deliver additional features faster. Um, our clients were trying to pull us in different directions. So that required, uh, two things. One is, um, hiring and scaling the team quickly. So now we are, at the moment we’re 22 engineers; so hiring and scaling the engineering team quickly and then enabling new team members to be as productive as possible in day zero. Um, and this is where, this is where the boring, the boring actions come into play. Um, uh, so first of all, making sure that you have enough documentation so somebody can get up and running on day one, um, and they can start doing pull requests on day one. Second of all, making sure that you have, um, clear expectations in terms of quality and what is your happy path, and how can you achieve that. And third, um, is making sure everyone knows what is expected from them in terms of the metrics that we’re looking for and, uh, the quality that we’re looking for in their outcomes. And this is something that we use Typo for. So, for example, we have an international team. We have people in India, Portugal, US East Coast, US West Coast. And one of the things that we were getting stuck early on was our pull requests were getting opened, but then it took a really long time for people to review them, merge them, and take action and get them deployed. So, um, we established a metric, and we did this using Typo, where we were measuring, hey, if you have a pull request open more than 12 hours, let’s create an alert, let’s alert somebody, so that somebody can be on top of that. We don’t want to get somebody stuck for more than a working day, waiting for somebody to review the pull request. And, and the other metric that we look at, which is deployment frequency, we see that an uptick of that. Now that people are not getting stuck, we’re able to have more frictionally, frictionless, um, deployments to our SDLC where people are getting less stuck. We’re seeing collaboration between the team members regardless of their time zone improving. So that’s something actionable that we’ve implemented.

Kovid Batra: So I think you’re doing the boring things well and keeping a good visibility on things, how they’re proceeding, really helped you drive this transition smoothly, and you were able to maintain that productivity in the team. That’s really interesting. But touching on the metrics part again, uh, you mentioned that you were using Typo. Uh, there, there are, uh, various toolings to help you, uh, plan, execute, automate, and reflect things when you are, when you are into a position where as a leader, uh, you have multiple stakeholders to manage. So my question to both of you, actually, uh, when we talk about such toolings, uh, that are there in the market, like Typo, how these tools help you exactly, uh, in each of these phases, or if you’re not using such tools, you must be using some level of metrics, uh, to actually, let’s say you’re planning an initiative, how do you look at numbers? If you’re automating something and executing something, how do you look at numbers and how does this whole tooling piece help you in that? Um, yeah.

Cesar Rodriguez: I think, I think for me, the biggest thing before, uh, using a tool like Typo was it was very hard to have a meaningful conversation on how the engineering team was performing, um, without having hard, hard data and raw data to back it up. So, um, the conversation, if you don’t, if you’re not measuring things, it’s more about feelings and more about anecdotal evidence. But when you have actual data that you can observe, then you can make improvements, and you can measure how, how, how that, how things are going well or going bad and take action on it. So, so that’s the biggest, uh, for me, that’s the biggest benefit for, from my perspective. Um, you have, you can have conversations within your team and then with the rest of the organization, um, and present that in a, in a way that makes sense for everyone.

Kovid Batra: Makes sense. I think that’s the execution part where you really take the advantage of the tool. You mentioned with one example that you had set a goal for your team that okay, if the review time is more than 12 hours, you would raise an alert. So, totally makes sense, that helps you in the execution, making it more smooth, giving you more, uh, action-driven, uh, insights so that you can actually make teams move faster. Uh, Ariel, for you, any, any experiences around that? How do you, uh, use metrics for planning, executing, reflecting?

Ariel Pérez: So I think, you know, one of the things I like doing is I like working from the outside in. By that I mean, first, let me look at the things that directly impact customers, that is visible. There’s so much there on, you know, in terms of trust to customers. There’s also someone’s there on like actual eventual impact. So I lay looking, for example, um, the, it may sound negative, but it’s one of those things you want to track very closely and manage and then learn from is, what’s our incident number? Like, how many incidents do we have? You know, how many P0s? How many P1s? That is a very important metric to trust because I will guarantee you this, if you don’t have that number as an engineering leader, your CEO is going to try to figure out, hey, why are we having so many problems? Why are so many customers angry calling me? So that’s a number you’re going to want to have a very strong pulse on: understand incidents. And then obviously, take that number and try to figure out what’s going on, right? There’s so much behind it. But the first part is understand the number and you want that number to go down over time. Um, obviously, like I said, there’s a North star metric. You’re tracking that. Um, I look at also, which, you know, I don’t lean heavily on these, but they’re still used a lot and they’re still valuable. Things like NPS and CSAT to help you understand how customers are feeling, how customers are thinking. And it allows me to get often when it’s paired with qualitative feedback, even more so because I want to understand the ‘why’ and I’ll dive more into the qualitative piece, how critical is it and how often we forget that piece when we’re chasing metrics and looking for numbers, especially we’re engineers, we want numbers. We need a story and the story, you can’t get the story just from the numbers. So I love the qualitative aspect. And then the third thing I look at is, um, SCIs or failed customer interactions, trying to find friction in the journeys. What are all the times a customer tries to do something and they fail? And you know, you can define that in so many kinds of ways, but capturing that is one of those things you try to figure out. Find failed customer interactions, find where customers are hitting friction points, and let’s figure out which of those are most important to attack. So these things help guide, at the minimum, what do we need to work on as a team? Right? What are the things we need to start focusing on to deliver and build? Like, how do I get initiatives? Obviously, that stuff alone doesn’t turn into initiatives. So the next thing I like ensuring and I drive to figure out what we work on is with all my leaders. And in our organization, we don’t have separate product managers. You know, engineering leaders are product managers. They have to build those product skills because we have such a technical product that we decided to make that decision, not only for efficiency’s sake and stop having two people in every conversation, but also to build up that skill set of ‘I’m building for engineers, and I need to know my engineering product very well, but now let me enable these folks with the frameworks and methodologies, the ideas and the things that help them make product decisions.’ So, when we look at these numbers, we try to look at what are some frameworks and ways to think about what am I going to build? Which of these is going to impact? How much do we think it’s going to impact it? What level of confidence do I have in that? Does that come from the gut? Does that come from several opinions that customers tell us that, is the data telling us that, are competitors doing it? Have we run an experiment? Did we do some UX research? So the different levels of, uh, confidence in I want to do this thing. Cause this thing’s going to move that number. We believe that number is important. The FCI is it through the roof. I want to attack them. This is going to move it. Okay. How sure are you? He’s going to move it. Now, how are we going to measure that? And indeed moved it. Then I worked, so that’s the outside of the onion. Then I work inward and say, great, how good are we at getting at those things? So, uh, there’s two combinations of measures. I pull measures and data from, from GitLab, from GitHub, I look at the deployments that we have. Thankfully, we run a database. We have an OLAP database, so I can run a bunch of metrics off of all this stuff. We collect all this data from all this telemetry from our services, from our deployments, from our providers for all of the systems we use, and then we have these dashboards we built internally to track aggregates, track metrics and track them in real time, because that’s what Tinybird does. So, we use Tinybird to Tinybird while we Tinybird, which is awesome. So I, we’ve built our own back dashboards and mechanisms to track a lot of these metrics and understand a lot of these things. However, there’s a key piece which I haven’t introduced yet, but I have a lot of conversations with a lot of people on, hey, why did this number move? What’s going on? I want to get to the place that we actually introduce surveys. Funny enough, when you talk about the beginning of DORA, even today, DORA says, surveys are the best way to do this. We try to get hard data, but surveys are the best way to get it. For me, surveys really help, um, forget for a second what the numbers are telling me, how do the engineers feel? Because then I get to figure out why do you feel that way? It allows me to dive in. So that’s why I believe the qualitative subjective piece is so important to then bolster the numbers I’m seeing, either A: explain the numbers, or the other way around, when I see a story, I’m like, do the numbers back up that story? The reality is somewhere in the middle, but I use both, both of those to really help me.

Kovid Batra: Makes sense. Makes sense. Great guys. I think, uh, thank you. Thank you so much for sharing such good insights. I’m sure our audience has some questions for us, uh, so we can break in for a minute and, uh, then start the QnA.

Kovid Batra: All right. I think, uh, we have a lot of questions there, but I’m sure we are going to pick a few of them. Let’s start with the first one. That’s from Vishal. Hi Ariel, how do you, how do I decide which metrics to focus while measuring teams productivity and individual metrics? So I think the question is simple, but please go ahead.

Ariel Pérez: Um, I would start with in terms of, I would measure the core four of DORA at the minimum across the team to help me pinpoint where I need to go. I would start with that to help me pinpoint. In terms of which team productivity metrics or individual productivity metrics, I’d be very wary of trying to measure individual productivity metrics, not because we shouldn’t hold individuals accountable for what they do, not because individuals don’t also need to understand, uh, how we think about performance, how we manage that performance, but for individuals, we have to be very careful, especially in software teams. Since it’s a team sport, there’s no individual that is successful on their own, and there’s no individual that fails on their own. So if I were to think, you know, if I were to measure and try to figure out how to identify how this individual is doing, I would, I would look for at least two things. Number one, actual peer feedback. How, how do their peers think about this person? Can they depend on this person? Is this person there when they need him? Is this person causing a lot of problems? Is this person fixing a lot of problems? But I’d also look at the things, to me, for the culture I want to build, I want to measure how often is this person reviewing other people’s PRs? How often is this person sitting with other people, helping unblock them? How often is this person not coding because they’re going and working with someone else to help unblock them? I actually see that as a positive. Most frameworks will ding that person for inactivity. So I try to find the things that don’t measure activity, but are measuring that they’re doing the right things, which is teamwork. They’re actually being effective at working in a team when it comes to individuals.

Kovid Batra: Great. Thanks, Ariel. Uh, next question. That’s for you, Cesar. How easy or hard is the adoption and implementation of SEI tools like Typo? Okay, so you can share your experience, how it worked out for you.

Cesar Rodriguez: So, so two things. So, so when I was evaluating tools, um, I prefer to work with startups like Typo because they’re extremely responsive. If you go to a big company, they’re not going to be as responsive and as helpful as a startup is. They change the product to meet your expectations and they work extremely fast. So that’s the first thing. Um, the hard part of it is not about the technology itself. The technology is easy. The hard part is the people aspect of it. So you have to, if you can implement it early, uh, when your company is growing, that’s better because they’ll, when new team members come in, they already know what are the expectations and what to expect. The other thing is, um, you need to communicate effectively to your team members why are you using this tool, and getting their buy-in for measuring. Some people may not like that you’re going to be measuring their commits, their pull requests, their quality, their activity, but if you have a conversation with, with those people to make them understand the ‘why’ and how can you connect their productivity to the business outcomes, I think that goes far along. And then once you’re, once you’re in place, just listening to your engineers feedback about the tool, working with the vendor to, to modify anything to fit your company’s need, um, a lot of these tools are very cookie cutter in their approach, um, and have a set of, set of capabilities, but teams are made of people and people have different needs. So, so make sure that you capture that feedback, give it to your vendor and work with them to make the tool work for your specific individual teams.

Kovid Batra: Makes sense. Next question. That’s from, uh, Mohd Helmy Ibrahim, uh, Hi Ariel, how to make my senior management and junior implement project management software in their work, tasking to be live update tracking status update?

Ariel Pérez: Um, I, that one, I’m of two minds cause only because I see a lot of organizations who can get really far without actual sophisticated project management tooling. Like they just use, you know, Linear and that’s it. That’s all enough. Other places can’t live without, you know, a super massive, complex Jira solution with all kinds of things and all kinds of bells and whistles and reports. Um, I think the key piece here that’s important and actually it was funny enough. I was literally just having this conversation with my leadership team, my engineering leadership team. It’s this, you know, when it comes to the folks involved is do you want to spend all day asking, answering questions about where is this thing, how is this thing doing, is this thing going to finish, when is it going to finish, or do you want to just get on with your work, right? If you want to just get on with your work and actually do the work rather than talk about the work to other people who don’t understand it, if you want to find out when you want to do it, you need some level of information radiator. Information reader, radiators are critical at the minimum so that other folks can get on the same page, but also if someone comes to you and says, Hey, where is this thing? Look at the information radiator. It’s right there. You, where’s the status on the, it’s on the information radiator. When’s this going to be done? Look at the information radiator, right? That’s the key piece for me is if you don’t want to constantly answer that question, then you will, because people care about the things you’re working on. They want to know when they can sell this thing or they want to know so they can manage their dependencies. You need to have some level, some minimum level of investment of marking status, marking when you think it’s going to be done and marking how it’s going. And that’s a regular piece. Write it down. It’s so much easier to write it down than to answer that question over and over again. And if you write it down in a place that other people can see it and visualize it, even better.

Kovid Batra: Totally makes sense. All right, moving on. Uh, the next question is for Cesar from Saloni. Uh, good to see you here. I have a question around burnout. How do you address burnout or disengagement while pushing for high productivity? Oh, very relevant question, actually.

Cesar Rodriguez: Yeah, so so for this one, I actually use Typo as well. Um, so Typo has this gauge to, um, that tells you based on the data that it’s collecting, whether somebody is working higher than expected or lower than expected. And it gives you an alert saying, hey, this person may be prone to burnout or this person is burning out. Um, so I use that gauge to detect how is the team doing and it’s always about having a conversation with the individual and seeing what’s going on with their lives. There may be, uh, work things that are impacting their productivity. There may be things that are outside of work that are impacting that individual’s productivity. So you have to work around that. Um, we are, uh, it’s all about people in the end, um, and working with them, setting the right expectations and at the same time being accommodating if they’re experiencing burnout.

Kovid Batra: Cool. I think, uh, more than myself, uh, you have promoted Typo a lot today. Great, but glad to know that the tool is really helping you and your team. Yeah. Next question. Uh, this one is again for you, Cesar from Nisha. Uh, how do you encourage accountability without micromanaging your team?

Cesar Rodriguez: I think, I think Ariel answered this question and I take this approach even with my kids. Um, it’s not about telling them what to do. It’s about listening and helping them learn and come to the same conclusion as you’re coming to without forcing your way into it. So, so yeah, you have to listen to everybody, listen to your stakeholders, listen to your team, and then help them and drive a conversation that can point them in the right direction without forcing them or giving them the answer which is, which requires a lot of tact.

Ariel Pérez: One more thing I’ll add to that, right, is, you know, so that folks don’t forget and think that, you know, we’re copping out and saying, hold on, what’s your job as a leader? What are you accountable for? Right? In that part, there’s also like, our job is let them know what’s important. It’s our job to tell them what is the most important thing, what is the most important thing now, what is the most important thing long term, and repeat that ad hominem until they make fun of you for it, but they need to understand what’s the most important, what’s the strategy, so you need to provide context, because there’s a piece of, it’s almost like, it’s unfair, and it’s actually, I think, very, um, it’s a very negative thing to say, go figure it out, without telling them, hold on, figure what out? So that’s a key piece there as well, right? It’s you, you’re accountable as the leader for telling them what’s important, letting them understand why this is important, providing context.

Kovid Batra: Totally. All right. Next one. This one’s for you, Cesar. According to you, what are the most common misconceptions about engineering productivity? How do you address them?

Cesar Rodriguez: So, so I think the, for me, the biggest thing is people try to come with all these new words, DORA, SPACE, uh, whatever latest and greatest thing is. Um, the biggest thing is that, uh, there’s not going to be a cookie cutter approach. You have to take what works from those frameworks to your specific team in your specific situation of your business right now. And then from there, you have to look at the data and adapt as your team and as your business is evolving. So that’s, that’s the biggest. misconception for me. Um, you can take, you can learn a lot from the things that are out there, but always keep in mind that, um, you have to put that into the context of your current situation.

Kovid Batra: I think, uh, Ariel, I would like to hear you on this one too.

Ariel Pérez: Yeah. Uh, definitely. Um, I think for me, one of the most common misconceptions about engineering productivity as a whole is this idea that engineering is like manufacturing. And for so long, we’ve applied so many ideas around, look, engineering is all about shipping more code because just like in a fan of factory, let’s get really good at shipping code and we’re going to be great. That’s how you measure productivity. Ship more code, just like ship more widgets. How many widgets can I ship per, per hour? That’s a great measure of engineering productivity in a factory. It’s a horrible measure of productivity in engineering. And that’s because many people, you know, don’t realize that engineering productivity and engineering in particular, and I’m gonna talk development, as a piece of development, is it’s more R&D than it is like doing things than it’s actual shipping things. Software development is 99% research and development, 1% actually coding the thing. And if they want any more proof of that is if you have an engineer working on something or a team working on something for three weeks and somehow it all disappears and they lose all of it, how long will it take them to recode the same thing? They’ll probably recode the same thing in about a day. So that tells you that most of those three weeks was figuring out the right thing, the right solution, the right piece, and then the last piece was just coding it. So I think for me, that’s the big misconception about engineering productivity, that it has anything to do with manufacturing. No, it has everything to do with R&D. So if we want to understand how to better measure engineering productivity, look at industries where R&D is a very, very heavy piece of what they do. How do they measure productivity? How did they think about productivity of their R&D efforts?

Kovid Batra: Cool. Interesting. All right. I think with that, uh, we come to the end of this session. Before we part, uh, I would like to thank both of you for making this session so interesting, so insightful for all of us. And thanks to the audience for bringing up such nice questions. Uh, so finally, before we part, uh, Ariel, Cesar, anything you would say as parting thoughts?

Ariel Pérez: Cesar, you wanna go first?

Cesar Rodriguez: No, no, um, no, no parting thoughts here. Feel free to, anyone that wants to chat more, feel free to hit me up on LinkedIn. Check out stackgen.com if you want to learn about what we do there.

Ariel Pérez: Awesome. Um, for me, uh, in terms of parting thoughts is; and this is just because how I’ve personally thought about this is, um, I think if you lean on the figuring out what makes people tick and figure, and you’re trying to take your job from the perspective of how do I improve people, how to enrich people’s lives, how do I make them better at what they do every day? If you take it from that perspective, I don’t think you can ever go wrong. If you make your people super happy and engaged and they want to be here and you’re constantly motivating them, building them and growing them, as a consequence, the productivity, the outputs, the outcomes, all that stuff will come. I firmly believe that. I’ve seen it. I firmly believe it. It really, it would be really hard to argue that with some folks, but I firmly believe it. So that’s my parting thoughts, focus on the people and what makes them tick and what makes them work, everything else will fall into place. And if I, you know, just like Cesar, I can’t walk away without plugging Tinybird. Tinybird is, you know, data infrastructure for software teams. You want to go faster, you want to be more productive, you want to ship solutions faster and for the customers, Tinybird is, is built for that. It helps engineering teams build solutions over analytical data faster than anyone else without adding more people. You can keep your team smaller for longer because Tinybird helps you get that efficiency, that productivity out there.

Kovid Batra: Great. Thank you so much guys and all the best for your ventures and for the efforts that you’re doing. Uh, we’ll see you soon again. Thank you.

Cesar Rodriguez: Thanks, Kovid.

Ariel Pérez: Thank you very much. Bye bye.

Cesar Rodriguez: Thank you. Bye!

In this episode of the groCTO Podcast, host Kovid Batra interviews Anton Zaides, the Director of Engineering at Taranis and author of the Leading Developers newsletter. Their discussion focuses on the challenges and strategies involved in leading development teams versus platform teams.

‍

‍

He recounts how his early interest in gaming and experiences as a guild master in World of Warcraft shaped his leadership style, teaching him valuable lessons in social intelligence and teamwork. Maher outlines his proprietary framework for peak performance focusing on shared understanding, trust, and competence, and highlights the significant benefits of leveraging generative AI tools like GitHub Copilot for improving productivity. The episode also delves into the complexities of implementing new technologies and managing distributed teams, underscoring Maher’s strategies for overcoming these challenges through continuous learning and fostering a collaborative culture.

Timestamps

• 00:00 — Introduction

• 01:15 — Meet Anton

• 01:35 — Anton's Journey and Achievements

• 02:04 — Dev vs Platform Teams: What's the difference?

• 04:21 — Challenges in Platform Teams

• 12:24 — Strategies for Better Collaboration

• 25:12 — The Role of Product Managers in Platform Teams

• 30:03 — Final Thoughts and Advice

Links and Mentions

• Anton on LinkedIn

• Kovid on LinkedIn

• Watch this episode on Substack and Youtube

• Listen on Spotify, Amazon Music, and iTunes/Apple Podcasts

Episode Transcript

Kovid Batra: Hi everyone. This is Kovid, back with another episode of groCTO by Typo. And today with us, we have a very special guest who is coming to the show for the second time, but first time for this year. That’s Anton. Welcome to the show, Anton.

Anton Zaides: Thank you, Kovid. Great to be back.

Kovid Batra: So let me introduce Anton. Uh, so Anton, guys, is Director of Engineering at Taranis, a company from Tel Aviv. And, uh, he is also the author of Leading Developers, which is a trending newsletter, at least on my list. And he is having almost 18,000 subscribers there, writing some great articles we are really fond of at groCTO. So congratulations to that, Anton, and welcome to the show again.

Anton Zaides: Thank you so much.

Kovid Batra: All right. Uh, so today’s topic of discussion is one of the topics from Anton’s newsletter, which is ‘Leading Dev Teams Vs Platform Teams’. This was a very interesting topic. Uh, I read the whole newsletter, Anton, and I really found it very interesting and that’s the reason I pulled you off here. And, uh, before we like jump into this, I’m really curious to ask you a few questions about it. But before that, I just want to know, uh, how was your last year? How did 2024 go? What are your plans for 2025? So that we get to know a little more about you.

Anton Zaides: So 24 was very busy. I had my, uh, I had my first kid at the beginning of the year, so a year ago, and got promoted a month after that. So it was a year full of..

Kovid Batra: Super hectic.

Anton Zaides: Yeah! Hectic, career, family, and I think a small one would be in my, uh, first international conference, uh, back in September, which was a great experience for me, you know, like talking in English with an audience. So I would say lot of family, lot of career. And in the next year it’s more about family. I’m right now taking a 7–8 months break and I’m planning to work on my own thing. Early child education, mainly helping parents, children, like my own kid’s age. Just a bit of technology and also learn about it. You know, I feel parents don’t really know what they’re doing. So that’s my goal for next year, to be a better father and use technology for that.

Kovid Batra: No, that’s really amazing. I know this is, I think there are a few experiences in a human’s life and this is one of those which changes you completely. And, and in a, in a very good way, actually. Uh, when you’re young, you usually do not love to take responsibilities. Nobody loves to do that. But when such kind of responsibilities come in, uh, I think you, you grow as a person, there is something that, uh, something else that you explore in your life, at least I would, I’ve seen, uh, in my friend circle and of course, I can relate to what you’re saying also. So, congratulations and all the best. Uh, we really feel that you would do great here as well.

Anton Zaides: Thank you. Thank you. Definitely. We’ll try.

Kovid Batra: Yeah. All right, Anton, uh, coming to the main section, uh, talking about platform teams and dev teams, uh, this topic is very unique in, uh, in a way that nobody usually gets to talk about it in detail, in depth the way you have done it. Of course, a lot of generic articles are there. I’ve read a lot. This session could be a really good guide for someone who is, uh, in a position where they are moving into these roles from, uh, leading dev teams to platform teams. They could really have some learnings from what you have experienced in the past. So, first question to you actually, why did this topic come to you? What happened in your personal experience that made you realize that, okay, this could be something that an engineering manager or a tech lead who is switching between these kind of responsibilities would be interested in knowing?

Anton Zaides: Going back, I first started in a classic dev team, right? I wrote code like everyone else for a few years, and then I switched to the platform side, DevOps side, more infrastructure, and led the team there for a couple of years. And I decided to switch back. So it was two switches I did. And in my last role as an engineering manager of a classic product-facing, you know, user-facing team, I felt that most of the other engineering managers in the organization, they don’t really know how to work with the platform team. We have a DevOps platform team that provide us, you know, all the tools, they help us, and I felt they don’t really understand, uh, how to approach them, how to help them, how to connect them to the business. So they just really liked working with my team and I always got what I wanted and I pushed the agenda for that. And it really, really helped my developers too, right? Because they got close to the platform developers and they understood it better, that made them better developers. And I felt like this connection can help other engineering managers who never experienced how difficult it is to be in a platform or DevOps team. I’m using the terms, uh, interchangeably, but, uh, let’s call them platform for now. So I felt that, you know, I can show the other side and I hope it will help other engineering managers to see the difficulties and stop being annoying, because, you know, we are the, we are the clients. It’s very, very hard to satisfy developers for platform teams. It’s almost impossible. You’re always too slow. You’re always like, too many bugs. You’re always not prioritizing me enough. So I wanted to show a bit of the other side. So that was the focus of the article, like showing the inside of a DevOps team with some tips, product teams on how to help the, those DevOps teams. That was the idea.

Kovid Batra: Hmm. Interesting. Interesting. So this was some real pain coming out there and like you telling people, okay, this is what the picture is so that they know what’s going on. Right. I think that makes a lot of sense. And I think a lot of people connected to that. And even I like the article a lot. Um, I was reading one section, uh, from the article, which mentions about, like this is something which is really, really hard to manage, right? Uh, because the, the expectations are very hard and you just now mentioned about, uh, it’s, it’s very hard to satisfy the developers and then the requirements are changing too fast. So these were the first two things I remember from your article which were, you, you touched base upon. So can you just give me some examples and the audience about how you see things are changing really fast or how it is becoming very difficult for you to manage these demanding clients, actually?

Anton Zaides: First of all, I think when your clients are technical and they are inside the company, they feel the privilege to tell you how to do things and prioritize your work, right? Because they say, Oh, why does it take you a month? So, I know I can do it for a week, right? They feel they can do the platform work and they kind of push the platform teams. Um, I had an example where when I was doing the platform team, we were responsible for, I don’t want to get too technical, but we had, uh, you know, database services like Postgres, MongoDB, Redis, right? Storage databases. So we were in a private cloud and we were responsible for, uh, providing those database as a service. What do you have in AWS and GCP? You just can request one. So we needed to do the same in our own private cloud, which is quite complex. And we provided PostgreSQL and MongoDB and Redis. And every day another developer says like, why don’t you do Cassandra? Or why don’t you do CouchDB? Like they felt like they know what needs to be done and they didn’t. They never thought, you know, in my opinion, Postgres is perfect for 99.9% of the startups and their products, but the developers felt like they need to push me to provide them new database just because they wanted to use new technologies, right? And now I heard like, uh, for example, we have Jenkins, right? So in my company, I heard developers complain, why Jenkins? It’s so slow. We need to replace it for something faster. Right. And this is something as a product team, you’ll never hear your client tell you, why do you use React? You need to use Vue. Right? It’s faster. It’s, they don’t care, right? They care about the end result. And here the comments like this, like does somebody really know how hard it is to replace Jenkins with another tool? What are the costs? What are the benefits? Why do it? So So they feel very comfortable, like, suggesting and giving their opinion, even if nobody really asks them, I would say. That’s one thing.

And the other one about the priorities is it’s actually, I would say sense of urgency that there are a lot more fires in the platform teams. For example, if you have, uh, we had the case of a GPU problem, right? You know, the world has, uh, not enough GPUs. So we had, we use, uh, the cheaper version of GPUs where they don’t promise you enough. And then we had a bottleneck and we needed the GPUs, but we couldn’t get them. And now we needed to change all the infrastructure to request the higher GPUs and kind of balance them to save prices. And this is a project that took one month and it’s completely stopped what they’re working on, which was also important. And you have so many incoming things like that, you know, you have an alert somewhere, right? Something is crashing. Very often it’s the developer’s problem. But if you see, uh, prod crashing, you say, okay, it’s, it’s the DevOps. They don’t have enough memory or they don’t have enough nodes or something like that. And then you kind of need to debug and then you understand it’s the developer’s problem. You tell them and then they debug and come back to you because they don’t do their job well. So this all back and forth makes it very, very, very hard to concentrate. I remember sitting in, you know, you have this tap on the shoulder, “Please help me a bit. Uh, please explain to me why this is not working.” Uh, clients usually in a product team, you have customer support, you have customer success. You have so many layers that isolate the developers from distractions, right? And you can see it straight here. Your clients are sitting by your side and they just go over and sit by you expecting you to help them. I think product developers would have been crazy if your client would come up to you and say, “Oh, this. I see an error, help fix it now.” So, yeah, I agree. Those are the two things that, that make it, uh, very hard, clients being opinionated and always distracted.

Kovid Batra: Right. I think from the two points that you mentioned, uh, there is always unwanted suggestions, recommendations, and then there is, there is this explanation when you do not want to be directly interacting with them, there should be a first level of curation on whether the problem belongs to the platform team or to the developer, there should be some level of clarity there and then probably there should be deep diving into what’s going on, who’s responsible. So what I felt is, let’s say just hypothetically, uh, five years down the line, you are an engineering leader who is managing the complete tech for, for an org. Uh, you have platform team, you have your development team, right? What advice or what kind of culture you would like to set in? Because it seems like a problem of a culture or perception where people like blame the platform teams or do not empathize with the platform teams that much. So, as an engineering leader down the line who is leading two different teams, what kind of culture you would like to set in or what kind of practices you would want to set in so that platform teams who are equally critical and responsible and accountable for things as development teams are operating neck to neck? Or I’m not, I’m short of words here, but I hope you get the sense of what I’m trying to say.

Anton Zaides: Yeah, I think I got it and, it’s, it’s a small thing that we’ve actually tried, but I think if I would have been the decision maker to be on a biggest scale, actually to switch places for at least a while. So I believe that platform and DevOps knowledge is super useful for every engineer, right? Not always the other way around. So I truly believe that every product engineer should know about platform, at least the basics, not every platform engineer should know React, right? Depends on what they work in, but I would put the product engineers and put them for a month, uh, helping the platform teams in a project. Like, everyone should do a bit of platform work to understand, to see how they work, right? They can work in Kanban and not your usual scrum to see how they’re day to day. If you see from the other side, like if you need to provide support to your own team, right, you are the pipeline. You will see how many requests are coming through and the other way around. I feel that we had, uh, for two sprints, like for a month, we had one of the platform developers in our team because he wanted to experience the life of a developer to understand the problem better and the usage of his own systems. And it was really, really mind opening for him too, to understand why we complain, what he thought was so easy to understand that it’s our problem. Once he sat with us and tried and developed and, uh, released some backend code to production and understood it’s not that easy. And so this connection of switching places and it has some cost, but I feel it’s worth it.

And the second one I would say is connect, like the road map shouldn’t be different, right? They should be much more connected. So when you’re building the platform roadmap, you should have, of course, the engineering managers, but not only when you build it. Like, they should be there at every release kickoff, every, every time they should be part of the platform roadmap. This is the easy part. The harder part is to explain to the platform people the your product, right, how is your 3–4 months going to look? What are you working on? What do you expect? And not just the managers, which is what usually happens, right? You have a manager sitting with a manager, discussing and stuff like that. The people underneath need to understand that, uh, sit there. For example, a platform engineer should hear customer success stories that he indirectly helped because a big part of the problem that when you work in the platform team, you don’t really affect the business bottom line, right? You help developers create solutions, but if you can have those stories of how you helped someone deliver something faster and what was the impact on the company, it creates like a shared responsibility because next time you will want to help them faster. You will want to understand the problem better because you feel the impact. Saying, “I released the service to production in five minutes instead of three hours.” That’s nice. But saying, “I released the feature a week earlier and a bigger deal was, uh, agreed by the customer because of the DevOps team.” Right? Doing this connection. It’s not always easy, but in a couple of cases, we were able to do that connection. Um, platform work directly to business outcomes. I feel that would be something that we try, uh, much more. Um, so yeah, if I had to choose one, it’s just, uh, switching the places a bit, we had a concept called ‘DevOps Champions’, but it can be ‘Platform Champions’, uh, where you pick one developer from each product team and they have a weekly meeting with the platform team and like hear about the latest news, ask questions. And for example, they are the point of contact before you can contact the platform team. You have someone in your team who is interested in platform and he gets more, uh, he gets like, I would say Slack, direct Slack access to the DevOps team They know like this person, if you ask, we will drop everything and help them. And they, they do trust. And then the whole team talks to one person instead of to the DevOps team. And, and this helps a bit. So I hope it was not too confusing. So if I sum it up, I say switch places and have a dedicated platform, uh, representative inside the product teams and also connect the platform team to the business side. Yeah.

Kovid Batra: That really makes sense. Uh, this point which you mentioned about bringing DevOps Champions, right? Like who are going to be the point of contact for the product teams to share knowledge, understand things. Going back to your newsletter, uh, you mentioned about bringing more visibility and recognition also. So is this dev champs, DevOps Champions some way of recognition also that you want to bring in into the teams to have a better culture there? I mean, basically these teams lack that level of recognition just because they’re not, again, directly impacting the business. So they don’t really get to see or feel what exactly they have done is, is this an outcome or consequence of that?

Anton Zaides: No, I think it’s a bit different because the champions are product engineers, like who are originally from inside the team. So if I have five developers, one of them will be like, uh, will wear the platform hat, but he will be a product engineer and he will get to, to, uh, learn from them and work with them, the ones who are interested. For the recognition, I’m talking about recognition of the pure platform engineers, which are usually in the dark and separate there. And there it’s about what we, we discussed a bit earlier, also sharing their stories, but also public acknowledgement. That’s something that I really, I have the privilege of having a LinkedIn, you know, and I constantly write there. So I, I did a couple of shoutouts for our platform engineers after nice projects, and they really, really appreciated it because, you know, people usually, you know how it is. If it works, they don’t hear about platform, only when it breaks. So they don’t get like kudos for nice projects and stuff like that. So I really try both on LinkedIn, but also in internal companies like channels, you know, saying nice words, uh, appreciating the work, stuff like that.

Kovid Batra: Makes sense. Makes sense. Totally. I think, uh, one thing I would be interested in knowing, like any of the projects that you took up as a platform team lead and completed that project. What was the mindset, what was the need, uh, and then how you accomplished it? Just deep diving into that process of being a platform team lead, uh, leading a project to make the lives of your developers, uh, better and maybe making them more productive, maybe delivering faster.

Anton Zaides: So let me think, it’s been a while, right? It’s four or five years ago since I was there. But I think if I go back, right, my team’s role was to deliver database as a service for our customers, right? Customers and developers, they want, uh, whatever PostgreSQL, uh, MongoDB and they, it’s hard for me to explain to people how it is without a public cloud. I was in a government agency, so there was no GCP, AWS, Azure. It was like everything, you need to create everything. It was an air gapped environment. Because of, you know..

Kovid Batra: Uh, information, regulation.

Anton Zaides: Regulation, information, you couldn’t use stuff like that. So we need to do everything from, from scratch. And one thing that, uh, we were a small team, so all the communication was, uh, we didn’t have like a portal, right? I know it’s very hard to imagine a world without the public cloud, but it was like emails and messages, please create me a database and stuff like that. And one very small annoying thing was the extensions and Postgres. You have many default extensions, like you have PostGIS, like for geographic extensions, you have like, uh, for using it as a vector database, you have many extensions, and we wanted to help them use those extensions, right? Because every time they needed a new extension, they need to send us an email. We need to check it. We needed to roll it out and stuff like that. So I know it’s, I think it’s not what ideally what you, uh, meant because it was quite a small project, but I saw that pain and we kind of went and figured out the top 20–30 extensions that did some templates and did some UI work, which is quite rare for platform teams, right? Because you hate UI, usually if you’re in platform. At most, you can do some backend, but you prefer to do like, you know, flash scripts and stuff. So we did some basic, uh, interface with React, HTML, CSS. So to create this very ugly portal, which I think people appreciated. It makes the work easier. And I think the good, the good platform teams are not afraid of writing a bit of code and using like graphical interface to a small portal or like, uh, if you want to request to see stuff like that instead of waiting for product teams to help them create a nice screen and stuff like that. Now with Cursor and, you know, and all the LLM, it can take you 30 minutes to do everything you need. Like, you have APIs, you can put them where they can use buttons to do like that, you need to request something. So I think like that barrier, if I go back to the story to break the barrier and not say, okay, I can only do backend stuff. That’s how it works. I will. And just think about the next step and go where it’s, it’s uncomfortable. I had, I was lucky because I had the background as a product developer, so it’s easy for me. But all of my team members, there was like, no, no way we’re going to write React. No, it’s not our job and stuff like that. So I had to, to force them a bit, force them and I actually enjoyed it because you know, it’s It’s, it’s rarely in the platform that you can actually see something immediately

Kovid Batra: This was an interesting experience and how this experience would have changed in case of such kind of requirement when it comes to dev teams, like, because we are just comparing like a while leading dev teams is different from leading platform teams. So in this situation, of course, there was a barrier. Uh, there was a problem which the platform teams had to solve, but it came with a solution that platform teams are usually not inclined towards like building the UI, right? If a similar kind of a situation had to come in for the dev teams, how do you think it would have been easier or difficult for you to manage as a manager?

Anton Zaides: I would say as a dev team, you have a product manager, you have UX designers, and you get a ready Figma of how it should look like, and you just implement it in, in a couple of days, right? It’s so much easier because someone is doing the research of talking to the customers. Some platform teams have a product manager, right? I would not say, but they for sure don’t have a UX designer working with them, because the system is internals and everybody say, “Oh, just make it good enough. Uh, these are our people anyway. You don’t need to make it beautiful.” So this, this is usually how it works. And in the product team, for me as a manager, it’s so much, much less work for me. The product manager, uh, doing most of the work. And I would just like, you know, manage the people a bit, coach them. But as a platform team, I did it, like 50% of my job I did product management. For some of the time I did have a dedicated product manager, but some of that I didn’t and I needed to kind of fill the hole myself. Yeah, because in platform team, it’s the first team where you cut the product manager. You say, “Oh, it’s internal. No need. Uh, the engineering manager can manage.”

Kovid Batra: That’s even my point, yeah. So even I, I felt so, like for platform teams, do you think it is even important to have a product manager? Because the tech lead or probably the engineering manager who’s involved with the team would be a good start to make sure like things are falling in the right places and understanding the problem. See, ultimately for a product manager, it is very important to be more empathetic towards the client’s problems and be able to relate to it. The more they relate, The more fit is there, the better solutioning they can design. Right. Similarly for an engineering manager who is leading the platform team, it would be more of a product role and it makes more sense also, as per my understanding. What do you have to say about that?

Anton Zaides: I have had experience with product managers with platform team who didn’t come from an engineering background and it was always a failure in my experience. Uh, I would say it’s better to have no product manager to let the engineering manager do the job. And ideally in, in that team after, I think it was after a year and a half, one of the engineers, like she mentioned she wants to become a product manager. This is her career path and then it’s a perfect fit, right? If you have an engineer who wants to become a product manager from inside the company, then it can work great. But I feel that in the platform case, the product manager must have an engineering background. Otherwise, like you can try to learn to be technical, but it would just be, it would be a different language. It would be, it’s not like product teams. Yeah, I agree. I feel it’s, uh, yeah, it just doesn’t work in my experience.

Kovid Batra: Makes sense. By leading a platform team where you find this kind of a fit where some engineer who is interested in becoming a product manager comes in and plays a role, I think I sense that there is definitely a need of a person who understands the pain, whether that person is an engineer or the engineering manager who is working as a product manager, but you definitely need that kind of a support in the system to make sure that requirements are flowing in correctly, right?

Anton Zaides: Yeah, I agree.

Kovid Batra: And most of the time what I have seen or felt is that engineers usually shy away or the engineering team shies away from being involved that aggressively towards client requirements. So when it comes to platform teams, how do you bring that extra level of empathy towards customer problems? Of course, they are developers, they relate to the problem, but still, I feel that in a world where we live dealing with real world problems, being a developer, you still get to see some side of it because you’re a human, you’re living in the, in that world. But when it comes to platform teams, it’s all technical. You have seen things, but still, it’s more like you are just solving a technical problem. So the empathy towards deep diving into the problem and bringing up a solution, does it become harder or easier when you are raising a product manager in an engineering team for platform teams?

Anton Zaides: I think it’s quite hard and I think this is the role of the engineering manager, of the platform engineering manager. Like I feel the product managers still have difficulty bridging that gap. I would say that platform engineers, either by experience or by character, they care more about the technical side. You know this term of product engineer, which is like pure product engineer, not like software engineer, like the people who decide what to build. Platform engineers, from my experience, care about the technical side, like much, much more, right? They want to build excellent solutions, they are excited by crazy bugs and they are excited by saving costs, stuff that most people are less excited by that. And yeah, it’s, it’s purely the job of the engineering manager. Like, as a platform manager, you need to show the pains of the developers too. That’s much more than in a product team where the PM filled that gap. I feel that even if a PM is an ex-engineer, in my experience, somehow, like, if the engineering manager won’t do it, the developers will resist much more the PM. Right? I think that’s what comes to mind. You have much more resistance in the platform team because they want to stay in the code. They don’t want to join customer meetings. They don’t want those things. Just want to code. So you need to, you know, like, uh, peel the shell and try to bring developers to share their stories, send them for a month for a development team, as we discussed, which they will hate probably. So you need to, to, push a bit. And the PM, it’s not, they are not his or her direct report. So they have limited power and you can actually, I would not say force, but kind of help them hardly along that path, uh, of understanding the user brains. Yeah.

Kovid Batra: Great, Anton. I think, um, thanks. Thanks for this interesting talk and helping us deep dive into the platform teams and the dev teams and how they differ in their core DNA. Uh, I think there were some great insights about how things change when you are leading a platform team, that from the expectations, from the kind of mindset that the developers come with, the unwanted suggestions, and like how you bring more connectedness to the business and recognizing teams. So I think this was a very interesting talk. Before we moved from the session, uh, is there any advice, uh, parting advice that you would like to give to the audience?

Anton Zaides: My main advice would be to the product leaders, product engineering managers to try much harder to understand the pain of the platform teams in your organization and how can you help them. Schedule 1-on-1s with the platform engineering manager, be more involved because they will appreciate that help and they might not even know they need your help. And in my experience, you will benefit for sure.

Kovid Batra: Makes sense. Makes sense. I think this would not only help reducing the friction, but will also help, uh, in bringing a better and a collaborative effort to build better product also like better platforms also.

Anton Zaides: For sure.

Kovid Batra: Great, Anton. Thank you. Thank you so much once again, uh, it was great having you on the show. Thank you.

Anton Zaides: Thank you, Kovid. It was great being here.

In this episode of the groCTO Podcast, host Kovid Batra welcomes Maher Hanafi, VP of Engineering at Betterworks, to discuss engineering productivity hacks. Maher shares insights from his 16+ years of engineering and leadership experience, emphasizing the importance of passion and individualized growth paths for team members.

‍

‍

He recounts how his early interest in gaming and experiences as a guild master in World of Warcraft shaped his leadership style, teaching him valuable lessons in social intelligence and teamwork. Maher outlines his proprietary framework for peak performance focusing on shared understanding, trust, and competence, and highlights the significant benefits of leveraging generative AI tools like GitHub Copilot for improving productivity. The episode also delves into the complexities of implementing new technologies and managing distributed teams, underscoring Maher's strategies for overcoming these challenges through continuous learning and fostering a collaborative culture.

Timestamps

• 00:00 — Introduction

• 00:54 — Welcome to the Podcast

• 01:16 — Meet Maher Hanafi

• 02:12 — Maher’s Journey into Gaming and Leadership

• 04:21 — Role and Responsibilities at Betterworks

• 06:20 — Transition from Manager to VP of Engineering

• 13:59 — Frameworks for Engineering Productivity

• 22:40 — Challenges and Initiatives in Engineering Leadership

• 34:38 — Impact of Generative AI on Engineering

• 44:31 — Conclusion and Farewell

• 45:07 — Advice for Engineering Leaders

Links and Mentions

• Maher on LinkedIn

• Kovid on LinkedIn

• Watch this episode on Substack and Youtube

• Listen on Spotify, Amazon Music, and iTunes/Apple Podcasts

Episode Transcript

Kovid Batra: Hi, everyone. Welcome back to groCTO by Typo. Uh, this is Kovid, your host, wishing you all a very, very happy new year. Today, we are kicking off this year’s groCTO Podcast journey with the first episode of 2025, hoping to make it even better, even more insightful for all the listeners out there. And today, for the first episode, uh, we have our special guest, Maher Hanafi. He’s VP of Engineering at Betterworks, comes with 16 plus years of engineering and leadership experience. Welcome to the show, Maher.

Maher Hanafi: Thank you, Kovid. Thank you for having me and happy new year.

Kovid Batra: Same to you, man. All right. Uh, so, Maher, uh, today we are going to talk about some engineering productivity hacks from a VP’s perspective. But before we jump onto our main discussion, uh, I think there is a lot to know about you. And to start off, uh, we would like to know something about you that your resume or your LinkedIn profile doesn’t tell. Something from your childhood, which was very eventful and then defines you today. So would you, would you like to take the stage and tell us about yourself?

Maher Hanafi: Well, that’s a great way to start the conversation. Thank you for asking this. Um, yeah, it’s not something that is on my resume and in my bio, but um people who know me know this. So I’m into gaming and I used to play video games a lot when I was a kid, to the point that I wanted my career to, to be in gaming. So I have a telecommunication background, engineering background. And then, as soon as I finished that, and I was ready to go to the market to start working, I decided to completely go and pursue a career in gaming. So what I did is, um, I looked into the gaming job, game developer jobs, and I figured out everything they’d need to, um, to have, to be had as a game developer. And I learned that. I taught myself these things and two years later I was working for Electronic Arts. So a great story there is like this passion I had as a kid for many years led me to, um, go into and pursue that career. Another part of that same story, as a gamer, I used to play a lot of, uh, massive multiplayer online video games, like MMOs. Uh, one of the biggest one is World of Warcraft, and at that time, I used to play the game a lot to the point that I was a guild master, meaning I was leading a big team, uh, hundreds of people, um, telling them, you know, kind of a leadership position. So in other words, I was a manager, uh, before I even started my career as an, as an engineer, or, uh, before I became an Engineering Manager later. So that taught me a lot of things from, you know, social intelligence and how you manage people and how you hire and fire and kind of manage productivity and performance, which will be the topic of today. So happy to be going to that later in a moment.

Kovid Batra: Oh, that’s very, very interesting. So I think, uh, before you even started off your leadership journey, you, you were actually leading a team. Though it was just gamers, but still it must have taught you a lot.

Maher Hanafi: Absolutely. Yeah, I learned a lot and I’m so grateful to that experience and a lot of what I did there are things that I brought to my career and I used as a, as a manager, um, to, to get to the engineering level.

Kovid Batra: Perfect. Perfect. I think it’s time. Let’s, let’s move on to something, uh, which is around the topic. And before, before, again, we jump onto that, uh, tell us something about Betterworks, your role and responsibility as a VP of Engineering over there. How is it like at Betterworks?

Maher Hanafi: Yeah. So, Betterworks, we are an enterprise, uh, SaaS company. So we develop an enterprise performance management software for global big companies, all the tools and suite of tools they need to manage performance internally, uh, for big companies. Again, this is more challenging when you have a, you know, departments and team and business units, and like you’re just globally distributed. Managing performance in general is very challenging. So we build and provide all these tools for, for our big customers. I’m currently the VP of Engineering. I lead all our engineering teams. Uh, we’re split between India and the US, and yeah, uh, I do different things. I, obviously, lead the technical perspective from a vision and strategy and architecture, help the team make the right decisions, build the right software, and also I contribute a lot to our strategy over time and vision, including AI. So this was one of the most recent, you know, kind of areas of focus of mine to help the team and the company deliver generative AI integrations and features and hand feature on top of what we offer, which is obviously very, very kind of important these days to be on top of that and deliver. So that’s what I do. And again, as a VP of Engineering, there’s a lot of things that get into that, including, you know, managing the team, managing productivity, ensuring that everything is being efficient and effective in having an impact.

Kovid Batra: Talking about productivity and efficiency, I think, um, I was just stalking your profile and like, I was stalking you on LinkedIn and I realized like, you have had this good journey from being a developer and then manager and then leader, right? I would want to understand how your perspective towards improving team efficiency and team productivity has changed while you were working as a manager and now working as a VP, like how, how your perspective has changed?

Maher Hanafi: Yeah. I mean, working as a, you know, going from an IC to a manager is one thing, is like going from this, you hear this a lot, going from being a player to being a coach, maybe captain/coach. So you have your scope, which is small. Usually you have your team, which is also usually small. The areas of expertise in terms of like stack and technology is also small most of the time. So when I started my journey as a manager, I was managing mobile teams and mobile development teams. So that was my area of expertise when I turned into management. But then when you get into more like senior management and the Director of Engineering and VP of Engineering, you, your scope is growing and you will be turned more horizontal than vertical, right? Like your depth of expertise gets kind of, uh, get to a certain level where you cannot go any deeper if you want to manage bigger teams. And add to that, you get involved into managing managers and you become like a coach of coaches. So the whole dynamics change over time and your areas of focus change and you become less hands-on, less technical, but still you need to keep up with things that are happening. If you go online and search for VP of Engineering, you’ll find a lot of people saying that VP of Engineering is like the hardest job in the engineering technology stack or all the roles because it has this challenge of going horizontal, trying to be as vertical as possible, managing managers and managing performance and again, focus on impact. So I think the mindset, the way my mindset changed over time is I needed to let go some of my biggest passions when, you know, I used to code and I used to go deeper into little details and very specific stacks and go more horizontal, but keep myself really up to date with things, so I can go and speak to my teams, their language and help them move the needle or what with what they do and still be a someone who can bring a vision that everyone can stand behind. So it’s a completely different game over time, but it’s organic, you know, you cannot just hop on overnight to into a new role like this and just expect yourself to be successful. So there’s a lot of learning, a lot of education You need to keep up with everything that is happening as much as you can obviously And then help your team execute and find the gaps in your own set of skills, technical, non-technical skills to be the best VP of Engineering you can to help your team proceed.

Kovid Batra: So if I have to ask about one more, like one of the hardest things for you, when you had to change yourself and you moved into this role, what was it?

Maher Hanafi: I think, definitely, going very horizontal because I think when I turned more into senior leadership positions in engineering management, I found myself very quickly into completely outside of my comfort zone, right? Like I used to do, you know, I started with gaming, obviously, that was my area of expertise. And then I learned mobile, which was a passion of mine. And then I was, that was my space. I was very comfortable there. I can do anything. I can be very efficient and I can lead a team to deliver on these areas. But then overnight, you take over, you know, web development and backend technologies and then cloud native, you know, distribution systems. So overnight you find yourself completely outside of the zone where you’re very comfortable and your team is looking up for you to guide sometimes, right? And it’s very hard for you to do any of that if you are able to speak the language to catch up with these technologies, to be someone people can stand behind in terms of like, uh, trust in terms of guidance. So that’s the moment where I felt like, “Oh, this is not the, this is not a thing I can keep doing the same way I used to do other things before. Now I need to get myself into continuous learning more proactively even ahead, you know, going a little bit ahead of my initial plans and managing teams.” So, very quickly I turn on, “Okay, what is web development? What are the key areas and components and technology stacks? How can I manage a team that does that? How can I learn back end very quickly? How can I learn infrastructure and data and then QA and security and all of that?” So as you go into these roles, again, your scope is going to grow, you know, significantly, and you need to catch up with these technologies, again, to a certain level of depth. I cannot go as deep as I went into mobile and into other technologies I was very hands-on in, but you need to have that level of depth that is good enough to drive these teams to really be a source of trust and confidence and people can stand with you as a leader, and again, be productive and perform.

Kovid Batra: Right. I think that makes a lot of sense, actually. But the thing is, like, when you are in that dilemma that how, whether you should go vertically deep into the topic or you have a responsibility to like, go horizontal as well, how do you take that call, “Okay, this is where I have to stop”, and like “This is how I would be guiding my team.”? Because when you’re talking to technologists and specifically in your case you were coming from a mobile and then a gaming background and then you took up other technologies. Anyone who is expecting some guidance there would be much deeper into that technology. So what would be that situation? Let’s say, I am that person who has technically, probably spent three, four years already in web development and you have come in as a VP and you’re trying to have a conversation with me and telling me that, okay, this is how you should be taking up things. Don’t you think that I would be the person who already knows more hands-on than you? And then in that situation, how could you guide me better?

Maher Hanafi: Well, that’s, that’s where a mix of soft skills and hard skills get into the game. And that’s where you can get into the VP of Engineering role is to be smart and socially capable of navigating these situations, right? So first of all, all the hard skills, as I said, you need to go and learn the minimum to be able to speak the language. You cannot go to, again, back end engineers and start telling them things and telling them stories about your front end engineering background. It doesn’t work. So you need to get to a certain level of learning and efficiency in the stack and the technology to be able to at least speak at a high level. And then, the other thing is where the soft skills get into the game. You need to be vulnerable. You need to be very clear about your level of expertise. You need to highlight your team members as the experts and create this environment of collaboration where you come as a leader, but they are the expert in the field, and together you can make, you can move the needle, together you can make things happen. So build that kind of trust relationship that will, that is based on their competence and your leadership and together you can really get things in motion. It’s very hard for someone who doesn’t have the strong IC technical hands-on background in a specific stack to come and lead them from a technical perspective purely with their own leadership. And that’s, in another language, that’s not a good leadership framework or management style if you just come in and guide the whole team to do what you want them to do. So that’s where, again, your soft skills get into the play where you come in and say, okay, what’s the vision here? What’s the plan what you have been going through? What are the challenges? And then, over time as you get more mature and more experienced as a leader, you’ll find a way, you’ll find a way to make it work. But again, I think you need to really get your ego outside of the room. Get and talk to these individuals. Make sure they understand you are here to support them and guide them from a leadership perspective, but they are still the expert in the fields and you count on them and give them space to experiment, give them space to own and lead and drive things. And that’s what leads to good collaboration between the leaders and the team behind.

Kovid Batra: Totally makes sense. Totally makes sense. So, um, moving on to the part where we talk about managing the teams, making them more efficient, making them more productive, what do you think, is there a framework that fits for everyone? Do you follow a framework to improve the overall engineering productivity, developer productivity in your teams?

Maher Hanafi: Honestly, this is a very kind of hard question, right? There is no pattern. There is no formula, one size fits all here for performance and for productivity. As a leader, you need to get into learning what your team is about, what the challenges they are facing, what kind of combination of skills, again, hard and soft skills you have in the team to figure out what is missing and how can you address this. But there is still like, even if this is not like a, there is no specific framework, I personally have been following a framework that helped me a lot in my journey. This is based, this is a twist of Daniel H. Pink, um, kind of autonomous team or the art of mastery, based on his book Drive. It’s by someone called, I think, John Ferguson Smart, and it’s a combination of three things. Shared understanding, which is mainly making sure that everyone in your team has the same understanding of what you are trying to do, what is the vision, and get that level of alignment, because sometimes teams cannot perform if they don’t have the same definition of something. Like if you want to build a feature and two parts of your team have this different understanding of that feature, that’s not going to lead to a highly performant outcome. So shared understanding is key and sometimes we miss this as leaders. We, we kind of delegate this to other people or other departments like product and project management say, “Okay, well, you, you, you define what is the statement and let the team work on it.” But as an engineering leader, you need to make sure your team has that same alignment.

The second thing is I list, I actually, I talked about this earlier is trust. I think trust is, again, really underrated when it comes to engineering leadership and we focus on technical and like this and that, but to build the value of trust in your team, to make sure, again, what I said earlier, talk to your team and tell them you are the expert. I’m here to help you get the best out of your expertise. And then, they should trust you also as a leader, as someone who can really help them navigate these things, not worry about the external noise and focus on what they need to deliver. And this leads to peak performance, which hopefully we’re going to get to at some point. The third part of this is competence, and this is mainly about hard skills which are, you know, very related to how efficient they can be at their, their, the stack and the technology they’re working on and all of that. So it’s more about the deep knowledge. So now defining shared understanding, trust and competence, you have overlap between these things, shared understanding and trust gives flexibility. So if you and your team members have the exact same understanding and you trust them, you can give your team the flexibility to do whatever they want. They work in their own way, the best way that works for them and own and kind of drive a higher level of ownership and use their own better judgement to get to the delivery. And flexibility works a lot to improve performance. So if you give people the flexibility they need, they can be very successful. The overlap between trust and competence provides excellence; meaning that if you trust them and they have the right skills, they will deliver the best outcome from a technology perspective. They will build the best code they can, because they trust their own frameworks and practices. Obviously you need, as a leader, you need to make sure it’s all aligned across the teams and not, it’s not based on individuals. And then last overlap is between shared understanding and competence. You get the focus. So if they have the skills and they have a clear understanding, they can be very focused on delivering exactly the right desired outcome you have for the team.

So this is the framework I use. It’s very kind of, um, very vague from, from, from distance. But when you start using it and really try to put together some specific goals and expectations to get higher on all of these, you get the center of all of these overlap, which is a very highly autonomous team that master their technology and the work they do. And again, they can have, deliver the highest impact possible. So that’s one of the frameworks, obviously there are more, but that’s one I really, that really resonated with me. Uh, I have the books, I have the TED, I mean, I watched the TED talk from Daniel H. Pink, which is really great, I recommend it to everyone.

Kovid Batra: Perfect. I think shared knowledge, competence, flexibility, trust, like when you are putting it out there as a framework, I’m sure there are some specific processes, there are some specific things that you are doing to ensure everything falls into place. So can you just give like one example that is most impactful in implementing each of these pieces? Like one, one thing that impacts a lot that you are practicing.

Maher Hanafi: Yeah. Yeah, that’s a good point. And again, that was one framework, but there is a very popular framework, PPT, right? Like people, process and technology. These are key factors influencing engineering productivity and you need to work on them. The one focused on people has two sub, sub parts, which are the individual of part of people, and then there’s the team. So you need to make sure for the individual factors, you work on skills and experience and growth development. You need to make sure people have the motivation, engagement, work life balance, and all of that. And for the team, you need to focus on communication, collaboration, team dynamics. So one good example is I worked at companies where there were very distributed teams, including contractors, you know, engineering teams. there are some in-house engineering, there are contractors engineering, the in-house are distributed, the contractors are distributed. When I joined this company, people were naming the other parties by the name of the contractor, like the company, like, “Oh, this part of the software is like owned by this and that part is owned by us, the in-house engineers.” Based in the West, as an example. And I was so confused because for me, an engineering team is one engineering team, even if it’s distributed, like these boundaries are just geo-based boundaries. They cannot be just also deep into the engineering process in work. So what I did is I made sure like all these kind of boundaries, you know, are removed, virtual boundaries are removed. Engineering team is aligned. They use the same framework. They use the same language. They use even at some point, the same technology stacks as much as possible by aligning on design patterns, uh, building SDKs, building shared components. And that kind of created more dynamics between these teams that got them to deliver higher productivity and higher impactful software. Because at the beginning, again, there was, like every team was delivering their own standards, their own patterns, even their own stacks. Like some part was written in Python. The other part was no, the other part is in Go. They were just serving each other and in a handoff process, like, “Oh, you want this? Here you go. You have this service build.” And he does this and you have an API. But as soon as you, as a manager, I needed to put resources in different teams and focus on one areas. When I had to manage that mobility of the engineers, they were going into new piece of software saying like, “I’m not familiar with the stack and I’m not.. Even for me, even if I’m familiar with the stack, I’m not familiar with the design patterns that are in this stack in this piece of software.” And for me, that was a challenge. So, one big part we forget about improving productivity is making sure from a technology perspective, the tools, the stack, the design patterns are aligned as much as possible. You introduce new systems like CI/CDs and observability to make sure things are moving along really quickly.

And then the, the second part of this is as you said earlier, it’s the process, like what methodology you have, what kind of channels to communicate, work, you know, how efficient is your workflow as a team and what kind of practices you have introduced to your teams. And these practices should be as aligned as possible across everyone, you know, including, you know, distributed teams to achieve higher performance and higher productivity in general. That was, again, that was one of the biggest learning I had when I, when my teams started scaling up and also going more distributed from a, from a geo-based location ensuring that it’s not just a handoff process between software engineers. It was more about alignment. And I think that that solution can scale with the scale of the problem as well.

Kovid Batra: Makes sense. Perfect. Perfect. I think with that, I would like to know some of your initiatives that you would have worked in the last year or must be planning a few more initiatives this year to actually impact your engineering productivity. Is there something that was challenging last year for you? You accomplished something out of it or are still working on that?

Maher Hanafi: Yeah. So, one of the biggest areas I focus on is this again, individual and team factors, the people side of things, right? Again, technology, we talked about this enough, in my opinion, process as well, but the people side of things could be tricky. And it takes a lot of time and experience to get to a place where you can have as a leader, as an engineering leader, you can have an impact on the people. So some of the biggest initiatives I work on is ensuring on the individual side of things, we have a continuous learning development of skills for everyone on the team, no matter what level they’re in, even if you are the most highly senior engineer principal and architect level, there’s still something for you to learn. There is a new area to discover in engineering and software and hands-on work, but also maybe in some other soft skills. So providing resources, time and, you know, availability to go and explore different areas that definitely could be driven by their own passion and that’s another framework I want to bring, which is something as a, going back to the first question, you know, the story of my childhood and all of that, I was passionate about video games and I wanted to work in that space because I think when people work on their passion, they can really break the limits of what’s possible. So that’s something I always bring to my work and I get to my team and I say, let’s work together on aligning on where you want to be next and how can we achieve that. And I never bring my own pattern of growth and maybe success and say, Oh, like I go to a Director of Engineering and say, “If you want to be a VP of Engineering, this is what you need to do based on what I did.” No, everyone is different. Every path and journey is different. And I, what I do is I work with them to define their own definition to get to their own definition of success. And I say, “What makes you successful? What makes you happy in working on things that you’re very excited about? What makes you more motivated and engaged?” So the other tool or framework I use is really collaborate with individual and teams to identify their own definition of success. And then I add to it some spices, I would say, from my own recipe and from my own experience as a leader to just kind of tweak it a little bit. But most of the time that’s what I focus on is like, “Tell me exactly where you see yourself. What’s your passion about?” And this could be completely like 180 degrees. It could be doing like a software engineering on the backend and then when I go into AI. And I help them to transition there, again, over time. And I think that’s the key. And I, I think, and I hope I was able to turn around a lot of people in, in, in getting into higher productivity and performance because of this, because I never go to someone and say, “You need to do this. To be successful, you need to follow this path.” I always try to listen and get their own definition of success and work with them through this and then say, “Okay, based on everything you said, based on your passion, based on your motivation and where you want to be and with my own tweaks, This is what we need to do. And I will do followups with you and we’ll work together to achieve that.” This is something, again, if you talk to anyone I worked with in the previous companies or better works today, this is something that resonates really well with people. They recognize as a working efficient way to get better over time. And when you achieve this on the individual level, obviously your teams in general will be impacted and you’ll create some sort of like leadership and ownership and people driving things. And everyone is pushing the boundaries of what you can do as an engineering team in general. And it has been very efficient. And for me as an engineering leader, that’s where I get my rewarding experience. This is where I feel I had an impact. And this is where I was able sometimes again, to turn around completely low performance into high performance.

Kovid Batra: But I think in this case, as much as I agree to what you’re saying really resonates and in fact, that could be true for any department, like any leader enabling team members in the direction where they are passionate about, would something, would be something that would energize the whole, whole team. But still, I feel that there is a lot of complication that gets added because at the end of the day, we are humans. We have changing desires, changing passions, and then a lot of things get complex. So while you implement this framework in an engineering team, what kind of challenges you have seen? Is there sometimes some kind of a shortage of a particular skill set in the team because a lot of people are more passionate about doing the back end and you have less front end engineers or maybe vice versa. So there could be a lot of such complications there. So any challenges that you’ve seen while implementing these things?

Maher Hanafi: Absolutely. I mean, you said there are some complications and challenges, but there’s a lot. I mean, there are a lot of complications and challenges when you work as an engineering leader. This is again, as I said earlier, some people call it the most difficult position to be in because you’re, you’re managing different things. Again, we talked about people, process and technology. We, we talked about hard and soft skills, but on the, on this side, when you’re trying to implement something like this, some of the examples I can bring up here to the conversation are the initiatives you have running, maybe some of the greatest initiatives you have happening in the engineering team, like, uh, at Betterworks, as an example, we are, we have been building generative AI, you know, enhanced features and bringing these great technologies, we have been kind of refactoring, revamping some of our technologies to build newer, better systems. And, but you still have the other old legacy systems. You have things are running in production that you need to maintain. You have incidents to manage and stuff like that. And sometimes you have, you know, resources, people, teams are watching other teams and other people doing other exciting stuff, and they are still like doing the old stuff. And as an, again, an engineering leader, your job is to make sure that there’s a good dynamic. There’s a good culture of, again, trust and shared understanding that these things are happening to everyone at the same time. It’s just that it takes a little bit more time in process and priorities to get there. So it’s part of that, again, earlier, when I talked about the own definition of success is to really know where everyone is eager to be doing as, again, an individual. And then, when you talk to the team in general, you need to see what you’d listen to their feedback and understand their point of view. So sometimes some teams will say, “Okay, well, we have been coding in this part of the software for like three or four years now, and nothing is moving too much.” Versus other teams where like every quarter, they have a new feature, they have great stuff, it’s being communicated and published. And it gets a lot of like credits and all of that. So you need to make sure you have the right process in your team to be able to rotate the projects, to rotate the excitement, to get people to, again, own and lead to experiment. So some of the initiatives we do are always you know, hackathons, you know, give people time to just do something completely different from what they do on a daily basis. So that will, you know, trigger the creativity of everyone, the passion again, and you can see where everyone’s mind is at and what they want to do. So again, it’s, it’s a little bit tricky. It’s not that easy. It’s not like, Oh, everyone will be doing this. And then six months later, you’ll be doing something more fun. But that’s where, again, your presence as an engineering leader is so important. Your vision is so important. You need to people to have your teams behind you in terms of vision and trust that it’s going to happen in that kind of way of rotation and mobility and everyone will be impacted.

So, absolutely, it’s one of these challenges you see, like people trying to get into more exciting projects while you have some support. One other thing you need to do as a leader is to ensure these kind of single point of failures and you cannot. afford to have one person or one team that is just expert, very deeply expert in one area. And it creates this environment where you are afraid of two things, these team or these individuals leaving and creating a gap in knowledge, or these people being stuck in that knowledge and cannot afford to do anything else. Even if they are passionate about it or they are bored of that, you know, they, they have been building this service for too long. They want to experiment something else, but you cannot let them go because you say you’re the only expert. So my job is ensure that knowledge transfer is happening, people getting into new systems, delegate a little bit and offer everyone option to get out and do something else that they’re excited about. It’s a dance, right? It’s a push and pull. You need to get into understanding how things work. and be involved a little bit deeper to be more effective as an engineering leader.

Kovid Batra: I think the core of it lies in that you have to be a good listener, not like exactly ‘listening’ listening, but being more empathetic and understanding of what everyone needs and the situation needs and try to accommodate every time because it’s going to be dynamic. It’s going to change. You just have to keep adjusting, keep tweaking, calibrating according to that. So it totally makes sense.

Maher Hanafi: And the funny part is, uh, the funny part is a lot of this I learned while playing video games. That’s gonna connect to the first question you asked. You know, when you play a video game, you’re a guild master of like 200–300 people. And you know, you go and do these raids and experiences and then you have loot to share. And you need to make decisions and everyone wants something. Yeah, you kind of build up some experience early on about people dynamics, about making sure how you make people happy and how you navigate conflicts in opinions. And sometimes when you have very senior people also, you have a clash of opinions. So how would you navigate that? How would you make sure they can work in an environment where everyone has a strong opinion about things? So yeah, a lot of this I learned early on in my journey before even I got into engineering, while playing video games and dealing with people, which is really great.

Kovid Batra: Cool. I think that’s on the people part. And I think that was really, really insightful. I think we should have some, instead of books, have the list of games that one should play early on in their life to be a manager.

Maher Hanafi: Yeah.

Kovid Batra: So moving on from people like you mentioned about technology, right? What happened in 2024 or you’re planning for 2025 in technology to make your teams even more efficient?

Maher Hanafi: Yeah, I would say a few things. Focus on technology. There are, I would say, three big pillars. One of them is really addressing poor designs, poor patterns in your software. We underestimate this again as, underthink about it as a problem that is impacting productivity and performance. When engineers are dealing with older legacy software that has poor designs, it takes time. It introduces more bugs. No matter how skilled they are, it’s challenging. So really as an engineering leader, you need to always make sure there’s time to recover, time to pay back technical debt, time to go back and redesign, refactor, and reinvent a little bit your software stack to get people to enjoy newer, more modern architecture that will lead to high performance and productivity. Things can happen fast when you have the right patterns that are more accurate, more modern today. Again, this is very, this is something I do on a, you know, frequent basis at Betterworks and before, one of my key areas of focus as an engineering leader is to help teams pay back technical debt, build better software so they can be more productive. The second thing is investing, I would say. Investing in tooling and platforming. I mean, we always forget about platform engineering as a pillar to software engineering in general, but being able to build the right continuous integration, continuous delivery system, CI/CD, you know, have proper observability in place to get all these logging and monitoring and alerts you need to be able to know and quickly debug and figure out things. It helps a lot and it makes sure, you know, it creates a good level of confidence of the team in terms of the quality of the code. And again, you can, it’s, it’s a lot of things are happening most recently, and this is where I’m going into a third kind of component that is impacting performance and productivity from a technical perspective is generative AI. And we have seen over the last two years now, the development of these co-pilots, the coding assistance. And it’s true. It’s not fully there. It’s not fully efficient so far, but it’s very effective to get a certain level of delegation to AI when it comes to like, as an example, writing tests for functions you have, for helping you optimize some of the code base, even migrate from a stack to another. So it’s a, it’s becoming a powerful tool capable of learning from your stack and your, your software learning over time as well, adapting, and even solving some problems and some real problems at some point. As a very good example at Betterworks today, we have a, you know, top-down approach to adopting generative AI. Everyone at the company is really encouraged and asked to leverage AI in their own areas of expertise and for engineering in particular, we ask everyone to use these co-pilots and coding assistants to leverage the new ideas coming up out there to experiment and really to bring use case and say, “Okay, I have been using this to achieve this thing.” I think there are very key areas again, PR, pull request work and improvement, writing tests and even infrastructure in the future seems like infrastructure could have a big area of impact when AI helps optimize infrastructure, not to build everything from scratch on behalf of people. I don’t think AI will replace software engineers, honestly, but it will make them better software engineers capable of achieving way more, be more productive and more performant. And I think that’s the goal.

Kovid Batra: Makes sense. I think when you said redesigning and taking up the new patterns, getting rid of the old ones, or if it’s about, let’s say, rewriting code pieces, generative AI is actually putting in as a fundamental piece everywhere, right? And there could be a lot of use cases. There are a lot of startups. There are a lot of tools out there. But according to you, while you were researching that which areas should be now on higher priority from an engineering standpoint and AI could really be leveraged, I think you would have first checked this tool has evolved in this area, and this could be a right fit to be used right now. Like you mentioned about co-pilots, right? It can write a better level of code and it can actually be integrated. We can try new IDs to ensure that we have better code, faster code in place. Are there any specific tools, I mean, if you’re comfortable sharing names or telling us, what could work better for other teams as well, other engineering leaders, other engineering teams outside, out there, uh, any examples or anything that you found very interesting?

Maher Hanafi: I mean, the number one tool is obviously GitHub Copilot. A lot of teams today are on GitHub anyway. So it’s very well embedded into the system and you know, a lot of plugins for all the IDE’s out there. So I think it’s the first one that comes to mind. Also now they released the free license tier that will help a lot of people get into it. So I think that’s the no brainer. But, uh, for me, I will go a little bit off a tangent here and say that one of the best ways to experiment with, E gen AI as a software engineer could be to run gen AI locally on your machines, which are things we can do today. And personally, even a, as, as an, an engineering leader not being very, very hands-on today. You know, I found out that something like a combination of Ollama which helps you run systems, I mean LLMs locally and open source models out there like, uh, the Llama 3 models or the Mistral models. You can have, you can have a local assistant to do a lot of things, including code assistant and writing code and refactoring and all of that. And add to, if you add to that some IDEs like cursor, now you can use your ID connected to your own LLM, that again, if you have the level of experience to maybe go and fine tune it over time and use, leverage Ollama to also include, do some rag and bring some more code and bring some documentations to think in very good examples on how you do tests as an example, it could be a very strong tool for more experienced engineers. And I think one of the biggest area Gen AI would have an impact is testing. I think testing, the testing pyramid has always been to fully automate, the ambition is to automate as much as possible. And I think with gen AI, there will be more use cases to just do that. If you leverage generative AI to write tests, I think you will have a bigger, better suite of tools to ensure that your quality of code is meeting a certain level to test for edge cases you didn’t think about when you were writing code. So I think testing is one area. The other area would be in general research, honestly, in learning as a software engineer, if you have a co-pilot or just any LLM or chat based LLM, like chatGPT or Gemini or Claude, you can go and really, you know, learn about things faster. Yes, it does a lot of things for you. Like, as an example, you can copy paste a function, say, “Hey, can you optimize this?” The key if you’re leveraging generative AI is learning. It’s not to delegate. I mean, some people might think, “Oh, I don’t have to worry about this. I’m going to write random code, but then the, uh, gen AI will optimize it for me.” The key is for you to learn from that optimization that was offered to you. And we should not forget, you know, LLMs are not perfect and you can think about them as another software engineer, maybe more experienced for sure, but an engineer who can make mistakes. So it’s your part to be really curious and critical about the outcome you get from GenAI to make sure you’re at the same time leveraging the tool to learn, to grow, and to have a bigger impact and be more productive.

Kovid Batra: Yeah, I think these are some of the hard truths about AI, uh, code assistance, but lately I’ve been following a few people on LinkedIn, and I’ve seen different opinions on how Copilot has actually helped in improving the code writing speed or in general, the quality. There is a mixed opinion. And in such situations, I think any engineering org which is implementing such technology would want to have clarity on whether it is working out for them or not, and it’s completely possible that it works out for some companies and it doesn’t for some. In your case, do you like measure specific things when you, let’s say, implement the technology or you implement a new process just to, like, improve productivity, is there something that you specifically look at while implementing those at the beginning and the end to ensure, like, okay, if this is working out or not?

Maher Hanafi: Yeah, I mean, some things are measurable. Some things are not measurable, honestly, and this is known, you know, the challenge is to measure the immeasurable to find out where this technology is having impact without having tangible metrics to measure. And you need to use proxies based on that. You need to collect feedback. You need to get some sort of an assessment of how you feel about your own productivity as an engineer using these tools. So we do that every once in a while. Again, we have a very specific internal strategy and vision that is driven by, I mean, that is focused on using and leveraging generative AI in every area of the business, and one of them is software engineering. And when we started, one of the very good use cases, again, was QA and writing tests. And we have been measuring how much time it takes, I would say, a software development in tests to write the suite of tests for a new piece of code. We try to compare both, you know, ways the old ways, which is mainly kind of manual, like let’s look at this, let’s write all the tests that are needed or define the test suite for these, and then the other way is QA, you share the QA, the concept, the requirements, the acceptance criteria, and then you expect it to generate for you the test. And we have noticed that the time that takes an engineer in a software development engineering test to get to the desired outcome is way more significant. I don’t have exact percentages or numbers, but it’s like it takes 20 percent time versus, you know, a hundred percent to just achieve the whole test suite. So for, you know, this area of like bringing generative AI, it’s good, but again, we should not forget that these tests, you know, have to be reviewed. The human should be in the loop. I don’t believe in a lot of things to be fully automated and you don’t have to worry about, and you don’t have to look back. But I also, on another end, I really believe that Gen AI will become table stakes in software engineering. The same way we had these great IDs developing over time, the same way we had autocomplete for code, the same way we had process and tools to improve our quality of code, the same way we had patterns and, you know, things, I think Gen AI will become that thing that we all use, we all have, it’s common knowledge and it’s going to be a shift in the way we work as software engineers. You know, we used to use a lot of Stack Overflow and go and search and do this and do that. All that will be replaced now in your own environment, in the work and the flow of work and you will have all the answers you need. I don’t think it will take over software engineering 100 percent and like you don’t have to write anything and you hear, and you see this in LinkedIn, as you said, you hear like, oh, this was developed. I think these are, as of today, these are naive, you know, thinking about software engineering. You know, you can build a proof of concept, you can build some basic, one single feature aspects, but as you get to build enterprise, you know, distributed systems, this doesn’t scale to that level. But the technology is evolving and GenAI is doing its best to get there, and we’re here for it. We’re here to support that, and we’re here to learn it, and use it. But again, we all go back to the same saying of like a software engineer who’s leveraging generative AI will be more productive and efficient than a software engineer who doesn’t.

Kovid Batra: Makes sense. All right. I think with that, we come to the end of this episode. I could continue talking to you. It’s super, super exciting and insightful to hear all the things that you have been doing. I think you are a really accomplished engineering leader. It is very evident from what you’re saying, what you’re doing at the organization, at your organization. It is very difficult to be in this overwhelming position. It, it, it looks like that it is very overwhelming. So any piece of advice to all the other engineering leaders who are listening to you? How to keep that sanity in place while managing this whole chaos?

Maher Hanafi: I think it’s a matter of, again, going in circles here, but it’s, it’s a passion, right? I think you need to have the level of passion to be able to navigate this role. And the passion is what keeps you pushing the boundaries in making things that are complex and hard and challenging look easy and look fun and enjoyable, right? Some parts of my work are hard and tough, but I honestly enjoy them and I go through them with a positive attitude, it’s like, “This is a tough conversation I need to have. This is it. You know, I’m going to bring my principal engineers. We’re going to talk about something. And I know everyone will have an opinion, but you know what? We need to leave this meeting with a decision.” And, you know, you need to have the passion to be able to navigate these complexities. Being someone who is very driven about solving problems, navigating people dynamics, passion about technology, obviously, and have a good mindset of getting, you know, getting to the finish line. So we, you have been asking about a lot of frameworks and other frameworks, which again, very popular one is get things done. GTD. As an engineering leader, a VP for Engineering, you need to get things done. That’s your job. So you need to be passionate about that. Get to the finish line. So it’s a lot of things here and there. I don’t recommend engineering leadership in general. For people who are very passionate about just pure technical things, people who are very passionate about coding, it’s, it’s going to be very hard for them to detach from coding and technology aspect and get into navigating these things. So when you get to this level, you focus about different things from just the perfect code that you’ll ever write, and it’s more about the perfect outcome you can get out of the resources you have and have an impact. I use this word a lot. I think engineering leaders are all about impact and all about getting the best resources or the best outcomes from the resources they have and even minimize our resources, obviously, time and money in this case. So it’s not easy. But if you have the passion, you can make things happen and you can turn these complex things into fun challenges to have and solve them and really get that rewarding experience at the end where you go, “You know what? I came here, there was a big challenge, there was a big problem, I helped the team solve it, let’s move on to the next big thing.” And I think that’s my advice to people who are looking to become engineering leaders.

Kovid Batra: Perfect. On point. All right, Maher. Thank you. Thank you so much for your time. And we would love to have you again on the episode for sure, sometime again, and talk more in depth, what you’re doing, how you’re leading the teams.

Maher Hanafi: Thank you again. Thank you so much. I really appreciate it. Thank you for having me on, on your podcast.

‍

In this episode of the groCTO Podcast, host Kovid Batra interviews David Archer, the Director of Software Engineering at Imagine Learning, with over 12 years of experience in engineering and leadership, including a tenure at Amazon.

‍

‍

The discussion centers on successfully integrating acquired teams, a critical issue following company mergers and acquisitions. David shares his approach to onboarding new team members, implementing a buddy system, and fostering a growth mindset and no-blame culture to mitigate high attrition rates. He further discusses the importance of having clear documentation, pairing sessions, and promoting collaboration across international teams. Additionally, David touches on his personal interests, emphasizing the impact of his time in Japan and his love for Formula 1 and rugby. The episode provides insights into the challenges and strategies for creating stable and cohesive engineering teams in a dynamic corporate landscape.

Timestamps

• 00:00 - Introduction

• 00:57 - Welcome to the Podcast

• 01:06 - Guest Introduction: David's Background

• 03:25 - Transitioning from Amazon to Imagine Learning

• 10:49 - Integrating Acquired Teams: Challenges and Strategies

• 14:57 - Building a No-Blame Culture

• 18:32 - Retaining Talent and Knowledge Sharing

• 24:22 - Skill Development and Cultural Alignment

• 29:10 - Conclusion and Final Thoughts

Links and Mentions

• David on LinkedIn

• Kovid on LinkedIn

• Watch this episode on Substack and Youtube

• Listen on Spotify, Amazon Music, and iTunes/Apple Podcasts

Episode Transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of groCTO podcast. And today with us, we have a very special guest. He has 12 plus years of engineering and leadership experience. He has been an ex-Software Development Manager for Amazon and currently working as Director of Engineering for Imagine Learning. Welcome to the show, David. Great to have you here.

David Archer: Thanks very much. Thanks for the introduction.

Kovid Batra: All right. Um, so there is a ritual, uh, whosoever comes to our podcast, before we get down to the main section. So for the audience, the main section, uh, today’s topic of discussion is how to integrate the acquired teams successfully, uh, which has been a burning topic in the last four years because there have been a lot of acquisitions. There have been a lot of mergers. But before we move there, uh, David, we would love to know something about you, uh, your hobbies, something from your childhood, from your teenage or your, from personal life, which LinkedIn doesn’t tell and you would like to share with us.

David Archer: Sure. Um, so in terms of my personal life, the things that I’ve enjoyed the most, um, I always used to love video games as a child. And so, one of the things that I am very proud of is that I went to go and live in Japan for university and, and that was, um, a genuinely life-changing experience. Um, and I absolutely loved my time there. And I think it’s, it’s had a bit of an effect on my time, uh, since then. But with that, um, I’m very much a fan of formula one and rugby. And so, I’ve been very happy in the last, in the post-COVID-19 years, um, of spending a lot of time over in Silverstone and Murrayfield to go and see some of those things. So, um, that’s something that most people don’t know about me, but I actually quite like my sports of all things. So, yeah.

Kovid Batra: Great. Thanks for that little, uh, cute intro and, uh, with that, I think, uh, let’s get going with the main section. Uh, so integrating, uh, your acquired team successfully has been a challenge with a lot of, uh, engineering leaders, engineering managers with whom I have talked. And, uh, you come with an immense experience, like you have had been, uh, engineering manager for OVO and then for, uh, Amazon. I mean, you have been leading teams at large organizations and then moving into Imagine Learning. So before we touch on the topic of how you absorbed such teams successfully, I would love to know, how does this transition look like? Like Amazon is a giant, right? And then you’re moving to Imagine Learning. Of course, that is also a very big company. But there is definitely a shift there. So what made you move? How was this transition? Maybe some goods or bads, if you can share without getting your job impacted.

David Archer: Yeah, no problem. Um, so once upon a time, um, you’re correct in terms of that I’ve got, you know, over 12 years experience in the industry. Um, but before that, I was a teacher. So for me, education is extremely important and I still think it’s one of the most rewarding things that as a human you can be a part of. Helping to bring the next generation, or in terms of their education, give them better, uh, capabilities and potential for the future. Um, and so when somebody approached me with the position here at Imagine Learning, um, I had to jump at the chance. It sounded extremely exciting and, um, I was correct. It was extremely exciting. There’s definitely been a lot of movement and, and I’m sure we’ll touch on that in a little while, but there is definitely a, a, quite a major cultural shift. Um, and then obviously there is the fact that Amazon being a US-centric company with a UK arm, which I was a part of, um, Imagine Learning is very similar. Um, it’s a US-centric company with a US-centric educational stance. Um, and then, yeah, me being part of the UK arm of the company means that there are some cultural challenges that Amazon has already worked through that Imagine Learning still needed to work through. Um, and so part of that challenge is, you know, sort of educating up the chain, if you like, um, on the cultural differences between the two. So, um, definitely some, some big changes. It’s less easy to sort of move sideways as you can in companies like Amazon, um, where you can transition from one team to another. Um, here, it’s a little bit more, um, put together. There’s, there’s, there’s only one or two teams here that you could potentially work for. Um, but that’s not to say that the opportunities aren’t there. And again, we’ll touch on that in a little bit, I’m sure.

Kovid Batra: Perfect. Perfect. All right. So one, one question I think, uh, all the audience would love to know, like, in a company like Amazon, what is it like to get there? Because it takes almost eight to 10 years if you’re really good at something in Amazon, spend that time and then you move into that profile of a Software Development Manager, right? So how, how was that experience for you? And what do you think it, it requires, uh, in an Engineering Manager at Amazon to be there?

David Archer: That’s a difficult question to answer because it changes upon the person. Um, I jumped straight in as a Software Development Manager. And in terms of what they’re looking for, anybody that has looked into the company will be aware of their leadership principles. And being able to display their leadership principles through previous experiences, that’s the thing that will get you in. So if you naturally have that capability to always put the customer first, to ensure that you are data-driven, to ensure that you have, they call it a bias for action, but that you move quickly is kind of what it comes down to. Um, and that you earn trust in a meaningful way. Those are some of the things that I think most managers would be looking for, and when interviewing, of course, there is a technical aspect to this. You need to be able to talk the talk, and, um, I think if you are not able to be able to reel off the information in an intrinsic manner, as in you’ve internalized how the technology works, that will get picked up. Of course it will. You can’t prepare for it like you can an exam. There is an element of this that requires experience. That being said, there are definitely some areas that people can prepare for. Um, and those are primarily in the area of ensuring that you get the experiences that meet the leadership principles that will push you into that position. In order to succeed, it requires a lot of real work. Um, I’m not going to pretend that it’s easy to work at a company like Amazon. They are well known for, um, ensuring that the staff that they have are the best and that they’re working with the best. And you have to, as a manager, ensure that the team that you’re building up can fulfill what you require them to do. If you’re not able to do that, if you’re taking people on because they seem like they might be a good fit for now, you will in the medium to long-term find that that is detrimental to you as a manager, as well as your team and its capabilities, and you need to be able to then resolve that potential problem by making some difficult decisions and having some difficult conversations with individuals, because at the end of the day, you as a manager are measured on what your team output, not what you as an individual output. And that’s a real shift in thinking from being a, even a Technical Lead to being an Engineering Manager.

Kovid Batra: That’s for sure there. One thing, uh, that you feel, uh, stands out in you, uh, that has put you in this position where you are an SDM at Amazon and then you transitioned to a leadership position now, which is Director of Engineering at Imagine Learning. So what is that, uh, one or two traits of yourself that you might have reflected upon that have made you move here, grow in the career?

David Archer: I think you have to be very flexible in your thinking. You have to have a manner of thinking that enables for a much wider scope and you have to be able to let go of an individual product. If your thinking is really focused on one team and one product and it stays in that single first party of what you’re concentrating on that moment in time, then it really limits your ability to look a little bit further beyond the scope and start to move into that strategic thinking. That’s where you start moving from a Software Development Manager into a more senior position is with that strategic thinking mindset where you’re thinking beyond the three months and beyond the single product and you’re starting to move into the half-yearly, full-yearly thinking is a minimum. And you start thinking about how you can bring your team along for a strategic vision as opposed to a tactical goal.

Kovid Batra: Got it. Perfect. All right. So with that, moving to Imagine Learning, uh, and your experience here in the last, uh, one, one and a half years, a little more than that, actually, uh, you, you have, uh, gone through the phase of your self-learning and then getting teams onboarded that were from the acquired product companies and that experience when you started sharing with me on our last, last call, I found that very interesting. So I think we can start off with that point here. Uh, like how this journey of, uh, rearranging teams, bringing different teams together started happening for you. What were the challenges? What was your roadmap in your head and your team? How will you align them? How will you make the right impact in the fastest timeframe possible? So how things shaped up around that.

David Archer: Sure. Initially, um, the biggest challenge I had was that there was a very significant knowledge drain before I had started. Um, so in the year before I came on board and it was in the first year post-acquisition, the attrition rate for the digital part of the company was somewhere in the region of 50%. Um, so people were leaving at a very fast pace. Um, I had to find a way to plug that end quickly because we couldn’t continue to have such a large knowledge drain. Um now the way that I did that was I, I believe in, in the engineers that I have in front of me. They wouldn’t be in the position that they’re in if they didn’t have a significant amount of capability. But I also wanted to ensure that they had and acquired a growth mindset. Um, and that was something that I think up until that point they were more interested in just getting work done as opposed to wanting to grow into a, a sort of more senior position or a position with more responsibility and a bigger challenge. And so I ensured that I mixed the teams together. We had, you know, front enders and back enders in separate teams initially. And so I joined them together to make sure that they held responsibility for a piece of work from beginning to end, um, which gave them autonomy on the work that they were doing. I ensured that I earner trust with that team as well. And most importantly, I put in a ‘no-blame culture’, um, because my expectation is that everybody’s always acting with the best of intentions and that usually when something is going wrong, there is a mechanism that is missing that would have resolved the issue.

Kovid Batra: But, uh, sorry to interrupt you here. Um, do you think, uh, the reasons for attrition were aligned with these factors in the team where people didn’t have autonomy, uh, there was a blame game happening? Were these the reasons or, uh, the reasons were different? I mean, if you’re comfortable sharing, cool, but otherwise, like we can just move on.

David Archer: No, yeah, I think that in reality there, there was an element of that there, there was a, um, a somewhat, not toxic necessarily culture, but definitely a culture of, um, moving fast just to get things done as opposed to trying to work in the correct manner. And that means that people then did feel blamed. They felt pressured. They felt that they had no autonomy. Every decision was made for them. And so, uh, with more senior staff, especially, you know, looking at an MNA situation where that didn’t change, they didn’t see a future in their career there because they didn’t know where they could possibly move forward into because they had no decision-making or autonomy capability themselves.

Kovid Batra: Makes sense. Got it. Yeah, please go on. Yeah.

David Archer: Sorry, yes. So, um, we’re putting these things in place, giving everybody a growth mindset mentality and ensuring that, um, you know, there was a no-blame culture. There were some changes in personnel as well. Um, I identified a couple of individuals that were detrimental to the team and those sort of things are quite difficult, you know, moving people on who, um, they’re trying their best and I don’t deny that they are, but their way of working is, is detrimental to a team. But with those changes, um, we then move from a 50% regressive attrition to a 5% regressive attrition over the course of 23 and 24, which is a very, very significant change in, um, in attrition. And, uh, we also, at that point in time, were able to start implementing new methodologies of bringing in talent from, from below. So we started partnering with Glasgow University to bring in an internship program. We also took on some of their graduates to ensure that we had, um, for once with a better phrase, new blood in the team to ensure that we’re bringing new ideas in. Um, and then we prepared people through the training programs that they should need.

Kovid Batra: I’m curious about one thing, uh, saying that stopping this culture of blame game, uh, is definitely, uh, good to hear, but what exactly did you do in practice on a daily level or on a weekly level or on every sprint level that impacted and changed this mindset? What, what were the things that you inculcated in the culture?

David Archer: So initially, um, and some people think that this might be a trite point, but, um, I actually put out the policy in front of people. I wrote it down and put it in front of people and gave them a document review session to say, “This is a no-blame culture, and this is what I mean by that.” So that people understood what my meaning was from that. Following that, um, I then did have a conversation with some of the parts of, you know, some people in other parts of the company to say, “Please, reroute your conversations through me. Don’t go directly to engineers. I want to be that, that point of contact going forward so that I can ensure that communication is felt in the right manner and the right capacity.” And then, um, the, the other thing is that we started bringing in things like, um, postmortems or incident response management, um, sessions that, that where we, I was very forceful on ensuring that no names were put into these documents because until that point, people did put other people’s names in, um, and wanted to make sure that it was noted that it was so and so’s fault. Um, and I had to step on that very, very strongly. I was like, this could have been anyone’s fault. It’s just that they happen to be at that mine of code at that point in time. Um, and made that decision, which they did with a good intention. Um, so I had to really step in with the team and every single post mortem, every major decision in that, that area, every sprint where we went through what the team had completed in terms of work and made sure we did pick out individuals in terms of particularly good work that they did, but then stepped very strongly on any hint of trying to blame someone for a problem that had happened and made it very clear to them again that this could have happened to anyone and we need to work together to ensure it can’t happen to anyone ever again.

Kovid Batra: Makes sense. So when, when this, uh, impact started happening, uh, did you see, uh, people from the previous, uh, developers, like who were already the part of Imagine Learning, those were getting retained or, uh, the ones who joined after acquisition from the other company, those developers were also getting retained? How, how did it impact the two groups and how did they like, gel up later on?

David Archer: Both actually. Yeah. So the, the staff who were already here, um, effectively the, the, the drain stopped and there weren’t people leaving anymore that had had, you know, some level of tenure longer than six months, um, at all from that point forward, and new staff that were joining, they were getting integrated with these new teams. I implemented a buddy system so that every new engineer that came in would have somebody that they could work alongside for the first six months and show that they had some, somebody to contact for the whole time that they were, um, getting used to the company. And, uh, I frequently say that as you join a company like this, you are drinking from a fire hose for the first couple of months. There’s a lot of information that comes your way. Um, and so having a buddy there helped there. Um, I added software engineering managers to the team to ensure that there were people who specifically looked after the team, continue to ensure there was a growth mindset to continue to implement the plans that I had, um, to make these teams more stable. Um, and that took a while to find the right people, I will say that. Um, there was also a challenge with integrating the teams from our vendors in, um, international, uh, countries. So we worked with some teams in India and some teams in the Ukraine. Um, and with integrating people from those teams, there was some level of separation, and I think one of the major things we started doing then was getting the people to meet in a more personal manner, bringing them across to our team to actually meet each other face-to-face, um, and realize that these are very talented individuals, just like we are. They’re, they’re no different just because they, you know, live a five and a half hour time zone away and doesn’t mean that they’re any less capable. Um, they just have a different way of working and we can absolutely work with these very talented people. And bringing them into the teams via a buddy, ensuring that they have someone to work with, making sure that the no-blame culture continued, even into our contractors, it took a while, don’t get me wrong. And there were definitely some missteps, um, but it was vital to ensuring that there was team cohesion all the way across.

Kovid Batra: Definitely. And, uh, I’ve also experienced this, uh, when talking to other, uh, engineering leaders that when teams come in, usually it is hard to find space for them to do that impactful work, right? So you, you need to give those people that space in general in the team, which you did. But also at the same time, the kind of work they are picking up, that also becomes a challenge sometimes. So was that a case in your scenario as well? And did you like find a way out there?

David Archer: It was the case here. Um, there definitely was a case of the, the work was predefined, if you like, to some extent by the, the most senior personnel. And so one of the things that we ensured that we did, uh, I worked very closely with our product team to ensure that this happened is that we brought the engineers in a lot sooner. We ensured that this wasn’t just the most senior member of the team, but instead that we worked with different personnel and de-siloing that information from one person to another was extremely important because there were silos of information within our teams. And I made it very clear that if there’s an incident and somebody needs some help, and there’s only one person on the team, um, that is capable of actually working, then, um, we’re going to find ourselves in, in a real problem. Um, and I think people understood that intrinsically because of the knowledge loss that had happened before I started, or just as I was coming on board, um, because they knew that there were people who, you know, knew this part of the code base or this database or how this part of infrastructure worked, and suddenly we didn’t have anybody that had that knowledge. So we now needed to reacquire it. And so, I ensured that the, you know, this comes from an Amazon background, so anybody that, that has worked at this company will know what I’m talking about here, but documentation is key. Ensuring document reviews was extremely important. Um, those are the kind of things, ensuring that we could pass on information from one person to another from one team to another in the most scalable fashion, it does slow you down in delivery, but it speeds you up in the longer term because it enables more people to do a wider range of work without needing to rely on that one person that knows everything.

Kovid Batra: Sure, definitely. I think documentation has been like always on the top of, uh, the priority list itself now whomsoever I’m talking to, because once there are downturns and you face such problems, you realize the importance of it. In the early phase, you are just running, building, not focusing on that piece, but later on, it becomes a matter of priority for sure. And I can totally relate to it. Um, so talking about these people, uh, who have joined in and you’re trying to integrate, uh, they definitely need some level of cultural alignment also, like they are coming from a different background, coming into a new company. Along with that, there might be requirements, you mentioned like skill development, right? So were there any skill development plans that worked out, that worked out here that you implemented? Anything from that end you want to share?

David Archer: Yeah, absolutely. So with joining together our teams of frontend and backend developers, um, that’s obviously going to cause some issues. So some developers are not going to be quite as excited about working in a different area. Um, but I think with knowing that the siloing of information was there and that we had to resolve that as an issue and then ensuring that people who are being brought on via, you know, vendors from international countries and things like that, um, what we started to do was to ensure that we put in, um, pairing sessions with all of our developers. Up until that point, they kind of worked on their own and so, um, I find that working one-to-one with another individual tends to be the fastest way to learn how the things work, work in the same way as, um, a child learns their language from their parents far faster than they ever would from watching TV. Um, although sometimes I do wonder about that myself with my daughter singing baby shark to me 16 times and I don’t think I’ve ever sung that. So let’s see where that goes. Um, but having that one-to-one, um, relationship with the person means that we’re able to ask questions, we’re able to gain that knowledge very quickly. Having the documentation backing that up means that you’ve got a frame of reference to keep going to as well. And then if you keep doing that quite frequently and add in some of the more abstract knowledge sharing sessions, I’m thinking like, um, a ‘launch and learn’ type sessions or lightning talks, as well as having a, a base of, sort of a knowledge base that people can learn from. So, obvious examples of things like Pluralsight or O’Reilly’s library. Um, But we also have our own internal documentation as well where we give people tutorials, we walk people through things, we added in a code review session, we added in a code of the sprint and a session as well for our um, sprint reviews that went out to the whole team and to the rest of the company where we showed that we’re optimizing where we can. And all these things, they didn’t just enable the team to, to become full stack and I will say all of our developers now are full stack. I’d be very surprised if there are any developers I’m working with that are not able to make a switch. But it also built trust with the rest of the company as well and that’s the thing with being a company that has been acquired is that we need to, um, very quickly and very deliberately shout about how well we’re doing as a company so that they can look at what we’re doing and use us, as has frequently been the case recently actually as a best practice, a company that’s doing things well and doing things meaningfully and has that growth mindset. And we start then to have conversations with the wider company, which enables things like a tiger team type session that enables us to widen our scope and have more same company. It’s kind of a spiral at that point in time because you start to increase your scope and with doing that, it means that your team can grow because you know, that they know that thing, that they can trust us to do things effectively. And it also gives, going back to what I said at the beginning, and people more autonomy, then more decision-making capabilities they need to get further out into a company.

Kovid Batra: And in such situations, the opinions that they’re bringing in are more customer-centric. They have more understanding of the business. All those things ultimately add up to a lot of intrinsic incentivization, I would say. That if I’m being heard in the team, being a developer, I feel good about it, right? And all of this is like connected there. So I, it totally makes sense. And I think that’s a very good hack to bringing new, uh, people, new teams into the same, uh, journey where you are already continuing. So, great. I think, uh, with that, we have, uh, come to, uh, the end of this discussion. And in the interest of time, we’ll have to pause here. Uh, really loved talking to you, would love to know more such experiences from you, but it will be in the, maybe in the next episodes. So, David, once again, thanks a lot for your time. Thanks for sharing your experiences. It was great to have you here.

David Archer: Thank you so much and I really appreciate, uh, the time that you’ve taken with me. I hope that this proves useful to at least one person and they can gain something from this. So, thank you.

Kovid Batra: I’m sure it will be. Thank you. Thank you so much. Have a great day ahead.

David Archer: Thank you. Cheers now!

In the first session of the ‘Unlocking Engineering Productivity’ webinar series, host Kovid Batra from Typo welcomes two prominent engineering leaders: Paulo André, CTO of Resquared, and Denis Čahuk, a technical coach and TDD/DDD expert.

‍

‍

They discuss the importance of engineering productivity and share insights about their journeys. Paulo emphasizes the significance of collaboration in software development and the pitfalls of focusing solely on individual productivity metrics. Denis highlights the value of consistent improvement and reliability over individual velocity. Both guests underline the importance of creating clarity and making work visible within teams to enhance productivity. Audience questions address topics such as balancing technical debt with innovation and integrating new tools without disrupting workflows. Overall, the session offers practical strategies for engineering leaders to build effective and cohesive teams.

Timestamps

• 00:00 — Introduction

• 00:52 — Meet the Experts: Paulo and Denis

• 03:13 — Childhood Stories that Shaped Careers

• 05:37 — Defining Engineering Productivity

• 11:18 — Why Focus on Engineering Productivity Now?

• 15:47 — When and How to Measure Productivity

• 22:00 — Team vs. Individual Productivity

• 35:35 — Real-World Examples and Insights

• 37:17 — Addressing Common Engineering Challenges

• 38:34 — The Importance of Team Reliability

• 40:32 — Planning and Execution Strategies

• 45:31 — Creating Clarity and Competence

• 53:24 — Audience Q&A: Balancing Technical Debt and Innovation

• 57:02 — Audience Q&A: Overlooked Metrics and Security

• 01:02:49 — Audience Q&A: Integrating New Tools and Frameworks

• 01:08:47 — Final Thoughts and Farewell

Links and Mentions

• Paulo André on Linkedin

• Denis Čahuk on Linkedin

• Kovid Batra on Linkedin

• Watch this webinar on YouTube and Substack

• Listen on Spotify, Amazon Music, and iTunes/Apple Podcasts

Transcript

Kovid Batra: All right. Time to get started. Uh, welcome everyone. Welcome to the first episode, first session of our new, all new webinar series, Unlocking Engineering Productivity. So after the success of our previous webinar The Hows and Whats of DORA, we are even more excited to bring you this webinar series which is totally designed to help the engineering leaders become better, learn more and build successful, impactful dev teams. And today with us, uh, we have two passionate engineering leaders. Uh, I have known them for a while now. They have been super helpful, all the time up for helping us out. So let me start with the introduction. Uh, Paulo, Paulo André, uh, CTO of Resquared, a YC-backed startup. He has been the, he has been ex-engineering leadership coach for Hotjar, and he has, he’s an author of the Hagakure newsletter. So welcome to, welcome to the unlocking, uh, engineering productivity webinar, Paulo.

Paulo André: Thanks for having me. It’s a real pleasure to be here.

Kovid Batra: Great. Uh, then we have Denis. Uh, he’s coming to this for the second time. And, uh, Denis is a tech leadership coach, TDD expert, and author of Crafting Tech Teams. And he’s also a guitar player, a professional gamer. Uh, hi, hi, Denis. Welcome, welcome to the episode.

Denis Čahuk: Hi, thanks for inviting me again. Always a pleasure. And Hey, Paulo, it’s our first time meeting on stage.

Paulo André: Good to meet you, Denis.

Kovid Batra: I think I missed mentioning one thing about Paulo. Like, uh, he is like a very, uh, he’s an avid book reader and a coffee lover, just like me. So on that note, Paulo, uh, which book you’re reading these days?

Paulo André: Oh, that’s a good question. Let, let me pull up my, because I’m always reading a bunch of them at the same time, sort of. So right now, I’m very interested, I wonder why in, you know, geopolitical topics. So I’m reading a lot about, you know, superpowers and how this has played out, uh, in history. I’m also reading a fiction book from an author called David Baldacci. It’s this series that I recommend everyone who likes to read thrillers and stuff like that. It’s called the 6:20 Man. So.

Kovid Batra: Great.

Paulo André: That’s what I’m reading right now.

Kovid Batra: So what’s going to be the next superpower then? Is it, is it, is it China, Russia coming in together or it’s the USA?

Paulo André: I’ll tell you offline. I’ll tell you offline.

Kovid Batra: All right. All right. Let’s get started then. Um, I think before actually we move on to the main section, uh, there is one ritual that we have to follow every time so that our audience gets to know you a little more. Uh, this is my favorite question. So I think I’ll, I’ll start with Paulo, you once again. Uh, you have to tell us something from your childhood or from teenage, uh, that defines you, who you are today. So over to you.

Paulo André: I mean, you already talked about the books. I think the reason why I became such a book lover was because there were a ton of books in my house, even though my parents were not readers. So I don’t know, it was more decorative. But I think more importantly for this conversation, I think the one thing about my childhood was when they gifted me a computer when I was six years old. We’re talking about 88, 89 of the type that you still connected to your big TV in the living room. So that changed my life because it came with an instruction manual that had code listings. Then you could type it in and you can see what happens on the screen and the rest is history. So I think that was definitely the most consequential thing that happened in my childhood when you consider how my life and career has played out.

Kovid Batra: Definitely. Cool. Um, Denis, I think the same question to you, man. Uh, what, what has been that childhood teenage memory that has been defining you today?

Denis Čahuk: Oh, you’re putting me on the spot here. I’ll have to come up with a new story every time I join a new webinar. Uh, no, no, I had a similar experience as Paulo. Um, I have an older brother and our household got our first computer when I was five-six years old, first commodore 64. So I learned how to code before I could read. Uh, I knew, I knew what keys to press so I could load Donald Duck into the, into the TV. Um, yeah, other than that when I, when I got a little bit, you know into the teenage years, I, um, World of Warcraft and playing games online became my passion project when I, when I received access to the internet. Um, so that’s, you know, I played World of Warcraft professionally, semi-professionally for quite a few years, like almost an entire decade, you know, and that, that was sort of parallel with my, with my sort of tech career, because we’re usually doing it in a very large organization, game-wise. Yeah. And that, that, that had a huge influence because it gave me an outlet for my competitiveness.

Kovid Batra: That’s interesting. All right, guys. Thanks. Thanks for sharing this with us. Uh, I think we’ll now move on to the main section and discuss something around which our audience would love to learn from you both. Uh, so let’s, let’s start with the first basic fundamental definition of what productivity, what dev productivity or engineering productivity looks like to you. So Paulo, would you like to take this first? Like, how do you define productivity?

Paulo André: So you start with a very small question, right? Um, you actually start with a million-dollar question. What is productivity? I’m happy to take a stab at it, but I think it’s one of those things that everyone has their own definition. For what it’s worth, when I think about productivity of engineering teams, I cannot decouple it from the purpose of an engineering team. And then ultimately, the way I see it is that an engineering team serves a business and serves the users of that business in case it’s a product company, obviously, um, but any, any kind of company kind of has that as the delivery of value, right? So with that in mind, is this team doing their part in the delivery of value, whatever value is for that business and for those users, right? And so having that sort of frame in mind, I also break it down in my mind, at least, in terms of like winning right now and increasing our capacity to win in the future. So a productive team is not just a team that delivers today, but it’s also a team that is getting better and better at delivering tomorrow, right? And so productivity would be, are we doing what it takes to deliver that value regardless of the output? Um, it is necessary to have output to have results and outcomes, but at the end of the day, how are we contributing to the outcomes rather than to the, um, the just purely to the outputs? And the reason why I bring this up has to do obviously with sometimes you see the obsession about things like story points and you know, all of that stuff that ultimately you can be working a lot, but achieving very little or nothing at all. So, yeah, I would never decouple, um, the delivery of value from how well an engineering team is doing.

Kovid Batra: Perfect. I think very well framed here and the perspective makes a lot of sense. Um, by the way, uh, audience, uh, while we are talking, discussing this EP, please feel free to shoot out all the questions that you have in the comments section. We’ll definitely be taking them at the end of the session. Uh, but it would be great if you could just throw in questions right now. Well, this was an advice from Denis, so I wouldn’t want to forget this. Okay. Uh, I think coming back, Denis, what’s your take on, uh, productivity, engineering productivity, dev productivity?

Denis Čahuk: Well, aPauloal said, that’s a million dollar question. I think, I think coming from a, from like a more analytical perspective, more data-driven perspective, I think we like to use the, the financial analogies, metaphors a lot for things like technical debt and, you know, good story points. It’s all about estimating something, you know, value of something or, or scale of something, scope of something. I think just using two metaphors is very useful for productivity. One is, you know, how risky is the team itself? And risk can come from many different places. It can be their methodologies, their personalities, the age of the company, the maturity of the company. The project can be risky. The timing on the market can be risky, right? So, but there is an inherent risk coming from the team itself. That’s, that’s what I mean. So how risky is it to work with this team in particular? Uh, and the other thing is to what degree does the team reason about, um, “I will produce this output for this outcome.” versus “I need to fill my schedule with activity because this input is demanded of me.” Right? So if I, if I use the four pillars that you probably know from business model canvases for activity, input, output, outcome, um, a productive team would not be measuring productivity per se. They will be more aligned with their business, aligned with their product and focusing on what, which of their outputs can provide what kind of outcomes for the business, right? So it’s not so much about measuring it or discussing it. It’s more about a, you know, are we shifting our mentality far enough into the things that matter, or are we chasing our own tail, essentially, um, protecting our calendars and making sure we didn’t over-promise or under-promise, etc.?

Kovid Batra: Got it. Makes sense.

Paulo André: Can I just add one, one last thing here, because Denis got my, my brain kinda going? Um, just to make the point that I think the industry spends a lot of time thinking about what is productivity and trying to define productivity. I think there is value in really getting clear about what productivity is not. And so I think what both Denis and I are definitely aligned on among other things is that it’s not output. That’s not what productivity is in isolation. So output is necessary, but it is not sufficient. And unfortunately, a lot of these conversations end up being purely about output because it’s easy to measure and because it’s easy to measure, that’s where we stop. And so we need to do the homework and measure what’s hard as well, so we can get to the real insight.

Kovid Batra: No, totally makes sense. I think I relate to this because when I talk to so many engineering leaders and almost all the time this, this comes into discussion, like how exactly they should be doing it. But what, what is becoming more interesting for me is that this million dollar question has suddenly started raising concerns, right? I mean, almost everywhere in like in business, uh, people are measuring productivity in some or the other way, right? But somehow engineering teams have suddenly come into the focus. So this, this perspective of bringing more focus now, why do you think it has come into the picture now?

Paulo André: Is that for me or Denis? Who should go first?

Kovid Batra: Anyone. Maybe Paulo, you can go ahead. No problem.

Paulo André: Okay. So, look. In, in my opinion, I think I was thinking a little bit about this. I think it’s a good question. And I think there’s at least three things, three main things that are kind of conspiring for this renewed focus or double down on engineering productivity specifically. I think on the one hand, it’s what I already mentioned, right? It’s easier to measure engineering than anything else. Um, at least in the product design and engineering world, of course, sales are very easy to measure. Did you close or not? And that sort of thing. But when it comes to product design and engineering, engineering, especially if you focus on outputs is so much easier to measure. And then someone gets a good sense of ROI from that, which may or may not be accurate. But I think that’s one of the things. The other thing is that when times get more lean or things get more difficult and funding kind of dries up, um, then, of course, you need to tighten the belt and where are you going to tighten the belt? And at the end of the day, I always say this to my teams, like, engineering is not more special in any way than any other team in a company. That being said, when it comes to a software company, the engineering team is where the rubber meets the road. In other words, you do absolutely need some degree of engineering team or engineering capacity to translate ideas and designs and so on into actual software. So it’s very easy to kind of just look at it as in, “Oh, engineers are absolutely critical. Everything else, maybe are nice to have.” Or something of that, to that effect, right? And then lastly, I think the so-called Elon Musk effect definitely is a thing. I mean, when someone with that prominence and with, you know, the soapbox that he has, comes in and says, you know, we’re going to focus on engineers and it’s about builders and even Mark Andreessen wrote an article like three years ago or so saying it’s time to build, all of that speaks like engineering, engineering, engineering. Um, and so when you put that all together and how influencible all of us are, but I think especially then founders and CEOs are kind of really attuned to their industry and to investors and so on, and I think there’s this, um, feedback loop where engineering is where it’s at right now, especially the age of AI and so on. So yeah, i’m not surprised that when you put this all together in this day and age, we have what we have in terms of engineering being like the holy grail and the focus.

Kovid Batra: Uh, Denis, you, you have something to add on this?

Denis Čahuk: I mean, when it comes to the timing, I don’t think anything comes to mind, you know, why now? What I can definitely say is that engineering of everything that’s going on is the biggest cost in a, in a large company. I mean, it’s not, not to say that it’s all about salaries or operational expenses, but it is also from a business’s perspective, engineering is, you know, if I put a price to the business being wrong on an experiment, the engineering side of things, the product engineering side of things defines most of that cost, right? So when it comes to experiments, the likelihood of it succeeding or not succeeding, or the how fast you gain feedback to be able to, you know, to, to think of experiment feedback as cashflow, you know, you want the big bet that you do once every three months, or do you want to do a bunch of small bets continuously several times per day? You know, all of that is decided and all of that happens in engineering and it also happens to be the biggest fiscal costs. So it makes sense that, hey, there’s an, you know, there’s a big thing that costs a lot, that is very complex and it’s defining the company. Yeah, of course, business owners would want to measure it. It will be irresponsible not to. It doesn’t mean that it, that productivity from a team’s or an engineer’s, an individual’s perspective is the most sensible thing to measure. But I, you know, I understand the people that would intuitively come to that conclusion.

Kovid Batra: Yeah. I think that makes a lot of sense. And what do you think, like, this should be done that, that is totally, uh, understandable, but when is the right time to start doing this and how one should start it? Because every time our engineering leader is held accountable for a team, whether big or small, there is a point where you have to decide your priorities and think about things that you are going to do, right? So how and when should an engineering leader or an engineering manager for a team should start taking up this journey?

Paulo André: I think Denis can go first on this one.

Denis Čahuk: Well, I would never, you know, I would never start measuring. So I coach teams professionally, you know, they, they reach out to me because something about my communication on LinkedIn or newsletter resonated with them regarding, you know, a very no-nonsense way of how to deal with customers, how to communicate, how to plan, how to not plan, how to, how to bring, you know, that excitement into engineering, that makes engineering very hyperproductive and fun. And then they come to me and ask, well, you know, “I want to measure all these things to see what I can do.” I think that context is always misleading. You know, we don’t just go in, you know, it’s not a speedometer like the, I think the very, very first intuition that people still have from the 90s, from the, from the, like the initial scrum and Kanban, um, modes of thought that, “Oh, I can just put up speedometer on the team and it will have a velocity and it, you know, it will just be a number.” Um, I think that is naive. That is not what measuring is. And that is not the right time ever to measure that. Like that I think is my say. Um, the right time to measure is when you say, “I am improving A or B. I am consciously trying to figure out continuously, consciously trying to figure out what will make my teams better.” So a leader might approach, “Okay. If I introduce this initiative, how can I tell if things are better?” And then you can say, “Well, I’ll eyeball it or I’ll survey the team.” And at a certain point, the eyeballing is too inaccurate or it requires too many disagreeing eyeballs, or, um, you run the risk of a survey fatiguing the team, so it’s just way too many surveys asking boring questions, and when you ask engineers to do repetitive, boring things, they will start giving you nonsense answers, right? So that would be the point where I think measuring makes sense, right? Where you basically take a little bit of subjective opinion out, with the exception of surveys, qualitative surveys, and you introduce a machine that says, “Hey, this is a process.” You know, it’s one computer talking to the other computer, you know, in the case of GitHub and similar, which seems to be the primary vector for measurement. Um, can I just extract some metrics of, you know, what are the characteristics of the machine? It doesn’t tell you how fast or how slow it’s going. Just what are the characteristics? Maybe I can get some insights too and decide whether this was a good idea or a bad idea, or if we’re missing something. But the decision to help your teams improve on some initiative and introducing the initiative comes first. And then you measure if you have no other alternative or if the alternatives are way too fuzzy.

Kovid Batra: Makes sense. Paulo, would you like to add something?

Paulo André: Yeah, I mean, I think my, my perspective on this is not very different from, from Denis. Uh, maybe it comes from a slightly different angle and I’ll explain what I mean. So, at the end of the day, if you want to create an outcome, right? And you want to change customer behavior, you want to create results for the business, you’re going to have to build something. And where I would not start is with the metrics, right? So you asked Kovid, like where, where do we start in this journey? I would say do not start with the metrics because in my mind, the metrics are a source of insight or answers to a set of questions. And so start with the questions, right? Start with the challenges that we, that you have to get to where you want to be, right? And so, coming back to what I was saying, if you want to create value, you’re going to have to build something, typically, most of the time, sometimes it creates value by removing something, but in general, you are building and iterating on your products. And, and so with that in mind, what is going back to first principles? What is the nature of software development? Well, it’s a collaborative effort. Nobody does everything end-to-end by themselves. And so with that in mind, there’s going to be handoffs. There’s going to be collaboration. There’s going to be all, all of that sort of flow, right? Where, where the work goes through a certain, you can see it as a pipeline. And so then when it comes to productivity, to me is, is, you know, from a lean software development perspective is how do we increase the flow? If you think of a Kanban board, how do you go, you know, in a smooth way, as smooth as possible from left to right, from something being ready for development to being shipped in production and creating value for the user and for the company? And so if you see it that way with that mental model, then it becomes like, where is the constraint? What is the bottleneck? And then how do we measure that? How do we get the answers is by measuring. And so when it comes to the DORA metrics that you guys obviously with Typo provide, um, you know, a good, good insight into, and, and other such things, generally cycle time, lead time really allows us to start understanding where’s this getting stuck. And that leads to then conversations around what can we do about that? And ultimately everybody can rally around the idea of how do we increase flow? And so that’s where I would start is what are we trying to do? What is getting in our way? And then let’s look at the data that we have available without going too crazy about that into like, what can we learn and where can we improve and where’s the biggest leverage?

Kovid Batra: Makes sense. I think one, one good point that you brought here is that software development is a collaborative effort, right? And every time when we go about doing that, there are people, there are teams, uh, there are processes, right? Uh, how, how would you define in a situation that whether you should go about measuring, uh, at an individual-level productivity, a developer-level productivity, and, uh, and then when, when we are talking about this collaborative effort, the engineering productivity? So how do you differentiate and how do you make sure that you are measuring things right? And sometimes the terminologies also bring in a lot of confusion. Uh, like, I would never perceive developer productivity to be something, uh, specific to developers. It ultimately boils down to the team. So I would want to hear both of you on this point, like how, how do you differentiate or what’s your perspective on that? When you talk to your team that, okay, this is what we are going to measure, uh, your teams are not taken aback by that, and there is a smooth transition of thought, goals when we are talking about improving the productivity. Uh, Paulo, maybe you could answer that.

Paulo André: I was trying to unmute myself. I was actually gonna.. Um, and then it feels free to kind of like interject at any point with your thinking as well. You know, if I follow up on what I was just saying that this is a team sport, then the unit of value is going to be the team. Are there individual productivity metrics? Yes. Are they insightful? Yes, they can be. But for what end? What can you actually infer from them? What can you learn from them? Personally, as an engineering leader, the way I look at individual productivity metrics is more like a smoke alarm. So, for example, if someone is not pushing code for long periods of time, that’s a question. Like, what’s going on? There might be some very good reasons for that, or maybe this person is struggling and so I’m glad that I saw that in the, in the metrics, right? And then we can have a conversation around it. Again, the individual is necessary, but it’s not sufficient to deliver value. And so I need to focus on the team-level productivity metrics, right? Um, so that’s, that’s kind of like how I disambiguate, if you will, this, these two, like the individual and the team, the team comes first. I look at the individual to understand to what degree is the individual or the individuals serving the team, because it comes back to also questions, obviously, of performance and, and performance reviews and compensation and promotions, like all of that stuff, right? Um, but do I look at the metrics to decide on that? Personally, I don’t. What I do look at is what can I see in the metrics in terms of what this person’s contribution to the team is and for the team to be able to be successful and productive.

Kovid Batra: Got it. Denis, uh, you have something to add here?

Denis Čahuk: It’s, it’s such an interesting topic that sort of has nuances from many different perspectives that my brain just wants to talk about all three at the same time. So I want to sort of approach every, like, do a quick dip into all three areas. First is the business side, right? So, uh, for example, let’s take a, let’s take the examples of baseball and soccer. Um, off, when off season comes for baseball. Baseball is more of an individual sport than soccer, you know, like the individual performance stands out way more than in soccer when everything’s moving all the time. Um, it’s, it’s very difficult to individuate performance in soccer, although you still can and people still do and it’s still very sexy. Um, when it’s off season, people want to decide, okay, which players do we keep? Which players do we trade? Which players do we replace? You know, this is completely normal, and you would want to do this, and you would want to have some kind of metrics, ideally, merit-based metrics of, yeah, this person performed better. Having this person on the team makes the team better. In baseball, this makes perfect sense. In soccer, not so much, but you still have to decide, well, how much do we pay each player? And you can probably tell if you’re following the scene that every soccer player is being, you know, their salary, their, their, um, their contracts are priced individually based on their value to the brand of the team, all the way to public relations, marketing, and yes, performance on, on the field. Even if they’re on the bench all the time, you know, they might have a positive effect on the team as a coach or as a mentor, as a captain. Um, so if you did bring that into that, that’s one aspect. So now bringing it back into software teams, that’s the business side of things. Yes, these decisions have to be made.

Then there’s the other side of things, which is how does the team work? You know, from my perspective, if output or outcomes can be traced back to one individual person, I think there’s something wrong. I think there’s a lot of sort of value left on the table if you can say, “Oh, this thing was done by this one person.” Generally, it’s a team effort and the more complex the problems get, the harder it is, you know, look, look, for example, NASA, um, the Apollo missions. Which one engineer, you know, made the rocket fly? You don’t have an answer to that because it was thousands of people collaborating together. You know, which one person made a movie? Yes, the director or the producer or the main actor, like they are, they stand out when it comes to branding. But there were tens of thousands of people involved, right? So like to, you know, at the end of the day, what matters is the box office. So I think that that’s what it really comes down to, uh, is that yes, generally there will be like a few stars and some smoke alarms, as Paulo mentioned, I really liked that analogy, right? So you’re sort of checking for, hey, is anybody below standard and does anybody sort of stand out? Usually in branding and communication, not in technical skill. Um, and then try to reason about the team as a whole.

And then there’s the third aspect, which is how productive does the individual feel? You know, how productive, if somebody says they’re a senior with seven years of experience, how productive they, do they feel? Do they get to do everything they wanted to in a day? You know, and then keep going up. Does the product owner feel productive or efficient? Or does the leader feel that they’re supporting their teams enough, right? So it also comes down to perception. We saw this recently with the usages and various surveys regarding AI usage and coding assistance, where developers say, “Yeah, it makes me feel amazing because I feel more productive.” But in reality, the outcomes that it produces didn’t change, or it was so insignificant that it was very difficult to measure.

So with those three sort of three angles to consider, I would say, you know, the way to approach measuring and particularly this individual versus team performance, is that it’s a moving target. You sort of need to have a plan for why you’re measuring and what you’re measuring and ideally, once you know that you’re measuring the right things when it comes to the business, it’ll be very difficult, um, to trace it back to an individual. If tracing it back to an individual is very easy, or if that’s an outcome that you’re pursuing, I would say there’s other issues or potential improvements afoot. And again, measuring those might show you that measuring them is a wrong, is a bad idea.

Paulo André: Can I just add one, one quick thing again? Like, this is something that took me a little while to understand for myself and to become intuitive, which is not intuitive at all. Um, but I think it’s an important pitfall to kind of highlight, which is if we incentivize individual behaviors, individual productivity, that can really backfire on the team. And again, I remind you that the team is the unit of value. And so if we incentivize throughput or output from individual developers, how does that hurt the team? It doesn’t sound very intuitive, but if you think about, for example, a very prolific developer that is constantly just taking on more tickets and creating more pull requests, and those pull requests are just piling up because there’s no capacity in the team to review them, the customer is not getting any value on the other side. That work in progress is just in lean terminology. It’s just waste at that point, right? But that developer can be regarded depending on how you look at it as a very productive developer, but is it? Or could it be that that developer could be testing something? Or could it be that that developer is helping doing code reviews and so on and so forth, right? So again, the team and individual productivity can lead to wildly different results. And sometimes you have teams that are very unproductive despite having very productive developers in them, but they are looking at the wrong, sort of, in my opinion, wrong definition of what productivity is and where it comes from, and what the unit of value is, like I said, it’s the team.

Kovid Batra: Yeah.

Denis Čahuk: Can I jump in quickly, Kovid?

Kovid Batra: Yeah.

Denis Čahuk: There’s something I’ve always said. Um, it’s very unintuitive, and I can give you a complete example from coaching, that it throws leaders off-guard every time I suggest it, and it ends up being a very positive outcome. I always ask them, you know, “What are you using to assign tickets? Are you assigning them?” And they say, “Yes, we use Jira.” Or something equivalent. And I tell them, And I ask them, “Well, have you considered not assigning the tickets?” Right? And, well, who should own it? And I say, “Well, it’s in the team’s backlog. The team owns it. Stop assigning an individual.” Right? And they’re like, and they’re usually taken aback. It’s like, “What do you mean? Like, it won’t get done if I don’t assign it.” No, it’s in the team’s backlog, of course it’ll get done. Right? And if not, if they can’t decide who will do it, then that’s a conversation they should have, and then keep it unassigned. Or, alternatively, use some kind of software that allows multiple people to be assigned. But you don’t need to, because the moment you start, you know, Jira, for example, had like a full activity log, so I comment on it, you comment on it, you review, I review, we merge, I merge, I ask a question. You have a full paper trail of everybody who was involved. Why would you need an owner, right? So this idea of an owner is, again, going back to lean activities and talking about handoffs, right? So I hand it off to you, you’re now the owner, and you’ll hand it off to somebody else. Well, and, but having many handoffs is an anti-pattern in itself, usually in most contexts. Actually the better idea would be, how can we have less people than we have? How can we have less handoffs then we have people? If there are seven people in the pipeline, there shouldn’t be seven handoffs, you know, how can we have just one deliverable, just one thing to assign and seven people working on it? That would be the best sort of positive outcome because then you don’t cap, you know, how much money you can put around a problem because that allows you to sort of scale your efforts in intensity, not just in parallelism. Um, and usually that parallelism comes at a very, very steep cost.

Paulo André: Yeah.

Denis Čahuk: Um, so incentivizing methods to make individual work activity untraceable can unintuitively have, and usually does, drastic and immediate positive, positive benefits for the team. Also, if the team is lacking in psychological safety, this will make it immediately sort of washed over them and they’ll have to have some like really rough conversations in the first week and then things drastically start improving. At least that’s my experience.

Paulo André: Yeah. And the handoff piece is a very interesting one. I’ll be very quick, uh, Kovid. When we think about the perspective of a piece of work, a work package, a ticket or whatever, it’s either being actively worked on or it’s waiting for someone to do something about it, right? And if we measure these things, what we, what we realize, and it’s the same thing if you go to the airport and we think about how often, how much time are we actually spending on something like checking in or boarding the plane versus waiting at some of the stages, the waiting time is typically way more than the active time. And so that waiting time is waste as well. That’s an opportunity. Those delays, we can think about how can we reduce those and the more handoffs we have in the process, the more opportunity for delay creeps in, right? So it’s, it’s a very different way of looking at things. But sometimes when I say estimates and so on, estimates is all about like active time. It’s how long it’s going to take, but we don’t realize that nothing is done individually, and because of the handoffs, you cannot possibly predict the waiting times. So the best that you can do is to reduce the handoffs, so you have less opportunity for those delays to creep in.

Kovid Batra: Totally. I think to summarize both of your points, I would have understood is that making those smoke alarms ready at individual level and at process level also ready so that you are able to understand those gaps if there is something falling apart. But at the end of the day, if you’re measuring productivity for a team, it has to be a collaborative team-level thing that you’re looking at and looking at value delivery. So I think it’s a very interesting thing. Uh, I think there’s a lot of learning for us when we are working at Typo that we need to think more on the angle of how we bring in those pointers, those metrics which work as those smoke alarms, rather than just looking at individual efficiency or productivity and defining that for somebody. Uh, I think that, that makes a lot of sense. All right. I think we are into a very interesting conversation and I would like to ask one of you to tell us something from your experience. So let’s start with you, Denis. Um, like you have been coaching a lot of teams, right? And, uh, there, there are instances where you deal with large-scale teams, small teams, startups, right? There are different combinations. Anything that you feel is an interesting experience to share here about how a team approached solving a particular problem or a bottleneck in their team that was slowing them down, basically like not having the right impact that they wanted to, and what did they do about it? And then how, how they arrived to the goal that they were looking at?

Denis Čahuk: Well, I can, I can list many. I’ll, I’ll focus on two. One is, generally the team knows what’s the problem. Generally, the team knows already, hey, yeah, we don’t have enough tests, or, ah, yeah, we keep missing deadlines, or our relationship with stakeholders is very bad, and they just communicate with us through, you know, strict roadmaps and strict deadlines and strict expectations. Um, that’s a problem to be solved. That’s not, you know, it doesn’t have to be that way. So if you know what the problem is, there’s no point measuring, because there’s no, there’s no further insight to be gained that, yeah, this is a problem, but hey, let’s get distracted with this insight. No, like, you know what the problem is, you can just decide what to do, and then if you need help along the way, maybe measurements would help. Or maybe measurements on an organizational level would help, not, not just engineering. Um, or you bring on a coach to sort of help you, you know, gain clarity. That’s one aspect. If you know what the problem is, you don’t need to measure. Usually people ask me, Denis, what should I measure? Should I introduce DORA metrics? And I usually tell them, Oh, what’s the main problem? What’s the problem this week? Oh yeah, a lot of PRs are waiting around and we’re not writing enough tests. Okay, that’s actionable. Like, that’s enough. Like, do you want more? Like, but do you need a bigger problem? Because then you just, you know, spend a lot of time looking for a problem that you wish was bigger than that so that you wouldn’t have to, right, because that’s just resistance that just either your ego or trying to play it safe or trying to put it into the next quarter when maybe there’s less stress and right, there isn’t. That’s one aspect.

The other aspect, you know, this idea of.. How did you phrase it? An approach that works that aren’t generally approaches that work. You know, I always say that everything we do is nowadays basically a proxy to eliminating handoffs, right? Getting the engineers very close to the customer and, um, you know, getting closer to continuous delivery. Continuous integration at the very minimum, but continuous delivery, right? So that when software is ready, it’s releasable on demand, and there isn’t like this long waiting that Paolo mentioned earlier, right? Like this is just a general form of waste. Um, but potentially something that both of these cases handle unintuitively that I like to bring in as a sort of more qualitative metric is, um, the reliability of the team. You know, we like to measure the reliability of systems and the whole Scrum movement introduced this idea of velocity, and I like to bring in this idea of, let’s say you want to be on time as a leader. Um, I’m interested in proving the theory that, hey, if you want to be on time, you probably need to be on time every week, and in order to be on time on the week, you probably need to be on time every day. So if you don’t know what an on-time day looks like, there’s no point planning roadmaps and saying that deadlines are a primary focus. Maybe the team should be planning in smaller batches, not with, not trying to chase higher accuracy in something very large. And what I usually use as a proxy metric is just to say, how risky is your word? Right, so how reliable is your promise? Uh, and we don’t measure how fast the team is moving. What I like to measure with them is say, okay, when do you think this will be done? They say Friday. Okay. If you’re right, Monday needs to look like this. Tuesday needs to look like this. Let me just try to reverse engineer it from that. It’s very basic. And then I’m trying to figure out how many days or hours or minutes into a plan they’re off-track. I don’t care about velocity. So no proxy metrics. I’m just interested if they create like a three month roadmap, how many hours into the three-month roadmap are they off-course? Because that’s what I’m interested in, because that’s actionable. Okay. You said three months from now, this is done. One month from now, there’ll be a milestone. But yesterday you said that today something would be done. It’s not done. Maybe we should work on that. Maybe we should really get down to a much smaller batch size and just try to make the communication structures around the team building stuff more reliable. That would de-stress a lot of people at the same time and sort of reduce anxiety. And maybe the problem is that you have a building-to-deploying nuance and maybe that’s also part of the problem. It usually is. And then there might be a planning-to-building nuance that also needs to be addressed. And then we basically come down to this idea of continuous delivery extreme programming, you know, let’s plan a little bit. Let’s Build a little bit. Let’s test it. Let’s test our assumptions. And behind the scenes once we do that for a few days, once we have evidence that we’re reliable, then let’s plan the next two weeks. Only when we have shown evidence of the team understands what a reliable work week for them looks like. If they’ve never experienced that and they’ve been chasing their own tail deadline after deadline, um, there’s not much you can do with such a team. And a lot of people just need a wake up call to see that, “Hey, you know what? I actually don’t know how to plan. You know, I don’t know how to estimate.” And that’s okay. As long as you have this intention of trying to improve or trying to look for alternatives, not to become better.

Kovid Batra: I think my next question would be, uh, like when you’re talking about, uh, this aspect in the teams, how do you exactly go about having that conversations or having that, that visibility on a day-to-day basis? Like most, most of the things that you mentioned were qualitative in nature, right, as, as you mentioned, right? So how, how do you exactly go about doing that? Like if someone wants to understand and deploy the same thought-process in a team, how should they actually do and measure it?

Denis Čahuk: Well, from a leader’s perspective, it’s very simple, you know, because I can just ask them, “Hey, is it done? Is it on anybody’s mind today?” Um, and they might tell me, “Yeah, it’s done, but not merged.” Or, “It’s waiting for review, but it’s done, but it’s kind of waiting for review.” And then that might be one possible answer. Um, it doesn’t need to be qualitative in the sense that I need a human for that. What, you know, what I’m looking for is precision. Like, is it, is it definitively done? Was there an increment? You know, did we test our assumptions? What, is there a releasable artifact? Is it possible to gain feedback on this?

Kovid Batra: Got it.

Denis Čahuk: Did you, did you talk to the team to establish if we deploy this as soon as possible, what question do we want to answer? Like what feedback, what kind of product feedback are we looking for? Or are we just blindly going through a list of features? Like, are we making improvements to our software or is somebody else who is not an engineer? Maybe that’s the problem, right? So it’s very difficult to pinpoint to like one generic thing. But a team that I worked with, the best proxy for these kinds of improvements from the leader was how ready they felt to be interrupted and get course correction. Right? Because the main thing with priorities in a team is that, you know, the main unintuitive thing is that you need to make bets and you need to reduce the cost of you being wrong, right? So the business is making bets on the market, on the product and working with this particular team with these particular individuals. The team is making bets with implementation details to a choice of technology, ratio between keeping the lights on, technical debt and new features, support and communication styles, you know, change of technology maybe. Um, so you need to just make sure that you’re playing with the market. The upside will take care of itself. You just need to make sure that you’re not making stupid mistakes that cost you a lot, either in opportunity or actual fiscal value. Um, but once you got that out of the way, you know, sky’s the limit. A lot of engineers think that we’re expensive. It’s large projects. We gotta get it right the first time. So they try to measure how often they got it right the first time, which is silly. And usually that’s where most measurements go. Are we getting it right the first time? We need to do this to get it right the first time, right? So failure is not an option. Whereas my mantra would be, no, you are going to fail. Just make sure it happens sooner rather than later and with as little intensity as possible so that we can act on it while there’s still time.

Kovid Batra: Got it. Makes sense. Makes sense. All right. Uh, Paulo, I think, uh, we are just running short on time, but I really want to ask this question to you as well, uh, just like Denis has shared something from his experience and that’s really interesting to know like how qualitatively you can measure or see things every time and solve for those. In your experience, um, you have, uh, recently joined this startup as, as a CTO, right? So maybe how does it feel like a new CTO and what things come to your mind when you would think of improving productivity in your teams and building a team which is impactful?

Paulo André: Yeah, I joined this company as a CTO six months ago. It’s been quite a journey and it’s, so it’s very fresh in my mind. And of course, every team is different and every starting point is different and so on, but ultimately, I think the pattern that i’ve always seen in my career is that some things are just not connected and the work is not visible and there’s lack of clarity about what’s value, uh, about what are the goals, what are the priorities, how do we make decisions, like all of that stuff, right? And so, every hour that I’ve been putting into this role with my team so far in these six months has been really either, either about creating clarity or about developing competence to the extent that I can. And so the development of competence is, is basically every opportunity is an opportunity to learn, both for myself and for anyone else in the team. And I can try to leverage my coaching skills, um, in making those learning conversations effective. And then the creation of clarity in my role, I happen to lead both product and engineering, so I cannot blame somebody else for lack of clarity on what the product should be or where it should go. It’s, it’s on me. And I’ve been working with some really good people in terms of what is our product strategy? What do we focus on and not focus on? Why this and not that? What are we trying to accomplish? What are those outcomes that we were talking about that we want to drive, right? So all of that is hard to answer. It’s deceptively difficult to answer. But at the end of the day, it’s what’s most important for that engineering productivity piece, because if you have an engineering team that is, you know, doing wasted work left and right, or things are not connected, and they’re just like, not clear about what they should be doing in the first place, that doesn’t sound like the ingredients for a productive team, right? And ultimately, the product side needs to answer to a large extent those, those difficult questions. So obviously, I could go into a lot of specific details about how we’re doing this and that. I don’t think we have at least today the time for that. Maybe we can do a deep dive later. But ultimately, it’s all about how do I create clarity for everyone and for myself in the first place so I can give it and then also developing the competence of the people that we do have. And that’s the increasing the capacity to win that I was talking about earlier. And if we make good progress on these two things, then we can give a lot of control and autonomy to people because they understand what we’re going for, and they have the skills to actually deliver on that, right? That’s, that’s the holy grail. And that’s motivation, right? That’s happiness. That’s a moment at work that is so elusive. But at the end of the day, I think that’s what we’re, we’re working towards.

Kovid Batra: Totally. I’ll still, uh, want to deep dive a little bit in any one of those, uh, instances, like if you have something to share from last six months where you actually, when prioritized this transparency for the team to be in, uh, how exactly you executed it, a small instance or a small maybe a meeting that you have had and..

Paulo André: Very simple example. Very simple example. Um, one of the things that I immediately noticed in the team is that a lot of the work that was happening was just not visible. It was not on a ticket. It was not on a notion document. It was nowhere, right? Because knowledge was in people’s minds, and so there was a lot of like, gaps of understanding and things that would just take a lot longer than they think they should. And so I already mentioned my bias towards lean software development. What does that mean? First and foremost, make the work visible because if you don’t make the work visible, you have no chance of optimizing the process and getting better at what you do. So I’ve been hammering this idea of making the work visible. I think my team is sick of me pointing to is there a ticket for it? Did you create a ticket for it? Where is the ticket? And so on. Because the way we work with Jira, that’s, that’s where the work becomes visible. And I think now we got to a point where this just became second nature, uh, for all of us. So that would be one example where it’s like very basic fundamental thing. Don’t need to measure anything. Don’t need complicated KPIs and whatnot. What we do need is to make the work visible so we can reason about it together. That’s it.

Kovid Batra: Makes sense. And anything which you found very unique about this team and you took a unique approach to solve it? Any, anything of that sort?

Paulo André: Unique? Oh, that’s a, that’s a really good question. I mean, everyone is different, but at the end of the day, we’re all human beings trying to work together towards something that is somehow meaningful. And so from that perspective, frankly, no real surprises. I think what I’m, if anything, I’m really grateful for the team to be so driven to do better, even if, you know, we lack the experience in many areas that we need to level up. Um, but as far as something being really unique, I think maybe a challenge our team has to really deal with tough technical challenges is around email deliverability, for example, that’s not necessarily unique. Of course, there’s other companies that need to debate themselves with the exact same problems. But in my career, that’s not a particular topic that I have to deal with a lot. And I’m seeing, like, just how complex and how tricky it is to get to get right. Um, and it’s an always evolving sort of landscape for those that are familiar with that type of stuff. So, yeah, not a good, not a good answer to your question. There’s nothing unique. It’s just that, yeah, what’s unique is the team. The team is unique. There’s no other team like this one, like these individuals doing this thing right here, right now in this company in 2024.

Kovid Batra: Great, man. I think your team is gonna love you for that. All right. I think there will be a lot more questions from the audience now. We’ll dedicate some time to that. We’ll take a minute’s break here and we’ll just gather all the questions that the audience has put in. Uh, though we are running a little out of time, is it okay for you guys to like extend for 5–10 minutes? Perfect. All right. Uh, so we’ll take a break for a minute and, uh, just gather the questions here.

All right. I think time to get started with the questions. Uh, I see a lot of them. Uh, let’s take them one by one on the screen and start answering those. Okay. So the first one is coming from, uh, Kshitij Mohan. That’s, uh, the CEO of Typo. Hi, Kshitij. Uh, everything is going good here. Uh, so this is for Denis. Uh, as someone working at the intersection of engineering and cloud technologies, how do you prioritize between technical debt and innovation?

Denis Čahuk: It’s a great question. Hey, Kshitij. Well, I think first of all, I need to know whether it’s actual debt or whether it’s just crap code. You know, like it’s crappy implementation is not an excuse for debt, right? So for you to have debt, there are three things needed to have happen. At some point in the past, you had two choices, A or B. And you made a choice without, with insufficient knowledge. And later on, you figured out that either something in the market changed or timing changed, or we gained more knowledge, and we realized that we, that now the other one is better, for whatever reason. I mean, it’s unnecessary that it was wrong at the time, but we now have more information that we need to go from A to B. Uh, originally we picked A. Now you also need to know how much it costs to go from A to B and how much you stand to gain or trade if you decide not to do that, right? So maybe going from A to B now cost you two months and ten thousand euros and doing it later next year, maybe it’s going to double the cost and add an extra week. That’s technical debt. Like the, the nature of that decision, that’s technical debt. If you, if you made the wrong decision in, in the past and you know it was the wrong decision and now you’re trying to explore whether you want to do something about it, that’s not technical debt. That’s just, you know, that’s you seeking for excuses to not do a rewrite. So it’s, first of all you need to identify is it debt. If it is debt, you know the cost, you know the trade-off, you know, you know, you can either put it on a timeline or you can measure some kind of business outcome with it. So that’s one side.

On the, on the innovation side, you need to decide what is innovation exactly? You know, is it like an investment? Is it a capital expense where I am building a laboratory and we’re going to innovate with new technologies? And then once we build them, we will find, um, sort of private market applications for them or B2B applications for them. Like, is it that kind of innovation? Or is innovation a umbrella term for new features, right? Cause, cause that’s operational. That’s much closer to operational expense, operational expense, right? So it’s just something you do continuously and you deliver continuously, and that innovation that you do can continuously feature development will also produce new debt. So once you’ve got these two things, these two sides figured out, then it’s a very simple decision. How much debt can you live with? How fast are you creating new debt compared to how fast you’re paying it off? And what can you do to get rid of all the non-debt, all the crap, essentially? That’s it, you know. Then you just make sure that you balance out those activities and that you consistently do them. It isn’t just, oh yeah. We do innovation for nine months and then we pay off debt. That usually doesn’t go very well.

Kovid Batra: I think this is coming from a very personal pain point. Now we’re really moving towards the AI wave and building things at Typo. That’s where Kshitij is coming from. Uh, totally. I think, thanks, thanks, Denis. I think we’ll move on to the next question now. Uh, that’s from, uh, Madhurima. Yeah. Hey Paulo, this one’s for you. Uh, which metric do you think is often overlooked in engineering teams but has significant impact on long-term success?

Paulo André: Yeah, that’s a great question. I’m going to, I’m going to give a bit of a cheeky answer and I’m going to say, disclaimer, this is not a metric that I track with, we track with, with my team, and it’s also not, I don’t know, a very scientific way or concrete way of measuring it. However, to the question, what is overlooked in engineering teams and has significant long-term impact, or success, on long-term success, that’s what I would call ‘mean time to clarity’. How quickly do we get clear on where we need to be and how do we get there? Right? And we don’t have all the answers upfront. We need to, as Denis mentioned earlier, experiment and iterate and learn and we’ll get smarter, hopefully, as we go along, as we learn. But how quickly we get to that clarity in every which way that we’re working. I think that’s, that’s the one that is most important because it has implications, right? Um, if we don’t look at that and if we don’t care about that, are we doing what it takes to create that clarity in the first place? And if that’s not the case, the waste is going to be abundant, right? So that’s the one I would say as an engineering leader, how do I get for myself all the clarity that I need to be able to pass it along to others and create that sense that we know where we’re going and what we don’t know, we have the means to learn and to keep getting smarter.

Kovid Batra: Cool. Great answer there. Uh, let’s move on to the next one. I think this one is again for Paulo. Yeah.

Paulo André: Okay, so you know what? Maybe this is going to be a bit, uh, I don’t know what to call it, but considering that I don’t think the most important things are gonna change in the next five years, um, AI notwithstanding, and what are the most important things? It’s still a bunch of people working together and depending on each other to achieve common goals. We may have less people with more artificial intelligence, but I don’t think we’re anywhere near the point where the artificial intelligence just does everything, including the thinking for itself. And so with that in mind, it’s still back to what I said earlier, um, in the session. It’s really about how is the work flowing from left to right? And I don’t know of a better, um, sort of set of metrics than the DORA metrics for this, particularly cycle time and deployment frequency and that sort of stuff that is more about the actual flow. Um, but like, you know, let’s not get into the DORA metrics. I’m sure the audience here already knows a lot about it, but that’s, that’s, I think, what, what is the most important, um, and will continue to be critical in the next five years, um, that’s, that’s basically it.

Kovid Batra: Cool. Moving on. All right. That’s again for, oh, this one, Denis. How do you ensure cloud solutions remain secure and scalable while addressing ever-changing customer demands?

Denis Čahuk: Well, there’s two parts to that question. You know, one is security, the other one is ever-changing customer demands. I think, you know, security will be a sort of an expression of the standard, or at least some degree of sensible defaults within the team. So the better question would be, what do engineers need to not have to consciously, to not have to constantly and consciously and deliberately think about security, right? So do they have support by, are they supported by a security expert? Do they have platform engineering teams that are supporting with security initiatives, right? So if there’s a product team that’s focusing on product, support them so that they also don’t have to become an expert in security, cause that’s where all the problems start, where you basically have a team of five and they need to wear 20 hats and they start triaging the hats and making trade-offs in security, you know. And usually, usually large teams that are overwhelmed, love doing privacy or security trade-offs because they don’t have skin in the game. The business has skin in the game, right? And then when you individuate incentive to such a degree that it becomes dysfunctional, um, security usually doesn’t bode well. Um, at least not till there’s some incident or maybe some security review or some inspection, et cetera.

So give the teams what they need. If they’re not a security expert, provide them support. Um, and the same thing with scalability. Scalability is also something that can benefit more from tighter collaboration, more so than security. Um, so just make sure that the team is able to express itself as a team through pair programming or having more immediate conversations rather than just, you know, asynchronous code review conversations or stand up conversations way at the end of the cycle. At the end of the cycle when the code is written and it’s going into merging or QA, it’s too late, the code is written, right? So you want the preempt. That solution is being created by the team being able to express itself as a team rather than just a group of individuals, being the individual goals.

Kovid Batra: Cool. I think, uh, we have a few more questions, but running way out of time now. Uh, maybe we can take one more last, last question and then we can wrap it up.

Paulo André: Sounds good. Okay, so this one is for me, right? How do I approach, uh, integrating new tools and frameworks into engineering workflows without disrupting productivity? That, that final piece is interesting. I think it also starts with how we frame this type of stuff. So there is a cost to making improvements. I don’t think we can have our cake and eat it, too, necessarily. And it’s just part of the job, and it’s part of what we do. And so, um, you know, for example, if you take the time to have a regular retrospective with your team, right, is that going to impact productivity? I mean, you could be coding for an extra hour every two weeks. It’s certainly going to have some impact. But then it also depends on what is the outcome of that retrospective, and how much does it impact the long-term, um, you know, capacity to win of the team. So with that in mind, what I would say is that the most important thing I find is that you don’t just, again, as an engineering leader, as an engineering manager, you just don’t, you don’t just download certain practices and tools and frameworks on the teams. You always start from what are we trying to solve here and why does it matter and get that shared understanding to the point where we’re all looking at the same problem roughly the same way. We can then disagree on solutions, but we agree that this is a problem worth solving right now, and we’re gonna go and do that. And so the tools and the frameworks are kind of like downstream from that. Okay, now what do we need to gain the inside? Oh, now what do we need to solve the problem? Then we can talk about those things. Okay? So as an example, one thing I’m working on now with my team, I mentioned this earlier, I believe is like, uh, a bit of a full-on product delivery, product discovery and delivery, um, process, right? That includes a product strategy, um, that shouldn’t change that much that often. And then there are a lot of tools and frameworks that we can use. Tools, we use three different types of projects in Jira, for example. And when it comes to frameworks, we’re starting to adopt something called opportunity solution trees, which is just a fancy way of saying what outcomes are we trying to generate, what opportunities do we see to, to get there and what are the solutions that can capitalize on these opportunities, right? That sort of thing. But it all starts with we need to gain clarity about where we’re gonna go as a business and as a product and everything kind of comes downstream from that, right? So I think if you take the time and this is where I’ll leave it. If you take the time and I think you should to start there and to do this groundwork and create this shared context and understanding with your teams, everything else downstream becomes so much easier because you can connect it to the problem that you’re solving. Otherwise, you’re just talking solutions for problems that most people will think they are inexistent or they just look completely different, right? And this takes work, this takes time, this takes energy, this takes attention, takes all of those things. But frankly, if you ask me, that’s the work of leadership. That’s the work of management.

Kovid Batra: Great. Well said, Paulo. I think Denis has a point to add here.

Denis Čahuk: Yeah, I had a conversation this week with one of the CEOs and founders of one of Ljubljana, Slovenia’s biggest agencies, because we were talking about this. And, and, and they asked me this question, they said, “Denis, you don’t have a catalog. Like, what do you do? Like, how do, how does working with you look like? Do we do a workshop or something?” And I said, and I asked, “Do you want to do a workshop? And, and I saw on their face, they said, “Well..” I told them, “Yes, exactly, exactly. That’s why I don’t have a catalog because, because, because the workshops are this, I will show you how a great team works, right? I will give you all of this fancy storytelling about how productive teams work, and then you’re like, “Great. Cool. But we’re not that and we can’t have that in our team.” So great, now I’d go away because I’m, because I’d feel demoralized, right? Like that’s not a good way of approaching working with that team. I, I always tell them, “Look, I don’t know what will help you. You probably also don’t know what will help you. We need to figure it out together. But generally, what’s more important than figuring out how to help you is to figure out how much are you willing to invest consistently in improvement? Because maybe I teach you something and you only have 10 minutes. That’s the wrong way about it, right? I need to ask you how much time do you have consistently every week 15 minutes? Okay, then when I need to teach you something that you can put in practice every 15 minutes Otherwise, I’m robbing you of your time. Otherwise, I’m wasting your time. If you have three hour retrospectives and we’re putting nothing into action, I’m wasting your time, right? So we need to personally figure out like what is consistent for you? What kind of improvement, how intense do you want it? How do you know if you’re making progress?”

Those two are the most important things, because I always come to these kinds of questions about new tools and frameworks because people love asking me about, “Hey, Denis. Can you do a TDD workshop?”, “Denis, can you do a domain-driven design workshop?”, “Denis, can you help us do event storming?” And I always say, “If what you need is that one workshop, it’s not going to solve any problems because I’m all about consistent improvement, about learning, about growing your team, about, you know, investing into the people, not about changing, you know, changing some label or some other label.” And I always come back to the mantra of what can you do consistently starting this week so that the product and the team is much better six months from now? That’s the big question. That’s, that should be the focus. Cause if you need to learn something, you know, go do a certification that takes you a year to perform correctly, and then you need to renew it every year. That’s nonsense. This week, what can we do this week? Start this week, apply this week, and then consistently grow and apply every single week for the next six months. That would be huge. Or you can go to a conference and send everybody on vacation and pretend the workshop was very productive. Thank you.

Kovid Batra: Perfect. I think that brings us to the end of this episode. Uh, I think the next episode that we’re going to have would be in the next year, which is not very far. So, before we depart, uh, I think I would like to wish the audience, uh, a very Happy New Year in advance, a Merry Christmas in advance. And to both of our panelists also, Paulo, Denis, thank you, thank you so much, uh, for taking out time. It was really great talking to you. I would love to have you both again here. talking more in depth about different topics and how to make teams better. But for today, that’s our time. Anything that you would like to, that you guys would want to add, please feel free. All right. Yeah, please go ahead.

Denis Čahuk: Thanks for inviting us.

Paulo André: Yeah, exactly. From my side, I was just going to say that thanks for having us. Thanks also to the audience that has put up with us and also asked very good questions, to be honest. Unfortunately, we couldn’t get to a few more that are still there that I think are very good ones. Um, but yeah, looking forward to coming back and deep diving into, into some of the topics that we talked about here.

Kovid Batra: Great. Definitely.

Denis Čahuk: And thank you for Kovid for inviting us and for introducing us to each other and to everybody backstage and at Typo for, they’re probably doing a lot of annoying groundwork at the background that makes all of this so much more enjoyable. Thank you.

Kovid Batra: All right, guys. Thank you. Thank you so much. Have a great evening ahead. Bye!

‍

In this episode of the groCTO Podcast, host Kovid Batra is joined by Ben Matthews, Senior Director of Engineering at Stack Overflow, with over 20 years of experience in engineering and leadership.

‍

‍

Ben shares his career journey from QA to engineering leadership, shedding light on the importance of creating organizations that function collaboratively rather than just executing tasks independently. He underscores the need for cross-functional teamwork and reducing friction points to build cohesive and successful teams. Ben also addresses the challenges and opportunities presented by the AI revolution, emphasizing Stack Overflow’s strategy to embrace and leverage AI innovations. Additionally, he offers valuable advice for onboarding junior developers, such as involving them in code reviews and emphasizing documentation.

Throughout the discussion, Ben highlights essential leadership principles like advocating for oneself and one’s team, managing team dynamics, and setting clear expectations. He provides practical tips for engineering managers on creating value, addressing organizational weaknesses, and fostering a supportive environment for continuous growth and learning. The episode wraps up with Ben sharing his thoughts on maintaining a vision and connecting it with new technological developments.

Timestamps

• 00:00 - Introduction

• 01:08 - Meet Ben Matthews

• 01:22 - Ben's Journey from QA to Engineering Leadership

• 03:21 - The Importance of Team Collaboration

• 04:03 - Current Role and Responsibilities at Stack Overflow

• 09:12 - Advice for Aspiring Technologists

• 17:41 - Embracing AI at Stack Overflow

• 23:30 - Onboarding and Nurturing Junior Developers

• 26:59 - Parting Advice for Engineering Managers

• 29:36 - Conclusion

Links and Mentions

• Ben on LinkedIn

• Kovid on LinkedIn

• Watch this episode on Substack and Youtube

• Listen on Spotify, Amazon Music, and iTunes/Apple Podcasts

Episode Transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of groCTO podcast. And today with us, we have an exciting guest. This is Senior Director from Stack Overflow with 20 plus years of experience in engineering and leadership, Ben Matthews. Hey, Ben.

Ben Matthews: Thanks for having me. I just wanted to cover you there.

Kovid Batra: All right. So I think, uh, today, uh, we’re going to talk about, uh, Ben’s journey and how he moved from a QA to an engineering leadership position at Stack Overflow. And here we are like primarily interested in knowing how they are scaling tech and teams at Stack Overflow. So we are totally excited about this episode, man. But before we jump on to the main section, uh, there is a small ritual that we have. So you have to introduce yourself that your LinkedIn profile doesn’t tell you about.

Ben Matthews: Okay. Uh, well, that’s not in my LinkedIn profile. Well, um, So I am the Senior Director of Engineering at Stack Overflow for our community products, but something about myself that’s not, uh, I, I love to snowboard. I’m a huge fan of calzones and I’m a total movie nerd. Is that what you had in mind?

Kovid Batra: Yeah, of course. I mean, uh, I would love you to talk a little more, even if there is something that you want to share that tells about you in terms of who you are. Maybe something from your childhood, from your teenage, anything, anything of that sort that you think defines you who you are today.

Ben Matthews: Uh, yeah. Um, yeah, that’s a great question. Of, of really just getting into tech in general, a lot of that did come from some natural inclinations, uh, that have kind of always been there. For the longest time I didn’t think I would really enjoy technology. There was the stereotype of the person who sat in the corner, just coded all day and never talked to people like kind of the Hollywood impression of what a developer was. That didn’t seem very appealing. I like interacting with people. I like actually making some tangible differences, but once I actually dug into it and actually saw like there was that click that a lot of people have the first time that you compile and run your code and you’re like, wait, I made that happen. I made that change and that’s what kind of the addiction started. But even after that, I still loved interacting with people. Um, and I think we were very lucky. I came at a time where the industry was starting to change, where it was no longer people working in isolation. This, this is a team sport now, like developers have to work together. You’re working with other departments. And that’s actually kind of what I really enjoy. I love, I love interacting with people and building things that people like to work with. So, um, that’s really kind of what sings to me about tech is it’s a quick way to build things that other people can interact with and bring value to them. And I get to do it together with another team of people who, who enjoy it as well. So I would say like, that’s kind of what gets me out of bed in the morning of trying to help people do more with their day and build something that helped them.

Kovid Batra: Great, great. Thanks for that intro. Um, I think, uh, I’m really interested to start with the part, uh, with your current role and responsibility at Stack Overflow. Uh, like, uh, like how, uh, you, you started here or in fact, like, we can go a little back also, like from where you actually started. So wherever you are comfortable, like, uh, you can just begin. Yeah.

Ben Matthews: Yeah. Um, so the, the full journey has its interesting and boring parts altogether, but how it really started was out of school, I still had that feeling of I didn’t know if development was for me because of the perception I had. But I actually got my first job as a quality assurance engineer for a small startup. Uh, now the best part about working at a small company is that you’re forced to wear multiple hats. That, you know, you don’t just have one role. I was also doing tech support. And then I also looked at some of the code. I helped to do some small code reviews. And from there, I thought like, you know, I would love to take a shot at doing this development thing. Maybe, maybe I would like it more. Um, and then I did, I kind of got that high of like, I pushed this live and people are using it and you know, that’s mine and they’re enjoying it and that kind of became addictive to me, of where I really liked being a developer. So I really leaned into that. Um, and then enjoying that startup and having a great mentor there, uh, that really kind of, I set a foundation for how I view, how I want to develop and the things I want to build, uh, of really taking the point of view of how I’m creating value for the users. And my, and my next role, I actually worked for a marketing agency doing digital marketing. Um, and that took that up to 11 of the number of things I had to interact with and be prepared for. Like every week or every couple weeks I had a new project, a new customer, a new problem to solve, and I had to use usually with code, sometimes not with code. We’re solving these problems and creating value and getting that whole high level view of working on databases, kind of doing QA for other people doing development front and back, and I got to see what I really like to do. But I also got an insight into how organizations work, how pieces of a company work together, pieces of a development team work together, and how that really creates value for, for users and customers, which in the end, that’s what we’re here to do is to create value for people.

Um, so my next role after that is my first foray into leadership. I went to another digital agency leading a small development team. And, um, it had its highs and lows. There was definitely a learning curve there. Um, there, there was that ache of not being able to develop of, of enabling other people to develop.

Kovid Batra: Yeah. And this was, and this was a startup or this was an organization like, uh, medium or large-scale organization?

Ben Matthews: This was a medium-sized organization, much more, uh, founded, they, they were trying to start up a new tech department, so I had a little freedom in setting some standards. But it was a mature organization. Um, they kind of knew what they wanted to accomplish. Um, so like then I had a big learning curve, excuse me, of what it’s like to work there, how do I lead people, how do I set expectations for them, um, how do I advocate for myself and others, and, you know, I had plenty of missteps that like looking back now, there’s a bunch of times I wish I could go back and say, “Nope, this is totally the wrong direction. Your instincts are wrong. You need to learn and grow.” Um, and then after that I went to a couple of other organizations of doing leadership there, some very, very large, some smaller, getting that whole view of kind of ins and outs and the stacks of what I would like to be. Then I landed here on Stack which has been a terrific fit for me of, of getting to work directly with users and, uh, and knowing that the people I’m leading are customers, of Stack Overflow just as much as they are employees here, which is very satisfying. We really feel like we’re helping people. I get to have a big impact on a very large application and, um, there’s still a lot of freedom for me to, to execute in the vision. Working with the other leaders here has been a joy as well, since we’re kind of like-minded, which I think is very important for people looking for a place to land. Uh, I know in a lot of interviews, you rarely get to interact with people who will be your peers, but when you do, like really see how well do you bounce off of each other, um, are you all alike? Cause that’s not great. Or are you all different? That’s not great either. You want to have like a little bit of friction there so you can create great ideas. And I think that’s what we have at Stack and it’s been wonderful.

Kovid Batra: No, I think that’s great. But, uh, one question here. Like, um, you were very, uh, passionate about when you told how you started your journey, uh, with the, with the startup, you got an exposure, uh, from the business level to, uh, product teams to developers, and that really opened your mind. Um, would you recommend this for anyone who is beginning their journey in, in, in tech, like, uh, would this be a recommended way of going about how you, uh, set your foundation?

Ben Matthews: Yeah, that’s a great question. I think a lot of people are going to have very different journeys. Um, that I think, you know, one thing that really stuck out to me actually just recently talking to someone when I was, I was at a panel just this past weekend and the variety of journeys that people took of where they started. I think one of the most fascinating ones was someone who was not in tech at all. They’ve been a teacher for 15 years, teaching parts of computer science and design, never professionally worked on one. And now they’re breaking into it now and having a lot of success. Um, I mean, I think my advice to people is like, like your journey is not right or wrong, whatever you’re trying to get to, I think there’s plenty of ways to get to it. What I would say that you do want to focus on though, is that you keep challenging yourself of what I thought I would be working on now is certainly not, uh, what I’m actually working on today, uh, even, whether, I think that’s at all levels, whether at senior, uh, executive, down to like junior engineer, uh, from year to year, the technology landscape changes. How we organize people and execute on that changes. Um, so whatever that journey is, whatever you think it’s going to be, I’m 99 percent sure it’s going to be different than what you envisioned and you have to be prepared to shift that way and keep learning and challenging yourself and it’ll be uncomfortable but that, that’s part of the journey.

Kovid Batra: Yeah, I think that’s the way to go, actually. Then that’s the area when you learn the maximum I think. Uh, so yeah, totally agree with that. Uh, when, uh, when you reflect back, when you see your journey from a QA to a Senior Director at Stack Overflow, I’m curious to know, like, do you know what is that quality in you, uh, that made you stand out and grow to such a profile in, in a, in a reputed organization?

Ben Matthews: Yeah, I think, um, I had a great mentor that pointed out a lot of things that weren’t obvious to me. Um, and I think being a developer, um, I think sometimes for, for us being a people leader is it doesn’t come as naturally sometimes because we tend to think more functionally, which isn’t a bad thing. But there’s some things that at least for me, it didn’t jump out, obviously. I remember one great piece of feedback that took me from just a team manager to get me into a higher level piece was really advocating for yourself. Uh, that didn’t come naturally to me. And I don’t think that comes naturally to a lot of people in our industry. Um, some like to just label it as bragging or see it as bragging, but if you’re not being proud of your successes, other people won’t know they’re there. But it’s not even just for you, but you should be bragging and, and communicating the successes of your team, communicating the successes of your organization. That’s a big part of letting people know of what’s worked, what hasn’t. So one that you can keep doing it. But also other people can emulate it, emulate it and other people in your organization can see you there. There needs to be a profile there. You need to be visible to be a leader. Uh, and I separate that from manager. Being a manager, you don’t necessarily have to be visible. You, there’s very good managers that don’t like to be in the limelight. They’re still supporting their people and moving things forward. But if you’re going to be a leader and set an example and set hard expectations of the vision of where things are going to go, you need to be visible and part of that is advocating and communicating more broadly.

Kovid Batra: Sure. Makes sense. Okay, coming back to your, your current, uh, roles and responsibilities at Stack Overflow. I’m sure working with developers, uh, who know, uh, what the product is about and they are themselves the users. What is that, uh, one thing that you really, uh, abide by as a principle for leading your teams? How, how you’re leading it differently at Stack Overflow, making things successful, scalable, robust?

Ben Matthews: Yeah. Um, and that’s a great question. Cause every organization is different, I’ve had to tackle this problem in different ways at different places. At Stack, I’ve been very fortunate that, uh, there’s already a very talented group of people here that I’ve been able to expand on and keep growing. Um, people tend to be very passionate about the project already, the project and products that we build. That’s a great benefit to have as well. You’re not really trying to talk people into the vision of Stack Overflow, that they were users before there were customers. So that, that was great. But, um, but with that also comes like a different way of how do you leverage the most out of people given this hand? Um, and I know it’s partially a cliché, but with that vision that’s already there with already talented people, um, kind of the steps of making sure you’re setting clear expectations for your folks, setting that vision very loudly, broadly, and clearly to them, um, and then making sure they have all the resources they need to do that. Sometimes it’s time, sometimes it’s, it’s some money or equipment. And then lastly, kind of getting out of their way and removing all the roadblocks. Those three steps are kind of the big parts that I think are general rule of thumb, but, um, given that a lot of other friction points were out of the way, I could really lean into that.

A great example was, uh, I had a team that, uh, was trying to work on a brand new product that, uh, no, it didn’t quite work out before, but we were going to give it another try. We were starting over. And looking at some of the things that went well and what didn’t, it was honestly just a clear lack of vision was their problem. They kept changing directions often. And I was talking to product of like, “Hey, what went wrong?” And they had their own internal struggles. We had our struggles and just aligning that saying like, “Hey, this is going to be a little bit more broad. We’re specifically trying to accomplish this. How do we do it?” And from a bottom-up approach, they set the goals, they set what they think the milestone should be, and that was so much more successful. Um, like that formula that doesn’t work everywhere, but it really thrives here at Stack of like, “Hey, what do you think? How is the best way to execute this?” And we tweak it, we manage it, we keep it on the rails. But once they started moving into it, um, it actually launched and became very successful. So that’s another way of like, kind of reading your team, reading the other stakeholders and, and leveraging their strengths.

Kovid Batra: But what I feel is that, uh, it’s great. Like this approach works at, uh, Stack, but usually what I felt is that when you go with the bottom-up approach, uh, there is an imbalance, uh, like developers are usually inclined towards taking care of the infra, managing the tech debt and not really intuitively prioritizing your, uh, customer needs and requirements, even though they relate to it at times, at least in case of Stack, I can say that. But still there is a, there is a bias in the developer to make the code better before looking at the customer side of it. So how, how do you take care of that?

Ben Matthews: That’s a, that’s a great point. Um, and just to be clear to other developers listening, I love that instinct if you have it, it’s so valuable that you want to leave code better than you found it. But, uh, to what your point, I think that goes back to setting those clear expectations again of, “Hey, like this is what we’re going to accomplish. This is how we need to do it. Um, if we can address tech debt along the way, you need to justify that. I give you the freedom to justify that. But in the end, I, I’m setting these goals. This is what has to happen by then and I’m happy to support you and what we need to get there.” Um, and then also sharing advice and, and, and you know, learning where the minds are on some of those paths. Uh, some people have experience in making these mistakes like I have. I’ve, uh, tried to say, “Well, we could also do this and then also do this and then also do our goal.” And then we’ve taken on too much, and we’re, you know, we’re trying to do too many things at once that we can’t execute.

So you’re right in that. Just kind of not giving any clear direction or expectations, things can kind of go off the rails and what they want to work on isn’t always what we need to focus on. I think there’s a balance there. But, uh, yeah, I mean, setting those expectations is a key part to those three steps, I would say arguably the most important part. If they don’t know which way they’re supposed to be aiming for, they can’t execute on it.

Kovid Batra: Makes sense. Okay, um, next thing that I want to know is, uh, in the last few, few, not actually, actually few years, it’s just been a year or two when the AI wave has like taken over the industry, right? And everyone’s rushing. Um, I’m sure there was a huge impact on the user base, but maybe I’m wrong, on the user base of Stack because people go there to see code, uh, libraries and like code which is there. Now, uh, ChatGPT and tools like that are really helping developers do like automated code. Uh, how you have, uh, taken up with that and what’s your new strategy? I mean, of course you can say everything here, but I would love to know, like how it has been absorbed in the team now.

Ben Matthews: Now, um, I think for the most part, we’ve kind of worn our strategy on our sleeve. Our, our CEO and Chief Product Officer and our CTO have talked about this a bit of, I mean, Stack is, is there to help educate and empower technologists of the world. This is a new tool that’s part of the landscape now and there are a lot of companies that are concerned about it or feel like it’s a doomsday. Um, we’re embracing it. It’s a new way for information to get in and out of people’s hands. Uh, and this is something we were going to try to be a part of. I think we’ve made some great steps of leveraging AI, uh, we’re trying to build some partnerships with people to kind of get a hand on the wheel to make sure that like this is going in the right direction. But, um, there’s technical revolutions every couple years, and this is another one. Uh, and how Stack fits into it is we’re still going to try to provide that value to folks and AI is a new part of it. Uh, we’re building new products that leverage AI. Um, we actually have a couple that are hopefully going to be launching soon that try to improve the experience for users on the site, leveraging AI. We’re going to try to find new ways for people to interact with AI to know that Stack Overflow is a part of what that experience is and to kind of create a cycle there. Um, But it’s changed how people work. But I think Stack Overflow is still a big part of that equation. Uh, we are a big knowledge repository, uh, like along with Reddit or, or news articles, like all of these things need to be there to even power AI. That, that’s sort of the cycle. Like, um, that has to go there. Without human beings, without a community generating content, AI is pretty powerless. But, um, so there has to be a way for us to keep that feedback loop going. And we’re excited that of all the opportunities to be a part of that and find new ways to keep educating people.

Kovid Batra: Definitely. I think that’s a very good point, actually. Like, without humans feeding that information, at least right now AI is not at that stage that it can generate things on its own. It’s the community that would always be driving things at the end. So I also believe in that fact. My question, uh, a follow-up question on that is that when such kind of, uh, big changes happen, how, how your teams are taking it? Like, at Stack, how people are embracing it, particularly developers? I’m just saying that if there are new products that we are going to work on or new tech that we are going to build, how people are embracing it, how fast they are adopting to the new requirements and the new thought process which the company’s adopting?

Ben Matthews: Uh, through the context of AI or just in general?

Kovid Batra: Just, just in the context of AI.

Ben Matthews: Oh yeah. Um, well, in a fun way, there’s been a wide range of opinions on how for us to embrace or to try to channel the AI capabilities that are now very pervasive in the industry. Um, um, so first part of it starts with a lot of that we’re trying to gather as much data and information we can. Again, we have a good user base. So we’re able to interact with them and ask them questions. We’re looking at behavior changes. And so from there, we try to make a data informed decision to our teams of like, “Hey, this is what we’re seeing. So this is what we’re going to try.” Um, I mean, the beauty of data is there’s a bunch of ways to interpret it and our developers are no different. They have some thoughts on, on the best ways to go about it. But I think this also goes to a general leadership technique is you’re never going to get unanimous consent on an idea. If that’s what your requirement is, you’re never going to move forward. What you do have to get is people to at least agree that this is worth trying or like understand that I might be wrong. And a lot of people feel like this is the best way, so we’ll give it a shot. Uh, and that’s something I’ve been proud of to be able to achieve at Stack. It’s something that is very important for a leader of saying, “Hey, I know you don’t agree, but I need you to roll along with me on this. I understand your point. You’ve been heard, but this is the decision we’re making.” Um, a lot of people agree with the idea. Some don’t, but trying to get the enthusiasm and I think also connecting the dots on those ideas with the larger picture. I think that’s also something people miss a lot during these revolutions of if you start out with like vision A. And then something big happens and now you have vision B, um, you still have to connect the dots in like, “Hey, we’re still trying to, to like provide value the same way. We’re still the same company. We’re in this new thing that you’re doing. This dot still connects to what we want to do. There’s still a path there. We’re not like totally pivoting to block chain or something like that. It’s not a huge change for us.” So I think that also motivates people like we’re still trying to build the same vision, the same power for the company. We’re just doing it in a different way. And what you’re doing is still really creating value. I think that’s a big part for leaders to, to keep people motivated.

Kovid Batra: Makes sense. When it comes to, uh, bringing developers on board and nurturing them, I think the biggest challenge that I have always heard from managers, particularly is, uh, getting these new-age, uh, junior developers and the fresh ones coming into the picture. Um, any thoughts, any techniques that you have used to, uh, bring these people on board, nurture them well, and so that they can contribute and create that impact?

Ben Matthews: Yeah. Uh, onboarding people is a huge thing that I try to give the other managers that work for me that are bringing on new team members. Um, uh, I mean, a big part of it, it goes back to empowerment, but I think a lot of it is also the same challenges we’ve had I think for decades, of me even having my own Computer Science degree. In my first development job, there was a huge gap of what I learned in school versus what I’m doing day-to-day as an actual developer. Uh, as far as I can tell, that hasn’t really changed that much. People come in from bootcamps or not. Uh, funny we’ve had a really good experience of people that don’t have formal degrees coming in, who have just been coding their whole time. They tend to actually have an easier time working within a team. That’s not to disparage any Computer Science degree, it’s still very valuable, but it’s just to highlight the gap between what you actually do and what they’ve been training. A great example is, um, of what we try to get junior engineers to really focus on initially, it’s like just doing code reviews. That is a huge part of what we do in modern development. It’s a great way for you to understand the code base, understand how your team works, understand like kind of the ins and outs and where some of the scary parts of the code are. And, um, and even though that can be intimidating, the best thing I think you can do in a code review is just ask questions of like, “Hey, I see you’re doing this. This doesn’t make sense to me. Can you explain why?” And after time, even a senior engineer will read them and be like, “You know what? That is kind of confusing. Why did we do it that way? Let me..” And they’ll even update their PR. I think that’s one of the best tools to get a junior engineer up to speed is just like get them in the code and reviewing it.

Um, the other part of kind of the unsung hero of all of software development that never gets enough love is just documentation, of having them go through some of the pieces of the product, commenting and documenting how things work. That, one, it helps onboard other people, but two, that, that forces them to have an understanding of how parts of the code work. Uh, and then from there at their own pace, here at Stack, we, we try to have people push code to production on day one. Uh, we find something small for them to do, work them through the whole build pipeline process so they can see how it works and like, kind of get that scary part of the way. Like something you wrote is now in production on Stack Overflow in front of hundreds of millions of people. Congratulations! But let’s just get that part out of the way. Um, but then how they can actually understand the code and keep building things, take on new tickets, work with product, size, refinement, all of that, we just ease them into that in their own pace, but keeping them exposed to that code through documentation and PRs really shortens the learning curve.

Kovid Batra: Cool. Makes sense. I think, uh, most of the things, uh, that I have seen, uh, working out for the developers, for, uh, the, the teams that are working well, the managers play a really, really good role there. Like the team managers who are leading them play a very good role there. So before we like end this discussion, I would love for you, uh, to give some parting advice to the engineering managers who are leading such teams, uh, who are looking forward to growing in their career also, uh, that would be helpful for them. Yeah.

Ben Matthews: Yeah. I, I, I, uh, I would say three big points that were big for me from that mentor. One, I’ve already spoke on of advocating for yourself. And, um, and for you, your team and your people, that’s a big part of getting visibility to, to try to grow, to show that you’re being successful. And, and, and honestly, just helping your other peers be successful. It’s a great way for people to see that you’re good at what you do. Another thing that, that I think people could focus on is building an organization that functions and not just executes. Those are kind of two different things, though they sound similar. For I can have a front end team that is great at pumping out front end code or building a new front end framework, and that’s valuable. They’re executing. But they have to work in concert with our back end team or DBA team, with product to align things, getting those things to work together, that’s an organization that functions. And though it may seem like you might be slowing down one to get them to work in tandem or in line with another one, um, that’s actually what’s really going to make your organization successful. If you can show that you have teams working together, reducing friction points and actually building things as one unit, that shows you’re being a good leader, you’re setting a clear vision and you’re, you’re creating the most value you can out of that organization. Um, and last I would say is, um, really identifying friction points or slowdowns in your organization, owning them and setting a plan on how to tackle them. There I had a natural inclination as I was moving up to hide my weaknesses, like to hide what was not going well in my organization. Um, and because of that, I wasn’t able to get feedback from my fellow leaders, from my manager or help. Um, but I would say if you have a problem that you’re tackling, own it and be like, “Hey, this is what’s going on. This is a problem I’m having here. So I’m going to address it.” And welcome any thoughts, but that’s another success story to share that you can tackle problems and things that are going wrong and also advocate for those. Uh, show that you can address problems and keep improving and making things better.

Uh, those three things I think have really helped me move forward in my career of kind of that mindset has made my organizations better, made my people better and let people know that, um, you know, I’m there to try to create the most value I can in the organization.

Kovid Batra: Makes sense. Thank you, Ben. Thank you so much for such a, such a great session, uh, and such great advice. Uh, for today, uh, in the interest of time, we’ll have to stop here, but we would love to know more of your, uh, stories and experiences, maybe on another episode. It was great to have you today here.

Ben Matthews: Thank you, Kovid. It was great to be here.

In this episode of the groCTO Podcast, host Kovid Batra engages in a comprehensive discussion with Geoffrey Teale, the Principal Product Engineer at Upvest, who brings over 25 years of engineering and leadership experience.

‍

‍

The episode begins with Geoffrey's role at Upvest, where he has transitioned from Head of Developer Experience to Principal Product Engineer, emphasizing a holistic approach to improving both developer experience and engineering standards across the organization. Upvest's business model as a financial infrastructure company providing investment banking services through APIs is also examined. Geoffrey underscores the multifaceted engineering requirements, including security, performance, and reliability, essential for meeting regulatory standards and customer expectations. The discussion further delves into the significance of product thinking for internal teams, highlighting the challenges and strategies of building platforms that resonate with developers' needs while competing with external solutions.

Throughout the episode, Geoffrey offers valuable insights into the decision-making processes, the importance of simplicity in early-phase startups, and the crucial role of documentation in fostering team cohesion and efficient communication. Geoffrey also shares his personal interests outside work, including his passion for music, open-source projects, and low-carbon footprint computing, providing a holistic view of his professional and personal journey.

Timestamps

• 00:00 - Introduction

• 00:49 - Welcome to the groCTO Podcast

• 01:22 - Meet Geoffrey: Principal Engineer at Upvest

• 01:54 - Understanding Upvest's Business & Engineering Challenges

• 03:43 - Geoffrey's Role & Personal Interests

• 05:48 - Improving Developer Experience at Upvest

• 08:25 - Challenges in Platform Development and Team Cohesion

• 13:03 - Product Thinking for Internal Teams

• 16:48 - Decision-Making in Platform Development

• 19:26 - Early-Phase Startups: Balancing Resources and Growth

• 27:25 - Scaling Challenges & Documentation Importance

• 31:52 - Conclusion

Links and Mentions

• Geoffrey on LinkedIn

• Kovid on LinkedIn

• Watch this episode on Substack and Youtube

• Listen on Spotify, Amazon Music, and iTunes/Apple Podcasts

Episode Transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of groCTO Podcast. Today with us, we have a very special guest who has great expertise in managing developer experience at small scale and large scale organizations. He is currently the Principal Engineer at Upvestm, and has almost 25 plus years of experience in engineering and leadership. Welcome to the show, Geoffrey. Great to have you here. 

Geoffrey Teale: Great to be here. Thank you. 

Kovid Batra: So Geoffrey, I think, uh, today's theme is more around improving the developer experience, bringing the product thinking while building the platform teams, the platform. Uh, and you, you have been, uh, doing all this from quite some time now, like at Upvest and previous organizations that you've worked with, but at your current company, uh, like Upvest, first of all, we would like to know what kind of a business you're into, what does Upvest do, and let's then deep dive into how engineering is, uh, getting streamlined there according to the business.

Geoffrey Teale: Yeah. So, um, Upvest is a financial infrastructure company. Um, we provide, uh, essentially investment banking services, a complete, uh, solution for building investment banking experiences, uh, for, for client organizations. So we're business to business to customer. We provide our services via an API and client organizations, uh, names that you'd heard of people like Revolut and N26 build their client-facing applications using our backend services to provide that complete investment experience, um, currently within the European Union. Um, but, uh, we'll be expanding out from there shortly. 

Kovid Batra: Great. Great. So I think, uh, when you talk about investment banking and supporting the companies with APIs, what kind of engineering is required here? Is it like more, uh, secure-oriented, secure-focused, or is it more like delivering on time? Or is it more like, uh, making things very very robust? How do you see it right now in your organization? 

Geoffrey Teale: Well, yeah, I mean, I think in the space that we're in the, the answer unfortunately is all of the above, right? So all those things are our requirements. It has to be secure. It has to meet the, uh, the regulatory standards that we, we have in our industry. Um, it has to be performant enough for our customers who are scaling out to quite large scales, quite large numbers of customers. Um, has to be reliable. Um, so there's a lot of uh, uh, how would I say that? Pressure, uh, to perform well and to make sure that things are done to the highest possible standard in order to deliver for our customers. And, uh, if we don't do that, then, then, well, the customers won't trust us. If they don't trust us, then we wouldn't be where we are today. So, uh, yeah. 

Kovid Batra: No, I totally get that. Uh, so talking more about you now, like, what's your current role in the organization? And even before that, tell us something about yourself which the LinkedIn doesn't know. Uh, I think the audience would love to know you a little bit more. Uh, let's start from there. Uh, maybe things that you do to unwind or your hobbies or you're passionate about anything else apart from your job that you're doing? 

Geoffrey Teale: Oh, well, um, so, I'm, I'm quite old now. I have a family. I have two daughters, a dog, a cat, fish, quail. Keep quail in the garden. Uh, and that occupies most of my time outside of work. Actually my passions outside of work were always um, music. So I play guitar, and actually technology itself. So outside of work, I'm involved and have been involved in, in open source and free software for, for longer than I've been working. And, uh, I have a particular interest in, in low carbon footprint computing that I pursue outside of, out of work.

Kovid Batra: That's really amazing. So, um, like when you say low carbon, uh, cloud computing, what exactly are you doing to do that? 

Geoffrey Teale: Oh, not specifically cloud computing, but that would be involved. So yeah, there's, there's multiple streams to this. So one thing is about using, um, low power platforms, things like RISC-V. Um, the other is about streamlining of software to make it more efficient so we can look into lots of different, uh, topics there about operating systems, tools, programming languages, how they, uh, how they perform. Um, sort of reversing a trend, uh, that's been going on for as long as I've been in computing, which is that we use more and more power, both in terms of computing resource, but also actual electricity for the network, um, to deliver more and more functionality, but we're also programming more and more abstracted ways with more and more layers, which means that we're actually sort of getting less, uh, less bang for buck, if you, if you like, than we used to. So, uh, trying to reverse those trends a little bit. 

Kovid Batra: Perfect. Perfect. All right. That's really interesting. Thanks for that quick, uh, cute little intro. Uh, and, uh, now moving on to your work, like we were talking about your experience and your specialization in DevEx, right, improving the developer experience in teams. So what's your current, uh, role, responsibility that comes with, uh, within Upvest? Uh, and what are those interesting initiatives that you have, you're working on? 

Geoffrey Teale: Yeah. So I've actually just changed roles at Upvest. I've been at Upvest for a little bit over two years now, and the first two years I spent as the Head of Developer Experience. So running a tribe with a specific responsibility for client-facing developer experience. Um, now I've switched into a Principal Engineering role, which means that I have, um, a scope now which is across the whole of our engineering department, uh, with a, yeah, a view for improving experience and improving standards and quality of engineering internally as well. So, um, a slight shift in role, but my, my previous five years before, uh, Upvest, were all in, uh, internal development experience. So I think, um, quite a lot of that skill, um, coming into play in the new role which um, yeah, in terms of challenges actually, we're just at the very beginning of what we're doing on that side. So, um, early challenges are actually about identifying what problems do exist inside the company and where we can improve and how we can make ourselves ready for the next phase of the company's lifetime. So, um, I think some of those topics would be quite familiar to any company that's relatively modern in terms of its developer practices. If you're using microservices, um, there's this aspect of Conway's law, which is to say that your organizational structure starts to follow the program structure and vice versa. And, um, in that sense, you can easily get into this world where teams have autonomy, which is wonderful, but they can be, um, sort of pushed into working in a, in a siloized fashion, which can be very efficient within the team, but then you have to worry about cohesion within the organization and about making sure that people are doing the right things, uh, to, to make the services work together, in terms of design, in terms of the technology that we develop there. So that bridges a lot into this world of developer experience, into platform drives, I think you mentioned already, and about the way in which you think about your internal development, uh, as opposed to just what you do for customers. 

Kovid Batra: I agree. I mean, uh, as you said, like when the teams are siloed, they might be thinking they are efficient within themselves. And that's mostly the use case, the case. But when it comes to integrating different pieces together, that cohesion has to fall in. What is the biggest challenge you have seen, uh, in, in the teams in the last few years of your experience that prevents this cohesion? And what is it that works the best to bring in this cohesion in the teams? 

Geoffrey Teale: Yeah. So I think there's, there's, there's a lot of factors there. The, the, the, the biggest one I think is pressure, right? So teams in most companies have customers that they're working for, they have pressure to get things done, and that tends to make you focus on the problem in front of you, rather than the bigger picture, right? So, um, dealing, dealing with that and reinforcing the message to engineers that it's actually okay to do good engineering and to worry about the other people, um, is a big part of that. I've always said, actually, that in developer experience, a big part of what you have to do, the first thing you have to do is actually teach people about why developer experience is important. And, uh, one of those reasons is actually sort of saying, you know, promoting good behavior within engineering teams themselves and saying, we only succeed together. We only do that when we make the situation for ourselves that allows us to engineer well. And when we sort of step away from good practice and rush, rush, um, that maybe works for a short period of time. But, uh, in the long term that actually creates a situation where there's a lot of mess and you have to deal with, uh, getting past, we talk about factors like technical debt. There's a lot of things that you have to get past before you can actually get on and do the productive things that you want to do. Um, so teaching organizations and engineers to think that way is, uh, is, uh, I think a big, uh, a big part of the work that has to be done, finding ways to then take that message and put it into a package that is acceptable to people outside of engineering so that they understand why this is a priority and why it should be worked on is, I think, probably the second biggest part of that as well.

Kovid Batra: Makes sense. I think, uh, most of the, so is it like a behavioral challenge, uh, where, uh, developers and team members really don't like the fact that they have to work in cohesion with the teams? Or is it more like the organizational structure that put people into a certain kind of mindset and then they start growing with that and that becomes a problem in the later phase of the organization? What, what you have seen, uh, from your experience? 

Geoffrey Teale: Yeah. So I mean, I think growth is a big part of this. So, um, I mean, I've, I've worked with a number of startups. I've also worked in much bigger organizations. And what happens in that transition is that you move from a small tight-knit group of people who sort of inherently have this very good interpersonal communication, they all know what's going on with the company as a whole, and they build trust between them. And that way, this, this early stage organization works very well, and even though you might be working on disparate tasks, you always have some kind of cohesion there. You know what to do. And if something comes up that affects all of you, it's very easy to identify the people that you need to talk to and find a solution for it. Then as you grow, you start to have this situation where you start to take domains and say, okay, this particular part of, of what we do now belongs in a team, it has a leader and this piece over here goes over there. And that still works quite well up into a certain scale, right? But after time in an organization, several things happen. Okay, so your priorities drift apart, right? You no longer have such good understanding of the common goal. You tend to start prioritizing your work within those departments. So you can have some, some tension between those goals. It's not always clear that Department A should be working together with Department B on the same priority. You also have natural staff turnover. So those people who are there at the beginning, they start to leave, some of them, at least, and these trust relationships break down, the communication channels break down. And the third factor is that new people coming into the organization, they haven't got these relationships, they haven't got this experience. They usually don't have, uh, the position to, to have influence over things on such a large scale. So they get an expectation of these people that they're going to be effective across the organization in the way that people who've been there a long time are, and it tends not to happen. And if you haven't set up for that, if you haven't built the support systems for that and the internal processes and tooling for that, then that communication stops happening in the way that it was happening before.

So all of those things create pressure to, to siloes, then you put it on the pressure of growth and customers and, and it just, um, uh, ossifies in that state. 

Kovid Batra: Totally. Totally. And I think, um, talking about the customers, uh, last time when we were discussing, uh, you very beautifully put across this point of bringing that product thinking, not just for the products that you're building for the customer, but when you're building it for the teams. And I, what I feel is that, the people who are working on the platform teams have come across this situation more than anyone else in the team as a developer, where they have to put in that thought of product thinking for the people within the team. So what, what, what, uh, from where does this philosophy come? How you have fitted it into, uh, how platform teams should be built? Just tell us something about that. 

Geoffrey Teale: Yeah. So this is something I talk about a little bit when I do presentations, uh, about developer experience. And one of the points that I make actually, particularly for platform teams, but any kind of internal team that's serving other internal teams is that you have to think about yourself, not as a mandatory piece that the company will always support and say, "You must use this, this platform that we have." Because I have direct experience, not in my current company, but in previous, uh, in previous employers where a lot of investment has been made into making a platform, but no thought really was given to this kind of developer experience, or actually even the idea of selling the platform internally, right? It was just an assumption that people would have to use it and so they would use it. And that creates a different set of forces than you'll find elsewhere. And, and people start to ignore the fact that, you know, if you've got a cloud platform in this case, um, there is competition, right? Every day as an engineer, you run into people out there working in the wide world, working for, for companies, the Amazons, AWS of this world, as your Google, they're all producing cloud platform tools. They're all promoting their cloud native development environments with their own reasons for doing that. But they expend a lot of money developing those things, developing them to a very high standard and a lot of money promoting and marketing those things. And it doesn't take very much when we talk just now about trust breaking down, the cohesion between teams breaking down. It doesn't take very much for a platform to start looking like less of a solution and more of a problem if it's taking you a long time to get things done, if you can't find out how to do things, if you, um, you have bad experiences with deployment. This all turns that product into an internal problem. 

‍Kovid Batra: In context of an internal problem for the teams. 

Geoffrey Teale: Yeah, and in that context, and this is what I, what I've seen, when you then either have someone coming in from outside with experience with another, a product that you could use, or you get this kind of marketing push and sales push from one of these big companies saying, "Hey, look at this, this platform that we've got that you could just buy into." um, it, it puts you in direct competition and you can lose that, that, right? So I have seen whole divisions of a, of a very large company switch away from the internal platform to using cloud native development, right, on, on a particular platform. Now there are downsides for that. There are all sorts of things that they didn't realize they would have to do that they end up having to do. But once they've made the decision, that battle is lost. And I think that's a really key topic to understand that you are in competition, even though you're an internal team, you are in competition with other people, and you have to do some of the things that they do to convince the people in your organization that what you're doing is beneficial, that it's, it's, it's useful, and it's better in some very distinct way than what they would get off the shelf from, from somewhere else. 

Kovid Batra: Got it. Got it. So, when, uh, whenever the teams are making this decision, let's, let's take something, build a platform, what are those nitty gritties that one should be taking care of? Like, either people can go with off the shelf solutions, right? And then they start building. What, what should be the mindset, what should be the decision-making mindset, I must say, uh, for, for this kind of a process when they have to go through? 

‍Geoffrey Teale: So I think, um, uh, we within Upvest, follow a very, um, uh, prescribed is not the right word, but we have a, we have a process for how we think about things, and I think that's actually a very useful example of how to think about any technical project, right? So we start with this 'why' question and the 'why' question is really important. We talk about product thinking. Um, this is, you know, who are we doing this for and what are the business outcomes that we want to achieve? And that's where we have to start from, right? So we define that very, very clearly because, and this is a really important part, there's no value, uh, in anybody within the organization saying, "Let's go and build a platform." For example, if that doesn't deliver what the company needs. So you have to have clarity about this. What is the best way to build this? I mean, nobody builds a platform, well not nobody, but very few people build a platform in the cloud starting from scratch. Most people are taking some existing solution, be that a cloud native solution from a big public cloud, or be that Kubernetes or Cloud Foundry. People take these tools and they wrap them up in their own processes, their own software tools around it to package them up as a, uh, a nice application platform for, for development to happen, right? So why do you do that? What, what purpose are you, are you serving in doing this? How will this bring your business forward? And if you can't answer those questions, then you probably should never even start the project, right? That's, that's my, my view. And if you can't continuously keep those, um, ideas in mind and repeat them back, right? Repeat them back in terms of what are we delivering? What do we measure up against to the, to the, to the company? Then again, you're not doing a very good job of, of, of communicating why that product exists. If you can't think of a reason why your platform delivers more to your company and the people working in your company than one of the off the shelf solutions, then what are you for, right? That's the fundamental question.

So we start there, we think about those things well before we even start talking about solution space and, and, um, you know, what kind of technology we're going to use, how we're going to build that. That's the first lesson. 

Kovid Batra: Makes sense. A follow-up question on that. Uh, let's say a team is let's say 20-30 folks right now, okay? I'm talking about an engineering team, uh, who are not like super-funded right now or not in a very profit making business. This comes with a cost, right? You will have to deploy resources. You will have to invest time and effort, right? So is it a good idea according to you to have shared resources for such an initiative or it doesn't work out that way? You need to have dedicated resources, uh, working on this project separately or how, how do you contemplate that? 

Geoffrey Teale: My experience of early-phase startups is that people have to be multitaskers and they have to work on multiple things to make it work, right? It just doesn't make sense in the early phase of a company to invest so heavily in a single solution. Um, and I think one of the mistakes that I see people making now actually is that they start off with this, this predefined idea of where they're going to be in five years. And so they sort of go away and say, "Okay, well, I want my, my, my system to run on microservices on Kubernetes." And they invest in setting up Kubernetes, right, which has got a lot easier over the last few years, I have to say. Um, you can, to some degree, go and just pick that stuff off the shelf and pay for it. Um, but it's an example of, of a technical decision that, that's putting the cart before the horse, right? So, of course, you want to make architectural decisions. You don't want to make investments on something that isn't going to last, but you also have to remember that you don't know what's going to happen. And actually, getting to a product quickly, uh, is more important than, than, you know, doing everything perfectly the first time around. So, when I talk about these, these things, I think uh, we have to accept that there is a difference between being like the scrappy little startup and then being in growth phase and being a, a mega corporation. These are different environments with different pressures 

Kovid Batra: Got it. So, when, when teams start, let's say, work on it, working on it and uh, they have started and taken up this project for let's say, next six months to at least go out with the first phase of it. Uh, what are those challenges which, uh, the platform heads or the people who are working, the engineers who are working on it, should be aware of and how to like dodge those? Something from your experience that you can share.

Geoffrey Teale: Yes. So I mean, in, in, in the, the very earliest phase, I mean, as I just alluded to that keeping it simple is, is a, a, a big benefit. And actually keeping it simple sometimes means, uh, spending money upfront. So what I've, what I've seen is, is, um, many times I've, I've worked at companies, um, but so many, at least three times who've invested in a monitoring platform. So they've bought a off the shelf software as a service monitoring platform, uh, and used that effectively up until a certain point of growth. Now the reason they only use it up into a certain point of growth is because these tools are extremely expensive and those costs tend to scale with your company and your organization. And so, there comes a point in the life of that organization where that no longer makes sense financially. And then you withdraw from that and actually invest in, in specialist resources, either internally or using open source tools or whatever it is. It could just be optimization of the tool that you're using to reduce those costs. But all of those things have a, a time and financial costs associated with them. Whereas at the beginning, when the costs are quite low to use these services, it actually tends to make more sense to just focus on your own project and, and, you know, pick those things up off the shelf because that's easier and quicker. And I think, uh, again, I've seen some companies fail because they tried to do everything themselves from scratch and that, that doesn't work in the beginning. So yeah, I think that's a, it's a big one. 

The second one is actually slightly later as you start to grow, getting something up and running at all is a challenge. Um, what tends to happen as you get a little bit bigger is this effect that I was talking about before where people get siloized, um, the communication starts to break down and people aren't aware of the differing concerns. So if you start worrying about things that you might not worry about at first, like system recovery, uh, compliance in some cases, like there's laws around what you do in terms of your platform and your recoverability and data protection and all these things, all of these topics tend to take focus away, um, from what the developers are doing. So on the first hand, that tends to slow down delivery of, of, features that the engineers within your company want in favor of things that they don't really want to know about. Now, all the time you're doing this, you're taking problems away from them and solving them for them. But if you don't talk about that, then you're not, you're not, you may be delivering value, but nobody knows you're delivering value. So that's the first thing. 

The other thing is that you then tend to start losing focus on, on the impact that some of these things have. If you stop thinking about the developers as the primary stakeholders and you get obsessed about these other technical and legal factors, um, then you can start putting barriers into place. You can start, um, making the interfaces to the system the way in which it's used, become more complicated. And if you don't really focus then on the developer experience, right, what it is like to use that platform, then you start to turn into the problem, which I mentioned before, because, um, if you're regularly doing something, if you're deploying or testing on a platform and you have to do that over and over again, and it's slowed down by some bureaucracy or some practice or just literally running slowly, um, then that starts to be the thing that irritates you. It starts to be the thing that's in your way, stopping you doing what you're doing. And so, I mean, one thing is, is, is recognizing when this point happens, when your concerns start to deviate and actually explicitly saying, "Okay, yes, we're going to focus on all these things we have to focus on technically, but we're going to make sure that we reserve some technical resource for monitoring our performance and the way in which our customers interact with the system, failure cases, complaints that come up often."

Um, so one thing, again, I saw in much bigger companies, is they migrated to the cloud from, from legacy systems in data centers. And they were used to having turnaround times on, on procedures for deploying software that took at least weeks or having month-long projects because they had to wait for specific training that they had to get sign off. And they thought that by moving to an internal cloud platform, they would solve these things and have this kind of rapid development and deployment cycle. They sort of did in some ways, but they forgot, right? When they were speculating out, they forgot to make the developers a stakeholder and saying, "What do you need to achieve that?" And what they actually need to achieve that is a change in the mindset around the bureaucracy that came around. It's all well and good, like not having to physically put a machine in a rack and order it from a company. But if you still have these rules that say, okay, you need to go in this training course before you can do anything with this, and there's a six month waiting list for that training course, or this has to be approved by five managers who can only be contacted by email before you can do it. These processes are slowing things down. So actually, I mentioned that company that, uh, we lost the whole department from the, from the, uh, platform that we had internally. One of the reasons actually was that just getting started with this platform took months. Whereas if you went to a public cloud service, all you needed was a credit card and you could do it and you wouldn't be breaking any rules in the company in doing that. As long as you had the, the right to spend the money on the credit card, it was fine.

So, you know, that difference of experience, that difference of, uh, of understanding something that starts to grow out as you, as you grow, right? So I think that's a, uh, a thing to look out for as you move from the situation when you're 10, 20 people in the whole company to when you're about, I would say, 100 to 200 people in the whole company. These forces start to become apparent. 

Kovid Batra: Got it. So when, when you touch that point of 100-200, uh, then there is definitely a different journey that you have to look up to, right? And there are their own set of challenges. So from that zero to one and then one to X, uh, journey, what, what things have you experienced? Like, this would be my last question for, for today, but yeah, I would be really interested for people who are listening to you heading teams of sizes, a hundred and above. What kind of things they should be looking at when they are, let's say, moving from an off the shelf to an in-house product and then building these teams together?

Geoffrey Teale: Oh, what should they be looking at? I mean, I think we just covered, uh, one of the big ones. I'd say actually that one of the, the biggest things for engineers particularly, um, and managers of engineers is resistance to documentation and, and sort of ideas about documentation that people have. So, um, when you're again, when you're that very small company, it's very easy to just know what's going on. As you grow, what happens, new people come into your team and they have the same questions that have been asked and answered before, or were just known things. So you get this pattern where you repeatedly get the same information being requested by people and it's very nice and normal to have conversations. It builds teams. Um, but there's this kind of key phrase, which is, 'Documentation is automation', right? So engineers understand automation. They understand why automation is required to scale, but they tend to completely discount that when it comes to documentation. So almost every engineer that I've ever met hates writing documentation. Not everyone, but almost everyone. Uh, but if you go and speak to engineers about what they need to start working with a new product, and again, we think about this as a product, um, they'll say, of course, I need some documentation. Uh, and if you dive into that, they don't really want to have fancy YouTube videos. And so, that sometimes that helps people overcome a resistance to learning. Um, but, uh, having anything at all is useful, right? But this is a key, key learning documentation. You need to treat it a little bit like you treat code, right? So it's a very natural, um, observation from, from most engineers. Well, if I write a document about this, that document is just going to sit there and, and rot, and then it will be worse than useless because it will say the wrong thing, which is absolutely true. But the problem there is that someone said it will sit there and rot, right? It shouldn't be the case, right? If you need the documentation to scale out, you need these pieces to, to support new people coming into the company and to actually reduce the overhead of communication because more people, the more different directions of communication you have, the more costly it gets for the organization. Documentation is boring. It's old-fashioned, but it is the solution that works for fixing that. 

The only other thing I'm going to say about is mindset, is it's really important to teach engineers what to document, right? Get them away from this mindset that documentation means writing massive, uh, uh, reams and reams of, of text explaining things in, in detail. It's about, you know, documenting the right things in the right place. So at code-level, commenting, um, saying not what the code there does, but more importantly, generally, why it does that. You know, what decision was made that led to that? What customer requirement led to that? What piece of regulation led to that? Linking out to the resources that explain that. And then at slightly higher levels, making things discoverable. So we talk actually in DevEx about things like, um, service catalogs so people can find out what services are running, what APIs are available internally. But also actually documentation has to be structured in a way that meets the use cases. And so, actually not having individual departments dropping little bits of information all over a wiki with an arcane structure, but actually sort of having a centralized resource. Again, that's one thing that I did actually in a bigger company. I came into the platform team and said, "Nobody can find any information about your platform. You actually need like a central website and you need to promote that website and tell people, 'Hey, this is here. This is how you get the information that you need to understand this platform.' And actually including at the very front of that page why this platform is better than just going out somewhere else to come back to the same topic."

Documentation isn't a silver bullet, but it's the closest thing I'm aware of in tech organizations, and it's the thing that we routinely get wrong.

Kovid Batra: Great. I think, uh, just in the interest of time, we'll have to stop here. But, uh, Geoffrey, this was something really, really interesting. I also explored a few things, uh, which were very new to me from the platform perspective. Uh, we would love to, uh, have you for another episode discussing and deep diving more into such topics. But for today, I think this is our time. And, uh, thank you once again for joining in, taking out time for this. Appreciate it.

Geoffrey Teale: Thank you. It's my pleasure.

In this episode of the groCTO Originals podcast, host Kovid Batra engages in an insightful conversation with Christopher Zotter, the Head of Digital Engineering at Sky, Germany. Christopher brings a wealth of experience, including a decade of leading engineering teams and founding a software development agency.

‍

‍

Known for his unique leadership philosophy, Christopher believes in the power of building trust, embracing failures, and fostering a transparent culture. He shares his journey from an apprentice in Germany to a leadership role, emphasizing the importance of hands-on experience and continuous learning. The discussion delves into the challenges and strategies of managing culturally diverse remote teams, effective communication, and transitioning from legacy systems to cutting-edge technologies.

Christopher also highlights the significance of being a role model and integrating community involvement into one’s career. This episode offers a deep dive into the principles and practices that can guide leaders in nurturing successful global development teams.

‍

Timestamps

• 00:00 — Introduction

• 00:49 — Welcome to the groCTO Podcast

• 01:39 — Meet Christopher: Personal and Professional Background

• 03:34 — Christopher’s Career Journey and Key Learnings

• 05:38 — The Importance of Community and Respect in Leadership

• 07:42 — Balancing Side Projects and Career Growth

• 11:33 — Leading Global Teams at Sky

• 15:20 — Challenges and Strategies in Remote Team Management

• 21:48 — Navigating Major System Migrations

• 24:26 — Ensuring Team Motivation and Embracing Change

• 27:35 — Using Metrics to Drive Improvement

• 30:59 — Conclusion and Final Thoughts

‍

Links and Mentions

• Christopher on LinkedIn

• Kovid on LinkedIn

• Watch this episode on Substack and Youtube

• Listen on Spotify, Amazon Music, and iTunes/Apple Podcasts

‍

Episode Transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of groCTO podcast. And today with us, we have a very special guest. Uh, he’s Head of Engineering at Sky, Germany. He is also the founder of a software dev agency, and he has been leading engineering teams from past 10 years now. And today, we are going to talk to him about how to lead those global dev teams because he has been an expert at doing that. So welcome to the show, Christopher. Great to have you here.

Christopher Zotter: Thanks for having me. I’m really excited to be here, part of the great podcast. I get to know this and also the last months and with key insights and hope I can provide some of my learnings from the past experience also to your great audience. So happy, happy to be here.

Kovid Batra: I’m sure you can do that. All right. But before we get started into, um, knowing something about your team and your, uh, areas of expertise of how you lead teams, we would love to know a little bit about you. Like something that LinkedIn doesn’t know, something that is very impactful in your life, from your childhood, from your teenage. Um anything that you would like to share

Christopher Zotter: So first of all, the most important part is not business, it’s my family. So I’m a proud father of two kids and I have a lovely wife. So this is the foundation of everything that I can do, also my job properly to be honest and gives me energy. Um, and also what is not on LinkedIn or it’s on LinkedIn, but it’s worth mentioning is I didn’t study anything. So you see now my title, which is, I also need to reflect, impressive to be honest, also to myself, but I only did a normal apprenticeship in Germany to work as a software developer. So I really start at the core of the things, but now I managed to do so. So I make my, my way through doing the things, getting hats, hands-on, and don’t fear to make mistakes. I learned from things, um, I did, I deployed the hard coded ID and tested it on production while on a software in the past. Yeah, that never happened again. So I really get hands-on and get these kinds of experiences. Um, And what is also, I think, important is to not only focus on, on the software things, but also doing some things for the society, for the community beside the work, which, which gave me the balance. So this is not on LinkedIn. This is something that has also very positive impact on, on my, on my past. So, um, yeah, that’s roughly where, who am I, but I can also continue a bit of my journey to, to becoming that position if you’re interested in too.

Kovid Batra: Sure, why not? Please go ahead.

Christopher Zotter: Um, yeah, then my, my, as I said, I, I did an apprenticeship in Germany, which takes mostly three, three and a half years, and I had the chance to work at the very small company. It’s not, it’s not, the company doesn’t exist anymore, I think, but I got the chance to work in a very small team with great experts, and I got responsibility from day one. So I didn’t develop something for the trash. It was really then something which can go to production, of course, with review process, et cetera. And again, the advice I can already share is try to do as many things as possible. Even if in the younger years, you have the time. I see that now with family, the priority shifts obviously, but use the time you have, do side projects if possible, because getting hands on the things, nothing can beat experience. And this is, I think also the big learning I had over the, uh, over the time is I get all of my, um, promotions all of my way through the career, starting from an apprenticeship, junior developer, senior developer, lead developer, and now Head of Engineering, um, through my experience. I did hands-on and I can prove, showcase what I did starting from code skills, simple HTML page for with the, with the simple contact form, everything. So I get my hands on different things to get, uh, get, get the knowledge, and I think knowledge and experience beats most of the, of the things, but you can’t study it. Um, you need to get hands-on. Yeah, just briefly, and now I’m here.

Kovid Batra: Yeah, no, I think that was a very, very nice intro, and I think we now, we now know you a little more. And one, one thing that I really loved when you said that, uh, it’s not just about work. Uh, there is family, there’s community that you want to do for. So I’m sure this community thing which you are doing, uh, this, this would have helped in shaping up, uh, some level of leadership, some level of giving back. I think leadership is another name for giving back. So from there, it should be coming in. So can you share some of your experience from there that helped you in your career moving from let’s say an IC to an EM and then growing to a leadership position?

Christopher Zotter: I like that you say leadership is giving back. Yes. Um, I didn’t see it that way, but it totally echoes with me. Um, at the end, it’s all about the people. Um, I think we have, we have also on this planet, so many, uh, wars happening, so many people working against it, and I’m, I try to do the opposite because we’re all humans. And I learned also through working for the community in a certain way. So I, I worked for one year to support disabled people, to go with them to school, young people, and there I learned, hey, these are all humans and everybody’s trying their best. Also now, in my position, it’s about people, it’s about getting their feelings, getting their circumstances and getting their perspectives, getting their culture. We will come to the topic later, um, because there are different cultures. We are working together, even in software development, you’re across the globe. Um, and there, you need, always need to, to think about and not act like everybody has the pressure to get it done, get it done. And so, we need to consider that humans behind and let’s find to create a win-win situation for everybody that everybody feels confident, confident and comfortable and respected. And, um, this I learned, I’m a very value-driven person. And my key value is respect because respect is there for everything no matter what you’re doing. Um, it starts going into the office, the cleaning person, greet the same way as you greet the CEO. Um, it’s, it’s, we are all humans, everybody’s putting the bits and pieces together and this sometimes we, we forget in our daily business. So, um, this is what I definitely learned from being there, putting, giving away something for the community or whatever there is. So yeah

Kovid Batra: Perfect. Perfect. And another interesting piece in your career is, uh, no academic background, uh, in engineering and then doing things hands-on. And then, uh, you are working on a side business as well, which you just mentioned where you, you recommend people to do that in the early ages, because that’s where you get the most of your experience and knowledge to do things, how to complete things. How exactly that has contributed in your career growth? Because I also come from a similar experience. I would love for you to explain it if this has contributed in some way

Christopher Zotter: Okay. Yeah, great. Um, that’s yeah. I started my side business also, I think now eight, nine years ago. Um, and by the way, this will now come to an end right now. It’s already more or less ended because my, my daily job requires full attention plus family. There is no time and you need to also to say no to the things. Um, but in that time it was, uh, it was pretty important for me because what I did is the things I learned in my company, in my apprenticeship, um, I tried to do then some projects for first, for my own and then for my inner circle. So for some friends, they had also built up a company, whatever that is, need a home page, need a web application. Um, and I built it on my side business. Then to adapt the things I learned in my, in my daily business and enhance it on a certain way in my environment to test it to work against and enhance the knowledge. Try things out if they’re working there in a smaller, bits of pieces, not in the big company where you’re working on. Um, helps me a lot to grow, trying out, trial and error. Uh, and at least that’s the experience you get and this experience, if you bring it back to your company, if you want it to make career, um, this is where you can benefit from, and yeah, that knowledge beats everything at the end.

Kovid Batra: Sure. I think for me, like I also had a side business and how it has helped me is that I was interacting with the customers directly, right? So that was for me a great experience, which when you are in a larger organization where you have people doing the front end job and then you are getting just the requirements, that relatability with the problem statement with the audience is much lesser So I think that way it has helped me much more from that point of view.

Christopher Zotter: Interesting, because we at Sky we have, our claim is the, the customer or the users in the centric of everything and I have the, the I, I’m a Sky, a soccer fan, and, and, and Sky probably just to name it what we are doing, um, because there is probably a conflict with your audience from India because Sky channel there is known and it’s a bit of a different thing than what Sky Germany is doing. So, um, for, for, for you, we are the major entertainment provider here in Germany called pay tv. We have sports, um, mostly the Bundesliga, so the German soccer football, uh, um, rights we have in place or some, uh, own produced movies. Uh, you can watch Netflix and stuff over our platform, either it’s streaming or it’s our Q receiver. And, um, as I’m a big, Bayern Munich fan, I use Sky or previously it was named Premier, uh, for a long, long time ago. So I’m also the customer on the one hand side to use our product and know what’s going on and know the issues and can bring it then into and learn from it on, on the other side, which is now a great benefit, but I can echo it. It’s, it’s definitely one of the key things to know who’s your audience and what are the users and what are the customers and go out and get to know them, what is their behavior in order to deliver them the best product, the best experience they can, they can have.

Kovid Batra: Sure, sure. Absolutely. All right. I think, uh, that was, outside what you do at Sky, most of it, uh, we discussed. Now moving in from that note into the world of Sky where you are heading teams and, uh, most of them are remotely working from India, from Germany and other parts of the world. So first thing I would like to understand, like, how things have changed in the last four or five years from your perspective? Um, you have grown from a manager to a leadership profile. What were those things that came into, uh, into your role as a responsibility, uh, that you took up with these global teams that help you grow here? How was the experience the last four years?

Christopher Zotter: It was an amazing ride. Um, I think every, every, every step has their challenges in, in a certain way. Um, being a developer, you can then go to either other developers or have your scrum master and feature teams. Um, but coming to be, um, a leader for such, such a, such a big team. So my team is currently, we have five people here in Germany and we have 15–16 right now sitting in Chennai, India. You have to think about different things. You have to think about the team harmony, how the people working together, you have to think about communication. You have to think about values, how everything works then together, and not only getting the code done in a proper way with all of their quality checks in between, but also that I need now to consider there helps me to get the experience in beforehand to know what is technically possible, what we need to do in order to shape, um, the best and the most effective process. We will talk about that, I think, later also, what can be done there. But also, um, yeah, to consider, as I said previously, the different perspectives. Everybody is on a different level, um, has different circumstances. Somebody is now getting it further earlier. So probably not that much focus on work, which is fine. We need to deal with that also to support wherever we can. Somebody is getting sick and all of the things you need to consider. Um, and it’s, it was also a big change for me and I’m still in progress to be honest, because I started my journey as a developer and I love to code also. Um, but so much coding in that position is not possible anymore. And you need to build up your team where you can trust and give them the task and get it back done or get it, getting the right feedback, uh, whatever that is. So this is one of the things to build trust to having a lot of conversations. So having a lot of coffee in the office with the different guys to get to know what’s going on. And of course, um, you are now, or I am now in a position to having, uh, stakeholders, uh, communication with our CTO, COO, uh, different, different areas, which you don’t have normally as a developer that you only get the requirements. So again, I’m a bit next to the customer, right? Because I can also bring my bits and pieces into some of the features and decisions. Um, and this, this is one of the biggest changes to, to go out of the real, getting the hands-on and, and yeah, bringing the layer on top to prepare everything and protect everything that my developers can really focus or my architects can focus on the work without any disruption and make the work as smooth and as fast as possible.

Kovid Batra: But I think in your case, um, as compared to, uh, I would say, a single culture, a uniculture team, um, your case is different. You have people in India, across the globe. This collaboration, uh, I’m sure this becomes a little difficult and it’s a challenge of a lot of companies after COVID, uh, because things have gone remote and people are hiring from across the borders. How, how it has been an experience for you to handle these remote teams who are from different culture? And what, what really worked out, what didn’t work out some of those examples from your journey?

Christopher Zotter: Uh, yes, this is definitely a challenge and I have to say I’m the only German-speaking guy in my team. So we are a German company, but I’m the only German speaking guy. So I, in Germany, we have also some Indian colleagues, some from Russia, uh, sorry, from Ukraine. We have some from, uh, Egypt. So it’s mixed. And as, as you said, a lot of people are coming from, from Chennai, India. And imagine this is about 4, 000 kilometers difference. Um, a lot of, uh, at the end, and we have two different cultures. And this was the biggest learning I got to know is at the beginning, just an example, a yes doesn’t mean a yes. Um, we had some requirements, we talked about that and I got the feedback, “Yes.” Okay, and then I assumed the ticket will be done, but it was only, “Yes. I got to know that I need to do that.” But not, “Yes, I understand it.” So there’s a communication, a learning over the time and which the whole company has to do. So we all need to transform here at Sky and also at Comcast Engineering in India that we are going together, find a way of communication, get to know the, the other, uh, the other culture, the other people, the other behavior, how they’re working.

Um, and of course, I’m also a fan of remote working, but also a fan of getting in touch, uh, getting into, into personal conversations with people, um, not only, uh, not via camera, but in person. So that’s also why we have some mandatory days at Sky where we need to go to the office. But I’ll also be there in India once or twice a year, even if it’s a long travel and, you know, challenge with family, but, um, the investment is, is worth it. Um, I got to know the, the Indian culture very well. Um, and it’s also kind to them to show appreciation. So they recognize, “Hey, they really take care about us and we’re not only there outsource for things, get the things done.” And as I said, I’m taking care of, at least my goal is to take care about the people, to treat them with respect and try to find the way together. And if you’re having the 1-on-1 conversations in person, get to know the culture, go to temples, get to know all of the things we’re running around, what they, what, the food. Oh! It’s amazing in India. Um, everything. Um, then you grow together and then this makes, after my second visit, I can say, um, the communication was a totally different one. So I got to know then, or I feel really the trust of my team then to say, “Hey, Christopher, this doesn’t work.” So they say and you know, this is a cultural topic because in india, it’s normally, uh, it’s they’re not used to saying, “No, it’s not working.” They say yes and try to make it work anyhow, but it doesn’t help in the, in the daily business. So it’s better to say, “Uh, I need help at the first place and then we can get it done as a team.” But coming to that point, that’s one of the biggest challenges I faced. It’s still not perfect yet, but this is where we think always about what is their circumstances? Is that really yes, they got it or do they need some other kind of help, um, that we can provide them to them?

Kovid Batra: I think a very, very good example. Being an Indian, I can totally relate to it. Uh, we go with that mindset and at times it is not, uh, beneficial for the business as such, but there is a natural instinct which says, okay, let’s say yes. Let’s say, “Yeah, we are trying.” And try to fight for it maybe. Not sure what exactly drives that, but yeah, a very, uh, important point to understand and look at.

All right. So I think this is, this is definitely one example, which, uh, our audiences, if they are leading some teams from India, would keep in mind when they’re leading them. Anything else that you, that comes to your mind that you would want to do to ensure good communication or collaboration across these teams?

Christopher Zotter: I think when we stick to the topic is to be the role model. Um, I said it in my introduction. I deployed something hard coded to production with an ID. I bring that always as an example to say “Yes, this was a failure.” But I took a great learning out of it. So to establish these kind of things to acting as a role model, especially as a leader, because then you lead and the people will follow you and you should.. My claim is to act as a leader who is not there. I’m the same. I only have another title, but we are all equal. I can’t do my work without you and the other way around. So we’re one team, no matter who has, which level of a junior or, uh, whoever that is, so working together as a team and be there and support everybody. And I say always, “If they don’t need me anymore, I did my job perfectly.” Um, so this is what I, what I’m aiming for. No, to be really a leader, to be a role model, to, to say, “Hey, this doesn’t work.” “Oh, this was my failure of the week.” That’s what we probably now try to establish failure of the week that everybody, uh, put that failure into learning and share that with the audience. Um, it breaks a bit everything. So they see, “Hey, they are now doing it. So I can do that as well.” And this takes away the fear of if I say too much things I can’t do, I get fired. That’s the most fear, I also get to know why talking to the people. Um, as I know, that’s not the case. I appreciate it more if you say it to me instead of hiding it. So, um, yeah, this is definitely, definitely the thing.

Kovid Batra: True. I think one example that comes to my mind, uh, when I talk to my, um, friends and colleagues who are working across different organizations, like Amazon, Microsoft, world, handling teams from India for US or vice versa. Um, whenever there is huge transitions, let’s say from legacy systems to new architecture, they are like for 6 to 10 to 12 months, I’ve seen they were in a stressed situation where they’re saying like, “The team is not here communicating and managing that stuff is becoming difficult for me.” They were making multiple trips to, to the, uh, to the main home ground and then getting things done. So in your case, you, you guys are remote-first and I’m assuming most of the times you’re dealing with such situations remotely. So has there been a situation where you had to migrate from some legacy systems to new systems, new architecture, and, uh, there were challenges on that journey?

Christopher Zotter: Um, we’re currently in. Uh, so we are in a big transformation phase at Sky. So this is taking off for some years. And, uh, let’s say we in the final steps to be there to create, we started everything, challenged every technology we had, um, a few years back and say, “What can we provide best to our customers? So what technology is cutting edge? What technology is bringing our faster cycles of deployment, faster cycles of changes?” And challenged our content management system up to all completely our CRM system. Um, and that’s, that’s, we’re currently in the middle of it. Um, the challenge is obviously, yes, you always did in the past, something is not documented, some processes are there, and not everybody’s trying to challenge all of the things which happened in the past but it’s exactly the right time to do so, to, to challenge what was there. Do we really need to convert it and migrate it to a new system or not? Um, and get better into doing that. So take the learnings, challenge it and bring it to the new system. And that we’re in the middle of, um, that’s why, why I also started at Sky to, to, to kick-off that journey and at this part of time I was the developer who started it and, um, now i’m happy to say that we are in a very good shape. So we are live with, uh, with most of the things already, the migration is still going on, but um, our sales journey and stuff is already live and going to customers. We have proper monitoring set up. We have good testing in place. So, um, yeah, but again, what I said is, um, I see also now the old worlds, the old systems, um, and we, we all have to be open-minded to getting, getting transferred to new things, um, to always learn every day, especially, I think your audience knows that pretty well. In software development or development is that every day is a new tool, every day is a new change, a new version and new things you need to update it here and there. To always stick to that level is a challenge we face every day, but we’re trying to do our best to always get the latest version and the best features out for our customers.

Kovid Batra: Sure. I think one very good point you highlighted, like as a leader, uh, as a manager, you might still realize that this change is for the good, and this change is going to impact us in much better ways for the business point of view, from our engineering point of view. But when it comes to the people who are actually developing, coding, uh, how do you ensure like such big migrations come handy, people don’t have resistance? Because giving a plan and a strategy, uh, is definitely one thing which you have to craft carefully. But one very important thing goes into the, the innate motivation of people to execute it so that they think of use cases, make it even better than what you have planned for, at least on the paper. So what, what do you do to ensure such kind of, uh, culture shift or such kind of culture being instilled in people to embrace that change?

Christopher Zotter: Um, first of all, I think if you are yourself your own customer, this is the first thing. So you need to consume your own product as well. So dog food it. Um, It’s a bit difficult with India, but we have possibilities to also use Sky at least in the office to play around, to watch the movies to watch the things, um, that we can identify with that. That’s the first thing that we know what we’re doing to know what, how our customers are acting and I always said is I use a lot of data, um, to just, hey, how many visits do we have on these pages? Or check this feature, has this impact on our sales, whatever that is. So using that data to show, hey, the button you’re changing right now is not only a color change. This has a psychologically thing. If you change it to green one to give a positive feedback to our customers that they would click then and buy the things, just stupid example. Um, And you will see when we put that on production or do some user tests, you see directly your impact and it would go to millions of customers. And coming out and bringing that every time, every day to the table, um, opens up, hey, the things they’re doing, they have a real impact and this is everybody can be proud of. And I said always, hey, look, if you show that to your family and your mother, this, you can, and that’s a good thing at that development. You can show the things, uh, if you’re doing an API, it’s also important, but it’s a different thing. That’s why I love that development to say, you can showcase the things. Um, so we’re constantly measuring the things constantly, constantly improving. And this gives also the, the, the developers a sense of, “Hey, this is really important, what I’m doing here and this is the impact.” Um, and in order not to, you know, putting too much pressure on the people. We always have, uh, uh, we are working in a safe environment, so a scaled agile framework where we plan the next three months ahead and the planning is done by the developers and the developers commit to this, um, uh, plan provided by the business and they commit what they can achieve. So they have then the plan and they have an influence on that. And this gives us a balance to first be predictable, but also, uh, make the developers identify with things they’re developing.

Kovid Batra: Got it. Got it. Makes sense. I think it revolves around creating those right incentives, creating those right experiences for the developers to understand and relate to. Uh, so while, while you’re talking about having those right incentives, measuring the impactful areas, uh, I’m sure you must be using some level of metrics, some level of processes to ensure that you continuously improve on these things, you continuously keep working on the impactful areas. So, uh, at, at Sky or at your previous organizations, what kind of frameworks you have deployed? What kind of metrics you look at for different initiatives?

Christopher Zotter: Um, first of all, uh, I got to know that only what you measure, you can improve. That’s the one claim I always get to know. Um, it can be a weight, but, uh, then you see also some improvements. So just an example. Um, I’m, I’m a developer. So, uh, let’s start with the coding part, probably GitHub. Um, yeah, I mean, GitHub, a lot of different cycles, um, starting from creating a pull request, uh, reviewing a pull request, checking if it gets rejected or not, how many comments you get, um, uh, up to, it’s connected to CI/CD where some of our testing frameworks are running against different features we wanted to merge. Um, this is one of the key indicators where we say, um, or in the past also where we, we were looking into and say, “Okay, um, how big is a pull request? How much time does it take that it gets reviewed?” Um, all of these KPIs, um, or there are KPIs behind that, but the, my goal is that I get identified if I need to go deeper into some of the topics to find probably some root cause. Um, the same happened on, on the delivery level. So not on the code level but on the delivery level where we have our tickets, our story points and where we can roughly say a story point is one day more or less, um, and if I see there’s one story point, but the ticket is in development for five days, um, I need to go into, uh, into communication, say, “Hey, are there any challenges?” Um, or, “Do you need some support? Is there a knowledge gap?” Or if a feature has too many bugs after that assigned, um, after it’s merged to our development stage, um, we probably have a lack of quality. It could lead to a lack of, uh, lack of yeah knowledge here and there. So this is my, my measures to not to and this is again coming into a culture topic, um, to use the data the right way and not to say, “I micromanage you. You get fired if you don’t hit the KPIs.” No. Um, the key is we need to have in these KPIs that I get an alert as early as possible that I need to go into communication and find a way to take the people by hand and work together against some strategies. Could be knowledge sharing, could be coachings, could be whatever that is. It could also be that I got identified. We have some issues with one of the product owners, for example, who doesn’t provide all of the details in a ticket beforehand. It comes to development. It can be a lot of things, but if I don’t do that, I don’t have or at least I get to know that by a lot of weeks later, and then it’s too late. So gives me an indicator where I need to get into communication to improve, um, the process, to improve, um, the people, to make them better and, and yeah, to support them.

Kovid Batra: Make sense. I think very rightly said, um, using these metrics always makes sense, but how you’re using it will ultimately be the core thing, whether they are going to help you or they can give back. So yeah, I think great advice there, Christopher. And I think in the interest of time, uh, we’ll have to take a pause here, though I, I really loved the discussion and I would love to deep dive more into how you’re managing your teams, but maybe another episode for that. Uh, and once again, uh, thanks a lot for taking our time, sharing your experience at Sky, telling us about yourself. Thank you so much.

Christopher Zotter: Thanks for having me. Uh, thanks for having me. It was a pleasure to be here. Happy to come a second time to dive deep, uh, deep dive into some of the topics, um, if interested and, uh, also kudos to you. It’s a great podcast. I love to listen to it on my own because I also pick some nuggets out of that each of the time. So keep, keep pushing that. Thanks a lot.

Kovid Batra: Thank you so much, Christopher.

In this episode of the groCTO Originals podcast, host Kovid Batra engages with Vilas, an accomplished engineering leader with significant experience at companies like Walmart, Netflix, and Bill.com.

‍

‍

Vilas discusses the concept of Developer Experience (DevEx) and how it extends beyond simply providing tools. Vilas highlights the importance of enabling developers with frictionless processes and addresses the multidimensional challenges involved. The conversation delves into Vilas’s journey in DevEx, insights from designing platforms and enabling developer productivity, and the necessity of engaging with key opinion leaders for successful adoption. Vilas shares personal anecdotes and learning experiences, stressing the significance of treating developer enablement as a product and encouraging collaboration.

The discussion concludes with advice for those stepping into DevEx roles, underlining the evolving significance of this field in the industry.

Timestamps

• 00:00 — Introduction

• 00:51 — Meet Vilas: The Man Behind the Expertise

• 04:28 — Diving into DevEx: Concepts and Definitions

• 06:32 — The Evolution of DevEx: From Platform to Productivity

• 13:19 — Challenges and Strategies in DevEx Implementation

• 31:34 — Metrics and Measuring Success in DevEx

• 37:46 — Final Thoughts and Parting Advice

Links and Mentions

• Vilas on LinkedIn

• Kovid on LinkedIn

• Watch this episode on Substack and Youtube

• Listen on Spotify, Amazon Music, and iTunes/Apple Podcasts

Episode Transcript

Kovid Batra: Hi everyone, this is Kovid, back with a new episode of groCTO podcast. Today with us, we have a very special guest. He’s an accomplished engineering leader, has been building successful teams from last 15 years at Walmart, Netflix, Bill.com, and with his expertise in DevEx and Dev productivity, he’s now very well renowned. So we found Vilas through LinkedIn and, uh, his posts around DevEx and Dev Productivity, and I just like started resonating with it. So, uh, welcome to the show, Vilas, great to have you here.

Vilas Veeraraghavan: Thanks Kovid. I am grateful for getting to meet people like yourself who are interested in this topic and want to talk about it. Um, so yeah, I’m looking forward to having a discussion.

Kovid Batra: Perfect. Perfect. But Vilas, before we get started, um, this is a ritual for groCTO podcast.

Vilas Veeraraghavan: Okay.

Kovid Batra: Uh, we will have to like, uh, know you a little more beyond what LinkedIn tells about you. So tell us about yourself, like your hobbies, how do you unwind your day? Something from your childhood memories that tells who Vilas today is. So, yeah.

Vilas Veeraraghavan: Okay. Okay. That’s, I was not prepared for it, but I’ll, I’ll share it anyway. Um, so I am a, the thing that most people don’t know about me, uh, is that I am a big movie fan. Like I watch movies of all languages, all kinds, and I pride myself on knowing, uh, most of the details around why the movie was made. Um, like, you know, I really want to get into those details. Like I want to get the inspiration of behind the movie. It’s almost like appreciating art. You want to get into like, why did this person do this? Uh, so I’m very passionate about that. Um, so that’s, that’s something that people don’t necessarily know. Um, and apart from that, like, I, I enjoy, uh, running and walking. It sounds weird to say I enjoy walking, but I genuinely do that. Like that’s my, that’s the place where I do most of my thinking, analysing, all of that.

Kovid Batra: Perfect. Which one’s the weirdest movie that you have watched and like found out certain details which were like very surprising for you as well?

Vilas Veeraraghavan: I don’t know if I would say weird, but you know, all of, every director, every film director has one movie that, you know, they have always yearned to make. So they, their entire career goes in sort of trying to get to that movie, right? Because it’s their magnum opus, right? That’s the, that’s the term that people use. Um, I always find that fascinating. So I always try to look for, for every director, what was their magnum opus, right? Uh, so for example, for Raj Kapoor, it was Mera Naam Joker, and that was his magnum opus. Like what went into really making that film? Why did he make it? Like what? And you’ll realize also that their vision, the director’s vision is actually very, um, pure in those, in a sense that they will not listen to anyone else. They will not edit it short. They will not cut off songs or scenes. It’s such a, uh, important thing for them that they will deliver it. So I always chase that. That’s the story I chase.

Kovid Batra: Got it. Perfect. I think that was a very quick, interesting intro about yourself. Good to know that you are a movie buff. And now like, let’s, let’s move on to the main section. So just for the audience, they know, uh, we’re going to talk about DevEx, dev productivity, which is Vilas’s main area of expertise. And his, his quote from my last discussion with him was that DevEx is not just, uh, some tools being brought in, some dev productivity tools being brought in. So I think with that note, uh, let’s get started, Vilas.

Vilas Veeraraghavan: Sure.

Kovid Batra: What according to you defines DevEx? Like let’s start with that first basic question. What is DevEx for you?

Vilas Veeraraghavan: Okay. So before I jump into that, I want to give you, give the context behind that statement I said, right? Um, it’s not about throwing tools at someone and expecting that things will get better. Um, I learnt that over time, right? I was a big fan of automation and creating tools to help people, and I would often be surprised by why people are not using them the way I thought they should. And then I realized it’s about the fact that their process that they are following today does not allow them to include this. There is too much friction that brings that. If they bring in a new tool, it’s too much friction. And then I realized also what the people, about management, all of that stuff. So it’s a very, it’s a, it’s a multidimensional problem. And so that, I just want to set that context because that’s how I defined DevEx, right? DevEx or I, as I like to call it more about dev enablement, is about making sure that your developers have the best possible path through which they can deliver features to production. Right? And so it’s, it’s not about productivity. I think productivity is inherent in the fact that if you enable someone, uh, you are providing them with the shortest paved road kind of thing to get to their destination. They will become productive. Uh, it’s sort of, uh, automatic extrapolation, if you will, from that. So that’s the reason why I, that’s how I defined DevEx. Um, but it’s important because that’s how, that was my journey to learn as well.

Kovid Batra: So I think, uh, before the discussion started, we were talking about how you got into this role and how DevEx came into play. So I think, uh, let audience also hear it from you. Like, we know like DevEx is a very new term. Uh, this is something that has been introduced very lately, but back in the day, when you started working on things, what defined DevEx at that time and how you got involved in it?

Vilas Veeraraghavan: Um, so back in the day when I started working in a software organization, the thing that drew me to, uh, what we would call ‘platform’ back then was the fact that there were a lot of opportunities to see quick wins from doing improvements for other teams. So for example, if I created something, if I improved something at the platform layer, it will not benefit one team. It will benefit all teams, multiple teams. And so the, the impact is actually pretty widespread and it’s immediate. You can see the, um, the joy of making someone happy. Like someone will come to you and say, “Oh, I was spending so much time and now I don’t have to do this.” Uh, so that drew me in, it wasn’t called DevEx. It wasn’t even called Dev Productivity at that time. Um, but this is I’m talking about like 2008, 2007–2008 timeframe. But then what happened over time was that, um, I realized that automation and creating the tools and all of that, uh, I realized how much of a superpower that can be for a company to have, uh, investment in that because it’s a multifold impact on how quickly people can get features. So how quickly you innovate, how efficient your engineering team is, how, um, excellent the, uh, how it says, the practices are within the engineering organization. They can all be defined by providing your engineers something that is, they can use every day and they don’t have to think and reinvent new ways and they don’t have to relitigate the same problem again and again.

Um, so that drew me in. Uh, so over time I’ve seen it evolve from just platform or like there used to be common libraries that people would write, which other companies, other teams would, uh, ingest and then they would release, uh, and we did not have, uh, continuous delivery. Uh, funnily enough, uh, we used to ship CDs, compact discs for those who are new to this process. Uh, so we would actually ship physical media over. So we would burn all the software on it and then we would ship it, um, to the data center and an admin would install it. So there was no concept of that level of continuous delivery, but we did have CI, and we did have a sense of automation within the actual pipeline, the software delivery pipeline. That is still valid.

Kovid Batra: There is one interesting question, like, uh, this is something that I have also felt, uh, coming from an engineering background. People usually don’t have, uh, an interest towards moving into platform teams, DevOps kind of things, right? You say that you are passionate about it. So I just want to hear it from you, like what drives that passion? Like you just mentioned that there is an impact that you’re creating with all the teams who are working there. Um, so is, is that the key thing or is it something else that is driving that passion?

Vilas Veeraraghavan: I mean, I feel like that is the key thing because I, I derive a lot of joy out of that, because I feel that when you make a change and sometimes, uh, the result, the impact of that change is not visible till it’s actually live and then people use it. I mean, for example, if you wanted to, let’s say you’re moving from a GitLab pipeline to, uh, using Argo CD for something or something like that. You’re doing a massive migration. It can be very troubling to look at it when you’re stepping back and looking at it as a big picture. But then when all of the change is done and you see how it has impacted, uh, you see how fast you’re running or you see, something like that, right? So I think it’s that, um, obviously is, which is a big motivator, but here’s the other thing, right? I think, uh, and this is a secret that I hope others also, uh, realize that it was right there all along. They just haven’t seen it. The secret is that by being in a space like DevEx, you actually solve multiple different domain, uh, domain areas, problems, right? So for example, at Walmart, I got deeply, I had a chance to deeply understand supply chain issues, like supply chain teams had issues that were different from maybe, uh, like teams that were doing more payment management. Uh, the problems are different, but when you look at the problem, uh, you have to understand deeply what that technology is. So you end up having a lot of really broad knowledge across multiple domain areas. And when you solve a problem for a domain area, you will be surprised to know, Oh, this actually solves it for five other areas as well. Right? So it’s, it’s a fascinating thing that I think people don’t realize immediately. So it feels less glamorous than something else, um, like a feature team maybe. Um, but in fact, it’s actually, in my opinion, uh, more powerful.

Kovid Batra: Got it. Is this the effect of working with large organizations particularly? Like, uh..

Vilas Veeraraghavan: It’s possible.

Kovid Batra: I’m not making any assumptions here but I’m just asking a question.

Vilas Veeraraghavan: Yeah. It’s possible.

Kovid Batra: Okay.

Vilas Veeraraghavan: Yeah, it is. I, I, yes. Uh, I, I will say that there is definitely a privilege that I’m, I should call out here, is that the privilege for me was to work, uh, in companies which allowed me the ability to like learn this, right? There was a lot of, um, bandwidth that was offered to me to learn all of this. Um, and Netflix was, is, is always good about a lot of transparency across organizations. Uh, so as an engineer, if you are working for a company like Netflix, you absorb a lot of information. And because you, if you’re curious, you can do more, you can do a lot, right? Um, obviously Walmart, fortune one, big, biggest company I’ve ever worked for. I think it’s, it is the biggest company in terms of size as well. Um, again, right, you have the ability to learn, uh, and you work your way out of ambiguity by defining structure yourself. Um, so same thing happens. I think I’ve been lucky in that way as well, um, to learn from all of these folks who worked there and obviously, amazing, talented people work in these places. So something, you keep hearing about it, you keep learning about it and then it makes you better as an engineer as well.

Kovid Batra: Makes sense. So, um, let’s, let’s deep dive into some of these situations where you applied your great brains around designing the platform teams, defining things for, uh, these platforms. So maybe, can you just bring up some examples from your journey at Netflix or Walmart or Bill.com where you had a great challenge in front of you? Uh, and what were the decision-making framework, uh, frameworks you, you, uh, basically deployed at that point of time and how things spanned out during the journey? So this might be a long question, but like, uh, I just wanted to, uh, dive into any one of those journeys if you, if you’re okay.

Vilas Veeraraghavan: Okay. I think we have had in the past, you’ve had Bryan Finster. So this was something that we traversed together along with many other people. Uh, we were all part of the same team, um, when we did this. Uh, so I’ll start with Walmart, uh, as an example. Um, I’ll, I’ll keep, keep it to sort of, I’ll go into generics and not give you specifics, but the challenge, uh, at a company like Walmart is that as a company, a big company, there is a lot of established practices, uh, a lot of established processes, established tools that teams use and businesses rely on, right? So each of these areas within the company is a business by itself. Uh, they are obviously wanting to get the best possible output for their customers. Uh, and they rely on a bunch of processes, tools, people, all of that, right? Um, if you now, going in, say that, “Hey, I’m going to introduce something that’s brand new.” Or if you’re going to change something drastically, you are creating unnecessary churn and unnecessary friction within the system, right? So in order for us to think about how we wanted to do dev enablement within Walmart, it is important to understand that you had to address the friction, right? If you are providing a solution that is replacing existing solution and doing just enough, that’s not going to cut it. It has to be a sea change. It has to be something that significantly changes how the company does software delivery, right? Uh, and so, one thing I’ll say is that I was very lucky to work for someone and for like leaders at Walmart that also understood this at that time. Um, so, for all those who are in the process right now, you cannot do it unless your leadership has that, you have buy in from that leadership, you have sponsorship from your executive teams. Uh, that helped us a lot.

Now, once you have buy in, you still have to produce something that is of value, right? And so that is where I’m saying this thing is important. So initially, uh, in my mind, uh, naively, my expectation was we build some amazing tools, right? And then we provide that to these teams and of course, they’ll be super happy, uh, the word of month will spread and that’s it. Right. All done. Um, what I found was in order to solve a problem where engineers were spending a lot of time doing toil, right? Like they were doing a lot of manual processes or repeated, uh, work throwing a tool at them was actually exacerbating the cognitive load problem, right?

Kovid Batra: Yeah.

Vilas Veeraraghavan: So now, while they maintain existing solutions, they have to now learn something new, migrate it, then convince their leaders and their teams to say, “Yeah, this is how we have to do things.” And then move forward. So you’re making that problem worse, that bandwidth problem, which is I’m a developer. I have certain amount of time to spend on feature delivery. I don’t have time for everything. So now I’m squeezing this into my, like 20 percent time, on my own free time outside of work to learn what this new thing is about. What that meant is that adoption would not succeed. So if adoption doesn’t succeed, then obviously, if your customers are not using you, you’re not, you’re a failed product, right? So what we realized was there are two other aspects to it that we had not thought about. One was process and the other one was people, right? So when I say people, I mean it could be management, it could be a key opinion leader within the space, right? That’s what we attacked. And you can obviously ask Bryan more about it. He is, he’s, he knows all about it. But the way that we attacked it was we created programs which were more grassroots, like more bottoms up view of saying, “Hey, we are starting to use these new tools. Come join us as we learn together. Let’s discuss what problems we have. Let’s talk about successes that we have. Let’s talk about how we want to do this well.” And we were open to feedback. So, inside my organization, uh, which is the dev enablement area, there was also a product organization. Uh, so we had product owners with each of the teams that are building these tools and the product owners had a pulse on the customer’s need.

So that is, that is how we found success over time. We did not obviously succeed at the start, and there was obviously, a lot of challenges we had to work through, but what happened is adoption only kicked up when we saw that we were able to, one, provide a solution that is X times better than where we were, right? So if you were to, if you were maintaining configuration, if you’re meeting five config, uh, different configs, now we just have to meet in one YAML file and that’s checked into GitHub or something like that, right? That’s a big difference productivity-wise. lesser errors. Uh, second thing is how many times do I have to look at the build? Uh, and then security review after the build and all that. So you say, okay, let’s do security scanning before the build. Uh, so even before you build a binary, you know if it’s safe to build it based on your code scan. Uh, things like that we did to improve the process itself. And then we educated our teams about it. All of our teams. We upskilled them. We gave them a chance to upskill themselves by giving them lots to, lots of references. We showed them like what the industry standards are. By showing them what the industry standards are, you created a need inside them say, “Hey, we need to be like that, right? Like, why can’t we do this?” And so that essentially became a motivating factor for most teams and most managers and directors and VPs started saying, “Hey, I want all of my teams to do exactly that.” Right. We need to be that kind of a team. And that introduced a lot of sort of gamification, right? Because when we, when you look at dashboards that look slick, right, and you’re like, “Hey, why can’t I do this? Why can’t my team do this?” It created a very natural tension, a very natural competition within the company, which served adoption well. Once the adoption was starting to grow and beyond a certain threshold, it became a very natural, or we didn’t have to go asking for customers, customers came looking for us. And so, that’s how we got to the point where there was more uniformity in how software is delivered.

Kovid Batra: Perfect. So I think it’s more around defining the right problem for the teams that you’re going to work with, defining a priority on those problems, how you were like very swiftly slide into their existing system so that the adoption is not a barrier in the first place itself. So the basic principles of how you bring in a product into the market. Similarly, you just have to..

Vilas Veeraraghavan: It is the exact same.

Kovid Batra: Yeah.

Vilas Veeraraghavan: Uh, platform, dev enablement, tooling, all of this. These are all products. Your developers are your customers. If your customers are not happy and they don’t use you, um, yeah, you are a failed organization then. That’s how it is. Right. So if you, if you feel like, um, just because you are part of a DevEx team, uh, what you say has to be the law of the land, it doesn’t work that way, right? The customers vote with their, with the time that they give you. Uh, and if that, if you find if, let’s say in an organization, you see that there are some tools that’s been released by the developer productivity or DevEx or enablement or platform engineering organization, but most people are using workarounds to do something. Then I hope the teams understand that there needs to be some serious change in the DevEx organization.

Kovid Batra: Cool. I’ll just go back to the first point itself from where you start. Is there any specific way to identify which teams are dealing with the most impactful problems right now and then you go about tackling that? Or it’s more like you are talking to a lot of engineering leaders around you and then you just think that, “Okay, this is something that we can easily solve and it seems impactful. Let’s pick this up.” How does that work?

Vilas Veeraraghavan: That’s actually a very, um, important thing to think about. And thanks for reminding me of that because I did ignore to say that. I didn’t say this the last time. Uh, you do need some champions and that’s why I said key opinion leaders, right? In the company, you need champions who can help do that early adoption and then find success. That comes from not just impact, which means, let’s say that someone is doing, uh, a hundred million dollars of business every year. Uh, and if they change something that they made to save a significant amount of money, that can be big impact, but it’s also about what their ambition is. So if I am a hundred million dollar business, but my ambition is I want to be a hundred million dollar business next year as well. They may not be able to be the, uh, they may not be the person who’s pushing at the boundaries, right?

Kovid Batra: Got it.

Vilas Veeraraghavan: They may be saying, “Oh yeah, it’s fine. I mean, everything is working just fine. I don’t want to break anything. I don’t want to touch anything. I don’t want to innovate. Let’s keep going.” But on the other hand, you will see, and this is common in many big companies is there’ll always be pockets of rapid innovation, right? And so, these folks who are in that space and their decision makers in those spaces, uh, them having a discussion with it, a really deep discussion, a very open discussion with them, uh, almost like a partnership, right? Saying, “Hey, I’m building this tool. Let’s imagine you have to use this tool. What would you want me to change in this so that it fits you?” And obviously, you’re going to take all of their input and decide which ones will be more useful to others as well. You’re not going to obviously, build something for just one team, but at the same time you get to know, like, you know, what is it that, what is it that is not getting them to adopt this right now? So you do need a set of those key opinion leaders very early in the process because they are also not just going to influence their team; they are going to influence other teams. And that’s how the word of mouth is going to spread. So that’s the first step. So it’s not just impact; its impact with ambition, which is where..

Kovid Batra: There should be some inherent motivation there to actually work on it, only then..

Vilas Veeraraghavan: I will, I will say one other thing, Kovid. Like if there is someone that, if there’s a team that doesn’t necessarily have ambition, but it’s doing more of a top-down, like get this done, right? I have often found that, uh, by leaders saying, get this done, it can sometimes backfire because the team feels like it’s an imposition on them. They may be very happy with their current state of tools, but it’s an imposition. Like now, why do you have to change this? Everything works just fine, right? You always have that inertia, like people, everyone doesn’t want change, and sometimes change might not be needed either. You might actually already be efficient, right? But that top-down approach doesn’t always work, which is why for us, I will say this, that for me, the greatest learning was how and seeing how much the bottoms-up approach worked at Walmart was actually very encouraging because I realized that you have to convince an engineer to see this for themselves. So it is very, that’s why I think opinion leaders are not necessarily VPs or they could be, it could be someone who’s well-respected in an area. It could be someone who is, um, like a distinguished engineer, uh, right, whose word carries a lot of value within an organization. Those are the, those are the people who, who tend to be those key opinion leaders, right? Uh, so top-down also doesn’t work. You can’t just be like, uh, your VP is ambitious, but you are not. That, that, that doesn’t work either.

Kovid Batra: Makes sense. Makes sense. All right. So I think when you have defined the team priority problem that you need to solve, then you start hustling, start building, of course, that phase has to be of a lot of to and fro, patience, transition, MVPs. Anything from that phase of implementation that came out to be a great learning for you that you would like to share?

Vilas Veeraraghavan: I’m thinking there was obviously a lot of learning. Uh, we, it was not, it is never a straight path, right, uh, when, when you’re doing something like this. But I think one thing that I, uh, evolved, uh, during that time was at the start, uh, I was definitely operating in a bit of a, “But this is the best way to do it.” Like I was, we were so convinced that there is no other way, but this to do it. That, uh, slight arrogance sometimes leads you down a path where you’re not listening to what people are saying, right? If people are saying, “Hey, I’m facing this pain.” And you’re hearing that across different organizations, different areas, and you dismiss it as, “Oh, it’s just a small thing. Don’t worry about it.” Right? That small thing can snowball into a very big problem that you cannot avoid, eventually. What I learned over time was I used to go into meetings being very defensive about what we already created and what, because the way I would look at it is, “Oh, well, that team can do it. Why can’t you?” And, uh, that was very naive at that time. But then I realized, uh, one of those meetings I went to, I, for some reason, I basically said, “Okay, fine. Tell me exactly how you would have solved the problem.” Maybe I was annoyed. I don’t know what, but I said, “Okay, how would you solve the problem if you were doing this?” And that person was so happy to hear that. And that person actually sat down with me for the next two hours and designed exactly how things could have been better, all of that. Like they, and I went, I was happy to go into detail, but it made me realize these are actually all allies that I should be adding to my list, right, as opposed to saying, “No, no, you have to use this. Like, what? Go away.” I, I, that was a big mistake I did. I probably did that for like six months. I, I will say that that was a bad idea. Uh, don’t do it. Uh, but after that it was, I, I was able to, the team was able to flourish because everyone saw us as partners in this thing, right?

So then we would go and we would say, “Okay, fine. You have this tool that we built, but don’t think about that. Think about what is the ideal tool that you need and let’s find out how much of this, this satisfies, right. And then whatever it doesn’t, we will accept that as feedback. And then we’ll go back and we’ll see and think about it and all that. And we will share with you what our priorities are. You tell us if this is making sense to you or not, and then we’ll keep this communication going.” That is a big evolution.

Kovid Batra: I totally relate to that. But I haven’t been like being back and forth on this thought of bringing in opinions and then taking a decision rather than just taking a decision and then like pushing it. I think it’s the matter of the kind of people you’re working with. You have to make a wise choice that whom you want to listen to and whom you don’t want to. Both things can backfire. I’ve actually experience both, uh, the same happened.

Vilas Veeraraghavan: Oh yeah. You don’t want to. Yeah, obviously, what, it goes without saying that there is gonna be some people who are, uh, giving you the right advice, right? And some people are just complaining because they are complaining. That’s it.

Kovid Batra: Yeah.

Vilas Veeraraghavan: Right? Uh, oh yeah, you have to separate that. But I’m saying there’s two ways to do this, right? Like when you, when you find that initial adoption starts hitting and all that, you can’t go into your shell and be like, “Okay, that’s it. My job is done. People will keep.” So that is what we, I felt like over a brief amount of time, right? When we said, “No, it’s all working just fine. Like, why do you, what are you complaining about?” And then I realized, I don’t know if maybe other folks in my team realized it earlier, but I realized it as a strategy. We needed to change that. And that put a very different face on our team because our team then started getting welcomed into meetings, which we originally were never a part of. It allowed us to see, uh, into their decision process because they were like, “Oh no, it’s important for you to know this because there is a lot of dependency on tools. We can’t change this process, but maybe we can adjust the tools and the settings to help us with this.” Right? So it was a very different perspective. And that learning, I was able to carry it into like other, uh, other initiatives, projects, companies, all of that. It has definitely served me well. Even now, if I’m listening to someone, I’ll usually say, “What would you do if you were in this space?” Right. And then let’s talk about it. Right. Very open. Um, but it is, it is important to have ego outside.

Kovid Batra: Yeah, totally. So I think it’s a very good point you just mentioned, like, uh, taking that constant feedback in some or the other form. But when you’re dealing with large teams, large systems, uh, I have got a sense that you need to have a system in place along with 1-on-1s and discussions with the people. So I’m sure you are focusing on making the delivery, uh, more efficient, faster, the quality should be better, less of failures, right? At the beginning of a journey, let’s say, any project, there must be something, some metrics that you define that, “Okay, this is what the current scenario is. And during the phase, these are our KPIs which we need to like look at every time, every 15 days or 30 days.” And then finally, when you are putting an accomplishment mark to your change that you have brought in, there is a goal that you must be hitting, right? So during this whole journey, what were your benchmarks? What were your ways of evaluating that system data? So that you are always able to like, most of the time it’s like, it’s for our own benefit. Like we know things are working or not. And at the same time you’re working with so many teams, so many stakeholders, you have some factual things in front of you saying, “Okay, this is what has changed.”

Vilas Veeraraghavan: Sure. Um, I’ll say this, um, we, the team used to do regular road shows, which means we would go around to different teams. We would have weekly and monthly meetings where we would showcase what’s coming, what’s happened, how this is a fit for, and we would try to always do something where you would demo this with the team that you’re talking to. We will demo it with something that they are doing, right, saying, “Hey, look, this is a build that you wanted to run. You want it to slow down all that. So you wanted it to speed up and it’s slow right now. This is how much we sped it up and all that.” So that is a roadshow thing. The reason I’m mentioning that is because that brings me to the metrics, right? Metrics, when we started, um, in the sense of day-to-day metrics, um, evolved over time, uh, till like, when I left, right? In the sense that at the very start, our metric was adoption, obviously, when we started creating the tool and sending it out. So for us, for us, it was an option. The mission statement for us was we wanted to get code into production in less than 60 minutes. So this was, when I say ‘code to production’, it is not just any code. It’s code that is tested. So, uh, which means we, we had to build it fast. We had to run unit tests. We had to run integration tests. We’ve also, uh, intended to run performance evaluation, performance testing, right? And then deploy it without having to go trouble the, the, the team again for details, right? Deploy it or, or at least make it ready to deploy. And then you obviously, have some gate that will say, “Okay, ready to deploy. Check.” Someone checks it and then it goes to product, right? We wanted this process to take 60 minutes or less. So that was the very mission statement kind of thing.

Kovid Batra: Got it, got it, yeah.

Vilas Veeraraghavan: But the metrics evolved over time. So initially, it was adoption, like how many people are using this tool? Um, it was about, uh, some common things, for example, um, a lot of folks within Walmart were using different code repositories, right? All of them, because they’re maintained by different parts of the organization. But because we unified those, we started checking, okay, is everything in one place? What is this amount of code that is maybe not in a secure space? Or something like that. Like that became an open thing to share. And we got a lot of partnership from our sister teams in InfoSec, in, uh, like all of these compliance areas, they started helping us a lot because they established policies that became metrics for us to measure. So just like I said, how secure is the code base? That is a great policy saying, “We need to have secure codebases that do not have high-level and medium-level vulnerabilities.” That meant we could measure those by doing code scans and saying, “Okay, we still have these many to go. We can point out exactly what teams need to do what.” And then we would slide in our tool saying, “Hey, by the way, this tool can do it for you if you just did this.” And so, immediately, it affected adoption, right? So, so that is how we started off with metrics.

Uh, but over time, uh, as we consolidated our, the space, we realized that, uh, I mean, once adoption was at like a 75, 80 percent kind of thing, we realized that we didn’t need to track it. I mean, then it’s like diminishing returns. It’ll take its time. The long tail is long. It’ll take time. Uh, at that time we switched, uh, to looking at more efficiency metrics. So which means we wanted to see how much is the scale costing us as a team. Like, are we scaling well to handle the load of builds that are coming to us, right? Are we, are the builds slowing down week over week for other teams, right? Things like that. So that is how we started seeing it because we wanted to get a sense of how much is the developer spending on things like long builds. So if you’re spent, if you’re like, “Oh, I start this build and I have to go away for an hour and come back.” It is a serious loss of productivity for that person. The context switch penalty is high, right? And when you come back, you’re like, “I forgot what I was even doing.” So we wanted to minimize that. So it became about efficiency metrics and that led to the goals and the strategy that we had to decide for the next year. Okay, we need to fix this one next time. So it was an adoption as much as saying, “Okay, make sure that we are still continuing on the, uh, what is the roadshows and things like that, but we’ll shift our attention to this.” So in the roadshows, we will call out those metrics. So you would start the discussion with saying, “Here is where we are right now.” There were publicly accessible dashboards, which is another thing that we believed truly as a DevEx team or a dev enablement team is every action that we take is very public. In a sense, it should be to all the organizations, public to the organization because that’s our customer, right? So we need to tell them exactly where we do, what we’re doing. The investment in money comes from these people, right? The other VPs or the execs are sponsoring this. So they need to see where their money is going. And so it was like transparency was key, and that’s why metrics were helpful. We showed them all the way from adoption to tuning to efficiency. That’s how sort of the thing went.

Kovid Batra: Cool. I think this was really, really interesting to know this whole journey, the phases that you have had. Just in the interest of time, I think we’ll have to just take a pause here, but, uh, this was amazing, amazing discussion that I’ve had with you. Would you like to share a parting advice or something for people who are maybe stepping into this role or are into this role for some time, anything you want to share with them?

Vilas Veeraraghavan: I want to, first of all, thanks, Kovid. This is, this is great. Uh, I, I really enjoyed this conversation. Um, and I also appreciate the curiosity you had, uh, to have this discussion in the first place. So, thanks for that. Um, message is simple, right? I don’t know how this happens, but DevEx never used to be cool in the past, right? In a sense that DevEx felt like one of those things that people would say, “Hey, you’re doing DevEx. You’re not necessarily releasing features.” But in reality, there were tons of features that, that the feature teams needed to deliver their features that we had to create before they did this. DevEx teams needed to be three to six months ahead of where the feature teams are so that when it comes to delivery, feature teams are not waiting on tools. We have to be giving it ready. So I believed it was cool back then, but I’m very happy to hear that DevEx is actually turning cooler because there is a lot of industry backing about it, right? Like, so there’s a lot of push, a lot of people talking about it, like yourself, uh, and we, like, we are doing right now. My only advice is, for those who are interested in it, I would suggest at least speaking to the right people so you know what the opportunities look like, right, before you say no. That’s all I ask.

Kovid Batra: Perfect. All right, that’s our time. Bye for now. But we would love to have you on another episode talking more about DevOps, DevX, dev productivity. Thanks, Vilas. Thank you for your time.

Vilas Veeraraghavan: Yeah. Thanks, Kovid. I’m happy to return anytime.