In this episode of the groCTO Originals podcast, host Kovid Batra talks to Venkat Rangasamy, the Director of Engineering at Oracle & an advisory member at HBR, about 'How AI is Revolutionizing Software Engineering'.
Venkat discusses his journey from a humble background to his current role and his passion for mentorship and generative AI. The main focus is on the revolutionary impact of AI on the Software Development Life Cycle (SDLC), making product development cheaper, more efficient, and of higher quality. The conversation covers the challenges of using public LLMs versus local LLMs, the evolving role of developers, and actionable advice for engineering leaders in startups navigating this transformative phase.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of the groCTO podcast. And today with us, we have a very special guest, Mr. Venkat Rangasamy. He's the Director of Engineering at Oracle. He is the advisor at HBR Advisory Council, where he's helping HBR create content on leadership and management. He comes with 18 plus years of engineering and leadership experience. It's a pleasure to have you on the show, Venkat. Welcome.
Venkat Rangasamy: Yup. Likewise. Thank you. Thanks for the opportunity to discuss on some of the hot topics what we have. I'm, I'm pleasured to be here.
Kovid Batra: Great, Venkat. So I think there is a lot to talk about, uh, what's going on in the engineering landscape. And just for the audience, uh, today's topic is around, uh, how AI is impacting the overall engineering landscape and Venkat coming from that space with an immense experience and exposure, I think there will be a lot of insights coming in from your end. Uh, but before we move on to that section, uh, I would love to know a little bit more about you. Our audience would also love to know a little bit more about you. So anything that you would like to share, uh, from your personal life, from your professional journey, any hobbies, any childhood memories that shape up who you are today, how things have changed for you. We would love to hear about you. Yeah.
Venkat Rangasamy: Yup. Um, in, in, in my humble background, I started, um, without nothing much in place, where, um, started my career and even studies, I did really, really on like, not even electricity to go through to, when we went for studies. That's how I started my study, whole schooling and everything. Then moved on to my college. Again, everything on scholarship. It's, it's like, that's where I started my career. One thing kept me motivated to go to places where, uh, different things and exploring opportunities, mentorship, right? That something is what shaped me from my school when I didn't have even, have food to eat for a day. Still, the mentorship and people who helped me is what I do today.
With that context, why I'm passionate about the generative AI and other areas where I, I connect the dots is usually we used to have mentorship where people will help you, push you, take you in the right direction where you want to be in the different challenges they put together, right? Over a period of time, the mentorship evolved. Hey, I started with a physical mentor. Hey, this is how they handhold you, right? Each and every step of the way what you do. Then when your career moves along, then that, that handholding becomes little off, like it becomes slowly, it becomes like more of like instructions. Hey, this is how you need to do, get it done, right? The more you grow, even it will be abstracted. The one piece what I miss is having the handholding mentorship, right? Even though you grow your career, in the long run, you need something to be handholding you to progress along the way as needed. I see one thing that's motivated me to be part of the generative AI and see what is going on is, it could be another mentor for you to shape your roles and responsibility, your career, how do you want to proceed, bounce your ideas and see where, where you want to go from there on the problem that you have, right? In the context of the work-related stuff.
Um, how, how you can, as a person, you can shape your career is something I'm vested, interested in people to be successful. In the long run, that's my passion to make people successful. The path that I've gone through, I just want to help people in a way to make them successful. That's my belief. I think making, pulling like 10 to 100, how many people you can pull out. The way when you grow is equally important. It's just not your growth yourself. Being part of that whole ecosystem, bring everybody around it. Everybody's career is equally important. I'm passionate about that and I'm happy to do that. And in my way, people come in. I want to make sure we grow together and and make them successful.
Kovid Batra: Yeah, I think it's, uh, it's because of your humble background and the hardships that you've seen in the early of your, uh, childhood and while growing up, uh, you, you share that passion and, uh, you want to help other folks to grow and evolve in their journeys. But, uh, the biggest problem, uh, like when, when I see, uh, with people today is they, they lack that empathy and they lack that motivation to help people. Why do you think it's there and how one can really overcome this? Because in my foundation, uh, in my fundamental beliefs, we, as humans are here to give back to the community, give back to this world, and that's the best feeling, uh, that I have also experienced in my life, uh, over the last few years. I am not sure how to instill that in people who are lacking that motivation to do so. In your experience, how do you, how do you see, how do you want to inspire people to inspire others?
Venkat Rangasamy: Yeah. No, it's, it's, it's like, um, It goes both ways, right? When you try to bring people and make them better is where you can grow yourself. And it becomes like, like last five to 10 years, the whole industry's become like really mechanics, like the expectation went so much, the breathing space. We do not have a breathing space. Hey, I want to chase my next, chase my next, chasing the next one. We leave the bottom food chain, like, hey, bring the food chain entirely with you until you see the taste of it in one product building. Bringing entire food chain to the ecosystem to bring them success is what makes your team at the end of the day. If we start seeing the value for that, people start spending more time on growing other people where they will make you successful. It's important. And that food chain, if it breaks, if it broke, or you, you kind of keep the food chain outside of your progression or growth, that's not actual growth because at one point of time, you get the roadblocks, right? At that point of time, your complete food chain is broken, right? Similar way, your career, the whole team, food chain is, it's completely broken. It's hard to bring them back, get the product launched at the time what you want to do. It's, it's, it's about building a trust, bring them up to speed, make them part of you, is what you have to do make yourself successful. Once you start seeing that in building a products, that will be the model. I think the people will follow that.
The part is you rightly pointed out empathy, right? Have some empathy, right? Career can, it can be, can, can, it can go its own progress, but don't, don't squeeze too much to make it like I want to be like, it won't happen like in a timely manner like every six months and a year. No, it takes its own course of action. Go with this and make it happen, right? There are ups and downs in careers. Don't make, don't think like every, every quarter and every year, my career should be successful. No, that's not how it works. Then, then there is no way you see failure in your career, right? That's not the way equilibrium is. If that happened, everybody becomes evil. That's not a point, right? Every, everything in the context of how do you bring, uplift people is equally important. And I think people should start focusing more on the empathy and other stuff than just bringing as an IC contributor. Then you want to be successful in your own role, be an IC contributor, then don't be a professional manager bringing your whole.. There's a chain under you who trust you and build their career on top of your growth, right? That's important. When you have that responsibility, be meaningful, how do you bring them and uplift them is equally important.
Kovid Batra: Cool. I think, uh, thanks a lot, uh, for this sweet and, uh, real intro about yourself. Uh, we got to, uh, know you a little more now. And with that, I, I'm sorry, but I was talking to you on LinkedIn, uh, from some time and I see that you have been passionately working with different startups and companies also, right, uh, in the space of AI. So, uh, With this note, I think let's move on to our main section, um, where you would, uh, be, where we would be interested in knowing, uh, what kind of, uh, ideas and thoughts, uh, are, uh, encompassing this AI landscape now, where engineering is changing on a day-in and day-out basis. So let's move on to our main section, uh, how AI is impacting or changing the engineering landscape. So, starting with your, uh, uh, advisories and your startups that you're working with, what are the latest things that are going on in the market you are associated with and how, how is technology getting impacted there?
Venkat Rangasamy: Here is, here is what the.. Git analogy, I just want to give some history background about how AI is getting mainstream and people are not quite realizing what's happening around us, right? The part is I think 2010, when we started presenting cloud computing to folks, um, in the banking industry, I used to work for a banking customer. People really laughed at it. Hey, my data will be with me. I don't think it will move any time closer to cloud or anything. It will be with, with and on from, it is not going to change, right? But, you know, over a period of time, cloud made it easy. And, and any startups that build an application don't need to set up any infrastructure or anything, because it gives an easy way to do it. Just put your card, your infrastructure is up and running in a couple of hours, right? That revolutionized a lot the way we deploy and manage our applications.
The second pivotal moment in our history is mobile apps, right? After that, you see the application dominance was with enterprise most of the time. Over a period of time, when mobile got introduced, the distribution channels became easier to reach out to end users, right? Then a lot of billion-dollar unicorns like Uber and Spotify, everything got built out. That's the second big revolution happening. After mobile, I would say there were foundations happening like big data and data analytics. There is some part of ML, it, over a period of time it happened. But revolutionizing the whole aspect of the software, like how cloud and mobile had an impact on the industry, I see AI become the next one. The reason is, um, as of now, the software are built in a way, it's traditional SDLC practice, practice set up a long time ago. What, what's happening around now is that practice is getting questioned and changed a bit in the context of how are we going to develop a software, make them cheaper, more productive and quality deliverables. We used to do it in the 90s. If you've worked during that time, right, COBOL and other things, we used to do something called extreme programming. Peer programming and extreme programming is you, you have an assistant, you sit together, write together a bunch of instructions, right? That's how you start coding and COBOL and other things to validate your procedures. The extreme programming went away. And we started doing code based, IDE based suggestions and other things for developers. But now what's happening is it's coming 360, and everything is how Generative AI is influencing the whole aspect of software industry is, is, is it's going to be impactful for each and every life cycle of the software industry.
And it's just at the initial stage, people are figuring out what to do. From my, my interaction and what I do in my free time with NJ, Generative AI to Change this SDLC process in a meaningful way, I see there will be a profound impact on what we do in a software as software developers. From gathering requirements until deploying, deploying that software into customers and post support into a lifecycle will have a meaningful impact, impact. What does that mean? It'll have cheaper product development, quality deliverables. and having good customer service. What does it bring in over a period of time? It'll be a trade off, but that's where I think it's heading at this point of time. Some folks have started realizing, injecting their SDLC process into generative AI in some shape and form to make them better.
We can go in detail of like how each phases will look like, but that's, that's what I see from industry point of view, how folks are approaching generative AI. There is, there is, it's very conservative. I understand because that's how we started with cloud and other areas, but it's going to be mainstream, but it's going to be like, each and every aspect of it will be relooked and the chain management point of view in a couple of years, the way we see an SDLC will be quite different than what we have today. That's my, my, my belief and what I see in the industry. That's how it's getting there. Yep. Especially the software development itself. It's like eating your own dog food, right? It happened for a long time. This is the first time we do a software development, that whole development itself, it's going to be disturbed in a way. It'll be, it'll be, it'll be more, uh, profound impact on the whole product development. And it'll be cheaper. The product, go to market will be much cheaper. Like how mobile revolutionized, the next evolution will be on using, um, generative AI-like capability to make your product cheaper and go to market in a short term. That's, that's, that's going to happen eventually.
Kovid Batra: Right. I think, uh, this, this is bound to happen. Even I believe so. It is, it is already there. I mean, it's not like, uh, you're talking about real future, future. It's almost there. It's happening right now. But what do you think on the point where this technology, which is right now, uh, not hosted locally, right? Uh, we are talking about inventing, uh, LLMs locally into your servers, into your systems. How do you see that piece evolving? Because lately I have been seeing a lot of concerns from a lot of companies and leaders around the security aspect, around the IP aspect where you are putting all your code into a third-party server to generate new code, right? You can't stop developers from doing that because they've already started doing it. Earlier, the method was going to stack overflow, taking up some code from there, going to GitHub repositories or GitLab repositories, taking up some code. But now this is happening from a single point of source, which is cloud hosted and you have to share your code with third parties. That has started becoming a concern. So though the whole landscape is going to change, as you said, but I think there is a specific direction in which things are moving, right? Very soon people realized that there is an aspect of security and IP that comes along with using such tools in the system. So how do you see that piece progressing in the market right now? And what are the things, what are the products, what are the services that are coming up, impacting this landscape?
Venkat Rangasamy: It's a good question, actually. We, after a couple of years, right, what the realization even I came up with now, the services which are hosted on a cloud, like, uh, like, uh, public LLMs, right, which, you can use an LLM to generate some of these aspects. From a POC point of view, it looks great. You can see it, what is coming your way. But when it comes to the real product, making product in a production environment is not, um, well-defined because as I said, right, security audit complaints, code IP, right? And, and your compliance team, it's about who owned the IP part of it, right? It's those aspects as well as having the code, your IP goes to some trained public LLM. And it's, it's kind of a compromise where there is, there is, there is some concern around that area and people have started and enterprises have started looking upon something to make it within their workspace. End of the day, from a developer point of view, the experience what developer has, it has to be within that IDE itself, right? That's where it becomes successful. And keeping outside of that IDE is not fully baked-in or it's not fully baked-in part of the developer life cycle, which means the tool set, it has to be as if like it's running in local, right? If you ask me, like, is it doable? For sure. Yes. If you’d asked me an year back, I'd have said no. Um, running your own LLM within a laptop, like another IDE, like how do you run an IDE? It's going to be really challenging if you’d asked me an year back. But today, I was doing some recent experiment on this, um, similar challenges, right? Where corporates and other folks, then the, the, the, any, any big enterprises, right? Any security or any talk to a startup founders, the major, the major roadblock is I didn't want to share my IPR code outside of my workspace. Then bringing that experience into your workspace is equally important.
With that context, I was doing some research with one of the POC project with, uh, bringing your Code Llama. Code Llama is one of the LLMs, public LLM, uh, trained by Meta for different languages, right? It's just the end of the day, the smaller the LLMs, the better on these kinds of tasks, right? You don't need to have 700 billion, 70 billion, those, those parameters are, is, it's irrelevant at this point of coding because coding is all about a bunch of instructions which need to be trained, right? And on top of it, your custom coding and templates, just a coding example. Now, how to solve this problem, set up your own local LLM. Um, I've tested and benchmarked in both Mac and PC. Mac is phenomenally well, I won't see any difference. You should be able to set up your LLM. There is a product called Ollama. Ollama is, uh, where you can use, set up your LLM within your workspace as if it's running, like running in your laptop. There's nothing going out of your laptop. Set up that and go to your IDE, create a simple plugin. I created a VC plugin, visual source plugin, connected to your local LLM, because Ollama will give you like a REST API, just connect it. Now, now, within your IDE, whatever code is there, that is going to talk to your LLM, which means every developer can have their own LLM. And as long as you have a right trained data set for basic language, Java, Python, and other thing, it works phenomenally well, because it's already trained for it. If you want to have a custom coding and custom templating, you just need to train that aspect of it, of your coding standards.
Once you train, keep it in your local, just run like part of an IDE. It's a whole integrated experience, which runs within developer workspaces, is what? Scalable and long run. It, if anything, if it goes out of that, which we, we, we have seen that many times, right, past couple of years. Even though we say our LLMs are good enough to do larger tasks in the coding side, if it's, if you want to analyze the complete file, if you send it to a public LLM, with some services available, uh, through some coding and other testing services, what we have, the challenges, number of the size of the tokens what you can send back, right? There is a limit in the number of tokens, which means if you want to analyze the entire project repository what you have, it's not possible with the way it's, these are set up now in a public site, right? Which means you need to have your own LLM within the workspace, which can work and in, in, it's like a, it's part of your workspace, that's what I would say. Like, how do you run your database? Run it part of your workspace, just make it happen. That is possible. And that's going to be the future. I don't think going any public LLM or setting up is, is, is not a viable option, but having the pipeline set up, it's like a patching or giving a database to your developers, it runs in local. Have that set up where everybody can use it within the local workspace itself. It's going to be the future and the tools and tool sets around that is really happening. And it's, it's at the phase where in an year's time from here, you won't even see that's a big thing. It's just like part of your skill. Just set up and connect your editor, whatever source code editor you have, just connect it to LLM, just run with it. I see that's a feature for the coding part of you. Other SDLCs have different nuance to it, but coding, I think it should be pretty straightforward in a year time frame. That's going to be the normal practice.
Kovid Batra: So I think, uh, from what I understand of your opinion is that the, most of the market would be shifting towards their Local LLM models, right? Yeah. Uh, that that's going to be the future, but I'm not sure if I'm having the right analogy here, but let's talk about, uh, something like GitHub, which is, uh, cloud-sourced and one, which is in-house, right? Uh, the teams, the companies always had that option of having it locally, right? But today, um, I'm not sure of the percentage, uh, how many teams are using a cloud-based GitHub on a locally, uh, operated GitHub. But in that situation, they are hosting their code on a third party, right? The code is there.
Venkat Rangasamy: Yup.
Kovid Batra: The market didn't shape that way if we look at it from that perspective of code security and IP and everything. Uh, why do you think that this would happen for, uh, local LLMs? Like wouldn't the market be fragmented? Like large-scale organizations who have grown beyond a size have that mindset now, “Let's have something in-house.” and they would put it out for the local LLMs. Whereas the small companies who are establishing themselves and then, I mean, can it not be the similar path that happened for how you manage your code?
Venkat Rangasamy: I think it is very well possible. The only difference between GitHub and LLM is, um, the artifact, the, GitHub is more like an artifact management, right? When you have your IP, you're just keeping it's kind of first repository to keep everything safe, right? It just with the versioning, branching and other stuff.
Kovid Batra: Right.
Venkat Rangasamy: Um, the only problem there related to security is who's, um, is there any vulnerability within your code? Or it's that your repository is secure, right? That is kind of a compliance or everything needs to be there. As long as that's satisfied, we're good for that. But from an LLM lifecycle point of view, the, the IP, what we call so far in a software is a code, what you write as a code. Um, and the business logic associated to that code and the customizations happenening around that is what your IP is all about. Now, as of now, those IPs are patent, which means, hey, this is what my patent is all about. This is my IP all about. Now you have started giving your IP data to a public LLM, it'll be challenging because end of the day, any data goes through, it can be trained on its own. Using the data set, what user is going through, any LLM can be trained using the dataset. If you ask me, like, every application is critical where you cannot share an IP, not really. Building simple web pages or having REST services is okay because those things, I don't think any IP is bound to have. Where you have the core business of running your own workflows or your own calculations and that is where it's going to be more tough to use any public LLM.
And another challenge is, what I see in a community is, the small startups, right, they won't do much customization on the frameworks. Like they take Java means Java, right, Node means Node, they take React, just plain vanilla, just run through end-to-end, right? Their, their goal is to get the product up to market quicker, right, in the initial stage of when we have 510 developers. But when it grows, the team grows, what happens is, we, the, every enterprise it's bound to happen, I, I've gone through a couple of cycles of that, you start putting together a framework around the whole standardization of coding, the, the scaffolding, the creating your test cases, the whole life cycle will have enforced your own standard on top of it, because to make it consistent across different developers, and because the team became 5 to 1000, 1000 to 10,000, it's hard to manage if you don't have standards around it, right? That's where you have challenges using public LLM because you will have challenges of having your own code with your own standards, which is not trained by LLM, even though it's a simple application. Even simple application will have a challenge at those points of time. But from a basic point of view, still you can use it. But again, you will have a challenge of how big a file you can analyze using public LLM. It's the one challenge you might have. But the answer to your question, yes, it will be hybrid. It won't be 100 percent saying everybody needs to have their own LLM trained and set up. Initial stages, it's totally fine to use it because that's how it's going to grow, because startup companies don't have much resources to put together to build their own frameworks. But once they get in a shape where they want to have the standardized practices, like how they build their own frameworks and other things. Similar way, one point of time, they'd want to bring it up on their own setup and run with it. For large enterprise, for sure, they are going to have their own developer productivity suite, like what they did with their frameworks and other platforms. But for a small startup, start with, they might use public, but long run, eventually over a point of, over a period of time, that might get changed.
And the benefit of getting hybrid is where you will, you'll make your product quick to market, right? Because end of the day, that's important for startups. It's not about getting everything the way they want to set up. It's important, but at the same time, you need to go to market, the amount of money what you have, where you want to prioritize your money. If I take it that way, still code generation and the whole LLM will play a crucial role on a, on the development. But how do you use and what third-party they can use? Of course, there will be some choices where I think in the future, what this, what I see is even these LLMs will be set up and trained for your own data in a, in a more of a hybrid cloud instead of a public cloud, which means your LLM, what you trained in a, in a hybrid cloud has visibility only to your code. It's not going, it's not a public LLM, it's more of a private LLM trained and deployed on, on a cloud can be used by your team. That'll, that'll, that'll be the hybrid approach in the long run. It's going to scale.
Kovid Batra: Got it. Great. Uh, with that, I think, uh, just to put out some actionable advice, uh, for all the engineering leaders out there who are going through this phase of the AI transformation, uh, anything as an actionable advice for those leaders from your end, like what should they focus on right now, how they should make that transition? And I'm talking about, uh, companies where these engineering leaders are working, which are, uh, Series B, Series A, Series C kind of a bracket. I know this is a huge bracket, but what kind of advice you would give to these companies? Because they're in the growing phase of the, of the whole cycle of a company, right? So what, what should they focus on right now at this stage?
Venkat Rangasamy: Here, here is where some start. I was talking to some couple of, uh, uh, ventures, uh, recently about similar topic, how the landscape is going to change as for software development, right? One thing came up in that call frequently was cheaper to develop a product, go to market faster, and the expectation around software development has become changing quite a while, right? In the sense, the expectation around software development and the cost associated to that software development is where it's going to, it's going to be changing drastically. Same time, be clear about your strategy. It's not like we can change 50 percent of productivity overnight now. But at the same time, keep it realistic, right? Hey, this is what I want to make. Here is my charter to go through, from start from ideations to go to market. Here are the meaningful places where I can introduce something which can help the developers and other roles like PMs. Could be even post support, right? Have a meaningful strategy. Just don't go blank with the traditional way what you have, because your investors and advisors are going to start ask questions because they're going to see a similar pattern from others, right? Because that's how others have started looking into it. I would say proactively start going through that landscape and map your process to see where we can inject some of the meaningful, uh, area where it can have impacts, right?
And, and have, be practical about it. Don't think, don't give a commitment. Hey, I make 50 percent cheaper on my development and overnight you might burn because that's not reality, but just.. In my unit test cases and areas where I can build quality products within this money and I can guarantee that can be an industry benchmark. I can do that with introducing some of these practices like test cases, post customer support, writing code in some aspects, right? Um, that is what you need to set up, uh, when you started, uh, going for a venture fund. And have a relook of your SDLC process. That's important. And see how do you inject, and in the long term, that'll help you. And it'll be iterative, but at the end of the day, see, we've gone from waterfall to agile. Agile to many, many other paradigms within agile over a period of time. But, uh, the one thing what we're good at doing is in a software as an industry adapting to a new trend, right? This could be another trend. Keep an eye on it. Make it something where you can make it, make some meaningful impact on your products. I would, I would say, before your investor comes and talked about hey, can you do optimization here? I see another, my portfolio company does this, does this, does this. That's, it's, it's better to start yourself. Be collaborative and see if we can make something meaningful and learn across, share it in the community where other founders can leverage something from you. It will be great. That's my advice to any startup founders who can make a difference. Yep.
Kovid Batra: Perfect. Perfect. Thank you, Venkat. Thank you so much for this insightful, uh, uh, information about how to navigate the situation of changing landscape due to AI. So, uh, it was really interesting. Uh, we would love to have you one another time on this show. I am sure, uh, you have more than these insights to share with us, but I think in the interest of time, we'll have to close it for today, and, uh, we'll see you soon again.
Venkat Rangasamy: See you. Bye.
In the recent episode of ‘groCTO: Originals’, host Kovid Batra engages in a thoughtful discussion with James Charlesworth, Director of Engineering at Pendo, who brings over 15 years of experience in engineering and leadership roles. The episode centers around the theme “Product vs Engineering: Building Bridges, Not Walls.”
James begins by sharing how his lifelong passion for technology and software engineering, along with pivotal moments in his life have shaped his career. Moving on to the main section, James addresses the age-old tussle between product and engineering teams, emphasizing that these teams should collaborate closely rather than operate in silos. He shares strategies for fostering empathy, collaboration, and effective collaboration while highlighting the importance of understanding each team’s priorities and the impact of misalignment.
James also underscores the value of one-on-one meetings for having meaningful conversations, building strong relationships, and understanding team members on a deeper level. He also explores the significant role of Engineering Managers in enabling their teams to overcome these challenges, ensuring smooth team dynamics, and achieving successful product outcomes.
Kovid Batra: Hi everyone. This is Kovid, back with a new episode of the groCTO podcast, and today with us, we have a very special guest. He's the Head of Engineering at Pendo, and he has more than 15 years of engineering and leadership experience. Welcome to the show, James. Happy to have you here.
James Charlesworth: Hi, Kovid. Thank you so much for having me on. I'm actually not Head of Engineering at Pendo. I am a Director of Engineering and I run the Sheffield office here in the UK. So thank you for having me on.
Kovid Batra: Oh, all right. My bad then. Okay. So I think today, uh, we are going to have a very interesting discussion with James. We're going to talk about the age-old tussle between product and engineering, and James, uh, is an expert at handling those situations. So he's going to tell us what are the tactics and what are the frameworks he's using here. But before, James, we move on to that section, uh, we would love to know a little bit more about you. Uh, maybe some of your hobbies, some of the life-defining events for you, who James is basically. Please go on.
James Charlesworth: Thanks, Kovid. Um, yeah, this sounds super nerdy, but my hobby has always been technology and software engineering. Um, I first started doing software engineering when I was probably about 11 or 12 years old. I had a Cyon Series 3 that my parents bought me from a boot fair, and I just learned how to program that. Like, I'll just sit there for ages typing these tiny little keys. Um, and my hobby has been like using software and coding to actually solve problems in the real world and build products. And that's kind of led me towards web development and SaaS products. And that's ultimately what we do at Pendo, is help people build better products. So, um, yeah, that's a pretty boring answer to your question about my hobbies. I do also like play music and things. Um, I played guitar in a band for a long time. Um, so that's the only non-techie hobby I guess I have.
Kovid Batra: No, that's great. Thank you for that sweet, small intro about yourself. Anything that, uh, that entices you from your childhood or from your maybe teenage that has defined you a lot? I mean, this, this is something that I usually ask a lot of people, but from there, we, we get to know a lot more about our guests. So if you don't mind, can you just share some of that, uh, experience from your past that defines you today?
James Charlesworth: Yeah, I think the biggest defining moment that a lot of people go through is when they first leave home for the first time and they don't have a direction because I didn't have much of a direction when I was like 18 years old and I left home. I did the wrong degree. I did a degree in control systems engineering and I ended up doing software. So it took me a while to get into web development because of doing the wrong degree. Um, and actually because I had no real direction, I was just sort of fluttering in the wind and just doing whatever. But through that process of just giving yourself a bit of freedom and going out and into the world and doing whatever you want, you really learn about yourself and you learn about other people, and I think that's when I went from being obsessed with computers to being obsessed with people and the way that people interact with each other and, um, you know, like I met people from all different walks of life, and you notice the similarities between anybody from all across the world, but you want to notice the differences, and you can notice how you can celebrate those differences.
And so I think, like, having that moment of moving away from home and, um, like, living by yourself and stuff like that, um, really opens your eyes up to, like, who you want to be and where you want your place in the world to be. So I'm sorry if that's a little bit, um, esoteric but it's, yeah, there was no like one defining moment really. I mean, it was just one of those and then like being in a band goes in with that because I always wanted to be a rock star. It never really worked out. But this idea of you can just get some friends, get together, get a van and just like go touring and play music, um, across the country, that's really cool, and that's really cool when you're in your sort of early twenties and you just want that freedom. Um, and that goes hand in hand with meeting people from, from all over the place. So yeah, like, you know, I'm obsessed with people. I'm obsessed with like human interactions and the way people, um, the way people like carry themselves and interact with each other and what they care about and how we can all align that. Yeah.
Kovid Batra: That's really interesting now. I mean, uh, the kind of role you are into where you are into leadership, you're leading teams, you're a Director of Engineering and this aspect of being aware of different aspects of different people and culture makes you more comfortable when you are, uh, leading people, you, you bring more empathy, you bring more understanding to their situations, and I'm sure that has come, uh, from there, and it, it is definitely growing as you are moving into your career.
So I think, James, this was, this was, uh, really, really interesting. Uh, let's move on to our main section. I think, uh, everyone is waiting to hear about that. Uh, so this has been an age-old tussle, as I said. Uh, the engineers have never liked the product managers. I'm not generalizing it, but just saying, so please, please don't, don't take it wrong. Uh, but yeah, usually the engineers are not very comfortable, uh, in those discussions and this has been an age-old tussle, we all know, know about it. When we talk about product and engineering teams, I personally never think these two as two separate teams. Like it, it never works like that. One thing that I learned as soon as I moved into this industry is it's 'product engineering'. It's not product and engineering separately. So it's not healthy for a team to have this kind of a tussle when you actually are moving towards the same goal and almost every engineering team that I see, there, there is some level of friction there and it's, it's natural to be there because the product managers usually might not be that well, uh, hands-on with the code, hands-on with the kind of daily practices our dev goes through. And then, planning according to that, keeping in mind that, okay, it should be, uh, pushy as well as comfortable for the developers to deliver something. So that's where the main friction starts and you come up with unreasonable requirements which the developers might not be able to relate to that, how it is going to impact the product.
So there are multiple reasons due to which this gap, this friction could be there. So today, I think with that note, I would, uh, hand over the mic to you and, uh, would want to know how you have had such experiences in your past, in your current role and how you end up resolving this so that people operate, like developers and product operates as one single team towards that one goal of making the business successful.
James Charlesworth: Yeah, absolutely. And what you said there about coming together to solve a problem together is really, really important. I think like the number one thing that underpins this is that everybody, product managers, engineers, designers, managers, needs to remember that you're all employed by the same organization and you've got the same shared goals and your, um, contribution to that is no more or less valuable than anybody else's. Like you mentioned that word 'empathy' in your introduction, like empathy is, we're gonna talk about empathy a lot today, right, because empathy is all about putting yourself in somebody else's shoes and seeing what their goals are. Um, and firstly, like trying to steer their goals to what you need, but also trying to like, um, emphasize what your own goals are, um, and align those to the others.
Like the way I always think about product managers is a lot of engineers, they feel like they're on feature factory teams. They feel like they're just being told what to build, and you get into this feature factory loop. Um, and it just seems like all the Product Manager wants to do is add features into the product, add features into the product, add features into the product. Um, and it can feel sometimes like product managers are paid like on commission, like they get a certain commission based on how many features they deliver at a point or something. That's not true. Product managers are paid a salary just like you do, and the way that your success is ultimately measured is the same way that your product manager's success is ultimately measured. And so, it's really, really important to realize that you do align around this goal, and you need to have a two-way conversation about it. Like you need to, you need to really, really explain like what your, you think the priorities should be, and you need to encourage your product manager to explain what they think their priorities should be for the team, and then you can align and find some middle ground that ultimately works best for the business.
But yeah, like in my experience anyway, it's just, you say age-old, like this has been quite a long thing. And before products managers, it was business people. It was maybe, you know, one of my first jobs in software engineering, um, we didn't really have products managers. We just had like the Director of engineering, product research, design, whatever, um, who would just come up with the idea and just say, "This is what we're building." And that's very difficult, um, because you've reported in to that person. So you basically had to just do exactly what they said, and that was super, super unhealthy because that builds up a huge amount of resentment. And I much, much prefer the model we have now, where we have product managers, where engineers don't report into the product managers, because that means that product managers had to lead the product without authority, um, and engineers have to lead the best engineering direction without authority. So you have this thing where you're encouraged to influence your peers on the same team as opposed to just doing the thing that your boss tells you to do, which is how it used to work when I started in this industry.
So it's got, it's got a lot better. Um, and the, yeah, as I've gone through my career and I've worked with some really, really good product managers and some really good product leaders, I've noticed that pattern between the, the product managers that are really, really good, that are really successful are the ones that have that empathy and we will talk about empathy a lot, right? Because it's super, super important. But product managers can have that empathy that can empathize with what engineers actually want to get out of a situation, um, and then align that with their own goals.
Kovid Batra: I have a question here. When you, when you say empathy, I think, uh, in your introduction also, you mentioned, like, when you meet different people from different cultures, different backgrounds, you tend to understand. Your, your brain develops that empathy naturally towards different situations and different people. But that has happened only because you have seen things differently, right? When we put this context into product and engineering, a product manager who has probably never coded in their life, right? Who does not have the context of, uh, how things work in, in the development workspace, right? In that situation, how a manager like that should be able to come to this piece that, okay, uh, if the developer is saying that this is going to take five days or this is difficult and this is complicated to implement and it won't add much value. So in those scenarios, a person who is not hands-on with coding or has never done that piece on his own or her own, uh, how do you think, uh, in a professional environment that empathy would come in? And of course, the Product Manager has his or her own, uh, deliverables, the metrics that need to be looked at. So how does that work in that situation?
James Charlesworth: Well, the same way it works the other way around as well. So the situation you've just described, right? You've got a Product Manager who is trying to get what they need to get done, but they don't understand the full details behind the implementation. You've also got an engineer that does understand the full details behind the implementation, but they don't understand the full business context behind what you're trying to build, right? Because that's the Product Manager's job. So the engineers, they might know exactly how the database is structured and how all of the backend architecture works, which is very complicated, but they don't understand, like they haven't been speaking to customers. They don't know the kinds of things that the Product Manager knows. So both sides need to essentially understand what the other person's priorities are, and that's what empathy is. Empathy is understanding what somebody wants, and not necessarily always giving them what they want, but the very least like comprehending and considering what somebody's goals are in your own way you deal with them, right?
So, um, back to your situation about software engineering. Okay, so if let's say, a Product Manager has come to you and said, "We just need to add this button to this page. It's super, super important. We want to, we want this button to send an email out." And the engineers come back and they say, "Oh, we actually don't have any backend email architecture that can send emails out. So we're going to actually have to build all of that." Um, that, you know, the Product Manager can go, "Well, what's so difficult about that? Just put a button there and send an email out." And the engineers are kind of caught in this rock where they're in a hard place where they're sort of saying, "Well, this is a lot of work. Like that's weeks and weeks and weeks of work, but how do I go to the business and say 'It's a lot of work'?" Um, and so, the solution is to really, really explain and break down to your Product Manager why this is more work than they realize and the Product Manager's job is to turn around to you and explain why we really, really need this. So you both need to align and you both need to understand. Product managers need to understand that some stuff is complicated and the only way they're going to understand it is complicated is if you just explain it to them, right? Like there's no secrets in software engineering. If you spend an hour sitting down and explaining to a Product Manager how your backend is architected and how your databases all fit together and you know, what email service we're using and what the limitations are of that email service, and then they'll understand it. It'll take you an hour to explain that. And equally, your Product Manager can sit down with you and they can show you the customer calls where people are really, really wanting this feature, right? And they can educate you on why we really need this feature, and then ultimately, you'll come, you'll come together where you understand why your Product Manager is pushing for this so hard, and your Product Manager will understand why you're pushing back against this so hard, and you'll find a solution that makes everybody happy in the end. But you do need to listen. You need to listen to the other person's, um, goals and what they want to get out of it. Um, and that's the empathy side. Eventually, it's like, it's on this respecting somebody's motives. It's respecting somebody's, um, like what they've been given, their mandate that they've been given for a certain situation.
Kovid Batra: Right. I think this is one scenario where I definitely see putting in effort in explaining to the other person what it really means, what it stands for. Obviously, anyone cannot be so inconsiderate about the other person when they're working together. So maybe in one or two, uh, situations like this, let's say, I'm a Product Manager, uh, where I have to explain things to the developer, and if I do that for, let's say, two or three such instances, from the fourth or fifth time, automatically that level of trust is built, and you are in a position to maybe, uh, not even explain a lot of times. You get that synchronization in place where things are working well with you.
And on that note, I really feel that people who are joining in large size teams, like, uh, a Product Manager joining in or a developer joining in, usually in large size teams, we have started to see this pattern of having engineering managers also, right? So in your perspective, uh, how much does an Engineering Manager play a role in, uh, bridging this gap and reducing this friction? Because, uh, few of my very close friends who have been from the engineering background have chosen to be in the management space now, and they, they usually tell us what things they are working upon right now. And I feel that that really helps the business as well as the developers to deliver the right things on time and you get a lot of context from both the sides. So what's your perspective on that, uh, of bringing those engineering managers into the system?
James Charlesworth: Yeah. I mean, I think the primary, number one responsibility of an Engineering Manager is to empower the engineers to do all those things that you've just been speaking about, right? So like your number one responsibility, engineering managers tend to have better people skills than engineers. That's why people go into management. Um, and your job is to teach the engineers on your team how to do that, all of those things you've just described. Sometimes you have to step in and sometimes there's a high pressure situation where you do actually have to say, you know, "I'm going to bridge the gap here between engineers and product." But your primary job as an Engineering Manager is to enable the engineers on your team to all have that kind of conversation with the product managers and with the business. Um, and so it's coaching. So it's support. So it's, um, career development, and also, you know, hiring the right people, that's quite a large job of an Engineering Manager. Performance management. Um, and so, a lot of that. Engineering managers should never be the one person that bridges gap between product and engineering because then they're going to become a bottleneck, and also the engineers are never really going to learn to do that themselves.
Um, so yeah, that's always been, and I learned from some really good engineering managers or software development managers about this, about like, um, you know, empowering the people that you've put in charge. Engineering managers aren't in their position because they're necessarily better at everything than the engineers. They're usually better at one or two things. Um, but they're not as good at things like technical architecture. So as an Engineering Manager myself, I would never overrule an IC's opinion on a software architecture because that's not my job. My job is not that. I might know, I might have been doing software for years and years and years and I understand how systems are architected and how databases work and stuff. But I'm also employing people who are better at that than me, and that's the point. And so I would never overrule them, and I would never overrule how they collaborate with their Product Manager. But I would guide and coach them towards being able to do that. Um, and so, that's the case of speaking to engineers, speaking to product managers, trying to find out if they're talking past each other, trying to find out, you know, where, where the disconnect is, and then trying to solve that between the two groups of people. So I think the answer to your question is like the main role of an Engineering Manager is to become a force multiplier on their team, essentially, and to enable everybody to do that. Um, yeah, you can't have engineer managers who are just there to fix the gap. It's just not scalable. That's not a good thing.
Kovid Batra: No, I totally understand that. So when we are talking about bringing, uh, this level of comfort where people are working together, talking about your experience in your teams, there must have been such scenarios and you must have like put in some thoughts at the time of orientation, at the time of onboarding the team members that how they should be working to ensure that things work as a team, uh, can you just tell us about a few incidents and how you ended up solving them and how you put in the right, uh, onboarding for the team members to have that inculcated in the culture?
James Charlesworth: Yeah, the best onboarding is like that group effect of just observing something happening and then joining in with it. So like, by standard the best way to onboard somebody is just to add them to a high-performing team. Like honestly, you just put someone on the team that's super, super collaborative and they will witness how people can collaborate. But I've had you know, I've had positive and negative experiences in the past with joining a team, primarily back when I was a software engineer. I remember I once joined a team for the very first time and I just never really got on with my Product Manager. Like I don't think we clicked as people. We never really had any kind of conversations or anything. Um, and I was never really onboarded properly. So at the start I did have a slightly, um, rocky relationship with this Product Manager where I just couldn't understand, I couldn't understand what they were trying to do. They never explained anything. They just said, "This is what we are doing." So I just had to say, "Well, that's going to take longer than you think." And I tried this for ages. And I spoke to my manager. My manager sort of gave the advice that I've just been trying to give, um, your listeners here, which is like, you know, you need to go out and do it yourself. I'm not going to fix this for you. So what I did is I took this Product Manager and I just said, "Look, let's go for a coffee once every two weeks. We'll just have a one-to-one." This was before COVID. So you can actually go out and do these kinds of things. Um, and we would, every lunch, every Monday, every two weeks, we would just go down the road and have a coffee in a cafe, um, in London where I was working at the time. And I just got to know them as a person. And I really, really got to understand that like, this is a person that is under a lot of pressure in their job and they're very, very stressed out, and they take that sometimes out on their team. It's not necessarily their fault, but that is the way that they deal with things. Um, and if I can just be a little bit, have a little bit of sympathy to that sort of situation they're put in and I can work out what's going on behind that, and I would ask them about like what they want to do, what their career aspirations, what do you know, what do they want to be one day, where they want to work and this sort of stuff. And those kinds of small conversations, like I say, half an hour every two weeks, just a one to one, um, completely fixed the relationship and completely fixed everything else, because you just build up so much more trust with somebody if you're just having small one-on-one conversations with them.
And my kind of hack for engineers, if you like, is to have one-to-ones. People think one-to-ones is just for managers and it's for people to talk to their boss or it's for people to talk to people that report to them. Anyone can have a one-to-one with anyone in the business and set up a regular, no-agenda meeting every couple of weeks. That's just half an hour where you just chat with somebody, and that is a super, super valuable way of building up rapport with people that will pay off dividends in the future, like half an hour invested between a Senior Engineer and their Product Manager, half an hour every couple of weeks will pay off dividends in the future when you meet, uh, when you meet a conflict and you realize that, oh! Actually, I know this person really quite well now because we have coffee every two weeks, every Monday, right? And so you don't need to be somebody, you don't really need a massive reason to have a one-to-one with somebody. Just put it in the calendar, chat to them and say, "Look, I, you know, I really like us to work more effectively together. Um, let's have half an hour every Monday. I'll buy you a croissant or something, whatever it is you want to do." Um, and then just ask them about their life, asking about their career goals, ask them about like what kind of challenges they're facing. And yeah, before you know it, you'll be helping each other out. You'll be desperate to help each other out because that is human nature. We like helping each other. So yeah.
Kovid Batra: I think I would like to, just because I've been working with a lot of engineers and engineering managers these days, what I have really felt is that throughout their initial years of career, they have been talking with a computer, right? It's very difficult to find out what to talk about. I think the advice that you have given is very simple and I think very impactful. I have experienced that myself, but I have, I would say, I have been an exception to the engineering and development space because I have been a little extrovert and have been talking about things lately, at least in my comfort zone. Uh, so I was able to find out that space with people who are themselves very introvert, uh, but still I could break through and I could break that ice.
It's very difficult for the other side of the people who are developers throughout their career to come back and like start these conversations on their own. So what are the things that you really think we should be talking about? Like, even if a Product Manager is going to the engineer or the engineer is wanting to break that ice and like build in that empathy and understand that person, what kind of things you look forward to, uh, in such kind of conversations, let's say?
James Charlesworth: That's an interesting one. Like a lot of, there's a lot of people that are introverted in this industry. A lot of people use introversion as like a crutch or as an excuse, and they shouldn't. Be just, you know, being introverted doesn't mean you can't connect with other people. It just means you connect with other people differently. It means that, you know, you look inwards for experiences and things. Um, and so the practical advice would be to try and recognize how another person functions. You might find that your Product Manager is actually more introverted than they let on. A lot of people just put on a show. A lot of people are super, super introverted, but they put on a show in day-to-day, especially in work life, and they'll, you know, pretend to be all extroverted and they'll pretend to be all confident, but they're not. And I've known many people like this, that if you have an actual conversation with them, they'll admit to you that they're actually super introverted and they get super, super nervous whenever they have to talk to people, but they do it and they force themself to do it because they've learned throughout their careers.
So, um, yeah, I'm not suggesting people should push themselves too far out of their comfort zone, but In terms of practical advice, speaking in statements is quite a big thing, though a lot of people don't realise, but, um, I can't remember where I read this, this is from some book or something on like how to make friends and influence people, I don't think it's that exact book, but essentially, if all you're doing is asking somebody questions, then you're putting all of the onus in the conversation on them, and that's not actually that comfortable in conversation. So if you're talking to a Product Manager and you're just asking them, like, "Why are we doing this?" "Why does the customer want that?" "What's the point of this feature?" That's actually not, that's not a nice thing to do because you're making them lead everything. What you really want to do is just talk in statements. You just want to say, "Hey, like I'm just building this. It's really cool. We've got, we've got connectivity going on between this WebSocket and this backend database. There you go. That's the thing. Um, we've just realized that this is a little bit late. And so, it's going to be a few days extra, but we found an area over here where we can cut some corners." Like just to say things, say things that are going on, tell people stuff that's going on in your life. Um, and then there's no pressure on them to intervene. And this is like standard small talk, right? If you just tell people things, then they can decide to walk away or they can decide to engage you in conversation, but you're not putting too much pressure on them. You're not asking them a barrage of questions that they feel like they have to answer. So that's standard advice for introverts. I think if you are introverted and you feel like you need to talk to somebody to share, share details about what you're working on, share details about, um, you know, your current goals and where you are and see what happens, they might do the same. You might learn something.
Kovid Batra: Yeah, sure. I think, I think everyone actually wants to do that, but it's just that there has to be an initiation from one side. And if it's more relevant and feels like, uh, coming very naturally to build that bond, I think this would really, really work out.
Cool. So I think this was, this was really, uh, again, I would say a very simple, but a very impactful advice that one-on-ones are really things that work, right? At the end of the day, we are humans and at least for developers, I think because they are day-in and day-out just interacting with their computers, I think this is a good escape for them to actually probably go back and talk to people and have those real conversations and build that bond. So yeah, I think that's really amazing. Anything else?
James Charlesworth: You can talk about computers.
Kovid Batra: Sorry?
James Charlesworth: You can talk about computers. Like, if you're really into software, like, this is why gaming, I'm not really a gamer, but I know a lot of people connect over gaming, a lot of people bond over gaming because that's something that you get into as like an introspective thing, and then you find out that somebody else is also into it, you're into the same game, and you can connect over that, and it turns something that was a really insular, inward looking experience into like a shared group sociable thing, right? So like, yeah, I'm in many ways, I'm quite jealous of people that are into gaming because it does have that social aspect. So yeah, talk about computers. Like, just because your life is staring at a screen and talking to a computer, you can still share that with other people and even product managers as well. Product managers in tech companies, they're super, super technical. They might not be able to code, but they definitely know how computers work and they definitely know how systems work. They're designing these things. So talk to them about it. Talk to them about, um, you know, the latest Microsoft Windows version that can spy on your history of AI. Like, talk to your Product Manager about that. They will have opinions on this sort of stuff. And so, yeah, sorry to cut you off, but like, honestly, just because you're into computers and you're into coding, like that, that can be a way to connect with people. It doesn't have to be a way to stay isolated.
Kovid Batra: Definitely, definitely. Uh, perfect. I think more or less the idea is to have that empathy for people, do more one-on-ones and build that trust in the team, and I think that would really solve this problem. And I think one thing that we should have actually talked in the beginning itself, uh, the impact of this problem, actually. Like for our audience, I won't let that question go away like that. Uh, there must have been experiences where you would have dealt with consequences of having this friction in the team, right? So maybe the engineering managers, the product managers, the engineering teams out there, uh, who are looking at delivering successfully, I think they should be, uh, aware of what are the consequences of not putting some focus and effort in solving this problem before it becomes something big. So any of your, uh, experiences that could highlight the impact of this problem in the teams, I think that would be appreciated.
James Charlesworth: I mean, like pretty much all systems out there that are absolutely laden with tech debt and every product is late, is the result of this. It's the result of the breakdown between what the business needs or what the product owner needs and what the engineers are building. And I've worked on many, many systems that have been massively over-engineered because the engineers were given too much free reign. And so it was, you know, you know, not much tech debt, but really, really, really over complicated and took forever to deliver any value to any customers. They've also worked on systems that were massively under-engineered and they fall down and they break and there's bugs all the time. And that's because the engineers weren't given enough reign to do things properly. So you need to find that middle ground. And yeah, like honestly, I've worked, I've seen so many situations where the breakdown in conversation between product managers and engineers has just led to runaway bugs, runaway tech debt, runaway like people leaving their jobs. I've seen that happen before as well. Yeah, and that's, that's really bad. These are all bad outcomes for the entire business, right? You don't want engineers quitting because they don't get on with their Product Manager, and that's something I've seen before. Um, you don't want a huge amount of tech debt piling up because engineers are too scared to put their hands up and say, "Look, we're accruing tech debt here. This approach isn't working." So they're too scared to do that. So they just do the feature factory thing and they ultimately, build up loads of tech debt and then, a huge bug is released. You don't want that. Um, but you also don't want engineers to be just left to it and put in a room for a month and come back with some massively elaborate overengineered system that doesn't actually solve the problem for the customer. So all of these things are bad situations. The good situation is the one that is an iterative approach with feedback and collaboration between engineers and product. It's the only real way of doing it.
Kovid Batra: Definitely. Great, James. Thanks a lot, uh, for giving us so much practical and insightful advice on, uh, how to deal with this situation, and I'm sure this would be really helpful for a lot of engineering teams, product engineering teams out there to be more successful. And we would love to have you back on the show once again and talking about such insightful topics and challenges of the engineering ecosystem. But for today, I think it's time. Uh, thank you so much once again. It was great to have you on the show.
James Charlesworth: No worries. Thanks very much, Kovid.
In the recent episode of ‘groCTO: Originals’, host Kovid Batra engages in an insightful conversation with Vladislav Maličević, CTO at Jedox. The central theme of the discussion revolves around “Inside Jedox: The Buy vs. Build Debate”.
The episode starts with Vladislav recounting his 20-year journey from being one of Jedox’s first developers to stepping into the role of CTO. Moving forward, He sheds light on the company's vision, the transformation from an open-source project to a full-fledged cloud platform, and the various hurdles and achievements along the way, such as competing with industry giants like IBM and SAP. He also points out that many early team members remain with the company to this day.
Vladislav then dives into important decisions surrounding whether to build in-house or outsource various parts of their product, explaining that spending constraints often guide these choices. He also emphasizes the 80/20 rule (Pareto principle) and highlights the importance of integrating with Microsoft Excel as a key factor in their success.
Kovid Batra: Hi, everyone. This is Kovid, back with a new episode of groCTO. Today on our show, we have Vlado from Jedox. Welcome to the show. Great to have you here.
Vladislav Maličević: It's a pleasure to be here. Hi.
Kovid Batra: Hey, Vlado. All right. Like before, um, I start off with a beautiful discussion with you around the age-old 'Buy vs Build', I would love to know a little bit more about you, um, your hobbies, what you do at Jedox. So let's, let's start with a quick, cute intro about yourself.
Vladislav Maličević: Yeah. So, uh, my name is Vlado. The long name is Vladislav Maličević, uh, long name coming. It's a, it's a Serbian name and, uh, coming, coming originally from, from Bosnia, but I've been living and working here in Germany for the past 22 or 23 years. I started, uh, 20 years ago this year, uh, with Jedox. I was one of the first, uh, employees, one of the first developers and, uh, slash the, uh, employee of the company, went through the ranks over the years. I was lucky to follow the growth of the company and went through the ranks in the, in the engineering department. I was, the Head of, uh, Development and the Director of Development, VP, um, Development, uh, and later on added support, uh, um, coined the cloud team back in the day. And, um, a few years back, I joined the C-level as a CTO with the company of 450-500 people today. Right. And it was an incredible journey, um, to, to, to look at, uh, from, from within, uh, observe and participate in, in this, uh, in this long journey.
So, um, yeah, but more about personal. So I'm a, I'm a father of three girls. Um, I also have a sausage dog and, uh, yeah, with my wife, uh, we live, uh, with my, with our kids here in Karlsruhe in Germany, which is a university city, um, let's say, more, uh, in the southern part of Germany. Yeah. So that's, that's about it.
Kovid Batra: Cool. I think, uh, this is really amazing to see. I mean, rarely we see this someone spending such long time joining in as an employee and then growing to that C-level in a 20-25 year journey. So that, that has been, uh, one of my first experiences, actually, with someone on this show. I would love to know how it all started and what is Jedox about, uh, what was your vision and the whole company's goals and vision at that point of time? Now, 20, 20 years hence, how, how do things look like?
Vladislav Maličević: Yeah, sure. Yeah, I mean, the only constant in life is change, right? And, and many things, uh, stay unplanned. Initially, I, I really didn't, didn't intend to, to stay with Jedox. I thought it was in-between, uh, just an in-between jobs kind of thing, and, um, also the setup, it was a very small company, small office, uh, just a few, few people, uh, which by the way, all of them are still with the company. So all the people that were in the company when I joined are still with the company, which is also one, one quality, I must say. Like I said, I initially didn't, didn't, didn't plan to stick too long, but the challenge was there and it, it, it became more and more interesting from day-to-day. And, um, we were kind of, it's, it's easy when you have a kind of a black, uh, blank canvas, yeah. There is no product and then you start from scratch and you start building something and you know, over time, it becomes, uh, you see more and more of a product and you, you see more and more customers and it's sticking with the, resonating well with the, with the, with this huge community. And then you also add ecosystem to the, to the mix, you have partners in between the customers, growing globally, opening new offices, adding more people and things like that. So it is, it is simply, um, it was, it was an incredible journey. Usually you start off, like you said, either you hop from one, one, one job to another every few years and change, or you join as a, as a founder, right? Uh, you could also be, uh, it's not, not unusual to have a founder on the team, uh, being early on there and then, you know, doing something with the company and moving on, right? I indeed, I wasn't the founder, but was one of the first early people. So I, I sticked with the, with the, with the product and with the company, and, this is, um, resonates well with my, uh, passion. I kind of map myself or I reflect a lot of my, my work life and life with the product that we built over the years.
What Jedox actually is, is, um, I mean, uh, we are proud, uh, leader in the magic quadrant, Gartner's magic quadrant for, for EPM, CPM, or enterprise performance management, corporate performance management, or XPNA, how they call it nowadays. Being in the upper right corner, it was obviously not, uh, not, it was a journey. It's not like we showed up immediately there, right? From, from zero to hero, right? It took us a few years to move slowly through the, through the, from the lower left to the, to the upper right corner. And certainly, you know, competing there with the, with others, with the big names like Oracle, like SAP, like Anaplan, um, it certainly make, makes us proud because we are by, by far a much smaller company, uh, by, by sheer size, and, um, to some extent also by history or by tenure, right? Um, but yeah, it shows that, um, you don't need a lot of people and a lot of money to build good products and, and make them stick with the, with the customer.
One of the things that helped us in the beginning, I mean, that, that's also, we evolved over time. Uh, one of the things that helped us in the beginning to put a foot in the door in the market is the fact that initially we were, um, actually we started as, as a freeware and then switched to open source, which is kinda, you know, 20 years ago, it was things like Linux started showing up around. I mean, actually it was, uh, uh, Linux was, was way before, but, but around that time, there was like a boom of open source. And we were, um, I belie, theve first product in the market to offer planning, uh, as open source, and that was a big shock in the market and it helped us a lot to, to, to spread the word, uh, globally and become known in the market, although we are, uh, we had the low or no, no marketing budget whatsoever. Right? Um, and then over the years we, we matured, we kind of, um, made a clear separation between, between open source and the commercial bit. And, and, uh, we curated both brands in parallel. But over time, we, we, we focus nowadays, we are focused totally on, on our cloud product under the name Jedox. And, um, basically open source is, is the past. It's also not something that we see in the market nowadays anymore in this, in this, uh, let's say in this bubble. It's relatively, you could say, it's a, it's a niche, but it's a quite, quite, uh, I wouldn't say lucrative, but quite, quite a big niche. It's a specific need. From the business to be able to quickly plan any kind of data, usually finance data, but any kind of numbers, being headcount, in any vertical, in any industry. Yeah. Nowadays, it's even, you see it in every, literally every company needs to do some kind of planning. And doing that with a tool like, like Jedox, makes it less error prone and, uh, very, very seamlessly integrated, allowing, um, to connect to, to the existing third-party systems, um, connecting all the data from all the different systems that you usually find, on average companies nowadays have 150 plus tools or services that they consume. Jedox is well-versed in, in accessing all these different existing products in the, in the customer's ecosystem and then combining those in, in Jedox.
In a nutshell, Jedox is, is a, is a platform. It's a local platform for building business applications, right, speaking less technically. But, what you have in that platform are components. There's a lot of IP, Jedox IP in there. You have your own in-memory database. You have your own ETL tool. You have your, your backend, middleware. You have, uh, frontend for, for mobile, for web, obviously, and we have quite a good integration with, uh, Office, in particular with Microsoft Excel, which is kind of a go-to application for any business user nowadays, right? Most of the time, the journey of our future customers starts somewhere in Excel, they did something over the years in Excel, and, um, they built it, they invested hours and hours in it and they've been living it, but, you know, they, over the years it, it became cumbersome to, to maintain it, multiple copies of it, multiple versions of it, uh, sharing it across the team or even teams, uh, error prone, and it's, it's, uh, known as an Excel chaos, which we actually try to, to solve. Right.
A lot of product, obviously, 20 years we weren't sitting, um, so we were quite busy developing that, but nowadays, it's quite extensive and mature, very grown up, uh, enterprise platform for building business applications, right? And coincidentally, majority of the, let's say, first, first-time users come from somewhere from the office of finance. Usually, that is the, that is the entry point where users come from. But, uh, it's not limited to, right, it's just the, usually the entry point, but we spread quite quickly within the organizations because they see the value of the product.
Kovid Batra: Got it. I think this is very, uh, interesting, competing in a landscape where you have MNCs and legacy players already there. You have been there from the very beginning, so the company founders and the company belief in that respect on day zero and today, uh, would be very different, right? At that time, you guys might not have even imagined where you would be 20 years hence. Of course, people have a vision there, but what was it like for the Jedox team and Jedox founders at that point of time?
Vladislav Maličević: Yeah, I mean, I mean the, the vision was there, but the, the vision, I could say that the, the vision was to, to, to rule the world or rule the bubble, rule the, rule, this, this, let's say, small niche, even back in the day. Appetite was certainly there, but we were also realistic. We knew that, you know, it, it will take a while to, um, even meet, uh, let alone exceed, the functionalities of the, of the established product in the market back in the day. Already, the market was there. It was booming. It was ruled by IBM. IBM was the absolute leader. A company called Infor was, was, uh, also quite prominent in the market back in the day. Actually, they weren't even called Infor back in the day, but through acquisitions, they, they grew into Infor, um, and they still exist, uh, to date. We knew we were on the, on the, let's say, on the, on the lower end and we weren't the disruptor, but one of the vehicles was, was definitely open source and coming through the open source, uh, on the one hand side, you have a, you have a behemoth, let's say, or a mature, um, established leader in the market selling, you know, I don't know, a couple thousand dollars per user, per seat, um, license. And then all of a sudden, this small team from Germany comes with a product that almost, almost, right, not, not really back in the day, but, but, um, almost matches the, the functionality, brings in, let's say, a subset of the functionality for no, no cost at all. It was open source and everybody was open also to contribute back in the day. There was no GitHub back in the day. We used to use SourceForge, sourceforge.net. That was, uh, that was the platform of choice back in the day where we hosted our code.
The word spread quite quickly and, um, the adoption, we saw traction very early. I think I joined in November, October-November 2004 and we had the first version of the product that you pretty much you can recognize even today and in today's products. So everything you need to know, everything you need to be able to work, you already had. Um, I believe we, we shipped in February of 2006. So it's a year and a half. It took us 18 months to put, uh, put the product together, and already there was, uh, in-memory database. We had a frontend for Excel. We also had, uh, let's say some primitive way of ingesting data, let's say, um, some, some baby version of, of ETL within the product. We had a predecessor to our, uh, today's web frontend. We had it, uh, it was, uh, Web 1.0, the old, old school, uh, web frontend that was already connected to, to, to this, um, to, to Excel and to the database. So we, we had web frontend. So we were ready to, to, to rock or ready to run.
Later on, additions came in, including ETL, including a modernized version of, uh, the web frontend. And nowadays, obviously, everything is happening in the web and you are doing, also authoring within the web and Web 2.0 was a thing back in the day. Like we quickly jumped on the boat. Later on, other innovations happened. Shift to Kubernetes, so, microservices and things like that. So going from the legacy, I mean, actually the, the first shift was the cloud cloud was the thing. There was no cloud back in the day, right? Maybe there was some hosting somewhere, but usually customers were running it on their own, even on their laptops or, um, within their corporate network, server, client server kind of thing. And then later, 2012-2013, we saw cloud kind of picking up and this is where we started our excursion into cloud. And from there, um, we moved on. Today, we are a cloud company, a SaaS product.
Kovid Batra: Yeah. So, in this, in this whole journey, I think you survived, in fact, you, you thrived as, as a product, as a, as, as a company, right? Of course, you mentioned that you became an open source product, right? So that, that was one critical move which probably helped you a lot in exceeding what your competitors or counterparts for doing, but there must have been much more deeper technical decisions, and with this question, I think I'm trying to understand from you how many times you had to take those critical calls which impacted the business in an immense way, and whether those were decisions where you were building products in-house or you were outsourcing it and how, how did that journey come along, now, 20 years hence, when you look in, in the, in the retrospective.
Vladislav Maličević: I mean, in retrospective, I wouldn't say there were too many critical events, right? The situation in the market is dynamic and you have to react on, literally on a daily basis. You have to make decisions on, uh, really, literally, some, some important decisions are made on a daily basis. However, the strategy, you don't change every, every two days. I would say, we had three, four waves, uh, over the course of 20 years where we were, for example, cloud decision to go all in on cloud. Um, it took us a while, right? Because we are, I'd say, uh, first of all, it's quite conservative, the market itself is quite conservative. You are usually working with financial data. Financial data is very critical. People are not eager to, to expose financial data out of their corporate network. So when the cloud showed up, it was kind of, oh, do we, do we, do we even jump onto this boat? And, and I remember, uh, vividly, so there were, there were like pros and cons, and, and there were voices in the company. I would say majority of the voices were, were, uh, against cloud. "Hey, nobody will jump on this boat." "Hey, nobody wants to put data in public cloud." "This will not fly." And indeed, it didn't, uh, it didn't, uh, didn't fly immediately, right? It took us a while and depending on the market, obviously here in Germany, it's quite, I would say a bit conservative market. So it takes a few years for, for things to become mainstream, and for the adoption, one thing was technically not nothing, I wouldn't say nothing special, but was a smart move by Microsoft back in the day when they introduced, uh, something, a thing called German cloud, um, which was kind of an idea to, to bring in sovereign German cloud on German soil, operated on German soil, but German company, right? Disconnected from the rest of the world, kind of from, from the corp in, in the US and things like that. This kind of brought more trust into it, of course, with additional marketing and massaging customers, um, across the German and Dach region, Austria, Switzerland, and the Germany region. But it definitely helped in adopting cloud more. And then a few, few years later, all of a sudden, it became, you know, cloud became commodity, somewhat delayed, but became commodity even in Germany. And then it was no brainer. Yeah, okay. Let's go. You don't have these conversations anymore or, or very rarely. Yeah.
That was one thing which was kind of critical back in the day. We started talking about 2011-2012, but the real push came around 2015-2016. So it took us a few years to come from zero to, to really, hey, full-steam ahead, let's, let's, let's do this, this cloud thing. That would be one thing, I think being close to, to, to Excel. So initially being open source helped promoting the brand. You would need to spend millions and millions globally on marketing to spread, spread the word about Jedox, um, normally, and with open source, it kind of went word of mouth and it very quickly spread. Um, again, context, right? We're not in the Google business, right? We're not a commodity that every consumer is using, but let's say, in our bubble, the word spread super-quickly. And, um, later I remember I spoke, we acquired one company, uh, in, in Australia, uh, back in the day and, and they became, before we acquired them, they run as a partner for a few years. And, um, I had a pleasure talking to, to one of the founders of that company, and he said that he remembers well when we announced the first initial version. He was back in the day using IBM and he read it on some forum that there is, um, there is a new product called Jedox and it's open source and it's free where you can download it and use it, and, and he does almost everything, um, that we used to pay for and he wrote to his colleagues, emails saying, "Germans are coming." And I use that reference often. It's quite quite interesting because hey, where's Australia from here, right? On the opposite side of the world, but it really, uh, the word spread quickly. So I think that was a good decision to go with open source initially. It didn't, on the other hand, it didn't create any traction. I must say, very little, almost no traction on the development community, right? We had it, we had it up, but we were the sole maintainers, very little input from the community, right? Maybe it's too technical, yeah? And again, maybe it's a context and a niche which we are in. It's not some commodity that everybody needs on their desktop. So maybe that's one thing.
So, open source, cloud, uh, being close to Excel was always, uh, I think was a good thing. Uh, Excel is the, I don't know. Um, there's this big question. Yeah. What is the most common functionality in every enterprise software? And that's actually 'export to Excel', right? In every enterprise software, you will find that button or option 'export to Excel', in every enterprise software. So, I don't know, there are billions of users of Excel, certainly hundreds of millions of Excel users globally, and, um, this is a kind of citizen developer. Uh, if you, if you, if you look at like from, from that aspect and us being close to that, let's say, both, both literally close. We, we are very compatible with Excel. We integrate well with Excel. We also understand well, uh, Excel format. We can ingest it and import and export it in Excel format. So literally that, but also the, this concept of spreadsheets, I think this was also a good, right choice.
Kovid Batra: Yeah, I think that most of the time it really helps, like instead of going out and introducing something completely new, which is not in the behavior of the user. It might be a hit, of course, like there are revolutionary ideas which are not a part of the behavior and then people form a behavior around it. But mostly, what I've seen is that any product team building a product closer to the existing behavior of people and the way they are using the current solutions, if you are close to it, then it is very easy for adoption, easy for people to understand and relate to, and they quickly start using. And then, of course, you can put them on a journey of gradual learning where you introduce new features, you put in more services and then they grow from there. But the initial hooks should be like that where you are close to the existing solution and yet offering something very impactful and having more data than what the current solution is giving them. So yeah, I think it's, it's a mix of, um, few good decisions, I would say. There was, there is no single bullet, magic bullet that is going to solve for sustaining or a business thriving in this market. It was constantly your eagerness to learn, your eagerness to explore, and then changing and adopting towards things that are coming in, like cloud came in and then, of course, at every point you understand that user behavior as well as what the market trends are saying and moved in that direction. So, of course, this really worked out well for you.
Few more things that I would want to learn here is that on this journey, when you're building such an immense product used by thousands and maybe millions of users, I'm not sure how many users you have right now, but, uh, I'm sure like there are hard decisions that you're taking about, like, uh, building something in-house and, uh, acquiring other companies, like once you just mentioned about one. So when, when there is a decision around building something in-house and, uh, like outsourcing it, can you just give us some example from your journey and, uh, how did you conclude on certain decisions like that?
Vladislav Maličević: Yeah, some, some of those, uh, decisions were, were made quite easily due to whatever constraints, right? So if you have, let's say, uh, if money is your constraint, obviously, and you, let's say, you have a few idle people on payroll, obviously, you go and build, um, start building, especially when you don't understand the magnitude of the, complexity of the problem, right? You don't see, you don't see the big picture in the beginning, right? You go into it somewhat naive. I can say, I mean, I was, uh, I was quite young at the time. If you don't know the, the, the magnitude of the, of the problem, if you don't see the, the, the whole, uh, scope of it, and you are, you have a white canvas, you go for it and you simply, you give it a try. So there was no, there was actually no, in the beginning there was no, um, um, nothing to, no decision to be made whether to invest or acquire or whatnot, because the money was not there, right? So, So let's say in the beginning, majority of decisions were, were built. Um, and then over time, you have the opportunity to change. You can focus, you can keep the core, core of the product to yourself and then, whatever is not core, you can try to outsource. The good thing with a, with a platform like ours is that once you have the platform in place, you can start building actually these, um, applications on top of it and you can make those applications to, to a product. So for example, uh, one more time, one more thing that happened last year, we entered magic, another magic quadrant last year for financial consolidation, which is a, let's say, um, off the shelf separate product from our core product, but it's built on top of the platform and it, and it's sold separately. Right? So there are, there are players obviously in the market who do just that, uh, have a product just for that, but we built it on top of our platform. So you get the platform and you get a, you get a financial consolidation of it and you can build any kind of, uh, business application with it. So, um, once you have applications like that, then, and if it's easy to package it like it is with Jedox, then you can come up with things like a marketplace, which we do have, right? We do have a marketplace. So we put these applications in the marketplace and then you can easily install them from there, and then, it's, I don't know, it covers 60, 70, 80, some, some, some cover 90 percent of the functionality out of the box, and then you just fill it up with life, with your information, and then, uh, off you go, right? It's, it's configured and you can use it, it's ready to use.
Um, so, uh, the kind of the decision is definitely the, um, um, you have, you have spend constraints, so, so you have to be cautious on, on the spend. Similarly with cloud, right? Do you go to public cloud or do you build and host, you know, you do collocate your servers, you build them yourself and run them yourself, uh, somewhere, right? Yeah, that kind of decision someone needs to make, and in the beginning, maybe decision-making is super easy. Yeah, of course, you go and you buy a pizza box and you put discs in it and CPUs and then you collocate it to the, at your nearest host of choice. But then, if you want to run it at scale, things like compliance come into place and you need to, attestations, you need ISO, SOX and CSA star, and whatnot. You cannot manage them anymore on the commodity hardware that, that fails every, every three months, something's broken and you need to take the system offline and things like that. So yeah, this is where, where you go into cloud and use services and build it, build it like a Lego, cherry-pick services that you need and build, build something out of it and outsource kind of responsibility to a, to a infrastructure provider of your choice. Same with code, right? Usually, in the beginning, if you have monetary crusades, but you have the means, if you have, uh, well, just a couple of people should be sufficient to get you going, right? That's the thing, right? In the beginning, this Pareto of 80/20, with 20 percent of, uh, personnel, of people, you can build a lot of products, you can build 80 percent of the product. But the last 20 percent of the product are the hardest, and then you need additional 80 percent of people to, to, to add on board. If you have the means, this is where you, you can make, uh, make decisions, whether you, you outsource it, uh, let it be built, or you take managed service, OM solution for the means, for the, for the particular case. I mean, nowadays, it would be totally different, right? You look from different perspective or from different dimensions and cost being just one of those, right?
Kovid Batra: Yeah.
Vladislav Maličević: You, uh. So, yeah, it depends. It depends on the context, right? In what kind of context and what kind of setup you are. We are scaled up and we are a mature company, profitable company nowadays, so we can afford ourselves to take a bit more time to make decisions such as outsourcing or buying, acquiring pieces of product into the whole. Whereas when you are at the beginning, usually you only have an idea and your free time and then you go and roll up your sleeves and you work, you code, you usually don't have money, right, to, to go and buy expensive services from others, right? Um, yeah.
Kovid Batra: Cool, Vlado. I think that's interesting. Um, we are running short on time, so we'll have to wrap up now, but it was a really interesting talk. Would, would love to talk more, uh, and know more details about what happened in those 20 years, what things you actually felt were very challenging that were solved, on those pieces, but I think that would need another episode and I would love to have you for another episode, absolutely.
Vladislav Maličević: Thanks a lot. Yeah. Let's, let's do that some other time.
Kovid Batra: Sure, absolutely. All right. So that's it for today. Thank you, Vlado. Thank you for your time. Uh, looking forward to host you once again, uh, very soon.
Vladislav Maličević: Thanks a lot. Bye-bye.
Kovid Batra: All right. See you. Bye.
In the latest episode of 'groCTO Originals' podcast, host Kovid Batra engages in a thought-provoking conversation with Leonid Bugaev, Head of Engineering at Tyk. The episode delves into ‘Thriving in recession: Guide for tech leaders.’
The episode starts with Leonid sharing his background, his approach to balancing work at Tyk with side projects, and the key differences between remote and distributed companies. He explains the impact of economic downturns on businesses, stressing survival as the primary objective. He also shares communication techniques for announcing layoffs to developers and explores challenges in managing teams and maintaining operational efficiency in difficult situations. Leo also advises engineering leaders to prioritize customer retention and think in business terms instead of engineering and R&D. He suggests encouragement through additional bonuses & learning opportunities to employees who stay after layoffs.
Lastly, Leonid concludes with essential advice to view change as a driver of innovation and growth rather than a threat.
Kovid Batra: Kovid Batra: Hi, everyone. This is Kovid, back with all new episode of the groCTO podcast, formerly known as Beyond the Code. And today with us on our episode, we have a very special guest who has 18 years of engineering and leadership experience. He's currently heading Engineering for Tyk. Welcome to the show. Leonid.
Leonid Bugaev: Hello.
Kovid Batra: Great to have you here.
Leonid Bugaev: Yeah. Glad to be here. So, it's a good chance to, and a very interesting topic, which was suggested. Uh, so I'm, you know, like I have been in IT for the last 20 years. So a lot of things, I see the companies rising and falling, uh, uh, tried various technologies, uh, I've been both like very deep in engineering, uh, and now I'm in more leadership roles for the last 10 years. So it will be interesting to, you know, like share some of this experience, I guess.
Kovid Batra: Sure. Absolutely, absolutely. But before, uh, like we get started on our today's topic, uh, which is very interesting, and I think nobody has talked about it yet, even though it has been there from the last few years. So we are definitely.. For the audience, I'm just putting it out loud, uh, we are going to talk about how to navigate and lead dev teams during the time of recession. So that's the topic for today. But before we jump into this topic, Leo, I think, uh, we would love to know a little bit more about you. Uh, something, uh, around your hobbies, your personal life that you think would be interesting and would love to share with the audience. So please go ahead and tell us who Leo is.
Leonid Bugaev: Yeah, absolutely. So, you know, like, uh, I was also, you know, like a person who is, who likes challenges, and I was also into like, you know, like startup side projects and all this kind of stuff. So like, I had my first business, it's like at 17 in university, and you know, like, uh, I always worked for startups as well and I really enjoyed it. So I've never really been in, like in a big corporate environment. So, similar, always fast-paced rhythm, and I really enjoy it. So as for now, I'm, you know, like I'm currently living in Istanbul. I'm, you know, like I have two kids, a beautiful wife. And like, uh, I personally, uh, kind of like my hobbies and like my work is kind of like a good intersection. I still, uh, up to this day, I do have a lot of side projects. Some of them I even try to monetize actually, some of them just like for fun and I always stay up-to-date, especially like with the current AI hype and all this kind of stuff. So I'm very, very curious, and, uh, yeah, okay, that's it.
Kovid Batra: Great, great. And what about your current role at Tyk, like when you were heading engineering for such a company, uh, which is multinational, like you have offices in different parts of the world. How is your experience, uh, working at a multinational? Whereas when you say, uh, you are very curious, you have a lot of side projects, don't you think it is very contrasting, like, uh, on a daily life, how you see things?
Leonid Bugaev: Uh, well, I don't know if, you know, like, uh, uh, if it's actually contrasting or not, but you know, like an interesting thing is that I probably would never again work in the office, for example, that's definitely, you know, affected my life in the last 10 years, I'm working like fully remotely, uh, for various, like clients in the US in the Europe, et cetera. And it, uh, changed my lifestyle a lot. Uh, it changed the way how I, uh, manage my work-life balance, how I find time for my, like side projects as well and so, because like it allows you to save some of the time as well. And, uh, yeah, so it's, uh, it's very interesting. And being like a distributed company, you know, like there is also kind of a bit of a difference between like remote and distributed company because when we're talking about remote companies, for example, like you have an office in like your country and then employees like working from other cities, for example, in that country, and you are still close to each other, but being distributed means that people are literally spread across the world, a lot of mixed, different time zones. It's, uh, very, very challenging for building in general, like, uh, teams, the communications, all the channels, and you know, like being, you know, like efficient in communication and so on, becomes like super important and actually like essential for survival of such teams, I guess.
Kovid Batra: Yeah.
Leonid Bugaev: So it's for sure affected a lot, you know, like as the way how I think, how I build the teams, what kind of people I hire and so on. Yeah.
Kovid Batra: Perfect. Great. All right. Thanks for that quick intro, Leo. Let's move on to, uh, our main topic for the day. And, uh, Let's start discussing about these economic crisis that happen time to time in the world, right? And, uh, the latest one is something that we are going through and almost out of it. We are really not sure about it, but we have seen the, yeah.
Leonid Bugaev: I highly doubt it.
Kovid Batra: Yeah, but we have definitely seen the consequences of it from various angles, in our society, in our companies, everywhere. So I think I just want to first understand, uh, from your perspective, how do you see these economic downturns and how do they play into, uh, companies and businesses when they come?
Leonid Bugaev: Yeah. Overall, like, uh, when you live long enough, you start seeing the patterns. When it repeats again and again, you, like, are not surprised anymore that much, and you kind of like know what to expect and what to prepare for. And I think that's like one of the most important things to understand here. So it's always like, uh, economics, et cetera, it's always in cycles. So we had some amount, for example, of time with cheap money, uh, short, like percent rates, uh, a lot of loans, we see market is booming, everyone gets investments and so on. And now, we are in the, like an interface. So like money is very, very hard. Uh, loans under like a big percentage, and the way how companies get treated, uh, from the outside and from the inside change dramatically because, like your values in the company change a lot. And, uh, in a lot of the cases, you know, like, um, I think one of the main things to understand during these times is that it's not.. First of all, it's a time of chance because the ones who will survive this period, will afterwards get a way nice bonus and a very big boost.
So your first goal as a company during such times is to survive, and it's actually not that easy, especially, you know, like if company gets used to, for example, to the VC money, constant growth, and so on, because like, uh, as I mentioned, like I do feel it, I have some like insights on how the stuff works and right now, getting the investment, et cetera, is much, much harder. In the past, it was enough to get to, you know, like to convince investors that like you have some traction, some good ideas, numbers, et cetera. Now they're looking for the cashflow. How much money do you have in the bank? How much time, how much money you spend, et cetera? Are you profitable or not? I remember those times when companies that were bought, were measured in Instagrams. Like, uh, this company was bought for two Instagram, for three Instagram, et cetera. You know, like, uh, and, uh, they, some of them even didn't have revenue, like you know, like the market was booming. And also, you know, like I do see a lot of consolidation in the market happening. Uh, so yeah, if it's even, like when applied to like our market, like it were like API management and so on. I do see some vendors literally like bankrupt, uh, in the lighter industries as well. Some of them get bought by bigger vendors, et cetera. So it's, you know, like very challenging times. And as I mentioned, like survival, uh, not even growth, but survival is probably one of the main, uh, ideas which you need to understand when going through recession, I think, and it actually involves a lot of steps and, uh, and changing the mindset on how you use a company and its values. Yeah.
Kovid Batra: Cool. Totally. I think it's very important to understand, as you said, that these are the patterns and they are bound to happen, and with that, I just want to like move on to something which I feel that everyone should, whether you are in the engineering department of a company or you are in any other department of the company, you should be financially, economically, um, aware that these things can happen anytime and one needs to be prepared for such kinds of turmoil. And that's applicable not just to individuals, but also to the businesses as well. What do you think? What's your thought on that? How companies that have come out well out of this situation have been able to navigate it or handle it better?
Leonid Bugaev: Yeah. Well, first of all, like for example, my role is like an engineering leader. Like I understand that like if you actually spend more time with engineering, like 90 percent of your time is spent with engineering and not with, like the leadership team and business. You're doing the job wrong, especially in such times, because in such times, you really need to spend way, way more time to communicating like, uh, and understanding the business part, how you actually earn the money. And if you're talking about, like, you know, like metrics, like there's actual money on the table, at that time, it's the main metric, and, uh, you need to, you know, like clearly understand where you spend the money and what is your, like, uh, like return on investment. Let's say so. That's why, you know, like during such times, uh, we may see that some of the like research and development projects get closed. There are some like, uh, uh, optimizations of the talent, which was maybe too hard, like too much during the, like good times and so on. The important part here is that if it's not done right, it can actually also like harm the company because like, you know, like if you see that like your cash flow is not where you want it to be. And, uh, if the leadership team, for example, that is, like, not maybe like that's like technical or similar, and you do not have a good connection, the decisions are still made from the above. And if they don't fully understand, like the product, and if you don't fully understand the product, there can be some consequences. All of it needs to be synchronized with the business.
Kovid Batra: Right.
Leonid Bugaev: And, uh, so if you have some, for example, multiple products which you offer to the customers, you need to clearly understand like how much each of those products actually bring you money, and how much time, for example, you spend on the customer support, on the development time, and so on and so forth. And you need to, like, manage all this, like, uh, like, even, like, spreadsheets, and so on. And same with, you know, like money and understand, like, things like budgeting for the tooling, for the HR, and so on and so forth. I know that, like for a lot of people, especially, from, like engineering, it's very hard to talk about money and very hard to deal with these kinds of like routine tasks as well.
And I've been there myself. I mean, like, uh, and it's still very hard for me. It's still like a cause, like, you know, like procrastination and fear and you know, like, I just want to do things. Uh, but you know, like the tip here is, it's like if you will not be able to like optimize this money, et cetera, you will not have a company to work with or for, and like, uh, you won't be able to do things anymore.
Kovid Batra: And I think the biggest, I think the biggest challenge for someone who is coming from a technical background is having that context right. The first step is that, like first you understand what exactly the business is saying. And then as a leader, like, as you said, you have experienced it yourself. I'm sure you would have been in that place where you would have gotten that understanding that where you are right now. But then, you have the whole team to lead along, right? And like take along and lead them so that they are also aligned with the business goals. So I think that's more difficult than, uh, for yourself to first understand what's going on. So I might be, um, having that exposure as an engineering leader on a day-to-day basis with the business, with the product and everything. And it would be still a little easier for me to understand what's going on there. And based on that, I can gain that context and I can definitely align my thoughts to that. But when it comes down to delivering that context to someone who has less exposure to the business, to the product, and let's be very frank and true about it. Like, we try to bring developers to that point where they have complete customer empathy, they have complete exposure to all the things that are happening in the business. But of course there is a layer where leaders are talking, engineering managers and product managers are talking who have context for both sides, but developers are still in that silo where when you start explaining to them these concepts, it might not come easy to them, right?
Leonid Bugaev: Yeah. Yeah. It's really tricky. And, you know, like especially when you know, like a company starts to get like mature, you kind of like, you have to build the layers, like managers, like managers of managers, some, like the board, et cetera. And not everything, first of all, can be, you know, like exposed. Sometimes you can expose it only at the, like, at the final minute or similar. There were a bunch of, like posts on the Hacker News, et cetera, with some examples on how people get fired via Zoom without, like, uh, you know, like a previous notice, et cetera, et cetera. And I've, you know, like, I've been through similar situations. There is always a story behind it. It's not easy, and, you know, there is no easy answer behind it on how to, like deliver such news. So it's very challenging. Working in this role, I've been through multiple, like leadership trainings and one of them, which I found very interesting is, basically they interview, uh, like quite a lot, like multiple sessions and they kind of build like your, like psychological profile with your values, et cetera. And that's you know, quite an interesting document in the end, uh, where you can better understand yourself and it's one that you can also share with your peers, so they will understand like what kind of a person you are, what are your values, et cetera. And my profile was quite unique, uh, in the sense that like, uh, uh, I had like two major like, um, motivators, how they call it. And my major was like, uh, 'peace and harmony', and the second was 'enjoy life and be happy'. You know, like it really contrasts with what I actually need to do sometimes when like, you know, like when such thing happens and, uh, it was, you know, like way hard for me, like it was like a mental shift for myself on how to approach the situations, how to not blame myself, how to, you know, like be more peaceful, how to be reasonable and how to explain it to like people whom you manage, why these changes are required and so on and so forth.
But it's never easy. It's never easy, but once you get, uh, some clear picture and some clear message, and especially, if this clear message is coming from the company, not just, like from you, like this is the direction where we're going, this is what we need to do, et cetera, it becomes actually much easier because like, and especially like, um, for example, uh, at Tyk, we try to share all our financial numbers, churn, new customers, et cetera, et cetera, in the company dashboard, and we share it with everyone publicly in our Slack every month. So every month, everyone can see our numbers, where we're going, are we good, are we bad, et cetera. And every few months, uh, we have like a call with the leadership team where we also try to be open, uh, about the challenges. Obviously, sometimes when, you know, like, uh, for example, we had like one round of layoffs, like about like one and a half year ago, and, uh, sometimes you can't mention all the things. You can put some, you can start preparing for the challenges, you can start, uh, like showing the data, et cetera. It takes some time for people also to prepare for you. It obviously, also rises anxiety, and you need to somehow deal with this anxiety. And that's where, you know, like the personal relationships, uh, with your team is very, very important. You can't treat them just like as employees, you have to be very close to them. And so, they will trust you and your judgment and so on. But yeah, it's, it's challenging. It's challenging.
Kovid Batra: I totally understand, and I feel you there. In these situations, I think the most important part is like first keep your calm in place and then keep everyone and treat everyone as humans, not just employees there. I think that's the biggest factor that would drive how you are communicating things. Of course it really matters what the company's communicating and within that concise communication you are putting across the next steps from there, because for any human, uh, it's very true. Like when you tell something and you keep it open-ended and it's bad news, people would run into chaos, right? They wouldn't know what's going on. They would have their own interpretations. They would decide their own next steps, right? But when it comes with the thought of empathy, with clear, concise communication, and you as a leader are connected and you have your calm in place., I think you would be able to navigate through this situation in a much, much better way as compared to someone who is not doing this.
So in this situation, when you did something, can you recollect some of those incidents, some of those, uh, anecdotal things that happened at that point of time, uh, which you did and could be a good example to explain where you took care of these aspects and, uh, you felt that you did right in that situation? The person who came to you asking, uh, what's going on and you were able to actually help them understand what exactly happened and how things could look like in the near future. So has anything of that sort happened with you?
Leonid Bugaev: Yeah. So, uh, first of all, as I mentioned, not all information can be, you know, unfortunately, you know, like shared with, like people whom you manage, et cetera, and there comes a period of time when you like, you know, like are by yourself and you know the news, but you can't tell them, and you know, like this tricky situation when you jump on a call with someone, but you know, for example, that they will leave and, but you can't tell it. So like, uh, that's definitely like a tricky one. The last time when we had a similar situation, it was very important to actually track some metrics as well, because, um, if there is, uh, one case when you've had to let go a very good employee and like everyone is asking, "Why? What's happened?" I don't know why. And another case is that like, uh, when there is some known issue, yes, maybe you try to fix it, some performance improvement plan or similar. Um, and also if it's like covered by some metrics, uh, like sprint points or similar, that's another case. And especially, if, uh, such metrics are visible to your, like engineering leaders, to your managers, for example, and so on, and then like, in such situations, there always will be people who are confused, afraid, angry, and so on and so forth. What's very important is that like, you can't please everyone. That's like, that's a bad situation from all angles, no matter how you take it. But it's very important that like, uh, You're like a core team, you're like a managing team, etc. You'll be prepared for it and you'll have the right questions, the right answers to the questions. In advance, before all it happens, I've tried to like prepare, like some, like a questionnaire, whatever questions they may end up with, from the people whom they manage and so on. And it makes them like, uh, like much more calm, much more easier because like they know what to answer.
And another case is that like a person will leave and will not get any, like exit package or similar. Another thing is if you know that like this person will be treated well, and like, you know, the company will give them like some good exit package and so on. So having such details and mentioning them to like managers again, et cetera, is also very important. So you need to, uh, clearly explain them the reasons and these should be very valid reasons and give them all the documentation, uh, all the numbers. And, uh..
Kovid Batra: I think it becomes all the way, all the way more important to have this level of clear communication, better performance reviews, and understanding for yourself, as well as for someone whom you're talking to. So like starting from your, uh, clear and concise communication which is transparent enough to gain that trust, and then coming down to doing proper performance reviews, even emphasizing more in those times, because people would ask for explanation that would be in a very chaotic mind-shape. So for sure, these are some of the leadership techniques that one can learn from this discussion that one should have when they are going through this particular situation. Apart from this, like, yeah.
Leonid Bugaev: I just wanted, like to add one more thing, like from, actually from a good point, from the good side. The trick is that sometimes such a shape for the company is actually a very good thing. So sometimes you get used to like a more relaxed rhythm to like, um, more like everything is good, like, uh, like everything is, everyone doing well, et cetera, and people are starting to be like calm, relaxed. And when we actually did this action, like the round of layoffs, and as I mentioned, like we focused only on people who had an issue with performance, whom we identified. We actually found it's like our overall, like velocity and like the ability to deliver actually increased.
Kovid Batra: Yeah.
Leonid Bugaev: So, uh, that actually went really good for the company.
Kovid Batra: And I think it should be like that in those situations, because when you talk about the leadership or the founders, in such situations, they become more aggressive because they have to like adjust to what is going on and like adapt to what is going on and like aggressively fight in those situations, and similarly, if as a team, as a company, if you're not doing that, of course, there are chances that you would fall apart. So I think it's definitely good what you are saying that will bring everything in place from the point of view of a leader to deliver what is needed in those situations. So, yeah, cool. And I think with that note, where we're talking about optimizing things and going through this, uh, stress situation, there is a lot that needs to be done in those times because you have a lower number of resources now and you have to deliver more, right? So how do you take up that challenge? Because, um, however we may put it, when people feel the fear of, uh, losing their jobs, that kind of a situation always sometimes pushes them to do even more, but also, people take a backseat, right? They know that anything wrong can happen. So how do you manage teams? How do you deliver operational efficiency in that situation?
Leonid Bugaev: Yeah. If your company did it at least once, then people would expect that most things come in the future and, you know, like the order levels of anxiety always, you know, like it will rise. No matter what you do, you can't just like smooth it somehow. But, uh, if you, like are regularly doing it, like, as I mentioned, some clear communication and being very open about your actions, uh, they start to understand it. And also, um, it's not about, you know, like providing, uh, these actions during it when it happens, it's also giving them, for example, you know, like what actually gives people a feeling of like productivity or feeling good, et cetera. Usually, it's progress. It's like seeing that you're like progressing somewhere and it can be seen in various things. So it can be, for example, in enhancing performance reviews, as you mentioned, so like, uh, when you start focusing on the performance. Like, and what we actually, one of the actions we did is that we provided a very clear format on how performance reviews should be done, but, you know, focus not on, you know, like, kind of like punishing people if they don't hit some goals, like they have an issue, but, you know, like trying to work together with them to provide some opportunities to grow. Like, "You want to go through some, like, a Kubernetes certification course? No problem. We'll give you budget for this." So, like, let's give some opportunities for learning and so on. So, uh, those people who are like left in the company, they should be encouraged, uh, and they should be motivated, they should maybe get some like additional bonuses and so on. And sometimes like if your company offers it, et cetera, sometimes maybe it also makes sense to motivate with additional, I don't know, like stock options, for example, or like some salary bumps, or similar. So like that's kind of like also essential.
And also like product metrics are also very important because like when the team is working on some feature, some product and they don't have visibility on, uh, does this actually bring money to the company or not? Like some feedback loops from the customers, they feel a bit disconnected from the business and they don't really understand like what's happening. But when you start connecting them with all of the business metrics, uh, when you stream them, all the, like customer feedback, et cetera, they start to feel that they are part of something bigger. They start to get, like faster feedback loops. They start to see that like, uh, we got this client because of you guys, because you build this, and this actually, you know, like, uh, brings a lot of motivation. Product feedback loops is one of the most important things to motivate your teams and improve stability. Yeah.
Kovid Batra: Yeah. And I think in these times it becomes even more important, right? Uh, less resources, you have to move fast, you have to innovate more to stay in the market, up in the game. So, I think in general, the philosophy, the ideals say that one should be working on high-impact features. Uh, but I think in these times it becomes even more impactful, right? That you have to focus on these areas. You have to work on these metrics. You can't let your customers churn in this situation. You have to do every possible thing that requires your customer to be there to pay you. And of course, that cannot happen without prioritizing things in the right direction. So in these situations, how do you ensure that things are moving in the right direction at an even faster rate?
Leonid Bugaev: Yeah, I think it's also, you know, like, um, important to understand that the overall, like company structure and how the teams get, like built. It makes a lot of, you know, a lot of difference. And sometimes it does make sense to rethink how you actually structure your processes, how you structure your team and so on. So let me give you an example. So, um, we came up with a scheme, like, um, about like two years ago. And right now, we're refining, and we're actually constantly refining it. So, uh, I think like first of all, constantly moving and constantly changing your processes, it's like a, it's a key thing. Don't be afraid of change. Then like, uh, don't be afraid to hire people who do the best, a good job for those things you don't like to do. So, I, for example, I am good with people. I'm good at engineering, but I really don't like, and I'm pretty bad at budgeting at like, uh, long-term planning, at various reporting and so on and so forth. So a few years ago, like when we, um, started scaling the team, and it was like a weird jump, like from, uh, like 10 to 50, for example. It's like a five times change. We realized it's like in order to keep up this growth, we need to support operational, uh, and delivery, um, uh, initiatives. So we hired a person, like who's like really amazing, and we had a really good bond, who took some of those responsibilities out of me. And the same was also about the product vision as well. So when you grow, you need someone to have, uh, uh, especially like if you have multiple departments, multiple teams, et cetera, like some coherent vision of like, uh, so all of those teams will work as like, you know, together and everything that they deliver will be somehow connected to each other. You will be developing it as one team. It's much more efficient rather than you all work separately. And from this point of view, they also, such teams also, uh, really allowed us to help, um, get enough time to build good benchmarks, to build like good metrics for your product, what we want to measure, how we want to measure, what exactly we want to build. So this process is super, super important, especially like in such times going very deep into engineering is not an answer. You need to start optimizing your product for the customers, for the churn, maybe for the user experience and so on. So it's not time for like research and development, and et cetera.
So, yeah, that's for sure. Like, uh, we've changed a lot. And right now, for example, we're also trying to like change and optimize some of the processes we, you know, like, uh, trying to, I would say, uh, involve, uh, our technical leads even more into the product area, even more like into non-engineering tasks. So they, together with like product managers, they will plan some like roadmaps in advance, find some brokers, et cetera, and try to think as a product, as a business, as a, as from the money point of view, how are we going to sell it? How are we going to like, you know, like what kind of like customers and jobs are to be done. We want to be covered. So we're trying to like teach people how to think business-wise, in business language, not in the engineering language.
Kovid Batra: Makes sense. The understanding that I'm building here to actually navigate such situations is to have the right culture coming in place with people. And along with that, of course, you would put more focus on those important metrics, which will be impactful, whether they are from the operational efficiency point of view, or whether these are some metrics that directly link to customer satisfaction, customer engagement. So I think a combination of the culture, the right operational metrics and right product and business metrics would sum up to give you a framework, uh, on how teams should operate in such situations. So even though we have talked about the operational part and the customer-centricity part, I would want to understand, like, when you are trying to bring in this culture, that things have changed and you're bringing that transparent communication, you're trying to bring people together, how do you ensure that people are really onboarded? Like, do you go an extra mile to understand that from your teams? Or what exactly do you do to understand whether everyone is coming on the same boat or not?
Leonid Bugaev: Yes. So first of all, when you know, like such things happen, like when there are some big changes, uh, it's going through like multiple phases. First, you have a phase, uh, like preparation. And during this preparation, I usually try to prepare like engineering leaders, uh, with the message. And like, as I mentioned, like prepare them in advance, but the team members still like don't know about it, majority of them. So when, uh, such as something here, like some big announcements happen, some changes, uh, usually it's like a company-wide announcement, like from the founders, from the board, et cetera. And then it should be followed really, uh, to be at the team-level, uh, like calls, uh, more private ones, et cetera. It's very important that every team will have, uh, how to say, like a 'safe zone' to speak out. Usually, it's first of all, people feel safer when they are in a smaller group, especially when they are within the team. Also they need to feel that like you are part of the team, not just like some boss from the top. So like as they should be able to openly speak with you about the problems, about the concerns and so on. And you as a person when you like joint such calls, you should be like super-transparent and super-open. You can't afford to say something like, "I don't know." You can't afford to say like, "I can't tell you this." Or similar. You should be very confident and you should be able to answer any kind of, like concern, or like follow-up later on it and so on. So if you will not be confident, then like, as they will also will not be confident and that's like, that's super important.
So like preparation and getting in advance all the questions, all the answers is super important. And also another thing is that, uh, when you build the, um, like hierarchy of the, like management, et cetera, sometimes maybe, people, uh, so it actually also depends on the cultures a lot. Like while working in distributed teams, I realized that like people from different cultures are very different in communication. Some of them are like very open, uh, some of them are very direct. Some of them are afraid to ask questions in public. And, uh, when you know this, like nuances, you can treat it better. So you need to know your people, you need to know your team. And for some of the team members, to whom I see that, like, they are, like, quiet, they, like, uh, they, and, and I see that by their face, by their emotion, like, something is not right, I will follow-up directly one-on-one with them, or, like, if I know that, like, they have a very good relationship with their manager, for example, I will ask the manager to follow-up with them, and if they have any concerns, to, like, communicate with me directly, and so on. But you need to be constantly on the line and constantly be available for any kind of communication, especially like, uh, for the first week, like, it should be like your main job. Communication, communication, communication. Your main job when such things are happening is to come to people, to give them answers and to be available to them. So the worst thing you can do is that like send some announcement and then like close Slack, whatever you use. And like, you know, like don't answer and, you know, like be back in a few days and so on. So that's, yeah, the worst thing.
Kovid Batra: Cool. I think that that's some really, uh, I would say, hands-on advice coming from someone who has seen situations, and that seems to be very helpful and we can totally relate to it. So now, when, uh, you have, uh, made us understand how things should move in such situations, what's your forward-looking strategy? Or what's your, like major pointers that someone should take away from the whole discussion that we have had? So I would like to quickly summarize that, uh, as we are running out of time. And, uh, hear from you the last few important concluding pointers.
Leonid Bugaev: Yeah, right. So, like, I think like the number one is that like, uh, uh, you should stop, um, being afraid of money-related questions. So, money becomes the number one essential metric, and you need to understand how the company makes money, how the product makes money, which exact parts of the product make money, and which of them are actually, you know, like don't and actually drain your money. So that's number one to understand. You can't do it if you do not have the proper metrics in place. So like, uh, configuring, first of all, like product usage metrics is super important, but also having team metrics, uh, is equally important, specifically like knowing how much in terms of like code category of tickets, the features, et cetera, how much time do you spend? And how much is, for example, uh, change failure rate, or maybe like cycle times for specific, like product features. And, you know, like in the end, like if you, for example, know that like your team spends, I don't know, like $20,000 per sprint, then when you start like making the features, uh, like some customer asks you to like build some feature. Okay, it will take us one sprint to build. It'll cost you like a $20k, you know, like, is it actually worth doing or not? You know, like.
Kovid Batra: Yeah.
Leonid Bugaev: So money becomes very important. And, uh, when you actually need to make the hard decisions, you need to like, uh, the communication is the key. The transparency, if you like as a leader, don't have the answers, if you're not confident, people will not be confident the same. And you should be very close to your team. They should treat you as a team member. You should build the trust lines and you should do it before. It's not like you're coming one day, like, "Hello, I'm your friend. "No, like, it's like, it takes time. And, um, you should have, uh, uh, especially like if you like to have a more complex, bigger team, you should have a very good chain of communication. And also another thing is that you should have, um, very good performance review, uh, process and the performance improvement process. Everything should be audited. Everything should have, uh, been written down, et cetera. It will help you so much in the future if you need to make some hard decisions. And when you make them, when, for example, you need to like lay off some people, especially like if it's like monthly or similar, the best thing you can do as a leader is to be with the people like, uh, "I'll be available.” Your calendar should be open for anyone and you should be proactively following up with everyone, answering all the questions and being as transparent as possible.
Kovid Batra: Makes sense. Makes sense. Totally. It is very, very important to communicate to the teams that they should be involven during these phases in constant innovation and learning so that they can find out areas where they can actually create the impact even in such times. So motivating them in the other direction, like telling them that things would be fine if we move with this motivation of continuous learning and improvement and taking steps towards more innovation. I think, uh, would definitely bring that change and make it easy for everyone, uh, to navigate such situations.
I think with that, uh, I think, uh, we come down to the closing notes. Uh, any parting advice, Leo, for our audience, like, uh, who are aspiring engineering leaders, passionate engineering leaders out there, anything you want to share?
Leonid Bugaev: Uh, don't be afraid to change. So the change is always, you know, frightening, but it's essential for innovation and growth. So that's, yeah, the major, I think, advice.
Kovid Batra: Perfect, man. Perfect. All right. Thanks a lot, Leo. It was great having you on the show. Uh, really, really insightful thoughts. And I think the hands-on experience always says for itself. So cheers, man.
Leonid Bugaev: Thank you so much for having me here.
In the latest episode of 'groCTO Originals' podcast (formerly: 'Beyond the Code'), host Kovid Batra engages in a thought-provoking discussion with Sergio Visinoni, a Fractional CTO, Tech Advisor & Mentor at groCTO Community. He’s also the author of the newsletter ‘Sudo Makes me A CTO’ and runs a tech leadership coaching startup as a solopreneur. The heart of their conversation revolves around ‘Maslow's Hierarchy for Tech Teams’.
The episode kicks off with Sergio discussing his background & then introducing a framework inspired by Maslow’s Hierarchy, categorising tech team maturity into 3 levels: vital infrastructure, application service quality, and developer performance. He explains how this framework helps align technical and business strategies, identify issues, and communicate needs to business leaders. Through a case study, Sergio illustrates that high feature output doesn’t always equate to high performance.
Lastly, Sergio addresses challenges like standardizing DORA metrics across diverse teams and justifying infrastructure needs, emphasizing how the framework aids in balancing stability and performance for data-driven decision-making and effective communication.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a very special humble guest. He comes with 24 plus years of engineering and leadership experience. He has been a Tech Mentor, and a Fractional CTO at multiple startups and orgs. He's also the author of the newsletter 'Sudo Make Me a CTO'. Currently, he's a solopreneur running his own tech leadership coaching startup, and I would like to welcome our guest from Spain, Sergio. Welcome to the show.
Sergio Visinoni: Hi, everyone. Hi, Kovid. I'm really happy to be here.
Kovid Batra: Same here. So today, Sergio, I think, uh, we have a very interesting topic to talk about and I derived it from the previous conversation that we were having. It's about the Maslow's hierarchy for tech teams. So I think it's very interesting. It's something related to, uh, personal life also, like how Maslow's hierarchy plays a role in our lives and how that maps to tech teams actually. But before we jump into that, I think, uh, the audience would love to know a little bit more about you. You can share your personal things also. Let us know who is Sergio. Over to you.
Sergio Visinoni: Yeah, sure. Thank you, Kovid. Yeah. So before we get into the very interesting topic, let me bore you to death with some personal details. Uh, no jokes aside, I'm Sergio. As you said, I've been spending more than 20 years in the tech industry. I'm originally from Italy. Um, I've been living in many countries, so mostly Europe, but then I spent a bit of time also in Mexico and then I moved here to Spain in 2016. The biggest chunk of my career has been in online marketplaces. That's where I basically went from being a software engineer and to actually being a VP, uh, of, like overseeing more than 300 engineers across multiple countries. So that's been like the peak of complexity that I've been dealing with. Uh, and after that, I've been, um, getting my hands dirty again with smaller companies and startups, until finally, at the end of last year, I took the decision to, you know, uh, move out of the traditional employment setup, uh, because I felt like I wanted more flexibility. I have a family, I have two kids, as you want more personal details. So I want to spend, be able to spend more time with them when needed. Like if there is something at school, I want to be able to go there without, you know, having to, uh, have too much justifications to add and also want to spend a bit more time for myself as well. So that's why I took the jump from January 1st, I became what I like to say a 'solopreneur', which makes it sound cool. Uh, the reality is that what I'm doing is mostly consulting for now. At the moment I have three B2B clients, three companies that I'm consulting with in different capacities. One of them is a traditional fractional CTO. Others are more project-specific. Uh, in parallel to that, I'm, uh, building up my own coaching and mentoring, uh, practice. I really like working with individuals, be them senior engineers or tech leaders who just want to get better in their professions. I really enjoy that because it reminds me of one of the things that I loved the most when I was an engineering leader, which was like working with people in my team, right?
Kovid Batra: Yeah.
Sergio Visinoni: And then, you know, eventually, I also want to start building, you know, online products that can sell themselves. That's why I consider this a solopreneurship. Consulting is a part of it. I don't want to be a full-time consultant forever, but I need to start close to what I can do, uh, right now, as I build my business over time.
On the personal side, I said that I have a family, have two kids. Uh, my main hobby is actually woodworking. So I like to have analog activities to do, uh, lots of pieces of furniture here at home. Uh, I've been there myself. And you can actually see the progression from the first pieces, it's not very good to the last pieces getting better It's like software, you know, when you look back at the software you wrote one year ago, you realize that's not very good. Uh same goes with woodworking. And then yeah, I like reading a lot. I'm an avid reader. Um, I spend time, as you said, producing my own content as well. I have my own newsletter. I write a lot of content on LinkedIn, trying to, you know, be part of this community, and as well, you know, I'm not hiding that it is a big channel for me to market my own brand, right? I try to show my knowledge through all that content so that hopefully people will feel confident, uh, you know, signing up for my service.
Kovid Batra: Sure. I'm sure they would. Great. Thank you so much for this sweet, quick intro. Uh, and I wish you all the best on this solopreneur journey, and I really appreciate you for that.
Cool. So I think now is the time we move on to making dev teams better, enabling engineering leaders to make dev teams better, and I really would love to, uh, hear about your theory of building great dev teams and how you bring in Maslow's hierarchy in that. Uh, over to you, man.
Sergio Visinoni: Yeah. So I'm going to start with a bit of context, right? Um, I remember the year when the 'Accelerate' book came out. Uh, that was 2018, and I actually remember it was, it's fun. I still have a clear, vivid memory of a Slack chat I was having with a software architect that was in Norway. I was already here in Barcelona. And we're talking about, you know, engineering metrics, how they were using certain metrics in their team, et cetera, et cetera. Because I had been kind of banging my head against the wall on this topic. We know it's a difficult topic, right? It's very challenging. It's very easy to come up with wrong metrics. At the same time, I didn't want to just give up and say, "It's impossible to measure anything." Right? Um, and he said, "You know what? This new book just came out and they claim that they found causality, relationship between certain tech metrics and business outcomes." I I said, "Wow! I need to read this book." So that's how, you know, I saw the link on Amazon. I bought it immediately and I started reading it, and it came at a very good moment, because again, as I said, I was kind of thinking a lot about that space. That's where, you know, after reading the book, I've been working with a collaborator, and I also actually need to say that a lot of the credit for what we did goes to him. All right. Uh, he was in my team. He was the Director of Engineering of my team. Uh, he was tasked with helping me figuring out how we can look at metrics across the whole portfolio.
And this is the second piece of context that is important. At that moment in time, as I said, y'know, overseeing a big engineering organization, I was actually overseeing multiple teams operating in different countries for different marketplaces. So it was a very heterogeneous setup where we had a combination of shared platform services, but a lot, I would say more than 80 percent of the code and systems was run locally, right? And this for historical reasons. So this company has been growing very quickly by, uh, forking, uh, different versions of the same platform in different countries to allow for maximum customization, but also through acquisitions. So it's very common, you know, every company or actually no company grows following the ideal path. It's always like bumps on the road. And then, you know, on the engineering side, you're left to deal with some historical, uh, legacy to deal with. So we were facing this very heterogeneous setup. At the same time, you know, I was responsible for making something out of it, right? So I was responsible to oversee all of it and try to figure out how we can look at this portfolio and how we can understand where each team, where each organization is in terms of maturity. And that's where we started thinking about, okay, we need to develop a 'tech maturity framework' to be able to look at this and be able to talk about where every team is and also help the GMs and the CEOs understand what type of investments they're supposed to make to be able to improve the situation, right? So we wanted this to become not a tool to just assess or judge or evaluate. Actually, we wanted this to be a tool to help all the local tech leads in the different countries to have stronger arguments, better arguments to justify investments in architectural refactoring, you know, building better tools or improving processes and whatnot.
So that's where, you know, on the one side, the Accelerate book came out. On the other side, we were having this, uh, challenge on our own. Uh, and that's where with my colleague, Marco, uh, Marco Cupidi. Uh, I recommend him for another podcast, by the way. I think you should definitely interview him. We came out with this idea of the Maslow pyramid for, uh, engineering teams. We started investigating this idea of building the analogous of the Maslow pyramid for tech teams, uh, in this optics of figuring out what, how we can look at tech teams in terms of their maturity, right, because if you think about the Maslow pyramid for humans, you can roughly say, you know, the more you move up on the pyramid in terms of being able to focus on higher and higher needs, the higher the level of maturity your personality has reached, right, because you're not only focusing on surviving, you're not only focusing on recognition, you actually, at some point, you reach the level of self-realization. I think that's the peak of the pyramid.
Kovid Batra: Yes, self-actualization.
Sergio Visinoni: Self-actualization, exactly. So we started working with this idea and now we didn't complete the work, meaning that initially we thought we will have five or six levels of the pyramid. We ended up with three, but that was enough. Honestly, you know, we didn't actually want to stick with the same amount of levels in the pyramid of Maslow pyramid, but we ended up with three levels, and basically, they were organized as such. The first level, the base of the pyramid, which is analogous to, you know, feeding, uh, having food and providing, for Maslow, was focused on what we were calling the vital infrastructure layer. So basically, "Is your platform stable?" And the reason for that is that I've seen many times teams focusing too much on velocity or going faster where actually their main problem is with quality and stability. And whenever a team is facing a lot of stability issues, that has a lot of implications in terms of their ability to work effectively. So it introduces a lot of disruptions, right? They are constantly interrupted by issues, by problems. So there is no way for the team to focus on improving output before they improve their predictability of the cycle.
Kovid Batra: Right.
Sergio Visinoni: And predictability is always negatively affected by how many incidents you're having, right? Every time there is an incident, your attention is redirected to dealing with it, and therefore, again, it disrupts and it adds, creates a lot of waste in the process.
So that first layer, I remember, it included metrics such as availability, but also it had metrics around, uh, latency of the most important pages. We're mostly dealing with websites and with mobile apps as well. So there were metrics on crash rates on the apps, for instance, etc, etc. I don't remember the full list because, y'know, this was a few years ago, but it doesn't really matter because what we came up with was.. Yeah?
Kovid Batra: The highlight is stability like the first level.
Sergio Visinoni: Exactly. So, 'vital infrastructure' is infrastructure, the basic level of what you build, operating in a healthy way, is it healthy, right? Or does it need to constantly look for food because it's starving, right? That was kind of the concept.
And then, the second layer above that was focusing more at the application level. What is the quality of service of your application? And here we're looking more in terms of error rates on the app, or, uh, you know, some of the Core Web Vitals were included there. Not all of them because it was still early days. Uh, actually I don't think we were calling them Core Web Vitals yet, if my memory serves me well. But Google was already quite advanced on, you know, pushing the idea of these important metrics on web performance that reflect the user experience. So this was a combination of, you know, application-level and the quality of service that you're providing to your users, not in terms of user flow, right? So it was not the functional part of user experience, but the non-functional part of user experience. Is it fast enough? Is it reliable? Is it loading in the right way? et cetera, et cetera. So that was the second layer, and the third layer, uh, was basically what we're calling developer performance, I think, and it was mapped into the DORA metrics. So these were the four DORA metrics because that's where you get to, from our perspective, the optimization stage, right? Once the first two layers are in a good place, you can really start focusing your attention on the third layer.
Now, as Maslow says as well, you don't need to complete 100 percent of one layer to start looking at the next layer, right? So it's more like you want a slice where always the base is much larger than the layers above, but you don't want to only focus on feeding yourself until you have enough food to survive for the rest of your life. So there's always a balance. But for us, y'know, going back to when we introduced it, when we introduced this framework, and again, lots of credit goes to Marco. Uh, I was there mostly to help, but also to help socialize this and get buy-in from the business counterparts, right, because until that point, the engineering side of the organization was really considered as a black box for any people outside of engineering.
Kovid Batra: Yeah.
Sergio Visinoni: So, yeah, it's no, things are slow. We have lots of legacy. Old platform. Now, there were all these common words being thrown around, but most people didn't really understand what was going on, and then they resorted to kind of comparing across countries based on how quickly they could ship new features, regardless of whether those features were actually the same or not, right? There was a lot of oversimplification in the discourse around, "Is my team or is your team performing well from a CEO perspective?" And I wanted to not put an end to that, but actually help business leaders understand better, have a deeper understanding of, okay, this is the situation within your team. Now, how do we have them move to a better place, right?
So, using this analogy of the Maslow Pyramid turned out to be a very effective and powerful way to communicate because, you know, every man, every person and their mother have heard about the Maslow Pyramid, and even if they don't, it's very easy to understand the concept once you explain it, right? Of course, we're always putting a lot of caveats, right? Saying, you know, "Don't just translate everything Maslow said into this context and assume that it's going to work." Because there is a lot of simplification going on here, but analogies are useful because they help people grasp the concept more easily.
Kovid Batra: Yeah, it makes a model in your head where you can always understand where you are, what you exactly need to do. So that way it makes it easier for people to make those decisions and then move forward according to that. Yeah. Makes sense. I understand.
Sergio Visinoni: Yeah. So, that. On the one side, so there was the benefit for the business leaders, so they will understand better, you know, their situation. Secondly, it was helping local CTOs because again, I was VP of Engineering, but I had CTOs reporting to me because we had different titles depending on the countries. It was very heterogeneous. Don't get too fixated on the titles. But basically, I had local tech leads who were reporting to their CEO, but then they were dotted line reporting to me, and many of them were struggling to find arguments to justify investments in technology, right? Because especially when you're a small, medium-sized team where the competition on the market is very fierce, you know, you get a lot of pressure to just push new features, right? You just, you need to launch this new feature because we need the revenue, blah, blah, and we all, we've all been there. There are lots of good reasons for that to be the case and some bad ones, right? And especially, first-time tech leaders tend to have a hard time, balancing that need, that business need with, okay, I also need to make sure that we ensure this system will perform well in the long run, right, not just tomorrow, especially with businesses that were well-funded with good business models. So it was not a typical startup that might disappear in a couple of months. Uh, this was a proven model that we're rolling out across different countries. So the long-term horizon perspective was justified even in the early stages.
So we put together the model. We put together a series of metrics, but then, the hard part of the work started, which was how do we collect the metrics, right? So initially, it was a massive, uh, Google spreadsheet, and we're asking local CTOs to, you know, fill in the data on a monthly basis, and the interesting thing for us was to look at the trends. Like, we learn a lot from when we work with DORA metrics. The absolute value is largely meaningless, because it's really very context-dependent, and also depends on how you define the metric, right? Every one of these metrics, you know, you work with that, you need to start with defining, okay, "How do I actually want to measure it?" Because DORA doesn't tell you how to measure them, but even when you talk about availability, there are different ways to look at the numbers and figure out how to calculate this. So, it was a lot of work to kind of standardize on those metrics. And once we got to that level of standardization, then every team will see how they were evolving on a monthly basis, and we're generating monthly reports with different levels of granularity, right? So, for the executive team, we will look at an index that was calculated as a kind of summary or a compilation or, yeah, aggregation of all the submetrics to show, okay, "This team is at 75 percent in the journey. Last month they were at 70%." So there's been a significant improvement. And if you look back last six months, they've been increasing month over month, et cetera, et cetera.
Whereas some other teams maybe were either flat or even decreasing, declining. That proved to be another very useful tool because in my perspective, one of the best usages of engineering metrics is what they call, um, conversation starters. So those metrics are a way for you to spot that there is something going on. It's very dangerous to jump to conclusions just based on metrics.
Kovid Batra: One question.
Sergio Visinoni: But at least they're telling you.. Yeah, go ahead. Sorry.
Kovid Batra: So I think what I am understanding from your, uh, analogy and how this hierarchy is helping people to actually build a strategy, it's more towards a technical strategy. Am I getting it right or is it more around mapping the business strategy also in place? So, that's the real problem for the tech leaders, right, that you are really not sure about what your business needs and what your tech needs, and then you're trying to map both of them so that you survive well, and in fact, thrive in certain situations where you really want to move fast. So this hierarchy, uh, analogy is it helping purely on the tech strategy point or, uh, is it bringing in the business aspect also?
Sergio Visinoni: That is a fantastic question, Kovid. I would start by saying that you cannot have a tech strategy that is decoupled from the business strategy to begin with, right? Because otherwise, so there is no absolute tech strategy that is right for every context. Uh, the tech strategy needs to be tailored to the specific company, team, whatever the scope we're looking at. So by definition, this was helping them better the business strategy into the tech strategy. But, at the same time it was also helping CTOs in some cases define a clear tech strategy because they were finally seeing clearly, you know, this is where you have problems, and based on the model, we recommend you don't start optimizing for speed if your site is down every other day, right? You should start first by creating that stability, right? But it also helps them communicate with the business and actually manage business expectations in a more constructive way. So, you know, in order for us to be able to get to a place where we can fulfill all the needs for the business in terms of like new features, new capabilities that we need to build, first we need to address this. Until we address this, we're not going to be able to predictably do our job, and we'll constantly be facing, you know, urgent fires that will disrupt our ability to plan and actually execute on those plans. So in that sense, there is a clear connection.
Now, what the framework didn't tell was what features to build or how to solve a problem, right? That's exactly how then, you know, in my team, I was combining the framework as a diagnosis tool on one hand. So it was actually an observability tool. It was giving us information about where the potential problems were, and then I had a pool of experts and software engineers that in some cases I was able to deploy to help specific teams improve in certain areas, right? For instance, you know, "You guys, I have an architect here. You need help on refactoring this part of the architecture on your side. I'm gonna have this person working with you next quarter to help you move from here to there."
Kovid Batra: Yeah, exactly I think that's the best part. I think it's not a static framework, right? You are always moving in between these layers depending on the situation. All you have to do is like make sure what exactly each state tells you, those metrics of each state tells you, and based on that, you can at least formulate in your, uh, strategy that, okay, this is where we need to focus, and if this is a business requirement, are we mapped to do it or not? You can actually make decisions by knowing the reality of your system.
Sergio Visinoni: Exactly. You're absolutely right. And basically, it's a framework that helps you prioritize what to do, right?
Kovid Batra: Yeah.
Sergio Visinoni: Uh, it gives you clear insights on, okay, I should look here or I should look there. So, what's the plan, y'know? Again, this is the problem. This is the symptom. Now, how do we go about addressing the underlying problem? And again, that was happening either in isolation within the team or with support from people that were, you know, uh, located with me in Barcelona. The 'how' is really context-dependent, again, because depending on what the specific problem is. It's also depending on the local pool of competences on the team that is suffering, you might come up with different ways to address it.
The other interesting side effect of this approach, by the way, you know, it was not easy to deploy it because in the beginning, a lot of teams were seeing this just as extra toil, right? You're just asking me to collect metrics. What's in it for me? Right. It took some time to prove the value, right? And that's where, you know, strong conviction, but also repeating why we're trying to do something, y'know, being very consistent in the messaging is helpful. But, you know, in any organization, especially big organizations, there is a lot of competition for attention, right?
Kovid Batra: So what do you think was, uh, your takeaway from the incentivization for implementation? Like, uh, why people started sticking to it, uh, with you?
Sergio Visinoni: I think there were probably two broad categories of people. Like, generalization, but to simplify things here, one category of people were people that, understood this at an intuitive level and actually saw this as a way to, okay, achieve something they wanted to do. So people were thinking, okay, "How can we become a bit more data-driven in deciding on this type of work?" So for this group of people, it was obvious. Of course, nobody likes extra work in general, but they understood why, right? And then, there was more like the detractors or people who were, uh, resisting this type of change, and what worked with them was spending time to help them understand this will actually help them do what they wanted to do, and they were frustrated because they were not able to do it, right?. So typically, and this roughly mapped, you know, it's not exactly one to one, but this roughly mapped to the more junior profiles, those who were able to see, okay, "I don't have time. I don't have resources to do all the important things I will need to do because, you know, my boss tells me that we need to prioritize X, Y, and Z." And I was telling him, okay, "So how do we change that?" Right? "How can I, how can we help you create, build stronger arguments to be able to, y'know, put those on the table and be able to have a proper prioritization discussion and say, okay, if we do this, we're going to improve that, and therefore, if we improve that, this will be the potential consequences."
Kovid Batra: Right.
Sergio Visinoni: So this has been the main driver, um, to get most of the people on board.
Kovid Batra: Makes sense. And as you were talking about the challenges, I think if you could give me one example, uh, like some anecdotal information around how things worked out when you were implementing it, that would be something very insightful.
Sergio Visinoni: Yeah. So, on one side we discovered, for instance, without naming names, we discovered that one specific organization that was considered (quote, unquote) "high-performing" because they were churning out lots of features. It turned out their metrics didn't look very good. All right, so this was an interesting case of doing a lot of average work rather than doing a little bit of good work. And once we started going beyond those, so those metrics, the first thing they did were they put us onto something. We realized there was something there that required further investigation. So we started working more closely with the team and we started realizing that there were basically gaps in their knowledge, right? So nobody had any bad intentions. But the problem is that, especially in a big organization, there is a certain element of competition across countries. So nobody wants to look bad. Everybody wants to look better, right? And therefore, they were a bit trapped in this self-fulfilling prophecy of showing off that they were good, even though they weren't, and therefore they didn't really ask for help, right, because asking for help would have meant, you know, we don't necessarily know exactly what we're trying to do. In this discipline, it's very hard to know exactly what you're trying to do. There's a lot of uncertainty, lots of surprises around the corner. So, in this specific case, this framework allowed us to identify something that was very much below the radar until that moment, which led us to spend more time with this team. Actually, this team from a business perspective was one of the most important countries in my portfolio. So it became quite evident that I and my team should prioritize our attention to this team, and over time, that led us to help in making significant changes at the organizational level and on the way they work, and therefore, the end results.
So this has been like one of the biggest investments. The other one, actually the most important asset in that portfolio, um, was falling in the category of those who understood this from day one, right? So this was like mature people who just saw in this a potential support. So there, the collaboration from day one was extremely easy, and it really became a partnership where I actually took a big part of my team to work with them for a sustained amount of time to actually move them very close to excellence on, you know, on the, at that moment, the DORA ranges, if you remember, and that has had massive impact on the business, right? The business was going through an important transformation. There were changes in the leadership, at the top, but actually also these changes on the tech side allowed to support a lot of the initiatives that the business wanted to push. So this was a very good success case where all pieces came together, the local tech team, my team centrally and the business realizing, okay, we need to put investments here, we need to do things in a better way. Um, you know, nowadays, that country is still thriving, uh, and part of it is because of some of those investments we made during those days.
Kovid Batra: I think this, um, philosophy, the tech philosophy, I must say, solves a lot of problems. Like, first and foremost, I would say the decision-making, like anyone who is trying to make a decision that comes to a very good point where you know your reality, you know what is needed from the business and you can map those two and then come out with, okay, "This is the priority list for us." So that's the best thing I see coming out of this, and then, of course, like it makes you achieve as much as you can, not that as much as you want. So that is also very important because sometimes we overstretch ourselves to do things which probably are not realistic or not achievable. This would really help you give a fundamental check, and then, you would say, okay, "This is what needs to be done there."
One more thing, I think I discussed this in one more podcast that it is very difficult for tech leaders to explain to the business counterparts, why this tech thing is very important, right? Now they have a very good framework in place and a few metrics in place to tell them, okay, "This is where we need to focus right now." And if it is needed right now, then you have to bring it up. So I think a data-driven decision-making makes it very convincible for the business counterparts also to take up the decision.
So yeah, I think this was really great, Sergio. I think a very, very good thing I learned today and hopefully the audience did too. So with that, I would like to say buh-bye and would love to have you on another episode anytime soon, and talk more on such topics with you. Thank you so much, Sergio, for today.
Sergio Visinoni: Thank you, Kovid, and you know, just hit me up when you want me to join again, I will be very happy to have another chat.
Kovid Batra: Thank you. Thank you so much. See you.
Sergio Visinoni: Bye!
In the fourth episode of ‘The DORA Lab’ - an exclusive podcast by groCTO, host Kovid Batra engages in an enlightening conversation with Peter Peret Lupo, Head of Software Engineering at Sibli, who brings over a decade of experience in engineering management.
The episode starts with Peter sharing his hobbies, followed by an in-depth discussion on how DORA metrics play a crucial role in transforming organizational culture and establishing a unified framework for measuring DevOps efficiency. He discusses fostering code collaboration through anonymous surveys and key indicators like code reviews. Peter also covers managing technical debt, the challenges of implementing metrics, and the timeline for adoption. He emphasizes the importance of context in analyzing teams based on metrics and advocates for a bottom-up approach.
Lastly, Peter concludes by emphasizing the significant impact that each team member has on engineering metrics. He encourages individual contributors and managers to monitor both their personal & team progress through these metrics.
Kovid Batra: Hi everyone. This is Kovid, back with another episode of our exclusive series, the DORA Lab, where we will be talking about all things DORA, engineering metrics, and their impact, and to make today's show really special, we have Peter with us, who is currently an engineering manager at Sibli. For a big part of his career, he has been a teacher at a university and then he moved into the career of engineering management and currently, holds more than 10 plus years of engineering management experience. He has his great expertise in setting up dev processes and implementing metrics, and that's why we have him on the show today. Welcome to the show, Peter.
Peter Peret Lupo: Thank you.
Kovid Batra: Quickly, Peter, uh, before we jump into DORA metrics, engineering metrics and dev processes, how it impacts the overall engineering efficiency, we would love to know a little bit more about you. What I have just spoken is more from your LinkedIn profile. So we don't know who the real Peter is. So if you could share something about yourself, your hobby or some important events of your life which define you today, I think that would be really great.
Peter Peret Lupo: Well, um, hobbies I have a few. I like playing games, computer, VR, sort of like different styles, different, uh, genres. Two things that I'm really passionate about are like playing and studying. So I do study a lot. I've been like taking like one hour every day almost to study new things. So it's always exciting to learn new stuff.
Kovid Batra: Great, great.
Peter Peret Lupo: I guess, a big nerd here!
Kovid Batra: Thank you so much. Yeah. No, I think that that's really, uh, what most software developers and engineering managers would be like, but good to know about you on that note.
Apart from that, uh, Peter, is there anything you really love or would you like to share any, uh, event from your life that you think is memorable and it defines you today who you are?
Peter Peret Lupo: Well, that's a deep question. Um, I don't know, I guess like, one thing that was like a big game changer for me was, uh, well, I'm Brazilian, I came to Canada, now I'm Canadian too. Um, so I came to Canada like six years ago, and, uh, it has been transformational, I think. Like cultural differences, a lot of interesting things. I feel more at home here, to be honest. Uh, but like, yeah, uh, meeting people from all over the world, it's been a great experience.
Kovid Batra: Great, great. All right, Peter. So I think, first of all, thanks a lot for that short, sweet intro about yourself. From this point, let's move on to our main topic of today, uh, which is around the engineering metrics and DORA metrics. Before we deep dive, I think the most important part is why DORA metrics or why engineering metrics, right? So I think let's start from there. Why these engineering metrics are important and why people should actually use it and in what situations?
Peter Peret Lupo: I think the DORA metrics are really important because it's kind of changing the culture of many organizations, like a lot of people were already into, uh, measuring. Measuring like performance of processes and all, but, uh, it was kind of like, sometimes it wasn't like very well seen that people were measuring processes and people took it personally and it's like all sort of things. But nowadays, people are more used to metrics. DORA metrics is like a very good framework for DevOps metrics, and so widespread nowadays, it's kind of like a common language, a common jargon, like when you talk about things like mean lead time for changes, everybody knows that, everybody knows how to calculate that. I guess that's like the first thing, like the changing the culture about measuring and measuring is really important because it allows you to, uh, to establish a baseline and compare the results of your changes to where you were before and, uh, affirm if you actually have improved, if something got worse with your changes, if your, the benefits of your changes are aligned with the organizational goals. It allows everybody to be engaged at some level to, uh, reaching the organizational goals.
Kovid Batra: Makes sense. Yeah, absolutely. I think when we always talk about these metrics, most of the people are talking about the first-level DORA metrics, which is your lead time for changes or cycle time, or the deployment frequency, change failure rate, mean time to restore. These metrics define a major part of how you should look at engineering efficiency as a manager, as a leader, or as a part of the team. But do you think is it sufficient enough? Like looking at just the DORA metrics, does it sound enough to actually look at a team's efficiency, engineering efficiency? Or do you think beyond DORA that we should look at metrics that could actually help teams identify other areas of engineering efficiency also?
Peter Peret Lupo: Well, um, one thing that I like about our metrics is that it lets us start the culture of measuring. However, I don't see that as like the only source of information, like the only set of metrics that matter. I think there are a lot of things that are not covered in DORA metrics. The way that I see, it's like it's a very good subset for DevOps, it covers many different aspects of DevOps, and that's important because when you wanna measure something, it's important to measure different aspects because if you are trying to improve something, you want to be able to detect like side effects that may be negative on other aspects. So it's important to have like a good framework. However, it's focused a lot on DevOps, and, uh, I'll tell you, like, if you are on a very large organization with a lot of developers pushing features, like many changes daily, and your goal is to be able to continuously deliver them and be able to roll back them and assess like the time to restore the service when something breaks down. That's good, that's very, very interesting. And so I think it's very aligned with like what Google does. Like it's a very big corporation, uh, with a lot of different teams. However, context matters, right? The organizational context matters. Not all companies are able, for instance, to do continuous delivery. And sometimes in our matter of like what the company wants or their capability, sometimes their clients don't want that, like if you have like banks as clients, they don't want you to be changing their production environments every like 12 hours or so. Uh, they want like big phases, uh, releases where they can like do their own testing, do their own validation sometimes. So it's fundamentally different.
In terms of, uh, the first part of it, because when you get to DevOps and you get to like delivery stuff into production, things were already built, right? So building is also something that you should be looking at. So DORA metrics provide a good entry point to start measuring, but you do need to look at things like quality, for instance, because if you're deploying something and you're rolling back, and I want to make a parenthesis there, if you're measuring deployment frequency, you should be telling those apart because rolling back a feature is not the same as, like, deploying a feature. But if you're rolling back because something wasn't built right, wasn't built correctly, there's a defect there. DORA metrics won't allow you to understand the nature of the defect, where you got into, like, got into, like the requirements and continue what's propagated to codes and tests, or if somebody made a mistake on the codes, like it doesn't allow you for this level of understanding of the nature of your defects or even productivity. So if you're not in a scenario where you do have a lot of teams, you do have a lot of like developers pushing codes, code changes all the time. Uh, maybe your bottleneck, maybe your concerns are actually on the development side. So you should be looking at metrics on that side, like code quality, or product quality in general, defect density, uh, productivity, these sorts of things.
Kovid Batra: I think great point there. Uh, actually, context is what is most important and DORA could be the first step to look into engineering efficiency in general, but the important, or I should say the real point is understanding the context and then applying the metrics and we would need metrics which are on DORA also. Like, as you mentioned, like there would be scenarios where you would want to look at defect density, you would want to look at code quality, and from that, uh, I think one of the interesting, uh, metrics that I have recently come across is about code collaboration also, right? So people look at how well the teams are collaborating over the code reviews. So that also becomes an essential part of when you're shipping your software, right? So the quality gets impacted. The velocity of the delivery gets impacted. Have you encountered a scenario where you wanted or you had measured code review collaboration within the team? And if you did so, uh, how did you do it?
Peter Peret Lupo: Yes, actually in different ways. So one thing that I like to do, it's more of a qualitative measurement, but I do believe there is space for this kind of metric as well. One thing that I like doing, that I'm currently doing, and I've done in other companies as well, is taking some part of the Sprint's retrospective to share with the team, results of a survey. And one of the things that I do ask on the survey is if they're being supported by team members, if they're supporting team members. So it's just like a Likert Scale, like 1 to 5, but it highlights like that kind of collaboration support.
Kovid Batra: Right.
Peter Peret Lupo: Um, it's anonymous, so I can't tell like who is helping who. Uh, so sometimes somebody's, like, being very, like being helped a lot, and sometimes some other person is helping a lot. And maybe they switch, depending on like whether or not they're working on something that they're familiar with and the other person isn't or vice versa, I don't know. I have no means to do that, and I don't bother about that. Nobody should be bothering about that. I think if you have like a very senior person, they're probably like helping a lot of people and maybe they're not pushing many changes, but like everybody relies on them. Uh, so if you're working on the same, you should be measuring the team, right? But there are other things as well, like, um, you can see like comments on code reviews, who jumps to do code reviews, and all those kinds of things, right? These are very important indicators that they have like a healthy team, that they're supporting each other. You can even like indicate some things like if people are getting, uh, are learning more about the codes component they are changing or like some, like a service or whatever area, how you define it, uh, if you have like knowledge silos and, um, who should be providing training to whom to break out those silos to improve productivity. So yeah, that's very insightful and very helpful. Yeah, definitely.
Kovid Batra: Makes sense, makes sense Um, is there anything that you have used, uh, to look at the technical debt? So that is also something I have, uh, always heard from managers and leaders. Like when you're building, whether you are a large organization or you are a small one moving faster, uh, the degree might vary, but you accumulate technical debt over a period of time. Is there something that you think could be looked at as a metric to indicate that, okay, it's high time now, that we should look at technical debt? Because mostly what happens is like whenever there are team meetings, people just come up with ideas that, okay, this is what we can improve, this is where we are facing a lot of bugs and issues. So let's work on this piece because this has now become a debt for us, but is there something objective that could tell that yes, now it's time that we should sit down and look at the technical debt part?
Peter Peret Lupo: Well, uh, the problem is like, there are so many, uh, different approaches to technical debt. They're going to be more suited to one organization or another organization. If you have like a very, uh, engineering-driven organization, you tend to have less technical debt or you tend to pay that technical debt more often. But if it's not the case, if it's like more product-driven, you tend to accumulate those more often, and then you need to apply different approaches. So, one thing that I like doing is like when we are acquiring the debt; and that's normal, that's part of life. Sometimes you have to, and you should be okay with that. But when we are acquiring debt, we catalog it somewhere. Maybe you have like an internal wiki or something, like whatever documentation tool you use. You add that to a catalog where you basically have like your components or services or however you split your application. And then like what's the technical data you're acquiring, which would be the appropriate solutions or alternatives, how that's going to impact, and most importantly, when you believe you should pay that so you don't get like a huge impact, right?
Kovid Batra: Right. Of course. So just one thing I recently heard from one of my friends. Like they look at the time for a new developer to do the first commit as an indicator of technical debt. So if they.. First release, actually. So if someone who is joining new in the team, if they're taking too much time to reach a point where they could actually merge their code, and like have it on production, uh, if that is high and they, of course, keep a baseline there, then they consider that there is a lot of debt they might have accumulated because of which the learning and the implementation for the first release from a new developer is taking time. So do you think this approach could work or this approach could be inferential to what we are talking about, like the technical debt?
Peter Peret Lupo: I think that in this particular case, there are so many confounding variables. People join the team at different seniority levels. A senior might take less time than a junior, even in a scenario where there is more technical debt. So that alone is hard to compare. Even at the same level, people join with different skills. So maybe you have like a feature you need to write frontend and backend code, and some people are, uh, full stack but are more backend-inclined, more frontend-inclined. That alone will change your metric. You are waiting for one person to join that team so you can have like a new point of measurement. So you're not gonna have a lot, and there's gonna have like a lot of variation because of these confounding factors. Even that the onboarding process may change in between. The way that I usually like to introduce people to code is asking them to reduce the amount of warnings from like code linters first, and then fixing some simple defects, and then something like a more complex defect, and then writing a new feature. Uh, so, even like depending on your own onboarding strategy, your model strategy you're defining is going to affect that metric. So I wouldn't be very confident on that metric for this purpose.
Kovid Batra: Okay. Got it, got it. Makes sense. All right. I think if I have to ask you, uh, it's never easy, right? Like in the beginning, you mentioned that the first point itself is talking about these metrics is hard, right? Even if they make a lot of practical sense, but talking about it is hard. So when there is inherited resistance towards this topic, uh in the teams, when you go about implementing it, there could be a hell of a lot of challenges, right? And I'm sure, you would have also come across some of those in your journey when you were implementing it. So can you give us some examples from the implementation point of view, like how does the implementation go for, uh, these metrics and what are the challenges one faces when they're implementing it? And maybe if there are certain timelines to which one should look at for a full-fledged implementation and getting some success from the implementation of these metrics.
Peter Peret Lupo: Right. So, um, usually you're measuring something because you want to prove something, right? Because you want to like achieve like a certain goal, uh, maybe organizational, or just like the team. So I think that the first thing to lower, uh, the resistance is having a clear goal, and making sure that everybody understands that, uh, that the goal is not measuring anybody, uh, individually. That already like reduces the resistance a lot, and making sure that people understand why that goal is important and how you're going to measure in it is also extremely important.
Another thing that is interesting is to ask people for inputs on like how they think you could be measuring that. So making them also part of the process, and maybe the way that they're advising is not going to be like the way that you end up measuring. Maybe it influences, maybe it's exactly what they suggest, but the important thing is to make them part of the process, so they don't feel that the process, like the process of establishing metrics is not something that is being done to them, but something that they are doing with everybody else.
And so honestly, like so many things are already measured by the team, uh, velocity or however they estimate productivity. Even the estimates themselves are on like tickets on user stories or, uh, these are all, uh, attempts to measure things and they're used to compare the destinations with, uh, the actual results, so they know what the measures are used for. So sometimes it's just a matter of like establishing these parallels. Look, we measure productivity, we measure velocity to see if we are getting better, if we're getting worse. We also need to measure, uh, the quality to see if we're like catching more defects than before, if we have like more escape defects. Measurement is in some way already a part of our lives. Most of the times, it's a matter of like highlighting that, and, uh, people are usually comfortable with them, yeah, once you go through all this.
Kovid Batra: Right. Makes sense. Um, I think the major part is done when the team is aligned on the 'why' part, like why you are doing it, because as soon as they realize that there is some importance to measuring this metric, they would automatically be, uh, intuitively be aligned towards measuring that, and it becomes easier because then if there are challenges related to the implementation process also, they would like come together and maybe find out ways to, uh, build things around that and help in actual measurement of the metric also.
But if I have to ask, let's say a team is fully aligned and, uh, we are looking at implementing, let's say DORA metrics for a team, what should be the time frame one should keep in mind to get an understanding of what these metrics are saying? Because it's not like straightforward. You look at the common frequency, if it's high, you say things are good. If it's low, things are bad. Of course, it doesn't work like that. You have to understand these metrics in the first place in the cadence of your team, in the situation of your team, and then make sense out of it and find out those bottlenecks or those areas of inefficiency where you could really work upon, right? So what should be that time frame in one's mind that someone is an engineering manager who is implementing this for a team? What time frame should that person keep in mind and what exactly should be the first step towards measuring these once you start implementing them?
Peter Peret Lupo: Right. So it's a very good question. Time frame varies a lot and I'll tell you why; because more important than the time is the amount of data points that you have. If you wait for, like let's say, a month and you have like three data points, you can't establish any sort of pattern. You don't know if that's increasing, decreasing. There's no confidence. There's no statistical relevance. It's, like, the sample is too small. But like if you collect, like three data points, that's like generic for any metric. If you collect, like three data points every day, maybe in a week you'll have enough. The problem I see here is like, let's say, uh, something happens that is out of the ordinary. I want to investigate that to see if there is room for improvement there, or if that actually indicates that something went like really well and you want to replicate that success in the other cases. Um, you can't tell what's out of the ordinary if you're looking at three, four points.
Kovid Batra: Right.
Peter Peret Lupo: Uh, or if it's just like normal variation. So, I think that what's important is to have like a good baseline. So, that's gonna vary from process to process, from organization to organization, but there are some indications in the literature that like you should collect at least 30 data points. I think that with 30 data points you have like somewhat of a good, uh, statistical relevance for it, for your analysis, but I don't think you should, you have to wait for those many points in order to start investigating things. Sometimes you have like 10 or 12 and you already see something that. looks like something that you should investigate or you start having like an idea of what's going on, if it's higher than you expected, if it's lower than you expected, and you can start taking actions and investigating that as long as you consider that your interpretation may not be valid, bec ause like your sample is small. The time that it takes, like time frame, I guess that's going to depend on how often you are able to collect a new data point, and that's going to vary from organization to organization and from process to process, like measuring quality is different from measuring productivity, uh, and so on. So, I think all these things need to be taken into consideration. I think that the confidence is important.
And one other thing that you mentioned there, about like the team analyzing. It's something that I want to touch on because it's an experience that I've had more than once. You mentioned context. Context is super important. So much so that I think that the team that is producing the metrics should be the first one looking at them, not management, higher management, C-level, not them, because they are the only ones that are able to look at data points and say, "Yeah, things here didn't go well. Our only QA was on vacation." Or like somebody took a sick day or whatever reason, like they have the context. So they should be the first ones looking at the metric, analyzing the metric, and conveying the results of their analysis to higher levels, not the other way around, because what happens when you have it the other way around is that, like, they don't have the context, so they're looking at just the numbers, and if the number is bad, they're gonna inquire about it. If it's good, they are usually gonna stay quiet, uh, and they're gonna ask about the bad numbers, whether or not there was a good reason for that, whether or not it was like, uh, let's say, an exception. And then the team is going to feel that they have to defend themselves, to justify themselves every time, and it creates like a very poisonous scenario where the team feels that management is there to question them and they need to defend themselves against management instead of them having the autonomy to report on their success and their failures to management and let management deal with those results instead of the causes.
Kovid Batra: Totally, totally.
Peter Peret Lupo: Context is super important.
Kovid Batra: Great point there. Yeah, of course. Great point there, uh, highlighting the do's and don'ts from your experience and it's very relevant actually because the numbers don't always give you the reality of the situation. They could be an indicator and that's why we have them in place. Like first thing, you measure it. Don't come to a conclusion from it directly. If you see some discrepancy, like if there are some extraordinary data points, as you said, then there is a point which you should come out and inquire to understand what exactly happened here, but not directly jump onto the team saying that, Oh, you're not doing good or the other way around. So I think that that totally makes sense, uh, Peter.
I think it was really, really interesting talking to you about the metrics and the implementation and the experiences that you have shared. Um, we could go on on this, but today I think we'll have to stop here and, uh, say goodbye to you. Maybe we can have another round of discussion continuing with those experiences that you have had with the implementation.
Peter Peret Lupo: Definitely. It was a real pleasure..
Kovid Batra: It would be our pleasure, actually. But, uh, like before you leave, uh, anything that you want to share with our audience as parting advice, uh, would be really appreciated.
Peter Peret Lupo: All right. Um, look at your metrics as an ally, as a guide to tell you where you're going. Compare what you're doing now with what you were doing before to see if you're improving. When I say 'you', I'm talking to, uh, each individual in the team. Consider your team metrics, look at them, your work is part of the work that is being analyzed, and you have an influence on that at an individual level and with your team. So do look at your metrics, compare where you are at with where you were before to see if your changes were improved, see if your changes, uh, carried improvements you're looking for, and talk to your team about these metrics on your sprint retrospective. That's a very powerful tool to tell you, like, if your, uh, retrospective actions are being effective in delivering the change that you want in your process.
Kovid Batra: Great! I think great piece of advice there. Thanks, Peter. Thank you so much. Uh, this was really insightful. Loved talking to you.
Peter Peret Lupo: All right. Thank you.
In the third episode of ‘The DORA Lab’ - an exclusive podcast by groCTO, host Kovid Batra has an engaging conversation with Ben Parisot, Software Engineering Manager at Planet Argon, with over 10 years of experience in engineering and engineering management.
The episode starts with Ben offering a glimpse into his personal life. Following that, he delves into engineering metrics, specifically DORA & the SPACE framework. He highlights their significance in improving the overall efficiency of development processes, ultimately benefiting customers & dev teams alike. He discusses the specific metrics he monitors for team satisfaction and the crucial areas that affect engineering efficiency, underscoring the importance of code quality & longevity. Ben also discusses the challenges faced when implementing these metrics, providing effective strategies to tackle them.
Towards the end, Ben provides parting advice for engineering managers leading small teams emphasizing the importance of identifying & utilizing metrics tailored to their specific needs.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo, and today's episode is a bit special. This is part of The DORA Lab series and this episode becomes even more special with our guest who comes with an amazing experience of 10 plus years in engineering and engineering management. He's currently working as an engineering manager with Planet Argon. We are grateful to have you here, Ben. Welcome to the show.
Ben Parisot: Thank you, Kovid. It's really great to be here.
Kovid Batra: Cool, Ben. So today, I think when we talk about The DORA Lab, which is our exclusive series, where we talk only about DORA, engineering metrics beyond DORA, and things related to implementation of these metrics and their impact in the engineering themes. This is going to be a big topic where we will deep dive into the nitty gritties that you have experienced with with this framework. But before that, we would love to know about you. Something interesting, uh, about your life, your hobby and your role at your company. So, please go ahead and let us know.
Ben Parisot: Sure. Um, well, my name is Ben Parisot, uh, as you said, and I am the engineering manager at Planet Argon. We are a Ruby on Rails agency. Uh, we are headquartered in Portland, Oregon in the US but we have a distributed team across the US and, uh, many different countries around the world. We specifically work with, uh, companies that have legacy rails applications that are becoming difficult to maintain, um, either because of outdated versions, um, or just like complicated legacy code. We all know how the older an application gets, the more complex and, um, difficult it can be to work within that code. So we try to come in, uh, help people pull back from the brink of having to do a big rewrite and modernize and update their applications.
Um, for myself, I am an Engineering Manager. I'm a writer, parts, uh, very, very non-professional musician. Um, I like to read, I really like comic books. I currently am working on a mural for my son, uh, he's turning 11 in about a week, and he requested a giant Godzilla mural painted on his bedroom wall. This is the first time I've ever done a giant mural, so we'll see how it goes. So far, so good. Uh, but he did tell me that, uh, he said, "Dad, even if it's bad, it's just paint." So, I think that.. Uh, still trying to make it look good, but, um, he's, he's got the right mindset, I think about it.
Kovid Batra: Yeah, I mean, I have to appreciate you for that and honestly, great courage and initiative from your end to take up this for the kid. I am sure you will do a great job there. All the best, man. And thanks a lot for this quick, interesting intro about yourself.
Let's get going for The DORA Lab. So I think before we deep dive into, uh, what these metrics are all about and what you do, let's have a quick definition of DORA from you, like what is DORA and why is it important and maybe not just DORA, but other metrics, engineering metrics, why they are important.
Ben Parisot: Sure. So my understanding of DORA is sort of the classical, like it's the DevOps Research and Assessment. It was a think tank type of group just to, I can't remember the company that they started with, but it was essentially to improve productivity specifically around deployments, I believe, and like smoothing out some deployment, uh, and more DevOps-related processes, I think. That's, uh, but, uh, it's essentially evolved to be more about engineering metrics in a broader sense, still pretty focused on deployment. So specifically, like how, how fast can teams deploy code, the frequency of those deployments and changes, uh, to the codebase. Um, and then also metrics around failures and response to failures and how fast people can, uh, or engineering teams respond to incidences.
Beyond DORA, there's of course the SPACE framework, which is a little bit more broader and looks at some of the more day-to-day processes involved in software engineering, um, and also developer experience. We at Planet Argon, we do a little bit of DORA. We focus mainly on more SPACE-related metrics, um, although there's a bunch of crossover. For us, metrics are very important both for, you know, evaluating the performance of our team, so that we can, you know, show value to our clients and prove, you know, "Hey, this is the value that we are providing beyond just the deliverable." Sometimes because of the nature of our work, we do a lot of work on like the backend or improvements that are not necessarily super-apparent to an end user or even, you know, the stakeholder within the project. So having metrics that we can show to our clients to say, "Hey, this is, um, you know, this is improving our processes and our team's efficiency and therefore, that's getting more value for your budget because we're able to move faster and accomplish more." That's a good thing. Also, it's just very helpful to, you know, keep up good team morale and for longevity sake, like, engineers on our team really like to know where they stand. They like to know how they're doing. Um, they like to have benchmarks on which they can, uh, measure their own growth and know where in sort of the role advancement phase they are based on some, you know, quantifiable metric that is not just, you know, feedback from their coworkers or from clients.
Kovid Batra: Yeah, I think that's totally making sense to me and while you were talking about the purpose of bringing these metrics in place and going beyond DORA also, that totally relates to the modern software development processes, because you just don't want to like restrict yourself to certain part of engineering efficiency when you measure it, you just don't want to look at the lead time for change, or you just don't want to look at the deployment frequency. There are things beyond these, which are also very important and become, uh, the area of inefficiency or bottlenecks in the team's overall delivery. So, just for example, I mean, this is a question also, whether there is good collaboration between the team or not, right? If there is no good code collaboration, that is a big bottleneck, right? Getting reviews done in a proper way where the quality, the base is intact, that really, really matters. Similarly, if you talk about things like delivery, when you're delivering the software from the planning phase to the actual feature rollout and users using it, so cycle time probably in DORA will cover that, but going beyond that space to understand the project management piece and making sure how much time in total goes into it is again an aspect. Then, there are areas where you would want to understand your team satisfaction and how much teams are contributing towards the roadmap, because that's also how you define that whether you have accumulated too much of technical debt or there are too many bugs coming in and the team is involved right over there.
And an interesting one which I recently came across was someone was measuring that when new engineers are getting onboarded, uh, how much time does it take to go for the first commit, right? So, these small metrics really matter in defining how the overall efficiency of the engineering or the development process looks like. So, I just wanted to understand from you, just for example, as I mentioned, how do you look at code collaboration or how do you look at, uh, roadmap contribution or how do you look at initial code quality, deliverability, uh, when it comes to your team. And I understand like you are a software agency, maybe a roadmap contribution thing might not be very relevant. So, maybe we can skip that. But otherwise, I think everything else would definitely be relevant to your context.
Ben Parisot: Sure. Yeah, being an agency, we work with multiple different clients, um, different repos in different locations even, some of them in GitHub, Bitbucket, um, GitLab, like we've got clients with code everywhere. Um, so having consistent metrics across all of like the DORA or SPACE framework is pretty difficult. So we've been able to piecemeal together metrics that make sense for our team. And as you said, like a lot of the metrics, they're for productivity and efficiency sake for sure, but they also then, if you like dig one level deeper, there is a developer experience metric below that. Um, so for instance, PR review, you know, you mentioned, um, like turnaround time on PRs, how quickly are people that are being assigned to review getting to it, how quickly are changes being implemented from after a review has been submitted; um, those are on the surface level, very productivity- driven metrics. We want our team to be moving quickly and reviewing things in a timely manner. But as you mentioned, like a slow PR turnaround time can be a symptom of bad communication and that can lead to a lot of frustration, um, and even like disagreement amongst team members. So that's a really like developer satisfaction metric as well, um, because we want to make sure no one's frustrated with any of their coworkers, uh, or bottlenecked and just stuck not knowing what to do because they have a PR that hasn't been touched.
We use a couple of different tools. We're luckily a pretty small team, so my job as a manager and collecting all this data from the metrics is doable for now, not necessarily scalable, but doable with the size of our team. I do a lot of manual data collection, and then we also have various third-party integrations and sort of marketplace plugins. So, we work a lot in GitHub, and we use some plugins in GitHub to help us give some insight into, for instance, like you said, like commit time or number of commits within a PR size of those commits you know, we have an engineering handbook that has a lot of our, you know, agreed upon best practices and those are generally in place so that our developers can be more efficient and happy in their work, so, you know, it can feel a little nitpicky to be like, "Oh, you only had two commits in this giant PR." Like, if the work's getting done, the work's getting done. However you know, good commit, best practice. We try to practice atomic commits here at Planet Argon. That is going to, you know, not only like create easier rollbacks if necessary, there's just a lot of reasons for our best practices. So the metrics try to enforce the best practices that we have in mind already, or that we have in place already. And then, yeah, uh, you asked what other tools or?
Kovid Batra: So, yeah, I mean talking specifically about the team satisfaction piece. I think that's very critical. Like, that's one of the fundamental things that should be there in the team so that you make sure the team is actually productive, right? From what you have explained, uh, the kind of best practices you're following and the kind of things that you are doing within the team reflect that you are concerned about that. So, are there any specific metrics there which you track? Can you like name a few of them for us?
Ben Parisot: Sure, sure. Um, so for team satisfaction, we track a number of following metrics. We track build processes, code review, deep work, documentation, ease of release, local development, local environment setup, managing technical debt, review turnaround, uh, roadmap and priorities, and test coverage and test efficiency. So these are all sentiment metrics. I use them from a management perspective to not only get a feeling of how the team is doing in terms of where their frustrations lie, but I also use it to direct my work. If I see that some of these metrics or some of these areas of focus are receiving like consistently low sentiment scores, then I can brainstorm with the team, bring it to an all-hands meeting to be like, "Here's some ideas that I have for improving these. What is your input? What's a reasonable timeline look like?" And then, show them that, you know, their continued participation in these, um, these surveys, these developer experience surveys are leading to results that are improving their work experience.
Kovid Batra: Makes sense. Out of all these metrics that you mentioned, which are those top three or four, maybe? Because it's very difficult to, uh, look at 10, 12 metrics every time, right? So..
Ben Parisot: Yes.
Kovid Batra: There is a go-to metric or there are a few go-to metrics that quickly tell you okay, what's going on, right? So for me, sometimes what I basically do is like if I want to see if the code, initial code quality is coming out good or not I'm mostly looking at how many commits are happening after the PRs are being raised for review and how many comments were there. So when I look at these two, I quickly understand, okay, there is too much to and fro happening and then quality initially is not coming out well. But in the case of team satisfaction, of course, it's a very feeling, qualitative-driven, uh, piece we are talking about. But still, if you have to objectify it with, let's say three or four metrics, what would be those three or four important metrics that you think impact the developer's experience or developer's satisfaction in your team?
Ben Parisot: Sure. So we actually have like 4 KPIs that we track in addition to those sentiment metrics, and they are also sort of sentiment metrics as well, but they're a little higher level. Um, we track weekly time loss, ease of delivery, engagement, uh, and perceived productivity. So we feel like those touch pretty much all of the different aspects of the software development life cycle or the developer's day-to-day experience. So, ease of delivery, how, you know, how easy is it for you to be, uh, deploying your code, um, that touches on any bottlenecks in the deployment pipelines, any issues with PRs, PR reviews, that sort of thing. Um, engagement speaks to how excited or interested people are about the work that they're doing. So that's the more meat of the software development work. Um, perceived productivity is how, you know, how well you think you are being productive or how productive you feel like you are being. Um, and that's really important because sometimes the hard metrics of productivity and the perceived productivity can be very different, and not only for like, "Oh, you think you're being very productive, but you're not on paper." Um, oftentimes, it's the reverse where someone feels like they aren't being productive at all and I can go, and I know that from their sentiment score. Um, but then I can go and pull up PRs that they've submitted or work that they've been doing in JIRA and just show them a whole list of work that they've done. I feel like sometimes developers are very in the weeds of the work and they don't have a chance to step back and look at all that they've accomplished. So that's an important metric to make sure that people are recognizing and appreciating all of the work and their contributions to a project and not feeling like, "Oh, this one ticket, I haven't been very productive on. So, therefore, I'm not a very good developer." Uh, and then finally, weekly time loss is a big one. This one is more about everything outside of the development work. So this also focuses on like, how often are you in your flow? Are you having too many meetings? Do you feel like, you know, the asynchronous current communication that is just the nature of our distributed team? Is that blocking you? And are you being, you know, held up too much by waiting around for a response from someone? So that's an important metric that we look at as well.
Kovid Batra: Makes sense. Thanks. Thanks for that detailed overview. I think team satisfaction is of course, something that I also really, really care about. Beyond that, what do you think are those important areas of engineering efficiency that really impact the broader piece of efficiency? So, uh, just to give you an example, is it you're focusing mostly in your teams related to deliverability or are you focusing more related to, uh, the quality of the work or is it something related to maybe sprints? I'm really just throwing out ideas here to understand from you how you, uh, look at which are those important areas of engineering efficiency other than developer satisfaction.
Ben Parisot: Yeah. I think, right. I think, um, for our company, we're a little bit different even than other agencies. Companies don't come to us often for large new feature development. You know, as I mentioned at the top of the recording, we inherit really old applications. We inherit applications that have, you know, the developers have just given up on. So a lot of our job is modernizing and improving the quality of the code. So, you know, we try to keep our deployment metrics, you know, looking nice and having all of the metrics around deployment and, uh, post-deployment, obviously. Um, but from my standpoint, I really focus on the quality of the code and sort of the longevity of the code that the team is writing. So, you know, we look at coding practices at Planet Argon, we measure, you know, quality in a lot of different ways. Some of them are, like I said earlier, like practicing atomic commits size of PRs. Uh, because we have multiple projects that people are working on, we have different levels of understanding of those projects. So there's like, you know, some people that have a very high domain knowledge of an application and some people that don't. So when we are submitting PRs, we try to have more than one person look at a PR and one person is often coming with a higher domain knowledge and reviewing that code as it, uh, does it satisfy the requirements? Is it high-quality code within the sort of ecosystem of that existing application? And then, another person is looking at more of the, the best practices and the coding standards side of it, and reviewing it just from a more, a little more objective viewpoint and not necessarily as it's related to that.
Let's see, I'm trying to find some specific metrics around code quality. Um, commits after a PR submission is one, you know, if where you are finding that our team is often submitting a PR and then having to go back and work a lot more on it and change a lot more things; that means that those PRs are probably not ready or they're being submitted a little earlier. Sometimes that's a reflection of the developer's understanding of the task or of the code. Sometimes it's a reflection of the clarity of the issue that they've been assigned or the requirements. You know, if the client hasn't very clearly defined what they want, then we submit a PR and they're like, "Oh, that's not what I mean." so that's an important one that we looked at. And then, PR approval time, I would say is another one. Again, that one is both for our clients because we want to be moving as quickly with them as we can, even though we don't often work against hard deadlines. We still like to keep a nice pace and show that our team is active on their projects. And then, it's also important for our team because nobody likes to be waiting around for days and days for their PR to be reviewed.
Kovid Batra: Makes sense. I think, yeah, uh, these are some critical areas and almost every engineering team struggles with it in terms of efficiency and what I have felt also is not just organization, right, but individual teams have different challenges and for each team, you could be looking at different metrics to solve their problems. So one team would be having a low deployment frequency because of maybe not enough tooling in place and a lot of manual intervention being there, right? That's when their deployments are not coming out well or breaking most of the time. Or it could be for another team, the same deployment frequency could be a reason that the developers are actually not writing or doing enough number of like PRs in a defined period of time. So there is a velocity challenge there, basically. That's why the deployment frequency is low. So most of the times I think for each team, the challenge would be different and the metrics that you pick would be different. So in your case, as you mentioned, like how you do it for your clients and for your teams is a different method. Cool. I think with that, I.. Yeah, you were saying something.
Ben Parisot: Oh, I was, yeah. I was gonna say, I think that, uh, also, you know, we have sort of across the board, company best practice or benchmarks that we try to reach for a lot of different things. For instance, like test coverage or code coverage, technical debt, and because we inherit codebases in various levels of, um, quality, the metric itself is not necessarily good or bad. The progress towards a goal is where we look. So we have a code coverage metric, uh, or goal across the company of like 80, 85%, um, test coverage, code coverage. And we've inherited apps, big applications, live applications that have zero test coverage. And so, you know, when I'm looking at metrics for tests, uh, you know, it's not necessarily, "Hey, is this application's test coverage meeting our standards? Is it moving towards our standards?" And then it also gets into the individual developers. Like, "Are you writing the tests for the new code that you're writing? And then also, is there any time carved out of the work that you have on that project to backfill tests?" And similarly, with, uh, technical debt, you know, we use a technical debt tagging tool and oftentimes, like every three months or so we have a group session where we spend like an hour, hour and a half with our cameras off on zoom, just going into codebases that we're currently working on and finding as much technical debt as we can. Um, and that's not necessarily like, oh, we're trying to, you know, find who's not writing the best code or what the, uh, you know, trying to find all the problems that previous developers caused. But it's more of a is this, you know, other areas for like, you know, improvements? Right. And also, um, is there any like potential risks in this codebase that we've overlooked just by going through the day-to-day? And so, the goal is not, "Hey, we need to have no technical debt ever." It's, "Are we reducing the backlog of tech debt that we're currently working within?"
Kovid Batra: Totally, totally. And I think this again brings up that point that for every team, the need of a metric would be very different. In your case, the kind of projects you are getting by default, you have so much of technical debt that's why they're coming to you. People are not managing it and then the project is handed over to you. So, having that test coverage as a goal or a metric is making more sense for your team. So, agreed. I think I am a hundred percent in line with that. But one thing is for sure that there must be some level of, uh, implementation challenges there, right? Uh, it's not like straightforward, like you, you are coming in with a project and you say, "Okay, these are the metrics we'll be tracking to make sure the efficiency is in place or not." There are always implementation challenges that are coming with that. So, I mean, with your examples or with your experience, uh, what do you think most of the teams struggle with while implementing these metrics? And I would be more than happy to hear about some successes or maybe failures also related to your implementation experiences.
Ben Parisot: Yeah. So I would just say the very first challenge that we face is always, um. I don't want to see team morale, but, um, the, somewhat like overwhelming nature depending on the state of the codebase. Like if you inherit a codebase, it's really large and there's no tests. That's, you know, overwhelming to think about, having to go and write all those tests, but it's also overwhelming and scary to think, "Oh, what if something breaks?" Like, a test is a really good indicator of where things might be breaking and there's none of that, so the guardrails are off. Um, and that's scary. So helping people get used to, especially newer developers who have just joined the team, helping them get used to working within a codebase that might not be as nice and clean as previous ones that they've worked with is a big challenge. In terms of actual implementation, uh, we face a number of challenges being an agency. Like I mentioned earlier, some codebases are in, um, different places like GitHub or Bitbucket. You know, obviously those tools have generally the same features and generally the same, you know, sort of dashboard type of things. Um, but if we are using any sort of like integrated tool to measure metrics around those things, if we get it, um, a repo that's not in the platform, it's not on the platform where we have that integration happening, then we don't get the metrics on that, or we have to spin up a new integration.
Kovid Batra: Yeah.
Ben Parisot: Um, for some of our clients, we have access to some of their repos and not others, and so, like we are working in an app ecosystem where the application that we are responsible for is communicating and integrated with another application that we don't, we can't see; and so that's very difficult at times. That can be a challenge for implementing certain metrics, because we need to know, like, especially performance metrics for the application. Something might be happening on this hidden application that we don't have any control over or visibility into.
Um, and then what else? Just I would say also a challenge that we face is the, um, most of our developers are working on 2 to 3 applications at a time, and depending on the length of the engagement, um, sometimes people will switch on and off. So it can be difficult to track metrics for just a single project when developers are working on it for like maybe a few weeks or a few months and then leaving. Sometimes we have like a dedicated developer who's lead and then, have a support developer come in when necessary. And so that can be challenging if we're trying to parse out, like why there might've been a shift in the metrics or like a spike in one metric or another, or a drop and be like, "Okay, well, let's contextualize that around who was working on this project, try to determine like, okay, is this telling us something important about the project itself, or is it just data that is displaying the adding or subtracting of different developers to the project?" So that can be a challenge.
Specifically, I can mention an actual sort of case study that we had. Uh, we were using Code Climate, which is a tool that we still use. We use the quality tool for like audits and stuff. Um, but when I first started applying to Argon, I wanted to implement its velocity tool, which is like the sister tool to quality and it is like very heavily around cycle time. Um, and it was all great, I was very excited about it. Went and signed up, um, went and connected our GitHub accounts, or I guess I did the Bitbucket account at the time cause most of our repos were in Bitbucket. Um, didn't realize at the time at least that you could only integrate with one platform. And so, even though we had, uh, we had accounts and we had clients with applications on GitHub, we were only able to integrate with Bitbucket. So some engineers' work was not being caught in that tool at all because they were working primarily in GitHub application. And again, like I said, sometimes developers would then go to one of the applications in Bitbucket, help out and then drop off. So it was just causing a lot of fluctuations in data and also not giving us metrics for the entire team consistently. So we eventually had to drop it because it was just not a very valuable tool, um, in that it was not capturing all of the activities of all of our engineers everywhere they were working. Um, I wished that it was, but it's the nature of the agency work and also, you know, having people that are, um.
Kovid Batra: Yeah, I totally agree on that point and the challenges that you're facing are actually very common, but at the same time, uh, having said that, I believe the tooling around metrics observation and metrics monitoring has come way ahead of what you have been using in Code Climate. So, the challenge still remains, like most of the teams try to gather metrics manually, which is time-consuming, or in your case where agencies are working on different projects, it's very difficult or different codebases, very difficult to gather the right metrics for individual developers there also. Somehow, I think the challenges are very valid, but now, the tooling that is available in the market is able to cater to all those challenges. So maybe you want to give it a try and see, uh, your metrics implementation getting in place. But yeah, I think, thanks for highlighting these pointers and I think a lot of people, a lot of engineering managers and engineering leaders struggle with the same challenges while implementing those. So totally, uh, bringing these challenges in front of the audience and talking about it would bring some level of awareness to handle these challenges as well.
Great. Great, Ben. I think with this, uh, we would like to bring an end to our today's episode. It was really amazing to understand how Planet Argon is working and you are dealing with those challenges of implementing metrics and how well you are actually doing, even though the right tooling or right things are not in place, but the important part is you realize the purpose. You don't probably go ahead and do it for the sake of doing it. You're actually doing it where you have a purpose and you know that this can impact the overall productivity of the team and also bring credibility with your clientele that yes, we are doing something and you have something to show in numbers also. So, I really appreciate that.
And while, like before we say goodbye, is there parting advice or something that you would like to speak with the audience? Please go ahead.
Ben Parisot: Oh, wow! Um, yeah, sure. So I think your point about like understanding the purpose of the metrics is important. You know, my team, uh, I am the manager of a small team and a small company. I wear a lot of hats and I do a lot of different things for my team. They show me a lot of grace, I suppose, when I have, you know, incomplete data for them, I suppose. Like you said, there's a lot of tools out there that can provide a more holistic, uh, look. Um, and I think that if you are an agency, uh, if you're a manager on a small team and you sort of struggle to sort of keep up with all of the metrics that you have even promised for your team or that you know that you should be doing, uh, if you really focus on the ones that are impacting their day-to-day experience as well as like the value that they're providing for either, you know, your company's internal stakeholders or external clients, you're going to quickly see the metrics that are most important and your team is going to appreciate that you're focusing on those, and then, the rest of it is going to fall into place when it does. And when it doesn't, um, you know, your team's not going to really be too upset because they know, they see you focusing on the stuff that matters most to them.
Kovid Batra: Great. Thanks a lot, Ben. Thank you so much for such great, insightful experiences that you have shared with us. And, uh, we wish you all the best, uh, and your kid a very happy birthday in advance.
Ben Parisot: Thank you.
Kovid Batra: All right, Ben. Thank you so much for your time. Have a great day.
Ben Parisot: Yes. Thanks.
In the latest episode of ‘groCTO: Originals’ (formerly ‘Beyond the Code: Originals’), host Kovid Batra engages with Leigh Rathbone, Head of Quality Engineering at CAVU who has a rich technical background with reputable organizations like Sony Ericsson and The Very Group. He has been at the forefront of tech innovation, working on the first touchscreen smartphone and smartwatch, and later with AR, VR, & AI tech. The conversation revolves around ‘Evolution of Software Testing: From Brick Phones to AI’.
The podcast begins with Leigh introducing himself and sharing a life-defining moment in his career. He further highlights the shift from manual testing to automation, discussing in depth the automation framework for touchscreen smartphones from 19 years ago. Leigh also addresses the challenges of implementing AI and how to motivate teams to explore automation opportunities. He also discusses the evolution of AR, VR, and 3D gaming & their role in shaping modern-day testing practices, emphasizing the importance of health and safety considerations for testers.
Lastly, Leigh offers parting advice urging software makers & testers to always prioritize user experience & code quality when creating software.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today, we are lucky to have a tech industry veteran with us on our show today. He is the Head of Quality Engineering at CAVU. He has had fascinating 25-plus years of engineering and leadership experience, working on cutting-edge technologies including the world's first smartphone and smartwatch. He was also involved in the development of progressive download and DRM technologies that laid the groundwork for modern streaming services. We are grateful to have you on the show, Leigh.
Leigh Rathbone: Thank you, Kovid. It's great to be here. I'm really happy to be invited. I'm looking forward to sharing a few experiences and a few stories in order to hopefully inspire and help other people in the tech industry.
Kovid Batra: Great, Leigh. And today, I think they would have a lot of things to deep dive into and learn from you, from your experience. But before we go there, where we talk about the changing landscape of software testing, coming from brick phones to AI, let's get to know a little bit more about each other. Can you just tell us something about yourself, some of your life-defining experiences so that I and the audience can know you a little more?
Leigh Rathbone: Yeah. Well, I'm Leigh Rathbone. I live in the UK, uh, in England. I live just North of a city called Liverpool. People might've heard of Liverpool because there's a few famous football teams that come from there, but there's also a famous musical band called the Beatles that came from Liverpool. So, I live just North of Liverpool. I have two children. I'm happily married, been married for over 20 years. I am actually an Aston Villa football fan. I don't support any of the Liverpool football clubs. I'm not a cricket fan or a rugby fan. It's 100 percent football for me. I do like a bit of fitness, so I like to get out on my bike. I like to go to the gym. I like to drink alcohol. Am I allowed to say that, Kovid? Am I allowed to say that? I do like a little bit of alcohol. Um, and like everybody else, I think I'm addicted to Netflix and all the streaming services, which is quite emotional for me, Kovid, because having played a part in the building blocks and a tiny, tiny part in the building blocks of what later became streaming, when I'm listening to Spotify or when I'm watching something on Amazon Video or Netflix, I do get a little bit emotional at times thinking, "Oh my God! I played a minute part of that technology that we now take for granted." So, that's my sort of out-of-work stuff that, um, I hope people will either find very boring or very interesting, I don't know.
Kovid Batra: No, I definitely relate to it and I would love to know, like, which was the last, uh, series you watched or a movie you watched on Netflix and what did you love about it?
Leigh Rathbone: So, I watched a film last night called 'No Escape'. Um, it's a family that goes to, uh, a country in Asia and they don't say the name of the country for legal reasons. Um, but they get captured in a hotel and it's how they escape from some terrorists in a hotel with the help of Brosnan who's also in the film. So, yeah, it was, uh, it was high intensity, high energy and I think that's probably why I liked it because from the very almost 5-10 minutes, it's like, whoa, what's going on here? So, it was called 'No Escape'. It's on Netflix in the UK. I don't know whether it'll be on Netflix across the world. But yeah, it's an old film. It's not new. I think it's about three years old. But yeah, it was quite enjoyable.
Kovid Batra: Cool, cool. I think that that's really interesting and thank you for such a quick, sweet intro about yourself. And of course, your contributions are not minute. Uh, I'm sure you would have done that in that initial stage of tech when the technology was building up. So, thanks on behalf of the tech community there.
Uh, all right, Leigh, thank you so much and let's get started on today's main topic. So, you come from a background where you have seen the evolution of this landscape of software testing and as I said earlier, also like from brick phones to AI, I'm sure, uh, you have a lot of experiences to share from the days when it all started. So, let's start from the part where there was no automation, there was manual testing, and how that evolved from manual testing to automation today, and how things are being balanced today because we are still not 100 percent automated. So, let's talk about something like, uh, your first smartphone, uh, maybe where you might not have all the automation, testing or sophisticated automation possible. How was your experience in that phase?
Leigh Rathbone: Well, I am actually holding up for those people that, uh, can either watch the video.
Kovid Batra: Oh my God! Oh my God!
Leigh Rathbone: I'm holding up the world's first touchscreen smartphone and you can see my reflection and your reflection on the screen there. This is called the Sony Ericsson P800. I worked on this in 2002 and it hit the market in 2003 as the world's first touchscreen smartphone, way before Apple came to the market. But actually, if I could, Kovid, can I go back maybe four years before this? Because there's a story to be told around manual testing and automation before I got to this, because there is automation, there is an automation story for this phone as well. But if I can start in 1999, I've been in testing for 12 months and I moved around a lot in my first four years, Kovid because I wanted to build up my skillsets and the only way to do that was to move jobs. So, my first four years, I had four jobs. So, in 1999 I'm in my second job. I'm 12 months into my testing career and I explore a tool called WinRunner. I think it was the first automation tool. So, there I am in 1999, writing automation scripts without really knowing the scale of what was going to unfold in front of not just the testing community, but the tech community. And when I was using this tool called WinRunner. Oh, Kovid, it was horrible. Oh my God! So, I would be writing scripts and it was pretty much record and playback, okay? So, I was clicking around, I was looking at the code, I was going, "Oh, this is exciting." And every time a new release would come from the developers, none of my scripts would work. You know the story here, Kovid. As soon as a new release of code comes out, there's bug fixes, things move around on the screens, you know, different classes change, there might be new classes. This just knocks out all of my scripts. So, I'd spend the next sort of, I don't know, eight days, working, reworking, refactoring my automation scripts. And then, I just get to the point where I was tackling new scripts for the new code that dropped and a new drop of code would come. And I found myself in this cycle in 1999 of using WinRunner and getting a little bit excited but getting really frustrated. And I thought, "Where is this going to go? Has it got a future in tech? Has it got a future in testing?" Cause I'm not seeing the return on investment with the way I was using it. So, at that point in time, 1999, I saw a glimpse, a tiny glimpse of the future, Kovid. And that was 25 years ago. And for the next couple of years, I saw this slow introduction, very, very slow back then, Kovid, of manual testing and automation. And the two were very separate, and that continued for a long, long time, whereby you'd have manual testers and automation testers. And I feel that's almost leading and jumping ahead because I do want to talk about this phone, Kovid, because this phone was touchscreen, and we had automation in 2005. We built an automation framework bespoke to Sony Ericsson that would do stress testing, soak testing, um, you know, um, it would actually do functional automation testing on a touchscreen smartphone. Let that sink into 19 years ago. We built a bespoke automation framework for the touchscreen smartphone. Let that sink in folks.
Kovid Batra: Yeah.
Leigh Rathbone: Unreal, absolutely unreal, Kovid. Back in the day, that was pretty much unheard of. Unbelievable. It still blows my mind to this day that in 2005, 19 years ago, on a touchscreen smartphone, we had an automation framework that added loads and loads of value.
Kovid Batra: Totally, totally. And was this your first project wherein you actually had a chance to work hands-on with this automation piece? Like, was that your first project?
Leigh Rathbone: So, what happened here, Kovid, and this is a trend that happened throughout the testing and tech industry right up until about, I'd say that seven years ago, we had an automation team and a manual team. I'll give you some context for the size. The automation team was about five people. The manual test team was about 80 people. So, you can see the contrast there. So, they were doing pretty much what I was doing in 1999. They were writing some functional test scripts that we could use for regression testing. Uh, but they were mostly using it for soak testing. So in other words, random touches on the screen, these scripts needed to run for 24 hours in order for us to be able to say, "Yes, that can, that software will exist in live with a customer touching the screen for 24 hours without having memory leaks, as an example." So, their work felt very separate to what we were doing. There was a slight overlap with the functional testing where they'd take some of our scripts and turn them into, um, automated regression packs. But they were way ahead of the curve. They were using this automation pack for soak testing to make sure there was no memory leaks by randomly dibbing on a screen. And I say dibbing, Kovid, because you touched the screen with a dibber, right? It wasn't a finger. Yeah, you needed this little dibber that clicked onto the side of the phone in order to touch the screen. So, they managed to mimic random clicks on the screen in order to test for memory leaks. Fascinating. Absolutely fascinating. So at that point, we started to see a nice little return on investment on automation being used.
Kovid Batra: Got it. Got it. And from there, how did it get picked up over the years? Like, how have teams collaborated? Was there any resistance from, of course, every time this automation piece comes in, uh, there is resistance also, right? People start pointing things. So, how was that journey at that point?
Leigh Rathbone: I think there's always resistance to change and we'll see it with AI. When we come on to the AI section of the talk, we'll see it there. There will always be resistance to change because people go through fear when change is announced. So, if you're talking to a tester, a QA or a QE and you're saying, "Look, you're going to have to change your skill sets in order to learn this." They're gonna go through fear before they spot the opportunity and come up the other side. So, everywhere I've gone, there's been resistance to automation and there's something else here, Kovid, from the years 1998 to 2015, test teams were massive. They were huge. And because we were in the waterfall methodology, they were pretty much standalone teams and all the people that were in power of running these big teams, they had empires, and they didn't want to see those empires come down. So actually, resistance wasn't just sometimes from testers themselves, it was from the top, where they might say, "Oh, this might mean that the number of testers I need goes down, so, therefore, my empire shrinks." And there were test leaders out there, Kovid, doing that, very, very naughty people. Like, honestly, trying to protect their own, their own job, instead of thinking about the future. So, I saw some testers try and accelerate the use of automation. I also saw test leaders put the brakes on it because they were worried about the status of their jobs and the size of their empires.
Kovid Batra: Right. And I think fast-forward to today, we won't take much long to jump to the AI part here. Like, a lot of automation Is already in place. According to your, uh, view of the tech industry right now uh, let's say, if there are a hundred companies; out of those hundred, how many are at a scale where they have done like 80 percent or 90 percent of automation of testing?
Leigh Rathbone: God! 80 to 90 percent automation of testing. You'll never ever reach that number because you can do infinite amounts of testing, okay? So, let's put that one out there. The question still stands up. You're asking of 100 companies, how many people have automation embedded in their DNA? So I would probably, yeah, I would probably say it's in the region of 70 to 80 percent. And I'd be, I wouldn't be surprised if it's higher, and I've got no data to back that up on. What I have got to back that up on is the fact that I've worked in 14 different companies, and I spend a lot of time in the tech industry, the tech communities, talking to other companies. And it's very rare now that you come across a company that doesn't have automation.
But here's the twist, Kovid, there's a massive twist here. I don't employ automation testers, okay? So 2015, I made a conscious effort and decision not to employ automation testers. I actually employed testers who can do the exploratory side and the automation side. And that is a trend now, Kovid, that really is a thing. Not many companies now are after QAs that only do automation. They want QAs that can do the exploratory, the automation, a little bit of performance, a little bit of security, the people skills is obviously rife. You know, you've got to put those in there with everything else.
Kovid Batra: Of course.
Leigh Rathbone: Yeah. So for me now, this trend that sort of I spotted in 2014 and I started doing in 2015 and I've done it at every company I've been to, that really is the big trend in testers and QAs right now.
Kovid Batra: Got it. I think it's more like, uh, it's an ever-growing evolutionary discipline, right? Uh, every time you explore new use cases and it also depends on the kind of business, the products the company is rolling out. If there are new use cases coming in, if there are new products coming in, every time you can just have everything automated. So yeah, I mean, uh, having that 80-90% testing scale automated is something quite far-fetched for most of the teams, until and unless you are stagnated over one product and you're just running it for years and years, which is definitely not, uh, sustainable for any business.
So here, my question would be, like, how do you ensure that your teams are always up for exploring that side which can be automated and making sure that it's being done? So, how do you make sure? One is, of course, having the right hires in the team, but what are the processes and what are the workflows that you implement there from time to time? People are, of course, doing the manual testing also and with the existing use cases where they can automate it. They're doing that as well.
Leigh Rathbone: It's a really good question, Kovid, and I'll just roll back in the process a little bit because for me, automation is not just the QA person's task and not even test automation. I believe that is a shared responsibility. So, quality is owned by everybody in the team and everyone plays their different parts. So for me, the automation starts right with the developers, to say, "Well, what are you automating? What are your developer checks that you're going to automate?" Because you don't want developers doing manual checks either. You want them to automate as much as they can because at the unit test level and even the integration test level, the feedback loops are really quick. So, that means the test is really cheap. So, you're getting some really good, rich feedback initially to show that nothing obvious has broken early on when a developer adds new code. So, that's the first part. So, that now, I think is industry standard. There aren't many places where developers are sat there going, "I'm not going to write any tests at all." Those days are long, long gone, Kovid. I think all, you know, modern developers that live by the modern coding principles know that they have to write automated checks.
But I think your question is targeted at the QAs. So, how do we get QAs involved? So, you have to breed the curiosity gene in people, Kovid. So, you're absolutely right. You have to bring people in who have the skills because it's very, very hard to start with a team of 10 QAs where no one can automate. That's really hard. I've only ever done that once. That's really hard. So, what I have done is I've brought people in with the mindset of thinking about automation first. The mindset of collaborating with developers to see what they're automating. The curiosity and the skill sets to grow and develop and learn more about the tools. And then, you have to give people time, Kovid. There is no way you can expect people who don't have the automation skills to just upskill like that. It's just not fair. You have to support, support, and support some more. And that comes from myself giving people time. It's understanding how people learn, Kovid.
So, I'll give you an example. Pair learning. That's one technique where you can get somebody who can't automate and maybe you get them pairing with someone else who can't automate and you give them a course. That's point number one. Pair learning could be pairing with someone who does know automation and pairing them with someone who doesn't know automation. But guess what? Not everyone likes pairing because it's quite a stressful environment for some people. Jumping on a screen and sharing your screen while you type, and them saying, "No, you've typed that wrong." That can be quite stressful. So, some people prefer to learn in isolation but they like to do a brief course first, and then come back and actually start writing something right in the moment, like taking a ticket now that they're manually testing, and doing something and practising, then getting someone to peer review it. So, not everyone likes pair learning. Not everybody likes to learn in isolation. You have to understand your people. How do they like to learn and grow? And then, you have to understand, then you have to relay to them why you are asking them to learn and grow. Why am I asking people to change? 'cause the skill bases that's needed tomorrow and the day after and in two years time are different to the skill bases we need right now or even 10 years ago. And if people don't upskill, how are they going to stay relevant?
Kovid Batra: Right.
Leigh Rathbone: Everything is about staying relevant, especially when test automation came along, Kovid, and people were saying, "Hey, we won't need QAs because the automation will get rid of them." And you'd be amazed how many people believed that, Kovid, you'd be absolutely gobsmacked how many tech leaders had in their minds that automation would get rid of QAs. So, we've been fighting an uphill struggle since then to justify our existence in some cases, which is wrong because I think the value addition of QAs and all the crafts when they come together is brilliant. But for me, for people who struggle to understand why they need to upskill in automation, it's the need to stay relevant and keep adding value to the company that they're in.
Kovid Batra: Makes sense. And what about, uh, the changing landscape here? So basically, uh, you have seen that part where you moved to phones and when these phones were being built, you said like, that was the first time you built something for touchscreen testing, right? Now, I think in the last five to seven years, we have seen AR, VR coming into the picture, right? Uh, the processes that you are following, let's say the pair learning and other things that you bring along to make sure that the testing piece, the quality assurance piece is in place as you grow as a company, as you grow as a tech team. For VR, AR kind of technologies, how has it changed? How has it evolved?
Leigh Rathbone: Well, massively, because if you think about testing back in the day, everybody tested on a screen. And most of us are still doing that. And this is why this phone felt different and even the world's first smartwatch, which is here. When I tested these two things, I wasn't testing on a screen. I was wearing it on my wrist, the watch, and I was using the phone in my hand in the environment that the end user would use it in. So, when I went to PlayStation, Kovid, and I was head of European Test Operations for Europe with PlayStation, we had a number of new technologies that came in and they changed the way we had to think about testing. So, I'll give you some examples. Uh, the PlayStation Move, where you had the two controllers that can control the game, uh, VR, AR, um, 3D gaming. Those four bits of technology, and I've only reeled off four, there was more. Just in three years at PlayStation, I saw how that changed testing. So, for VR and 3D, you've got to think about health and safety of the tester. Why? Because the VR has bugs in it, the 3D has bugs in it, so it makes the tester disorientated. You're wearing.. They're not doing stuff through their eyes, their true eyes, they're doing it through a screen that has bugs in it, but the screen is right up and close to their eyes. So there was motion sickness to think about. And then, of course, there was the physical space that the testers were in. You can't test VR sat at a desk, you have to stand up. Look, because that's how the end users do it. When we tested the PlayStation Move with the two controllers, we had to build physical lounges for testers to then go into to test the Move because that's how gamers were going to use the game. Uh, I remember Microsoft saying that they actually went and bought a load of prompts for the Kinect. Um, so wigs and blow-up bodies to mimic different shapes of people's bodies because the camera needed to pick up everybody's style of hair, whether you're bald like me, or whether you have an afro, the camera needed to be able to pick you up. So all of a sudden, the whole testing dynamics have changed from just being 2 plus 2 equals 4 in a field, to actually can the camera recognize a bald, fat person playing the game.
Everything changed. And this is what I mean. Now, it's performance. Uh, for VR, for augmented reality, mixed reality glasses, there's gonna be usability, there's gonna be performance, there's gonna be security. I'll give you one example if I can, Kovid. I'm walking down the road, and I'm wearing, uh, mixed reality glasses, and there's a person coming towards me in a t-shirt that I like, and all of a sudden, my pupils dilate, a bit of sweat comes out my wrist, That's data. That's collected by the wearable tech and the glasses. They know that I like that t-shirt. All of a sudden, at the top right-hand corner of those glasses, a picture of me wearing that t-shirt appears, and a voice appears on the arm and goes, "Would you like to purchase?" And I say, "Yes." And a purchase is made with no interaction with the phone. No interaction with anything except me saying 'yes' to a picture that appeared in the top right-hand corner of my phone. Performance was key there. Security was really key because there's a transaction of payments that's taken place. And usability, Kovid. If that picture appeared in the middle of the glasses, and appeared on both glasses, I'm walking out into the road in front of a bus, the bus is going to hit me, bang I'm dead because of usability. So, the world is changing how we need to think about quality and the user's experience with mixed reality, VR, AR is changed overnight.
Kovid Batra: I think I would like to go back to the point where you mentioned automation replacing humans, right? Uh, and that was a problem. And of course, that's not the reality, that cannot happen, but can we just deep dive into the testing and QA space itself and highlight what exactly today humans are doing that automation cannot replace?
Leigh Rathbone: Ooh! Okay. Well, first of all, I think there's some things that need to be said before we answer that, Kovid. So, what's in your head? So, when I think of AI, when I think of companies, and this does answer your question, actually, every company that I've been into, and I've already mentioned that I've worked in a lot, the culture, the people, the tech stack, the customers, when you combine all of those together for each company, they're unique, absolutely unique to every single company. When you blend all of those and the culture and make a little pot of ingredients as to what that company is, it's unique. So, I think point number one is I think AI will always help and assist and is a tool to help everyone, but we have to remember, every company is unique and AI doesn't know that. So, AI is not a human being. AI is not creative. I think AI should be seen as a member of the team. Now if we took that mindset, would we invite everybody who's a member of the team into a meeting, into an agile ceremony, and then ignore one member of that team? We wouldn't, would we? So, AI is a tool and if we see it as a member of the team, not a human being, but a member of the team, why wouldn't we ask AI its opinion with everything that we do as QAs, but as an Agile team? So if we roll right back, even before a feature or an epic gets written, you can use AI for research. It's a member of the team. What do you think? What happened previously? It can give you trends. It can give you trends on bugs with previous projects that have been similar. So, you can use AI as a member of the team to help you before you even get going. What were the previous risks on this project that look similar? Then when you start getting to writing the stories, why wouldn't you ask AI its opinion? It's a member of the team. But guess what? Whatever it gives you, the team can then choose whether they want to use it, or tweak it, or not use it, just like any other member of the team. If I say this is my opinion, and I think we should write the story with this, the team might disagree. And I go, "Okay, let's go with the team." So, why don't we use AI as exactly the same, Kovid, and say, "When we're writing stories, let's ask it. In fact, let's ask it to start with 'cause it might get us into a place where we can refactor that story much quicker." Then when we write code, why aren't we as devs using AI as a member, doing pair programming with it? And if you're already pair programming with another developer, add AI as the third person to pair program with. It'll help you with writing code, spotting errors with code, peer reviews, pull requests. And then, when we come to tests, use it as a member of the team. " I'm new to learning Cypress, can you help me?" Goddamn right, it can. "I've written my first Cypress test. What have I done wrong?" It's just like asking another colleague. Right, except it's got a wider sort of knowledge base and a wider amount of parameters that it's pulling from.
So for me, will AI replace people? Yes, absolutely. But not just in testing, not just in tech, AI has made things easily accessible to more people outside of tech as well. So, will it replace people's jobs? I'm afraid it will. Yes. But the people who survive this will be the ones who know how to use AI and treat it as a member of the team. Those people will be the last pots of people. They will be the ones who probably stay. AI will replace jobs. I don't care what people say, it will happen. Will it happen on a large scale? I don't know. And I don't think anyone does. But it will start reducing number of people in jobs, not just in tech.
Kovid Batra: That would happen across all domains, actually. I think that that's very true. Yeah.
So basically, I think it's more around the creativity piece, wherein if there are new use cases coming in, the AI is yet not there to make sure that you write the best, uh, test case for it and do the testing for you, or in fact, automate that piece for the coming, uh, use cases, but if the teams are using it wisely and as a team member, as you said, that's a very, very good analogy, by the way, uh, that's a great analogy. Uh, I think that's the best way to build that context for that team member so that they know what the whole journey has been while releasing an epic or a story, and then, probably they would have that creativity or that, uh, expertise to give you the use case and help you in a much better way than it could do today, like without hallucinating, without giving you results that are completely irrelevant.
Leigh Rathbone: Yeah, I totally agree, Kovid. And I think this is, um, if you think about what companies should be doing, companies should be creating new code, new experiences for their customers, value add code. If we're just recreating old stuff, the company might not be around much longer. So, if we are creating new stuff, and let's make an assumption that, I don't know, 50 percent of code is actually new stuff that's never been out there before. Well, yeah, AI is going to struggle with knowing what to do or what automation test it could be. It can have a good stab because you can set parameters and you can say, you can give it a role, as an example. So, when you're working with chatGPT, you can say, as a professional tester or as a, you know, a long-term developer, what would be my mindset on writing JavaScript code for blah, blah, blah, blah? And it will have a good stab at doing it. But if it's for a space rocket that can go 20 times the speed of light, it might struggle because no one's done that yet and put the data back into the LLM, yet.
Kovid Batra: Totally. Totally makes sense. Great. I think, Leigh, uh, with this thought, I think we'll bring our discussion to an end for today. I loved talking to you so much and I have to really appreciate the way you explain things. Great storytelling, great explanation. And you're one of the finest ones whom I have brought on the show, probably, so I would love to have another show with you, uh, and talk and deep dive more into such topics. But for today, I think we'll have to say goodbye to you, and before we say that, I would love for you to give our audience parting advice on how they should look at software quality testing in their career.
Leigh Rathbone: I think that that's a really good question. I think the piece of advice, regardless of what craft you're doing in tech, always try and think quality and always put the customer at the heart of what you're trying to do because too many times we create software without thinking about the customer. I'll give you one example, Kovid, as a parting gift. Anybody can go and sit in a contact centre and watch how people in contact centres work, and you'll understand the thing that I'm saying, because we never, ever create software for people who work in contact centres. We always think we're creating software that's solving their problems, but you go and watch how they work. They work at speed. They'll have about three different systems open at once. They'll have a notepad open where they're copying and pasting stuff into. What a terrible user experience. Why? Because we've never created the software with them at the heart of what we were trying to do. And that's just one example, Kovid. The world is full of software examples where we do not put the customer first. So we all own quality, put the customer front and center.
Kovid Batra: Great. I think, uh, best advice, not just in software testing or in general or any aspect of business that you're doing, but also I think in life you have to.. So I believe in this philosophy that if you're in this world, you have to give some value to this world and you can create value only if you understand your environment, your surroundings, your people. So, to always have that empathy, that understanding of what people expect from you and what value you want to deliver. So, I really second that thought, and it's very critical to building great pieces of software, uh, in the industry also.
Leigh Rathbone: Well, Kovid, you've got a great value there and it ties very closely with people that write code, but leaders as well. So, developers should always leave the code base in a better state than they found it. And leaders should always leave their people in a much better place than when they found them or when they came into the company. So, I think your value is really strong there.
Kovid Batra: Thank you so much. All right, Leigh, thank you. Thank you so much for your time today. It was great, great talking to you. Talk to you soon.
Leigh Rathbone: Thank you, Kovid. Thank you. Bye.
In the latest episode of the ‘groCTO: Originals’ podcast (formerly Beyond the Code), host Kovid Batra welcomes Paul Lewis, CTO at Pythian and board member at the Schulich School of Business, who brings extensive experience from companies like Hitachi Vantara & Davis + Henderson. The topic for today’s discussion is ‘Team Building 101: Communication & Innovation’.
The episode begins with an introduction to Paul, offering insights into his background. During the discussion, Paul stresses the foundational aspects of building strong tech teams, starting with trusted leadership and clearly defining vision and technology goals. He provides strategies for fostering effective processes and communication within large, hybrid, and remote teams, and explores methods for keeping developers motivated and aligned with the broader product vision. He also shares challenges he encountered while scaling at Pythian and discusses how his teams manage the balance between tech and business goals, emphasizing the need for innovation & planning for future tech.
Lastly, Paul advises aspiring tech leaders to prioritize communication skills alongside technical skills, underscoring the pivotal role of 'code communication' in shaping successful careers.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest. He has more than 25 years of engineering leadership experience. He has been a CTO for organizations like Hitachi Vantara and today, he's working as a CTO with Pythian. Welcome to the show. Great to have you here, Paul.
Paul Lewis: Hi there. Great to be here. And sadly, it's slightly more than 30 years versus 25 years. Don't want to shame you.
Kovid Batra: My bad. All right, Paul. So, before we dive into today's topic, by the way, today's topic, audience for you, uh, it's building tech teams from scratch. But before we move there, before we hear out Paul's thoughts on that, uh, Paul, can you give us a quick intro about yourself? Or maybe you would like to share some life-defining moments of your life. Can you just give us a quick intro there?
Paul Lewis: Sure. Sure. So I've been doing this for a long time, as we just mentioned. Uh, but I've, I've had the privilege of seeing sort of the spectrum of technology. First 17 years in IT, like 5, 000 workloads and 29 data centers. You know, I was involved in the purchase of billions of dollars of hardware and software and services, and then moving to Hitachi, a decade of OT, right? So, I get to see what technology looks like in the real world, the impact to, uh, sort of the human side of the world and nuclear power plants and manufacturing and hospitals.
Uh, and then, the last three years at Pythian, uh, which is more cloud and data services. So, I get to see sort of the insight side of the equation and what the new innovation and technology might look like in the real future. I do spend time with academics. I'm on the board of Schulich School of Business, Masters of Technology Leadership, and I spend time with the students on Masters of Management and AI, Masters of Business Analytics.
And then, I spend at least once a quarter with a hundred CIOs and CTOs, right? So, we talk about trends, we talk about application, we talk about innovation. So, I get to see a lot of different dimensions of the technology side.
Kovid Batra: Oh, that's great. Thanks for that quick intro. And of course, I feel that today I'm sitting in front of somebody who has immense experience, has seen that change when there was internet coming in to the point where AI is coming in. So, I'm sure there is a lot to learn today from you.
Paul Lewis: That sounds like a very old statement. Yes, I have used mainframe. I have used AS400.
Kovid Batra: I have no intentions. Great, man. Great. Thank you so much. So, let's get started. I think when we are talking about building teams from scratch. I think laying the foundation is the first thing that comes to mind, like having that culture, having that vision, right? That's how you define the foundation for any strong tech team that needs to come in. So, how do you establish that? How do you establish that collaborative, positive team culture in the beginning? And how do you ensure the team aligns with the overall vision of the business, the product. So, let's hear it from you.
Paul Lewis: Sure. Well, realistically, I don't think you start with the team and team culture. I think you start with the team leadership. I know as recent in the last three years, when we built out the Pythian software engineering practice, well, I started by bringing in somebody who's worked for me and with me for 15 years, right, somebody who I trusted, who has an enterprise perspective of maturity, who I knew had a detailed implementation of building software, who has built, you know, hundreds of millions of dollars worth of software over a period of time, and I knew could determine what skill set was necessary. But in combination with that person, I also needed sort of the program management side because this practice didn't exist, there was no sense of communications or project agility or even project management capability. So, I had to bring in sort of a program management leadership and software delivery leadership, and then start the practice of building the team. And of course, it always starts with, well, what are we actually building? You can't just hire in technologists assuming that they'll be able to build everything. It's saying, what's our technology goal? What's our technology principles? What do we think the technology strategy should be to implement? You know, whatever software we think we want to build. And from that, we can say, well, we need at least, you know, these five different skill sets and let's bring in those five skill sets in order to coordinate sort of the creation of at the very least, you know, the estimates, the foundation of the software.
Kovid Batra: Makes sense So, I think when you say bringing in that right leadership that's the first step. But then, with that leadership, your thought is to bring in a certain type of personality that would create the culture or you need people who align with your thoughts as a CTO, and then you bring those people in? I think I would want to understand that.
Paul Lewis: I'm less sure you need to decide between the two. I know my choices usually are bringing in somebody to which already knows how to manage me. Right? As you can imagine, CTOs, CIOs have personalities and those personalities sometimes could be straining, sometimes can be motivational, sometimes could be inspirational, but I knew I need to bring somebody in that didn't have to, that already knew how to communicate with me effectively, that I already know knew my sort of expectations of delivery, expectations of quality, expectations of timeliness, expectations of adhering to technology principles and technology maturity. So, they passed that gate, right? So now, I had sort of right out of the gate trust between me and the leadership that was going to deliver on the software which is sort of the first requirement. From then, then I expect them to both evolve the maturity of the practice, in other words, the documentation and technology principles and build out the team itself from scratch.
So, determine what five skills are necessary and then acquire those skills and bring them into the organization. It doesn't necessarily mean hiring. In fact, the vast majority of the software, which I've built over the time, we started with partnerships with ecosystems, right? So, ecosystems of QA partnerships and development partnerships. Bring those skill sets in and as we determine, we need sort of permanent Pythian resources like software architecture resources or DevOps architecture resources or, you know, skilled senior development that we start to hire them in our organization as being the primary decision-makers and primary implementers of technology.
Kovid Batra: Makes sense. And, uh, Paul, does this change with the type of business the org is into or you look at it from a single lens, like if the tech team is there, it has to function like this, uh, does it change with the business or not?
Paul Lewis: I think it changes based on the business objectives. So, some businesses are highly regulated and therefore, quality might be more important than others. The reality is, you know, the three triangles of time, cost, and quality. For the most part, quality is the most fungible, right? There are industries where I'm landing a plane where quality needs to be, you know, near zero bugs and then tech startups where there's an assumption that there'll be severe, if not damaging bugs in production, right, cause I'm trying to deploy a highly agile environment. So, yes, different organizations have different sort of, uh, appetites for time, cost, and quality. Quality being the biggest measure that you can sort of change the scale on. And the smaller the organization, the more agile it becomes, the more likelihood that you can do things quickly with, I'll call it less maturity, out of the gate, and assume that you can grow maturity over time.
So, Pythian is an example. Out of the gate, we had a relatively zero sense of maturity, right? No documentation, no process, no real sort of project management implementation. It was really smart people doing really good work. Um, and then we said, "Wow, that's interesting. That's kind of a superhero implementation which just has no longevity to it because those superheroes could easily win the lottery and move on." Right? So, we had to think about, well, how do we move away from the superhero implementation to the repeatable scalable implementation, and that requires process, and I know development isn't a big fan of process holistically, but they are a fan of consistency, right? They are a fan of proper decision-making. They are a fan of documented decisions so that the next person who's auditing or reviewing or updating the code knows the purpose and value of that particular code, right? So, some things they enjoy, some things they don't, uh, but we can improve that maturity over time. So, I can say every year we want to go from 0 to 1, 1 to 2, 2 to 3, never to pass 3, right, because we're not, like Pythian, for example, isn't a bank, right, isn't an insurance company, isn't a telco, we're not landing planes, we're not solving, uh, we're not solving complex, uh, healthcare issues, so we don't have to be as mature as any one of those organizations, but we need to have documents at least, right, we need to ensure that we have automation, automated procedures to push to production instead of direct access, DBA access to the database in a production environment. So, that's kind of the evolution that we had.
Kovid Batra: So, amazing to hear these kinds of thoughts and I'm just trying to capture how you are enabling your developers or how you are ensuring that your developers, your teams are aligned with a similar kind of thought. What's your style of communicating and imbibing that in the team?
Paul Lewis: We like to do that with technology principles, written technology principles. So, think of it as a, you know, top 10 what the CTO thinks is the most important when we build software. Right? So what the top 10 things are, let's mutually agree that automation is key for everything we do, right? So, automation to move code, automation to implement code, uh, automation to test, automation in terms of reporting, but that's key. Top 10 is also we need to sort of implement security by design. We need to make sure that, um, it has a secure foundation because it's not just internal users, but we're deploying the software to 2,000 endpoints, and therefore, I need to appreciate endpoints to which I don't control, there I need, therefore I need a sort of a zero trust implementation. I need to make sure that I'm using current technology standards and architectural patterns, right? I want to make sure that I have implemented such a framework that I can easily hire other people who would be just as interested in seeing this technology and using technology, and we want to be in many ways, a beacon to new technologies. I want the software we build to be an inspirational part of why somebody would want to come to work at Pythian because they can see us using an innovating current practical architectural standards in the cloud, as an example.
So, you know, you go through those technology principles and you say, "This is what I think an ideal software engineering outcome, set of outcomes look like. Who wants to subscribe to that?" And then, you see the volunteers putting up their hands saying, "Yeah, I believe in these principles. These principles are what I would put in place, or I would expect if I was running a team, therefore I want to join." Does that make sense?
Kovid Batra: Yeah, definitely. And I think these are the folks who then become the leaders for the next set of people who need to like follow them on it.
Paul Lewis: Yeah, exactly.
Kovid Batra: It totally makes sense.
Paul Lewis: And if you have a set of rules, you know, I use the word 'rules', you know, loosely, I really just mean principles, right? To say, "Here are the set of things we believe and want to be true even if there's different maturities to them. Yes, we want a fully automated system, but year one, we don't. Year three, we might." Right? So, they know sometimes it's a goal, sometimes it's principle, sometimes it's a requirement. Right? We're not going to implement low-quality code, right? We're not going to implement unsecured code, but if you have a team to buy in those principles, then they know it's not just the outcome of the software they're building, but it's the outcome of the practice that they're building.
Kovid Batra: Totally, totally. And when it comes to bringing that kind of people to the team, I think one is of course enabling the existing team members to abide by that and believe in those principles, but when you're hiring, there has to be a good talent acquisition strategy there, right? You can't just go on hiring, uh, if you are scaling, like you're on a hiring spree and you're just bringing in people. So how do you keep that quality check when people are coming in, joining in from the lowest level, like from the developer point, we should say, to the highest leadership level also, like what's your strategy there? How do you ensure this team-building?
Paul Lewis: Well, on the recruiting side, we make sure we talk about our outcomes frequently, both internally in the organization and externally to, uh, you know, the world at large. So internally, I do like a CTO 'ask me anything', right? So, that's a full, everybody's, you know, full board, everybody can access it, everybody can, and it's almost like a townhall. That's where we do a couple of things. We disclose things I'm hearing externally that might be motivating, inspiring to you. It's, "Here's how we're maturing and the outcomes we've produced in software over this quarter.", let's say. And then, we'll do a technology debate to say, "You know what, there's a new principle I need to think about, and that new principle might be generative AI. Let's all jump in and have a, you know, a reasonably interesting technology debate on the best implications and applications of that technology. So, it's almost like they get to have a group think or group input into those technology principles before we write it down and put it into the document. And then if I present that, which I do frequently externally, then I gavel, you know, whole networks of people to say, "Wow, that is an interesting set of policies. That's an interesting set of, um, sort of guiding principles. I want to participate in that." And that actually creates recruiting opportunities. I get at least 50 percent of my LinkedIn, um, sort of contributions and engagements are from people saying, "I thought what you said was interesting. That sounds like a team I want to join. Do you have openings to make that happen?" Right? So, we actually don't have in many ways a lack of opportunity, recruiting opportunity. If anything, we might have too much opportunity. But that's how we create that engagement, that excitement, that motivation, that inspiration both internally and externally.
Kovid Batra: And usually, like when everyone is getting hired in your team like, do you handpick, like at least one round is there which you take with the developers or are you relying mostly on your leadership next in line to take that up? How does that work for your team?
Paul Lewis: I absolutely rely on my leadership team, mostly because they're pretty seasoned and they've worked with me for a while, right? So, they fully appreciate what kind of things that I would expect. There are some exceptions, right? So if there are some key technologists to which I think will drive inspirational, motivational behavior or where they are implementing sort of the core or complex patterns that I think are important for the software. So, things like, uh, software architecture, I would absolutely be involved in the software architecture conversations and recruiting and sort of interviewing and hiring process because it's not just about sort of their technology acumen, it's also about their communication capabilities, right? They're going to be part of the architectural review board, and therefore, I need to know whether they can motivate, inspire, and persuade other parts of the organization to make these decisions, right? That they can communicate both verbally and in the written form, that when they create an architectural diagram, it's easy to understand, sort of that side, and even sort of DevOps-type architects where, you know, automation is so key in most of the software we develop and that'll lead into, you know, not just infrastructure as code, but potentially even the AI deployment of infrastructure as code, which means not only do they need to have, you know, the technical chops now, I need them to be well read on what the technical jobs are needed for tomorrow. Right? That also becomes important. So, I'll get involved in those key resources that I know will have a pretty big impact on the future of the organization versus, you know, the developers, the QAs, the BAs, the product owners, the project managers, you know, I don't necessarily involved in every part of that interview process.
Kovid Batra: Totally, totally. I think one good point you just touched upon right now is about processes and the communication bit of it. Right? So, I think that's also very critical in a team, at least in large-scale teams, because as you grow, things are going hybrid, remote, and even then, the processes are, and the communication is becoming even more critical there, right? So, in your teams, how do you take up or how do you ensure that the right processes are there? I mean, you can give some examples, like how do you ensure that teams are not overloaded or in fact, the work is rightly distributed amongst the team and they're communicating well wherever there is a cross-functional requirement to be delivered and teams are communicating well, the requirements are coming in? So, something around process and communication which you are doing, I would love to hear that.
Paul Lewis: Good questions. I think communication is on three fronts, but I'll talk about the internal communication first, the communication within the teams. We have a relatively unique set of sort of development processes that are federated. So, think of it as there is a software engineering team that is dedicated to do software engineering work, but for scale, we get to dip into the billable or the customer practices. So, if I need to deliver an epic or a series of stories that require more than one, uh, Go developer or data engineer or DevOps practitioner, then I have the ability to dip into those resources, into those practices, assign them temporarily to these epics and stories, uh, or just a ticket that they, that I want them to deliver on and then they can deliver on them as long as it's all, as long as everybody's already been trained on how to implement the appropriate architectural frameworks and that they're subscribing to the PR process that is equivalent, both internally and externally to the team. We do that with standard agile processes, right? We do standups on a daily basis. We break down all of our epics in the stories and we deliver stories in the tickets and tickets get assigned people, like this is a standard process with standard PM, with standard architectural frameworks, standard automation, deployments, and we have specific people assigned to do most of the PRs, right? So not only PR reviews, but doing sort of code, code creation and code deployment so that, you know, I rely on the experts to do the expert work, but we can reach out into those teams when we need to reach out to those teams and they can be temporary, right? I don't need to assign somebody for an entire eight-week journey. Um, I could just assign them to a particular story to implement that work, which is great. So, I can expand any one particular stream from five people to 15 people at any one period of time. That's kind of the internal communication.
So, they do standups. We do, you know fine-tuned documentation, uh, we have a pretty prescriptive understanding of what's in the backlog and how and what we have to deliver in the backlog. We actually detail a one-year plan with multiple releases. So, we actually have a pretty detailed, we'll call it 'product roadmap' or 'project roadmap' to deliver in the year, and therefore, it's pretty predictable. Every eight weeks we're delivering something new to production, right? But that's only one of those communication patterns. The other communication patterns all to the other internal technology teams, because we're talking about, you know, six, seven hundred internal technologists, and we want them to be aware of not just things that we've successfully implemented in the past and how it's working in production, but what the future looks like and how they might want to participate in the future functions and features that we deliver on.
But even those two communication patterns arguably isn't the most important part. The most important part might actually be the communication up. Right? So now, I have to have communication on a quarterly basis with my peers, with the CEO and the CFO to say not only how well we're spending money, how well we're achieving our technological goals and our technological maturity, but even more importantly, are we getting the gain in the organization? So, are we matching the revenue growth of the organization? Are we creating the operational efficiency that we expect to create with the software, right? Cause I have to measure what I produce based on the value created, not just because I happen to like building software, and that's arguably the most difficult part, right, to say, "I built software for a purpose, an organizational purpose. Am I achieving the organizational goals?" Much more difficult calculus as compared to, "I said I was going to do five features. I delivered five features. Let's celebrate."
Kovid Batra: But I think that's the tricky part, right? And as you said, it's the hardest part. How do you make sure, like, as in, see, the leaders probably are communicating with the business teams and they have that visibility into how it's going to impact the product or how it's going to impact the users, but when it comes to the developers particularly, uh, who are just coding on a day-to-day basis, how do you ensure that the teams are motivated that way and they are communicating on those lines of delivering the outcomes, which the leaders also see? So, that's..
Paul Lewis: Well, they get to participate in the backlog prioritization, right? So, in fact, I like to have most of the development team consider themselves in many ways, owners of the software. They might not have the Product Owner title, or they might not be the Product Manager of the product, but I want them to feel like it's theirs. And therefore, I need them to participate in architectural decisions. I want them to buy-in to what the priority of the next set of features are going to be. I want to be able to celebrate with them when they do something successful, right? I want them to be on the forefront of presenting the value back to the rest of the team, which is why that second communication to the rest of the, you know, six or seven hundred technologists that they're the ones presenting what they created versus I'm the one presenting their credit. I want them to be proud of the code that they've built, proud of the feature that they've implemented and talk about it as if it's something that they, you know, had to spend a good portion of their waking hours on, right? That there was a technology innovation or R&D exercises that they had to overcome. That's kind of the best part. So, they're motivated to participate in the, um, in the prioritization, they're motivated to implement good code, and then they're motivated to present that as if it was an offering they were presenting to a board of decision-makers, right? It's almost as if they're going and getting new money to do new work, right? So, it's a dragon's den kind of world, which I think they enjoy.
Kovid Batra: No, I think that's a great thought and I think this makes them feel accountable. This makes them feel motivated to whatever they are doing, and at the end of the day, if the developers start thinking on those lines, I think you have cracked it, probably. That's the criteria for a successful engineering, for sure.
Apart from that, any other challenges while you were scaling, any particular example from your journey at Pythian that you felt is worth sharing with our audience here?
Paul Lewis: The challenge is always the 'what next?'. Right? So let's say, it takes 24 months to build a substantial piece of software. Part of my job, my leadership's job is to prepare for the next two years, right? So, we're in deep dive, we're in year one, we're delivering, we're halfway delivering some interesting piece of software, but I need to prep year three and year four, right? I need to have the negotiations with my peers and my leaders to say, "Once we complete this journey, what's the next big thing on the list? How are we going to articulate the value to the organization, either in growth or efficiency? How are we going to determine how we spend? Is this a $1m piece of software, or is this a $10m piece of software?" And then, you know, preparing the team for the shift between development to steady state, right? From building something to running something. And that's a pretty big mindset, as you know, right? It's no longer focused on automation of releases between dev, QA & production. It's saying, "It's in production now. It's now locked down. I need you to refocus on development on something else and let some other team run this system." So, both sides of that equation, how do I move from build to run in that team? And then, how do I prepare for the next thing that they build?
Kovid Batra: And how do you think your tech teams contribute here? Because what needs to be built next is something that always flows in, in terms of features or stories from the product teams, right? Or other business teams, right? Here, how do you operate? Like, in your org, let's say, there is a new technology which can completely revamp the way you have been delivering value so that tech team members are open to speak and like let the business people know that this is what we could do, or it's more like only the technical goals are being set by the tech team and rest of the product goals are given by the product team. How does it work for the, for your team here?
Paul Lewis: It's pretty mutual in fairness, right? So, when we determine sort of the feature backlog of a piece of software, there's contribution for product management, think of that as the business, right? And the technology architecture team, right? So, we mutually determine what our next bet in terms of features that will both improve the application, functionally improve the application technically. So, that's good.
When it comes to the bigger piece of software, so we want to put this software in steady state, do minor feature adjustments instead of major feature adjustments, that's when it requires much more of a, sort of a business headspace, right? Cause it's less about technology innovation at that point. However, sometimes it is, right? Sometimes I'll get, "Hey, what are we doing for generative AI? What new software can we build to be an exemplar of generative AI?" And I can bring that to the table. So, I have my team bringing to the decision-making table of, "Here's some technology innovation that's happening in the world that I think we should apply." And then, from the business saying, "Here's a set of business problems or revenue opportunities that we can match." So now, it's a matching process. How can I match generative AI, interesting technology with, you know, acquiring a new customer segment we currently don't acquire now, right? And so, how do I sort of bring both of those worlds together and say, "Given this match program, I'm going to circle what I think is possible within the budget that we have."?
Kovid Batra: Right. Right. And my question is exactly this, like, what exactly makes sure that the innovation on technology and the requirements from the customer end are there on the same table, same decision-making table? So, if I'm a developer in your team, even if I'm well aware of the customer needs and requirements and I've seen certain new technologies coming up, trending up, how do I make sure that my thought is put on the right table in front of the right team and members?
Paul Lewis: Well, fortunately, like most organizations, but definitely Pythian, we've created like an architectural review board, right? So, that includes development, architecture, product management, but it's not the executive team, right? It's the real architectural practitioners and they get to have the debate, discussion on what they think is the most technologically challenging that we want to solve or innovation that we think matters or evolution of technology that we think we want to implement within our technologies, moving from, you know, an IaaS to a PaaS to a Saas, as an example, those are all decisions that in many ways we let the technology practitioners make, and then they bring that set of decisions to the business to say, "Well, let's match this set of architectural principles with a bunch of business problems." Right? So, it's not top-down. It's not me saying, "Thou shalt build software. Thou shalt use Gen AI. Make it so." It rarely is that. It's the technology principle saying, "We think this innovation is occurring. It's a trend. It's important. We think we should apply it knowing its implications. Let's match that to one of a hundred business problems to which we know the business has, right? The reality is the business has an endless amount of technology problems, of business problems. Technology has an endless amount of innovation, right?
Kovid Batra: Yeah, yeah.
Paul Lewis: There's no shortlist in either of those equations.
Kovid Batra: Correct. Absolutely. Perfect, perfect. I think this was great. I think I can go on talking with you. Uh, this is so interesting, but we'll take a hard stop here for today's episode and thank you so much for taking out time and sharing these thoughts with us, Paul. I would love to have you on another show with us, talking about many more problems of engineering teams.
Paul Lewis: Sure.
Kovid Batra: But thanks for today and it was great meeting you. Before you leave, um, is there a parting advice for our audience who are mostly like aspiring engineering managers, engineering leaders of the modern tech world?
Paul Lewis: Um, the gap with most technologists, because they tend to be, you know, put their glasses on, close the lights in the room, focus on the code, that's amazing. But the best part of the thing you develop is the communication part. So, don't be just a 'code creator', be a 'code communicator'. That's the most important part of your career as a developer, is to present that wares that you just built outside of your own headspace. That's what makes the difference between a junior, an intermediate, senior developer and architect. So, think about that.
Kovid Batra: Great, great piece of advice, Paul. Thank you so much. With that, we'll say, have a great evening. Have a great day and see you soon!
Paul Lewis: Thank you.
In the latest episode of 'groCTO Originals' podcast (formerly: 'Beyond the Code'), host Kovid Batra engages in a thought-provoking discussion with Jacob Singh, Chief Technology Officer in Residence at Alpha Wave Global. He brings extensive experience from his roles at Blinkit, Acquia, and Sequoia Capital. The heart of their conversation revolves around ‘Enhancing DevEx, Code Review and Leading Gen Z’. https://youtu.be/TFTrSjXI3Tg?si=H_KxnZGlFOsBtw7Y The discussion begins with Jacob's reflection on India and his career break. Moving on to the main section, he explores the evolving definition and widespread adoption of developer experience. He also draws comparisons between tech culture in Indian versus Western companies and addresses strategies for cultivating effective DevEx for Gen Z & younger generations. Furthermore, he shares practical advice for tech leaders to navigate the ‘culture-market fit’ challenge and team structuring ideas from his hands-on experience at Grofers (now ‘Blinkit’). Lastly, Jacob offers parting advice to developers and leaders to embrace AI tools like Copilot and Cursor for maximizing efficiency and productivity, advocating for investing in quality tooling without hesitation.
Kovid Batra: Hi, everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest. He's currently a CTO in Residence with Alpha Wave Group, which is a VC group. He comes with 20-plus years of engineering and leadership experience. He has worked with multiple startups and orgs like Blinkit as a CTO. He's the guest whom I have met and he's the only guest whom I have met in person, and I really liked talking to him at the SaaSBoomi event. Welcome to the show, Jacob. Great to have you here.Jacob Singh: Thanks. Good to be here, to chat with you.Kovid Batra: Cool. I think, let's start with something very unique that I've seen experienced with you, that is your name. It's Jacob Singh, right? So, how did that fusion happen?Jacob Singh: Just seemed like fun, you know? Just can't, since I was living in India anyway, I figured Smith is harder to pronounce, so.. I'm just kidding. My dad's from here. My dad's Punjabi. So, you know, when a brown boy and a white girl, they love each other a lot, then, you know, you end up with a Jacob Singh. That's about it. There's not much else to it. I grew up in the States, but I've lived in India on and off for the past 20 years.Kovid Batra: Great, great. Perfect. That's rare to see, at least in India. Most of the generation, maybe half-Indian, half-American are in the U.S. But what did you love about India? What made you come here?Jacob Singh: Good question. I was trying to escape my tech stuff. So, I sort of started very early. I taught myself to code as a teenager and started my first business when I was 18 and I'd done pretty well. And then, when I was like 21-22, I just sort of decided I wanted to do something different, do something in the social sector, helping people. So, I took a job with an NGO in West Delhi and sort of shifted for that. That was the original purpose. Why did I stay? I guess there's something dynamic and interesting about the place. India's changed a lot in 20 years, as everybody knows. And, I think that's been continuously exciting to be a part of. It doesn't feel stagnant. It doesn't feel like, I mean, a lot of changes are not in the direction I would love, to be honest, but, you know, but it's an interesting place. There's always something happening. And I found that, and then eventually you build your community, your friends and your family and all that kind of stuff. So, this is home. Yeah, that's about it.Kovid Batra: Perfect. Perfect. Talking about the family, I was just talking to you on LinkedIn. I found that there was like a one-year break that you took in your career and you were just parenting at that time. And honestly, that's very different and very unique to a culture, to an Indian culture, actually. So, I just wanted to know how was your experience there. I'm sure it would have made you learn a lot of things, as it does for a lot of other parents. But I just wanted to hear about your experience with your kid.Jacob Singh: Hopefully, it's not so uncommon. I think it's starting to change especially the role of men as fathers in India. I think it's traditionally, like my dad's father, he just saw him for tea, you know, and he was reading the newspaper and he'd meet him once a year on his birthday and take him to a quality restaurant for a coke, you know, that was their relationship. I think things are different with Indian fathers these days. I think for me, you know, we were just, perfectly honest, was going through a divorce. Difficult. I needed to be there for my daughter and I was, you know, sort of taking half the responsibility in terms of time with her. This was eight years ago. And I think my parents had also divorced. So, I was kind of, my dad was a very active part of my upbringing and did all the things, did all the dishes, cooked all the meals, you know, was around. He was also working as a programmer and did all that, but he was at home as well. And he found ways to make it work, even if it had meant sacrificing his career to some extent. He was working from home when I was a kid in the 80s. So, he had a giant IBM 880, or whatever computer, a little tiny green screen, a 300-bot modem, you know, to connect and send his work up. So, that's how I grew up. Turned out to benefit me a lot, uh, when it came to learning computers, but, um, you know, he would convince him to do that cause he was good at his job, and he's like, I have to be there for my kids. And he made it work, you know? I think we all find those times where we need to lean into family or lean into work in different proportions, you know?Kovid Batra: Hmm. Great. I think amazing job there honestly, Jacob All right, that was great knowing you and thanks for that quick intro. Moving on to the main section of our today's podcast, enhancing the developer experience. So, that's our topic for today. So let's start very basic, very simple. What is developer experience according to you?Jacob Singh: What is developer experience? It's an interesting term. I guess it's, you know, the day-to-day of how a programmer gets their job done. I guess the term would be everything encapsulated from, how their boss talks to them, how they work with their teammates, the kind of tools they use for project management down to the quality of documentation, APIs, the kind of tools they use on their computer, the tools they use in the cloud that they work with, et cetera. And all of that encapsulated is how effective can they be at their job, you know, and the environment around them that allows them to be effective. I guess what I would define it as.Kovid Batra: And why do you think it's trending so much these days? I think what you mentioned and what I have also read everywhere about developer experience is the same fundamental that has been existing all the years, right? But why is it trending these days? Why do you think this is something up in the market?Jacob Singh: Good question. I guess, I mean, I've been around for a while, so I think in the earlier days of the industry, when I first started engineers were a little expensive, but they were also looked at as like a commodity that you could just use. Like, you put them on a spreadsheet, you pay the engineers, you get the work done. They weren't considered really central. They were considered sort of like factory workers in an expensive factory, to some extent. I think it was more so in the 80s and 90s, right? But like, it's still trending more and more in the direction of engineers kind of being very expensive and being decision-makers, moving into C-level positions, having more authority, seeing that, like, if you just look at, you know, the S&P 500, you look at the, you look at the stock market and you see that the top companies are all tech companies and they command most of the market cap. I think those days are over. So now, it's very much that if you're able to execute with your engineering roadmap, you're able to win the market. It's considered the basis of a lot of companies, sort of strategies, whether they're a tech company or not, and therefore the effectiveness of the developers and the team plays into which developers will join you. And when they join you, how likely are they to be engaged and to be retained? And then, how effective, you know, is each developer because they're a rare commodity because it's hard to find good developers. There's so much demand, et cetera, even in recessionary times, most of the layoffs are not engineering teams. And so, the effectiveness of each engineer and their ability to motivate and retain them becomes paramount to a company strategy.Kovid Batra: Right. Makes sense. So, according to you, I'm sure you have had the experience of seeing this shift in the West as well as in companies in India, right? When you see the culture, particularly talking about the tech culture in a company, like maybe, for example, you work with a company like Blinkit, which is huge today in India and you must have worked with other companies in the West. How would you compare, like, how are teams being led in these two different cultures? Jacob Singh: Well, I would say those kind of, you know, anything I say is going to be a gross generalization, and it's going to be incorrect more often than it's correct. I think there's more difference between two Indian companies than there is between any given American or any Indian company, you know. There's a lot of variation. But if I'm being put on the spot to make such generalizations, I would say that one big difference is the age and maturity of engineers. So, like, when I was 29, I got hired as an IC, a Principal Engineer at this company called Acquia. They kind of acquired my startup and I joined there, and, you know, we had PhDs on the team who were ICs, right? Our VP Engineering, you know, had 25 years of experience in the field and was, you know, sort of. You know, one of my colleagues was like heading R&D for the RFID team at Sun. You know, like the very senior guys were still writing code.Kovid Batra: Yeah.Jacob Singh: It's like, very much just like in the weeds writing code. They're not trying to be managers and an architect. They're just like a programmer, right? I got my first team, like to manage, like I got a small team like at 25-26, but really I got my first team of like really qualified, expensive engineers when I was like 32. Whereas here, I'm a VP Engineering at Grofers at like 29. It's like managing a 100 people. It's very common to be much early in your career. Engineers with 3-4 years of experience are sort of talking about, "I should be an SDE-IV". So, the whole like, that scale is different. You have a much younger audience. In the States, at least when I was coming up, there's a lot more earning your stripes over a long time before you go into management. Whereas here, we have a lot more very junior managers. I think that's a big difference.Kovid Batra: Okay. And that's interesting, actually.Jacob Singh: That creates a lot of other dynamics, right? I mean, you just have like, generally you know, you have more, I would, and I hate to say this, probably going to take shit for this, but having been an engineering leader in both places, I feel like you have more like discipline and like professionalism issues here, generally, which is not to do with Indians. It's just to do with the age of people. Like, they're 24 years old, they're not gonna be very professional, right? Like a lot of your team.Kovid Batra: No, totally. I think, we are not generalizing this, but as you said, it's probably about the age. In one of my podcasts, I was just talking to this fellow from Spain. He's leading a team of almost 30 folks now.Jacob Singh: Yeah.Kovid Batra: And 50% of them were early hires, like early 20 hires, right?Jacob Singh: Yeah.Kovid Batra: And he's that guy. And then I was talking to somebody in India who was leading a 50-member team there. Again, 50% of the folks were like junior engineers in their 25-26. And both of them had the same issue of handling Gen Zs. So, I think from where you are coming, it's totally relatable and I think we touched on a very good topic here. How to create a good developer experience for these early-age, 25-26-year-olds in the system? Because they're not stable, they are not, So again, I am also not generalizing. A lot of good folks are there, but they're not like in the right mindset of sticking to a place, learning gradually and then making that impact. They just like really want to hop on fast on everything.Jacob Singh: Yeah.Kovid Batra: So, how do you handle that? Because that definitely is a pain for a lot of us, not just in India, but across the globe.Jacob Singh: No, no, I've heard this a lot, you know, and I'm not really sure. I mean, I'm far from Gen Z. I was actually having this exact same conversation with the CTO of an Indian unicorn, a pretty large one, who was talking about the same thing. He's like, "How do I motivate these?" This seems like the younger guys, they don't really want to work and they're constantly, you know, making noise and they think it's their right to work from home. They think it's their right to work 20-30 hours a week. They don't want, they don't want to advance and follow all this sort of stuff. I guess my advice to him was maybe a bit generic and maybe incorrect. You know, I think there are differences in generations, but I think some truths are fairly universal and I've uncovered a couple of things which have worked for me. And every manager has their own style and because of that, and every company has its own culture and its own goals. And so, there's a thing that's 'culture-market fit'. So, certain leaders will do well in certain kinds of companies, right, who have certain kinds of cultures made for the market they're in. This is not generic advice for everybody. But for me, I like to work in startups and I like to work in you know, startups, which are working on, I would say, kind of top-line problems which means not efficiency-related problems so much as innovation-related problems. How do we discover the next big thing? What feature is going to work with customers? Et cetera. And in such places, you need people who are motivated by intrinsic, they need intrinsic creative motivation. Carrot and Stick stuff doesn't work. Carrot and Stick will work for a customer service team, for a sales team, it'll work for an IT team at a Fortune 500 who's shipping the same things over and over again, but for creative teams, they really need to care about it intrinsically. They need to be interested in the puzzle. They want to solve the puzzle. You can't sort of motivate them in other ways. And I think this applies to the younger generation as much as the older ones. You know, the best thing to do is to, basically, it's a very simple formula, it sounds cliché but figure out where the hell you're going, why you should go there and everyone in the team should know where you're going and they should know why they're important to that strategy, what they're doing that's important, you know, and they should believe it themselves that it can work. And then, they should believe that if it works, you're gonna take care of them. And if you solve those things, they will work hard and they will try to solve problems. A lot of companies think they can shortchange that by having a crappy strategy, by having, you know, a lot of program management, which removes people from the real problem they're solving by treating people as numbers on a spreadsheet, naturally, you're going to get, you know, poor results when you do that.Kovid Batra: Totally. I think very well answered, Jacob. I think finding that culture-market fit and finding the place where you will also fit in naturally, you would be easily able to align with the folks who are working there and maybe lead them better. I think that that analogy is really, really good here. Apart from that, do you think like not everyone gets that opportunity to find the right place for themselves, right, when there is a dearth of opportunities in the market? What would be the advice for the leaders that they should apply to them when they are not in the culture-market fit scenario?Jacob Singh: Leaders? You mean, if a leader is in an organization where they don't feel like the values of the tech team aligned to their value, whether it be engineer or CTO or something?Kovid Batra: Correct, yes.Jacob Singh: Good question. The best thing to do is probably to quit. But if you can't afford, I mean, I say that a bit flippantly. I'm not saying "quit early". I'm not saying "don't try". I mean, if you really have a true values alignment problem you know, then that's hard to get over. If it's tactical, if it's relationship-based, you can work on those things, right? If you feel like you have to be someone you don't like to fit in an organization, then that's unlikely to change if it comes from the top, right? There's a very cliché saying, but you know, "Be careful who you work with. You're more likely to become them than they are to become you." And so, I would say that. But to get more practical, let's say if you can't, or you're feeling challenged, et cetera. Your question was basically, okay, so let's say you're a VP Engineering or Director of Engineering and you're unhappy with the leadership in some way, right?Kovid Batra: Yeah. So, no, I think it makes sense. The advice is generic, but it definitely gives you the direction of where you should be thinking when you are stuck in such a situation. You can't really fight against it.Jacob Singh: Yeah. I will say a couple of things. This is also the same conversation I had mentioned earlier. This also came up with the typical thing of leadership not trusting tech. You know, they don't think we're doing anything. They think we're moving too slow. They think we're, you know, sandbagging everything, etc. And to solve that, I think, which is not a values problem. That's the case in almost every organization. I mean, there's never been a CEO who said, "Oh, man! The tech team is so fast. They just keep.. I can't come up with dumb ideas fast enough. They keep implementing everything." So, you know, it's never happened in the history of companies. So, there's always that conflict which is natural and healthy. But I think to get over that, that's basically a transparency problem, usually. It's like, are you clear on your sprint reviews? Do you do them in public? Do you share a lot of information around the progress made? Do you share it in a way that gets consumed or not? Are you A/B testing stuff? Are you able to look at numbers? Able to talk numbers with your business teams? Do you know the impact of features you're releasing? Can you measure it? Right? If you can measure it, release that information. If you can give timely updates in a way which is entertaining and appropriate for the audience that they actually listen those problems tend to go away. Then it's just, the main problem there is not that people don't trust you. It's just that you're a black box to them. They don't understand your language. And so, you have to find, you know, techniques to go over that. Yeah.Kovid Batra: Yeah. Makes sense. Great, great. All right, coming back to enhancing the developer experience there. So, there are multiple areas where you can see developer experience taking a hit or working well, right? So, which are those areas which you feel are getting impacted with this enhancement of developer experience and how you have worked upon those in any one of your experiences in the past with any of the companies?Jacob Singh: You said "enhancement of developer experience". What do you mean by that?Kovid Batra: So, yeah. I'll repeat my question. Maybe I confused you with too many words there. So, in your previous experiences, you must have worked with many teams and there would have been various areas that could have impacted the developer experience. So, just to give you a very simple example, as you talked about the tooling, the people whom they're working with. So, there could be multiple issues that impact the developer experience, right? So, in your previous experiences where you found out a specific developer experience related problem and how you solved it, how it was impacting the overall delivery of the development team. Just want to like deep dive into that experience of yours.Jacob Singh: Yeah. So I think a big one was I can talk about Grofers. So, one of the things we had when I first came to Grofers, we had about 50-60 people in tech, product engineering, data, design, etc. We had them into different pods. That was good. Someone had created like different teams for different parts of the application. So, it wasn't just a free-flowing pool of labor. There was the, you know, the shopping cart team and the browsing team and the supply chain, like the warehouse management team, the last mile team, it was like, you know, four or five teams. But there was a shared mobile team. So at the front end, there was, there was one Android team, there was one iOS team, there was one web team, which again, is very common, not necessarily a bad idea. But what ended up happening was that the business teams would, they wouldn't trust the tech deadlines because a lot of times what happened is there'd be a bunch of backend engineers in the shopping cart team, they'd finish something, and then they'd be stuck on the front end team because the front end team was working on something for the, or the Android team was working on something for the browsing team, right? The iOS team was free, so they would build that shopping cart feature. But they couldn't really release it yet because the releases had to go out together with Android and iOS, because, you know, the backend release had to go with that. So, we're waiting on this one. Then we're waiting on the web one. There's this cascading waiting that's happening. And now, the shopping cart team is like, "We're done with our part. We're waiting on Android. So we're going to start a new feature." They start a new feature. And then again, the problem starts again where that feature is then waiting on somebody else, waiting on the QA team or waiting on somebody else. So, all of these waiting aspects that happen ruin the developer experience because the developer can't finish something. They get something half done, but it's not out in production, so they can't forget about it. Production is a moving target. The more teams you have, the more frequently it's changing. So, you have to go back and revisit that code. It's stale now. You've forgotten it, right? And you haven't actually released anything to customers. So, the business teams are like, "What the hell? You said you're done. You said you'd be done two weeks ago." And you're like, "Oh, I'm waiting for this team." "Stop giving me excuses." Right?Kovid Batra: Right.Jacob Singh: That team's waiting on the other team. So, I think one of the big things we did was we said, we took a hard call and said, at the time, Grofers was not quick commerce. At that time, Grofers was like DMart online, cheap discounting, 2-3 day delivery, and we scaled up massively on that proposition. And, uh, we said, hey, people who care about the price of bread being 5% less or more, do they own iPhones? No, they do not own iPhones. That's like 5% of our population. So we just ditched the iPhone team, cross-trained people on Android. We took all the Android engineers and we put them into the individual teams. We also took QA, automated most of our tests, and put QA resources into each of the teams, SDATs, and kind of removed those horizontal shared services teams and put them in fully cross-functional teams. And that improved developer experience a lot. And it's kind of obvious, like people talk about cross-functional teams and being able to get everything done within a team, being more efficient, less waiting for the teams, but it has another huge benefit. And the other huge benefit is motivation-wise. You cannot expect, like I said earlier, you want your engineers to care about the business outcomes. You want them to understand the strategy. They don't understand why they're building it. But if an engineer has to build something, send it to another team, get that team to send it to some other team, get that team to send it to some other team, to a release team to get released eventually, right? And then, the results come back three months later. You can't expect that engineer to be excited about their metrics, their business metrics and the outcomes.Kovid Batra: Right.Jacob Singh: If you put everyone in one team, they operate like a small startup and they just continually crank that wheel and put out new things, continually get feedback and learn, and they improve their part of the business and it's much more motivating and they're much more creative as a result. And I think that changes the whole experience for a developer. Just reduces those loops, those learning loops. You get a sense of progress and a sense of productivity. And that's really the most motivating thing.Kovid Batra: Totally makes sense. And it's a very good example. I think this is how you should reshape teams from time to time based on the business requirements and the business scale is what's going to impact the developer experience here. But what I'm thinking here is that this would have become a very evident problem while executing, right? Your project is not getting shipped and the business teams are probably out there standing, waiting for the release to happen. And you started feeling that pain and why it is happening and you went on solving it. But there could be multiple other issues when you scale up and 50-60 is a very good number actually. But when you go beyond that, there are small teams releasing something or the other on an everyday basis. How exactly would you go about measuring the developer experience on different areas? So, of course, this was one. Like, your sprints were delayed or your deliverables were delayed. This was evident. But how do you go about finding, in general, what's going on and how developers are feeling?Jacob Singh: Well, we hit those scaling things and like you said, yes, people are delayed. It sounds obvious, but it's mostly not. Most leaders actually take exactly the opposite approach. They say, "Okay. No more excuses. We're going to plan everything out at the beginning of the quarter. We're going to.. You plan your project. We'll do all the downstream mapping with every other Android, iOS, QA team required. We'll allocate all their bandwidth ahead of time. So, we'll never have this problem again. And we'll put program managers in place to make sure the whole thing happens." They go the opposite direction, which I think is kind of, well, it never works, to be honest. Kovid Batra: Yeah, of course.Jacob Singh: In terms of measuring developer experience as you scale. So, we got up to like 220 people in tech I think at some point in Grofers and we scaled up very quickly. That was within a year and a half or something, that happened. And, you know, that became much more challenging. I honestly don't love the word 'developer experience' cause it doesn't mean anything specifically cause there's sort of your experience as an employee, right, HR kind of related stuff, your manager or whatever, there's your experience, you know, as an engineer, like the tools you're using and stuff like that, right? And then your experience, like, as a team member, like your colleagues, your manager, your kind of stuff like that, right? So it's slightly different from an employee in terms of, it's not about company confidence and stuff or strategy, but more about your relationships. So, there's different areas of it. For measuring, like, general satisfaction, we use things like Officevibe, we use things like continuous performance improvement tools, like 15Five. we brought in OKRs, a lot of things which kind of are there to connect people to strategy and regularly check in and make sure that we're not missing things. All of those were effective in pockets, depending on usage. But by far the most effective thing, and I know this might not be the popular answer when it comes to what type of sells, although I do like the product a lot, which is why I'm doing this. I think it's a cool product. A lot of it is really just like 1-on-1s, just making sure that every manager does a 1-on-1 every two weeks. And making it like, put it in some kind of spreadsheet, some kind of lightweight thing, but making sure that new managers learn they have to do it, how to do them well, how to, you know, connect with individuals, understand their motivations and like follow through on stuff and make small improvements in their lives. Like, that's the cheat code. It's just doing the hard work of being a manager, following through with people, listening to them. That being said, data helps. So, like, what you guys have what you guys built, I've built small versions of that. I wrote a script which would look at all the repositories, see how long things are sitting in PR, look at Jira, see how long things are sitting in wait. You know, build continuous flow sort of diagrams, you know, sort of just showing people where your value, team is getting stuck. I've, like hand-coded some of that stuff and it's been helpful to start conversations. It's been helpful to convince people they need to change their ideas about what's happening. I think those are some of the ideas.Kovid Batra: Thanks for promoting Typo there. But yeah, I think that also makes sense. It's not necessary that you have to have a tooling in place, but in general, keeping a tab on these metrics or the understanding of how things are flowing in the team is critical and probably that's from where you understand where the developer experience and the experience of the team members would be impacted. One thing you mentioned was that you scaled very rapidly at Grofers and it was from 50 to 250, right? One interesting piece, I think we were having this discussion at the time of SaaSBoomi also the code review experience, right? Because at that scale, it becomes really difficult to, like even for a Director of Engineering to go into the code and see how it is flowing, where things are getting stuck. So, this code review experience in itself, I'm sure this impacts a lot of the developer experience piece, so to say. So, how did you manage that and how it flowed there for you?Jacob Singh: Well, one is I didn't manage it directly. So, like Grofers is big enough that I had a Director of Engineering sort of, or VP Engineering for different-different divisions. And that level of being hands-on in terms of code reviews, I wouldn't really participate in other than like, you know, sometimes as an observer, sometimes to show proof, if we're doing something new, like we're doing automation, I might whip up some sample code, show people, do a review here and there for a specific purpose about something, but never like generally manage those, like, look at that. Grofers was really good this way. I think we had a really good academic culture where people did like public code reviews. There wasn't this like protection shame kind of thing. It was very open. We had a big open-source culture. We used to host lots of open-source meetups. There was a lot of positive sort of view of inquiry and learning. It wasn't looked at as a threatening thing, which in a lot of organizations is looked at as a threatening kind of thing. And the gatekeeping thing, which I think we try to discourage. I think we had a lot of really positive aspects of that. Vedic Kapoor was heading DevOps and Security infrastructure stuff that I work with a lot. He's consulting now, doing this kind of work. He did a lot of great, sort of workshops and a lot of like a continuous improvement program with his teams around this kind of stuff where they do public reviews every so often every week or whatever. The DevOps teams made a big point of being that service team for the engineer so they would kind of build features for engineers. So, we had a developer experience team, essentially, because we were that size. Well, the review process, generally, I mean, I gave this rant at SaaSBoomi, and I think I've given it often. I think PRs are one of the worst things that's happened to software engineering, in the last 20 years.Kovid Batra: Yeah, you mentioned that.Jacob Singh: Yeah, and I think it's a real problem. And it's this funny thing where everyone assumes that progress moves forward and it never goes backwards. And then they, the younger generation doesn't necessarily believe that it could have been better before. But I'll tell you the reason why I say that is that, you know, Git was created by Linus, by the creator of Linux because they needed, well, they needed something immediately, but also they needed something which would allow thousands and thousands of people working at different companies with different motivations to all collaborate on the same project. And so, it's the branching and the sub branching and the sub-sub branching which Git allowed people to simultaneously work on many different branches and then sort of merge them late and review them in any order they wanted to and discuss them at length to get them in and had to be very secure and very stable at the end of the day. And that made a lot of sense, right? It's very asynchronous and things take a very long time to finish. That's not how your software team works. You guys are all sitting on the same table. What are you doing? Like, you don't need to do that. You can just be like, "Hey, look at this, right? There's a different way to do it." Even if you're on a remote team, you can be like, "Let's do a screen share." Or, "Can I meet you tomorrow at two or whatever, and we'll go through this." Or like, "I had some ideas, paste it in Slack, get back to me when you can." You know, "Here's my patch." Whatever. And I think what ends up happening is that this whole, the GitHub, and for open-source projects, it's huge. Git is amazing. Pull requests are amazing. They've enabled a lot. But if you are a team where you all kind of work on the same codebase, you all kind of work closely together, there's no reason to send up this long asynchronous process where it can take anywhere between a couple of hours to, I've seen a couple weeks to get a review done. And it creates a log jam and that slows down teams and that reduces again, that loop. I'm big on loops. Like, I think you should be able to run your code in less than a second. You should be able to compile as quickly as possible. You should be able to test things as quickly as possible that you should be able to get things to the market and review them as quickly as possible. You should get feedback from your colleague as soon as possible. And like, I think a lot of that has gotten worse. So, engineers like learn slower and they're waiting more, they're waiting for PRs to get reviewed, there's politics around it. And so, I think that that process, probably should change. More frequent reviews, pairing you know, sort of less formal reviews, et cetera. Yeah, and TDD if you can do it. It's kind of the way to get much faster loops, productivity loops going, get things out sooner. Sorry, a bit of a long rant, but yeah, PRs suck.Kovid Batra: No, I think this is really interesting, how we moved from enhancing developer experience and how code review should be done better because that ultimately impacts the overall experience and that's what most of the developers are doing most of the time. So, I think that makes sense. And it was.. Yeah?Jacob Singh: I just want to caveat that before you misquote me. I'm not saying formal reviews are bad. You should also have a formal review, but it should be like, it should be a formality. Like, you should have already done so many reviews informally along the way that anyone is reviewing it already kind of knows it's there and then the formal review happens. And it's like in the books and we've looked at it and we put the comments. It shouldn't just be like, "Here's a 20K patch.", a day before the deadline. You know what I mean? That shouldn't happen anymore, I think that's what I'm trying to say.Kovid Batra: Yeah. No, no, totally makes sense. I think this last piece was very interesting. And, we can have a complete discussion, a podcast totally on this piece itself. So, I'll stop here. And thank you so much for your time today, for discussing all these aspects of developer experience and how code reviews should be done better. Any parting advice, Jacob, for the dev teams of the modern age?Jacob Singh: The dev teams or the other managers? I guess the managers are probably watching this more than developers.Kovid Batra: Whichever you like.Jacob Singh: A parting advice. I would say that we're at the most exciting time to be an engineer since I mean, maybe I'm biased, but since I started coding. When I started coding, it was like, just as the web was taking off. You know, like, I remember when, like, CSS was released, you know, that's old. So I was like, "Oh, shit, this is great. This is so much fun!" You know, like, when it started getting adopted, right? So I think, like the sort of dynamic programmable web was nice when I started, right? Now, we're at the second most exciting one, in my opinion, as an engineer. And I think it's surprising to me. I work with a lot of portfolio companies at Alpha Wave. I talk to new companies that I'm looking at investing in. It's really surprising to me how few of them use Copilot or Cursor or these various sorts of AI tools to assist in development or like everyone uses them a little bit, but not programmatically. They don't really look into it too much. And I think that's a missed opportunity. I still code. When I code, I use them extensively. Like, extensively. I'm on ChatGPT. I'm on Copilot. I pay for all these subscriptions. You know, I use ShellGPT. I don't remember shell commands anymore. ShellGPT, by the way, is great to plug. Write what you want to do, hit ctrl+L, and it'll like generate the shell command for you. Even stuff I know how to do, it's faster. But the main thing is, like, the yak shaving goes away. So, I don't know if you guys know yak shaving, but yak shaving is this idea of having to do all this configuration, all this setup, all this screw around to get the thing actually working before you can start coding. Like, learning some new framework or dependency management, bullshit like that. That stuff is so much better now. You take your errors. You paste them into ChatGPT. It explains it. It's right most of the time. You can ask it to build a config script. So, I think if you know how to use the tool, you can just be a million times more productive. So, I would say lean into it. Don't be intimidated by it. Definitely don't shortchange it. Dedicate some research effort. Trust your engineers. Buy those subscriptions, It's 20 bucks a month. Don't be so cheap, please. Indian engineering managers are really cheap with tooling, I think a lot of time. Just spend it. It's fine. It's going to be worth it. I think that would be my big thing right now.Kovid Batra: Great, Jacob. Thank you. Thank you so much. Thank you so much for this. We'd love to have another discussion with you on any of the topics you love in the coming shows. And for today, I think, thanks a lot once again.Jacob Singh: My pleasure. Same here. Good talking to you, Kovid. All right. See you.Kovid Batra: Thank you. All right, take care. Bye-bye.Jacob Singh: Happy hacking!
In the latest episode of 'groCTO Originals' podcast (formerly: 'Beyond the Code'), host Kovid Batra engages in a thought-provoking discussion with Roman Kuba, VP of Engineering at a tech-based startup Tset. He brings a wealth of experience from his leadership roles at renowned organizations including GitLab, Cloudbees, and CodeSandbox. The heart of their conversation revolves around ‘Scaling startups with a people-first approach’. https://youtu.be/lTtwQ6PPyq8?si=lnOtCuVxjtvu9Ui2 The episode begins with Roman discussing the key events that shaped his life, followed by his responsibilities at Tset. He then details strategies for aligning the team with high-level goals, fostering a collaborative effort rather than a top-down directive. He also addresses challenges encountered during the zero-to-one phase and effective ways to overcome them. Lastly, Roman leaves the audience with essential advice to prioritise user value creation and genuinely care for your team’s ambitions and well-being.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have an amazing guest who has 12-plus years of engineering and leadership experience. He's currently serving as a VP of Engineering at a tech-based startup called Tset. He has worked with prestigious names like GitLab as an engineering leader, manager in the past. He's a strong believer of giving back to the community. Great to have you on the show, Roman. Welcome to the show.Roman Kuba: Hi, Kovid. Thank you for having me.Kovid Batra: Great, Roman.Roman Kuba: And by the way, a small thing to correct, the company is called (pronounced) 'Set'.Kovid Batra: Yeah.Roman Kuba: I know a lot of people call it 'T-Set', but it's called 'Set'.Kovid Batra: Oh, I'm so sorry for that. Roman Kuba: All good, all good.Kovid Batra: I'll call it 'Set' from now. Is that cool?Roman Kuba: That sounds good. Yes, sure.Kovid Batra: So, we have VP of Engineering, Tset, on the show today. Before we get started, Roman, I would love to know a little bit about you. And let's just start with a life-defining moment for you in your life that has been really impactful in terms of making Roman who he is today.Roman Kuba: Life-defining moments. Well, there's definitely not too many of them or so, but like, I would say one, thinking back, like very far in the, in the past or so when I was like actually six years old, like, that's like crazy long time, right? But I had like a great opportunity or so with my parents back then. Like my, my dad was like still a student or so and this kind of thing. And we, we didn't have like a lot of money or so, but they saved a lot of money for a long time. And we would like to spend like, I think over half a year basically in Australia. So, I'm currently in Austria, right, or so, and Australia was like a lifelong dream for my parents to get there. And that was one of the things or so.Kovid Batra: I'll just stop you here. Just for our audience, Austria and Australia are two different countries, guys.Roman Kuba: Yes, no kangaroos.Kovid Batra: Yeah. So, you were in Australia.Roman Kuba: Yeah, there was like this thing where, interestingly, to this day, I have like still a lot of memories, even it goes back for a long time, right? And on the one side, it kind of like, changed a lot in like how I started looking at the world and various things, right? And like, having this like constant interest to say like, cool, there's so many cool places to see, so many different kinds of cultures to discover, right? And I think this is one of the things that kind of like changed a lot in how I look at certain things, how I look at like certain stuff that's happening in my own country and these kinds of stuff, right? And I always try to keep a very open mind. And I think having this experience as a young kid or so, it really changed how I look at new things. And my early career is like continuing to just like part of like, traveling to other countries, traveling, like using job opportunities in the way of like seeing more parts of the world was a big, big driving factor for me to be able like to find a job that allows us to do this. And yeah, I think by now I've had the opportunity to work with like so many international people. And I think, really looking back or so, I think that was for me, the one thing was, okay, cool, there's so much more out there than this little Austria. Austria is a very, very small country. And it kind of like shaped my interest for just the general world more than anything else, I think could have done in this age.Kovid Batra: Yeah. I think even I relate to that sentiment and the curiosity, this enthusiasm that it always brings is amazing to have. And like it impacts in so many ways that even today, I sometimes think that like when we are talking to people, the openness that we get, all these things are driven from all these aspects of meeting different people, being into different cultures. So I really relate to it and it's really interesting. Thank you. Thank you, Roman, for this quick brief about yourself. Moving on, you are holding this role of VP Engineering at Tset. I hope this time it's right, right?Roman Kuba: Yeah.Kovid Batra: So, what's your daily routine like? What do you do at Tset? What are your major responsibilities that are coming with this role?Roman Kuba: So I was like trying to describe the VP of Engineering is like, even if it's like in a, more in this leading kind of role, right? For me, one important part of the whole thing is like, every day, my main focus is, okay, what can I improve in our organization today? How can I make like the life of each of our engineers, like better in the way that how to do their day-to-day job, right? And I think like, just kind of like supporting thought is the main thing that kind of drives a lot of the actions I'm doing. So, the current company I'm at, I joined only like last June, right? So, it's like not that long ago, actually. And for me, one of the first things when I kind of started, I saw okay, there's a lot of really, a lot of kind of grown processes that the company fell into, right? And there's a lot of these processes that just like start to kind of grow and grow and grow. I've been out there. We're not like in a way that they were helping the engineers on a daily basis, but often people would think of them like, oh, there's like, I cannot do this faster because there's this overhead and this kind of stuff, right? And the other thing I uncovered with this is like, we also have a lot of implicit knowledge, like just in people's heads. And there's like no shared understanding of certain things. Why do we want certain things to be done in a certain way? How do we handle certain situations? What if we do a certain failure, right? And how to recover from these kinds of things? And we had like a very outdated knowledge base at this point where say, if I ask somebody or say, "Hey, by the way, how can I learn about this?" They would kind of first go through their Slack history and see where they posted a link to a certain page, cause they couldn't find it from just like searching or anything. And so, they always say, "Oh yeah, I have this information somewhere." And that was one of the things that started very early on, okay, how can I make life for everybody in engineering better basically, right? And that is like the main driver. They say like, "Okay, I focus a lot on knowledge base and these kinds of things." And yes, the knowledge base part was for me the critical one in saying like, okay, how can I make information discoverable by everybody? But also, how can I make information like contributable by everybody in a very, very small barrier of entry, right? And basically, all of this for me is also like a big part of what does it mean to lead an entire team, right? It shouldn't be like I constantly tell everybody what to do, but ideally, I want to give people context. I want people like, to know how I make certain decisions or which piece of information do I have that they might not have, right? But just opening this up, making it discoverable, make it useful for everybody, that's my day-to-day. And to this or so we're of course, having now challenges, like we need to scale the team when we need to grow and these kinds of things. And to even be able to do this, like you just need to have a very solid foundation as a company, to have like everybody, like, okay, this is how we operate, this is how we work, this is how you can join the team, so we don't lose on the one side, a lot of knowledge if somebody leaves, but also don't have to spend a ton of time in giving somebody who joins the company all this implicit knowledge, right? Ideally, they say, "Hey, go in there, you know, everything where we are, and then you can join the journey from day one, basically." And that's my focus & help, right?Kovid Batra: That's the interesting as well as one of the hardest parts of bringing to a company. It is when we are talking and when we think about things from a high-level perspective, as a leader, I'm sure this seems to be one of the most critical things to have if you want to scale. But the problem here that I've seen with most of the teams is, like the junior folks who are working, they don't intuitively align towards this. And they find it hard to contribute there. As a leader, you know it's important. So you can dedicate that time, that focus and bring in that goal for the team. Did you do anything specific to trigger that counterintuitive behavior for people to actually go and contribute back or help you make this a crowdsource thing rather than just one person doing it? Because it's an incremental process and it has to come from every angle, right? So, were you able to discover anything interesting there and implement it for the team?Roman Kuba: I, at the start, I necked everybody just like, "Where's this documented?" Right. And if I asked the question and somebody would tell me, "Oh, it's like about this or so." Then, I would kind of immediately say, "Hey, please document it." Right. And once it was written down, I then continued to share it further in the team. So, I kind of said that the work people create and how to write things down, I try to leverage it right away, right, so that the person writing it down also sees the value in it right away.Kovid Batra: That's a really good idea, actually. Roman Kuba: Yeah, for me, that is the number one thing or so. And I really hate these weird icons that pop up in a Mac camera recently or so. It's funny. So, please don't get distracted by them.Kovid Batra: Cool, cool.Roman Kuba: But I think this is so critical, right? If you try to make changes, for you as a manager, as a leader, you're more used to just having like a longer feedback cycle in general. I make a change and they're going to see the success or the impact of a change after a certain amount of time. But as soon as you start involving other people, I think it's critical that they get like very instant gratification of how their work contributes to the overarching goal, right? And by kind of leveraging what they do and saying, "Hey, look, this is what you contributed and it already creates value from the first day you did it." I think this is incredibly important for people to actually don't lose track of the change you want to make overall, right? But to say, "Cool, I'm now part of this journey." Right, and then they go in and now they ping other people. So I'm like, "Hey, have you documented this somewhere?" And it started to be a joke at the start where I say, "Oh, please, please, please document it." By now, but people like constantly ask her, "Where's this documented?" So, you know, it's become like a viral way of like how we write things down. And that was pretty cool.Kovid Batra: No, I think that that's a pretty good idea, actually. We just have to like go to the very basics of how we can really incentivize and reward people for doing this activity. And it makes a lot of sense. Cool, Roman. I think this was something about when you were scaling, really scaling the startup, right? But when it comes to the journey of zero to one, like, you have been at Codeship, right? This was a startup where you were part of the zero-to-one journey. I think those are the one of the most challenging times. Of course, scaling is a problem, I don't deny that, but in zero to one, you're fighting for survival, right? So, in that journey, as an engineering leader, I'm sure you must have tackled a lot of problems. But tell us about one initiative or one challenge that you think was really a challenge for you. And how did you handle it? And what did you learn from that?Roman Kuba: Yeah. So, like for everybody listening, like Codeship, that was my first really, I would say tech startup challenge in this case or so. I joined the company in 2014. Yes, that's a long time ago, actually, yeah. And we were like a CI/CD startup, right? So that means when, basically, this constant delivery and testing of software was pretty like, I don't want to say a super-new thing, but having like a SaaS product doing this, it was a thing that was slowly kind of getting more and more adoption in the market and people getting used to it. I joined that company actually as one of their very early members, as an engineer, I was like still really a front end developer or full stack developer back then, even like, and focused a lot on the front end part. For me, like the, cause you say, what is the challenge? Like there were a ton of challenges on a daily basis back then. Like, everything there, I had to learn a ton of stuff, like, how do startups work, how to make really, basically, build a SaaS product, right, that you have like a ton of other developers rely on now on a daily basis to say like, "Okay, how can we ship things without breaking it? How do we recover from mistakes?" And these kinds of things, right? That was amazing. And I would say, if I think about one specific thing that the biggest one is been there for some time and like we started to introduce a lot of like different kinds of JavaScript stuff, of course, like to make, drive a lot of the very interactive parts of the application, like think of a log output, right? If you know, run something on your terminal, of course, your terminal prints all this stuff. If you do it in the web, right, then you suddenly, basically, need to take all this kind of terminal content and present it to the user in pretty much real time in the web interface, right? And that was at a time where say, jQuery was like still very, very active. And Angular was one of the bigger frameworks and it was Angular 1. And React was like just coming, was slowly the thing kind of driving in, right? And we had this one page of a new part of our product where you could run like a lot of like really complex bills and you would get like a ton of terminal output. I think you would talk about like basically, on the screen, like about, 50-60K DOM nodes that you need to render in basically, like real time for them constantly, right? And it's expanding and this kind of stuff. And there was this one big challenge where I say, okay, we had big customers and they had very big logs and that page was just like crashing the browsers for users. So, we're not able like to look at their log output because it was just like too many DOM nodes to properly handle this refresh and this kind of thing in the way we did it back then. And from the engineering side or so, the interesting part was I really needed to spend a lot of time in dissecting the problem, where was like the big bottleneck, right? We looked at a ton of different kinds of metrics on the time to paint and the refresh on kind of when do we touch which kinds of things. And we had Angular back then as the main driving part for this front end page. And within basically, a week, I did two POCs. One was with React and the other one was with Vue back then. And Vue was like completely unknown. It was like this little fun side project from one person, right? Nobody has heard of it. It was like zero point something. And I had basically, neither knowledge, nor in react, nor in Vue, right? And for me, it was like my main go-to was okay, looking at a piece of documentation, say, "What can I learn about this piece of tech to solve my problem?" cause I identified that rendering is the biggest part in the refreshing and Angular was just really notoriously bad at refreshing a lot of nodes. And like I know back then, so it was React with a constant like, I would say roadblocks we hit back then, cause it was like much more complicated. And the big roadblocks were on a lot on the technical side of things cause we also had to take into account what is the knowledge we currently have within our team, right? It's not good or so if like I build something that only I understand and nobody else in the company can easily contribute to, right? So, taking these constraints into account is incredibly important, especially in the early parts of the journey of a startup. You need to take all the resources you have in a smart way. And with Vue, I was able, like to build this page in such an easy way that even a backend developer could look at the code, understand how it works, understand how to contribute to it or so in a very easy way, and it didn't need to jump through a ton of like building hoops and kind of steps to understand it and so, cause it was looking so similar to just like plain HTML in the way it was rendered, right? So, it was, we'd like to build this POC basically, within a week. And then, it took me like another, like half week, week or so to implement it really in the product with everything they wanted to do. And then, there was this defining moment, okay, of like, I recall this moment. Like, you click this button in your own like UI and say, "Okay, let's merge it to production." It goes live, really just all the tests ran through, kind of like it went live and then you see it's deployed. And say, okay, now all the users are seeing that piece of code running, right? And then suddenly, the browser stopped crashing. Like you had users, "Hey, it's working for me." And that was like, for me, this thing was a, that was very defining the way I started to look at, okay, what value tests bring, what value documentation brings, what value like other parts within the company bring regarding knowledge we have and constraints. And yeah. That was, it was a fun one or so. And I think it helped a lot in the journey for the company.Kovid Batra: So now, like just going back and thinking about the same incident, what do you think that one thing drove you towards solving this problem? Like, what comes to your mind? Was it your curiosity to explore something else or was it something like the need of the hour and there was no escaping it? What pushed you to actually go forward and take up this challenge?Roman Kuba: Like, I was basically the only front end developer back then, right? I was the only one able, like to fix it.Kovid Batra: Yeah. So, it was more of a question of survival for you then. Roman Kuba: Yes. It was, like for us as a company, it was really, we have this product, we want to sell it, like this customer is curious, right? But if I have like this negative connotation with our product where people say, "Oh, it's not working." That's just not great, right? And for you as a startup or so, I think you always need to make very conscious decisions on what you do, what do you focus on, right? There's always like ideal solutions to say it is the best solution you can build or the other one is like, okay, what is the solution I can build now that just provides the most value to our users, right? And sometimes, even the value for the user and the ideal solution, they just go in very separate ways, right? And I think that is the thing I just learned at this point or so, when do you prioritize the right pieces of code? When do you kind of like look at what do I really need to invest in long term as a company? And it also changed a lot of my perception when it kind of, concepting things about like, where do metrics play a bigger part in the way what I build, right? like I started to weigh, look more for like performance metrics from the start. I'm looking at really edge cases in how I build things, how fast am I actually in deploying and recovering from these kinds of things. So, yeah. Ideally, if I can go incrementally forward with these kinds of changes going forward, that's always like the better approach than just say, throwing everything over the fence and restarting. That was more just like escape hatch because we had a really big problem. But usually, always making smart decisions with the constraints you have in mind and say, "Okay, what do I need to make as a small step to bring me closer to the ideal value I want to create for the user?" And my ideal solution can be the really North Star, but it shouldn't be my first stepping stone.Kovid Batra: First step towards that. Totally. I think it's a great, great piece of advice. And being in that position and taking that call, I think is the hardest part. Like, when you talk about it, you can say that just keep that balance on, like, don't go for the ideal solution, just look at what's the next best step. But that really requires some level of research, some level of understanding of what should be the next first step, because you can end up being in a tech debt situation for things like these that you have been doing. And it could be that you might delay the delivery. So, I think great piece of advice, but if I have to ask you, what exactly is that framework or even if it's not a defined framework, how do you take that call that, okay, this is going to be the first step. What's that feeling that you get when you see, okay, this is what I'm going to implement and this is what I'm going to leave for the next step. How do you decide that?Roman Kuba: I would say always like to weigh a little bit, the risk, right. Especially in a startup, like everything that you do has a lot of risk involved, right? If you build new features, have you validated them with users, will users like them and these kinds of things, right? And for me, it's always like on one side, I want to kind of like, I don't want to say minimize risk, but I want to keep the risk to a low amount of like effort when it comes to my previous investment. For me, like if I need to spend like a month of building something and there's super high risk involved in like, if it's even a month spent well, right? That's something, especially in the startup world, a month is like a ton of time. You're not, you're never getting this back, right? So, if you say, "Okay, that's for me, actually a step I can take. That takes me only like a week." Right? And maybe it's even like a higher risk or so, or like a lower risk in this case, right? Then I think that's always like the better thing to do. Even if you say like, okay, maybe it's, maybe I then need another month or afterwards to validate what I'm doing or so. And then later, a user says, "Yes, it's the right journey." Then you invested a week, right? But the thing is, so, if you invest a month and then it's like the bad thing, it's, yeah, you're not getting this back. But having a week and then spending an extra month to say, "Okay, yes, it was a good idea." That is how I usually kind of try to look at things. Yeah, that's the thing. Just getting you to the goal and getting the confirmation that like you don't waste your resources. That is, for me, the big thing.Kovid Batra: Makes sense. Just to add to it, I think a lot of times, we as developers make a decision purely based on the effort it's going to take and we just find the shortest paths to it. What I loved about your narrative is that there was no single point when you were thinking about the effort that would go into it. You were always thinking from a customer standpoint, like what value should be delivered right now. So, even without you saying, I'm just taking this from you that thinking for the customer, delivering the value should be the primary objective in your mind. The effort, whether it is one week or 10 days or diving into a new technology to ramp up your learning and do stuff, I think that never became the hurdle for you. It was always just the path that you have to take to deliver that value. So I think, amazing, Roman, I think I already feel inspired from the way you are thinking and doing things. All the best to you for your upcoming endeavors and may you shine like this ever. On that note, I think I would ask for one last piece of advice for our audience today from you as an engineering leader, as an engineering manager, people who are aspiring to be that what would you like to tell them?Roman Kuba: That's a fun one. I would say, the engineer in me would say, like really focusing on the value is the number one priority because your user, they just don't care which piece of tech you're using, right? They're not caring which framework you're using and all this kind of stuff. And it's for developers, very uncomfortable. And this thing I needed to learn. But making a decision that says, okay, even if it takes you a little longer, what is the thing you want to create for the user for them to get the benefit, right? That is for me, the number one thing. Start thinking about the value you want to create. The leader in me just says or so for anybody, because I went through this journey, right? Like being a developer, then leading a front end team, then stepping up to become an Engineering Manager, right? What I always did and do to this day is like really honestly caring for the people you work with, like understanding their ambitions, understanding what they want to achieve, right, or so. Like, everybody, even they, when we talk about tech, right, they also have fears about like, do they make the right decisions, right? Really genuinely be interested in what people think, how they feel about certain situations, right? Because in this case, you also want to create value for the people that you work with. And I think that is the number one thing, like yeah, generally care for each other in this kind of case or so. And do this journey on a startup or a tech product that you're ever building, like together. And yeah, that's my advice, I would say.Kovid Batra: Great, Roman. Thank you. Thank you so much for this advice and thank you for your time today. We'd love to see you on the show again once we hit a benchmark where we have another episode and we would love to call guests like you back on the show. Really loved the talk.Roman Kuba: Thank you, Kovid, for having me. It was a pleasure being here.Kovid Batra: Thank you, Roman. See ya!Roman Kuba: All right. Take care. Bye-bye.
In the latest episode of the ‘groCTO: Originals’ podcast (Formerly: Beyond the Code), host Kovid Batra welcomes Glenn Santos, VP of Engineering at PDAX. Glenn is also dedicated to empowering developers to become leaders with his initiative ‘eHeads’, a community for engineering leaders to exchange experiences and insights. His vast experience includes valuable contributions to renowned companies such as Salarium, TraXion Tech Inc., and HCX Technology Partners. The discussion revolves around ‘First 90 Days of Leadership, DORA & SonarQube’.
The episode kicks off with Glenn sharing his hobbies and life-defining moments, followed by an insightful discussion on how Glenn as a VP of Engineering manages his role, the company’s mission, and day-to-day challenges. Further, he shares strategies for aligning developers with business goals and navigating compliances in FinTech while maintaining velocity. He also shares his 90-day draft for building trust in the initial days as a leader and highlights the use of DORA metrics and SonarQube to measure team success, address integration challenges, and plan targeted improvements.
Lastly, he offers parting advice to aspiring leaders and engineering managers to embrace leadership opportunities and prioritize personal growth over comparing themselves to others’ progress.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest. He’s currently VP of Engineering at PDAX, which is one of the best crypto and digital asset exchanges in the Philippines. He’s also known as the organizer of eHeads, a fellowship for local engineering leaders. His trajectory of career has revolved around mainly helping others work better. So he’s a passionate tech leader with a lot of compassion and empathy. Welcome to the show, Glenn. Happy to have you here.
Glenn Santos: Thanks. Thanks for having me.
Kovid Batra: Great, Glenn. So, before we start off and learn some great stuff from you, from your experience, we would love to know a little bit more about you, like your hobbies, your day-to-day activities. So quickly, if you could introduce us with yourself and tell us about your life-defining moments and some of the best experiences that you have had so far, your hobbies, how you unwind your day, I think that would be great.
Glenn Santos: So probably, my most life-defining experience was when I discovered TechCrunch before. So, when TechCrunch was just starting out, I was just a usual rank-and-file worker in a big company. I wasn’t a developer at all. So, when TechCrunch published like 10 ideas on how to create a startup, these were the ideas that they thought would boom. I found one that was particularly something that Filipinos here where I am from could do, which is some sort of labor arbitrage. So, it’s called outsourcing now. It’s very popular across the world. But at that time, we did not have the technology to make it easy, so I had to build my own forum, I had to create my own website, and do all the other stuff needed to get that business up and running.
For my hobbies, I’m actually an avid fan of cars. And I’m also a foodie, as they call it. So, I like trying new foods. Technology-wise I still read, like, Hacker News to keep up-to-date. But I also mix it up with some newsletters to supplement my knowledge in engineering management. And I share my learnings in my LinkedIn. That’s maybe a quick run-through of what I, yeah, what I’ve done.
Kovid Batra: Yeah. Yeah. That really helps. Thank you so much for this intro and coming to the main section, the main discussion, like when we want to learn something from engineering leaders like you, I think the best would be to start with your current role wherein if you could just tell us, what you do as a VP of Engineering at PDAX, what PDAX exactly does, and what your day-to-day challenges are. I think let’s get started from there first.
Glenn Santos: So, as VP of Engineering, I handle most of the people side in the engineering management role. So, my focus is really on people and the processes that enable them to work better. So right now, one of my initiatives in the company is to roll out DORA metrics and SonarQube. In my day-to-day, I actually do 1-on-1s, I join meetings with engineers and I also help plan out what, since we’re at the start of the year, I’m helping plan out what we’re going to do for 2024.
Kovid Batra: So, when you say you are planning what is gonna go out for 2024, I mean, this is basically what a VP Engineering would be doing, like connecting the business to the tech side and, like enabling the teams to be aware of what we should build and what strategy we should follow. So, I think this is one interesting piece. And this is one of the challenging things of a leadership role where you bring in the business and align it with the technical strategy. How do you exactly do that? And if you would share some of your experiences with aligning your teams to that technical strategy which ultimately aligns with the business goals. So, how do you do that?
Glenn Santos: So, first I need to understand the business goals for this year that’s going to be actually rolled out next week. But right now, it’s pretty clear what our direction will be business-wise. So on my end, I have to translate that into something that will help the engineering team with the help of product, of course. In our organization, product is separate from engineering. So, we align ourselves with each other so that the features that we build are according to that roadmap from the executives.
And aside from that, I also have to make sure that we keep code quality high because one of the things that I’d like to implement is that we build features more quickly. So, that’s enabled by better code which actually is a very good flywheel that contributes to the speed of development as well. So, we can do more with less once we have better code.
Kovid Batra: That totally makes sense. When it comes to aligning the team with these goals, it’s always a challenge for making the developers intuitively or naturally aligned with these goals. So, what exactly would you do in your meetings or your day-to-day work to ensure that these people are on a day-to-day level aligned with the business goals and the work that they are doing? Because it’s always a secondary effect, right? Like, the developer builds the code, ships it, and then ultimately, they see the results when the features are being adopted or your system is getting faster. So, it’s always a second-order effect. So, in day-to-day, how, do you make sure that they relate to that second-order effect goals and get rewarded with that actually?
Glenn Santos: So, when we’re building things aside from the regular, I think most of your audience would be familiar with the stand-ups and the catch-ups with product and the entire team. So, that’s part of it. But another part is, I always reiterate during our own engineering meetings, why we’re doing these things because we need to connect that with their own motivations. Each person has a different motivation, but I’m hoping that most of our engineers are motivated by growth and learning as well as achieving something that’s impactful. So, we share metrics in our meetings. We share how the users are accepting their features. And we also want them to, like connect the goals of whatever they’re doing with their own personal goals. So, we’re a fintech company that’s focused on wealth, increasing wealth. And most of our engineers are actually crypto traders as well. So we give, we roll out initiatives like helping them learn more about crypto and also how to handle their own funds. So that’s also something that we strive to do at PDAX.
Kovid Batra: I think that’s the best thing that you can have, like the people who are building the tool for a user, they themselves are users of that product and they understand the problem statement, they understand the solution around it. I think you answered the question really well here and you’re lucky to have that kind of motivation because in a lot of cases when people are building, let’s say some B2B products, the developers are totally disconnected from the kind of audience they have to build the product for, right? So, I think you’re in a good position and it’s a good strategy actually.
Cool. I’ll move on to the next question, Glenn. So basically, when you say that you are working with PDAX and it’s a financial institution, I’m sure there are a lot of compliances and security issues coming into the picture and, being a fast-moving company, you have to roll out so many features and in as less time as possible. So as a leader, how do you manage that balance? Because that is a little bit of a challenge. And when compliances come into the picture and specifically in FinTech, it’s a big, big challenge. So how do you manage that, your velocity while making sure that you are fulfilling all the compliances?
Glenn Santos: Yeah. Good question. Currently, we’re, there’s a really like a push and pull here. So, other teams, they need their central bank requirements because that’s part of the regulations, but we also want to build something quickly, which is also a mandate from our CEO, actually. So, what we do here is we actually set aside time for that compliance stuff. And, for the most part, it’s not handled by the engineers themselves. I let the managers handle that. But for example, we need input from tech leads or engineers, we need to bake that in so that it doesn’t disrupt their flow. So, I’m still a big believer of giving them a maker flow, these engineers, because that’s the only time where they can deliver quickly. And they’ll have well thought-out solutions to their, to the problems that we give them. So, we don’t want to interrupt that. But at the same time, we also want them to be communicative and collaborative. So, I think having those standups and having them work more async is actually key here so that they can contribute when they need to, but not, we don’t, like rush them into contributing these admin tasks.
Another thing is that we want to also build rapport with these other teams who are not technical, who might not understand what we’re doing so that when we’re, like a bit delayed when giving responses because we’re working on other stuff, we can smooth things out. And that’s actually another part of our like what we’re doing in the company currently, some process improvements so that these asks from external parties are handled well.
Kovid Batra: I think this is a good strategy where you are segregating their work to an extent where they don’t get interrupted in the flow of work on an everyday basis, but also they’re aware of things that are going on and they understand the context of it so that, as you said, like when they need it, when they need to contribute in that direction, they have that context and they implement it accordingly. So, yeah, I think balancing this on a day-to-day level is the key here probably because you don’t know when things go more into that direction where you are interrupting them every time. And then, there could be situations where they’re not completely aware of what’s going on on the compliance side and they end up building something which doesn’t fall into the picture and they have to rework. So, I think the balancing act is a must here, which I’m sure you’re doing. And you joined PDAX I think very recently, it’s most likely one year or so.
Glenn Santos: Less than a year actually.
Kovid Batra: Less than a year? All right. So, I think this is also an interesting piece, coming in at a leadership position and building that trust with the team. Right? So, this is something where I see a lot of people struggle, like people just don’t take the authority. In today’s world, at least they don’t just take the authority. They want to, like be influenced in a very subtle, different manner from the leaders. So, how are you handling this role? How are you handling building of that trust with the team in this initial year?
Glenn Santos: So, when I started, I actually, before I even started, I interviewed all the leaders that would be under me and I’ll be working closely with because I wanted to establish that initial rapport. I wanted to know if we clicked because for the most part, you don’t want your reports to be, like going against you. So, you want to have some harmony. When I started, I also actually, and I still do frequent 1-on-1s because I want to get to know them not just for their work, my direct reports who are engineering managers. I also want to know, what makes them tick, what they’re really like, and maybe some of their interests outside of work. So, that’s part of it.
And aside from that, for the engineers themselves, I’ll start doing some skip-level 1-on-1s as well so that I get a holistic picture of the engineering team. But, when building trust with them, I’m very transparent and open about what we’re going to do. So, I always reiterate that our goals for this year are code quality, this is how we will be measured, and I also want people to be more learning-focused this year. So, I’m really hoping that that aligns with them because one thing that I’ve taught recently is that you cannot give people motivation. They have their own motivations. You just have to align yourself with them so that they can do their best work.
Kovid Batra: Anything that you specifically follow when you join in? Any basic rule or format or template that you follow that, okay, whenever I’m going into a new position as a leader, like this is something that I should continue doing for some time.
Glenn Santos: Yeah. I actually, since I’ve joined a few companies recently, I’ve actually created my own 90-day, like my 90-day draft on what I should do in the first 90 days. So it’s split into 30, 60 and 90. So, while the goals are not that set in stone, I do want to get as much information about the organization as possible in the first 30 days, as well as talk to as many people in the organization. Yeah. So I go to, I actually go on-site, we’ve returned on site already, and I need to talk to as many people because for our companies, you have to interact with people who are not in tech, maybe some people in operations, some people in sales. So, you’d want to build that rapport with them so that they understand you and you understand them when they have things that they ask from you.
Kovid Batra: Right.
Glenn Santos: Yeah, so that template has been very useful for me. There’s actually a book out called ‘The First 90 Days’ I think, that I use as a basis.
Kovid Batra: Perfect. Great. Glenn, the last thing which I want to touch on with you in this discussion is something that you just mentioned you have taken up as an initiative: setting up the DORA metrics. So, DORA metrics is probably one aspect that I want to understand. But broadly, I want to understand what’s your way of measuring the success of an engineering team. Like, if your team is doing good, how do you define that for the team and how do you make sure that everyone is aligned on those KPIs and metrics, maybe DORA metrics? And, what all goes into setting up that momentum for the team so that everyone is motivated towards those? That they just don’t feel that they are under a microscope when you are talking about KPIs. They should naturally feel to work on those KPIs when they are working on a day-to-day level. So, I just want to understand this whole piece from you.
Glenn Santos: So, one of our, I guess our rallying cry this year is to be better engineers. So I’m pretty sure most engineers want to be better. So, DORA metrics, I also tell them that this is not actually some sort of measurement that we use just for that sake or to, like rank you. I want to use it to really create better engineers because when you follow the metrics, you’ll naturally hit roadblocks. Engineers love problem-solving, so this is one way to, like attack that part of the brain that loves feedback. It’s a very quick way to reinforce the feedback loop. That and SonarQube, which is also an automated way to collect metrics.
So, people love gaming, and we’ve seen that gaming is very very effective in producing behaviors that we want. And this is one way for them to really see if they’re doing well, they’re publishing clean code, they’re creating code that has no bugs, no vulnerabilities, so we want that. And also, it’s a team metric more than an individual metric, because the emphasis of DORA is really on teams. I want them to be more collaborative. So, if it fails, we’re not singling out one person. I’d rather tell the team, “Hey, you’re not doing well, help each other out, raise these metrics so that we can deliver better products to our customers.”
Kovid Batra: Right. Makes sense. Apart from building this first-level alignment of the team towards these metrics, what challenges did you see while implementing these success metrics for the team? And any specific example? So, I’m not sure if you have implemented it yet or not, but, let’s say, if you’re looking at implementing it, what would be your go-to strategy? What would be those one or two important metrics that you would be tracking? And how, again, you would bring that alignment with the team that, okay, these are the right metrics that we should be focusing on right now?
Glenn Santos: So, we’re actually in the process of implementing these metrics. We’ve ranked them accordingly. One thing that really stands out that I’d like to measure is the reliability of our code. So, that’s automatically measured by SonarQube. So one thing that I really emphasize here. One of the roadblocks, sorry, that we’ve come across is that if you’re using systems, different systems for like CI/CD or another company for your repos and maybe another company for your servers, it might be best if you streamline these first because that’s one of the challenges that we had. We had to string them together and DORA metrics is ideally collected in real time. So, for now, we’re not collecting it in real time. But, if for example, everything that you have is in AWS, it might be simpler or everything you have is maybe in Atlassian, that’d be simpler. And probably one of the people’s side challenges of implementing metrics is actually getting them to integrate, especially if you have lots of repos.
Kovid Batra: Yeah.
Glenn Santos: So, having time for them to do that, that’s usually the challenge. Do they do the features or do they do these integrations? So, I have to work with product, say that we need to slot this in. Maybe, you can slot this in, like before the sprint or during the sprint so that we can start collecting the metrics because we can only act upon the metrics once we’ve collected them. And yeah, we’re actually at just that part right now.
So, the next phase would be creating a plan, how to improve those metrics. So, we are not there yet, but we don’t want to plan ahead because that might involve, you know, we say that this is wrong, but our metrics would say that actually we’re doing okay here. So, we can focus on other metrics that are not up to par. So, we can put our engineering efforts there. So, it’s more targeted and has more impact.
Kovid Batra: Yeah. I think it also makes sense. Like, you cannot really jump the gun here. The whole point of having metrics is to first understand the problem. So, if you will just say that, okay, I will pick up this metric and start working on it from today itself with the team, that might not actually align with the real improvement areas. So, I think the thought process that you have right now for implementing these metrics makes a lot of sense. Like, first-level implementation, getting in place, getting that data in place, people looking at it regularly. And from there, you will start getting those indications where the inefficiencies lie. Just for example, if we talk about change failure rate, right? This is one of the important DORA metrics that needs to be tracked. So, if in your team, there are a lot of failures once you release to production, then that becomes the area of focus. And then, you start working towards it, taking measures towards it. But, in the beginning itself, if you say that okay, let’s start working on change failure rate, and surprisingly, your team is doing good on that metric, the team would say that why are we doing that? That would make it lose its purpose. So, it totally makes sense to look at it very deeply and understand at every team level which metrics would really work out for them. It’s not that for a particular team, the same metric that is working out would work for the other team also. So, it’s a process. I think the way you were taking it up, like phase-wise is something I would say is the right way to go about it.
And, great. I think, Glenn, it’s really nice to understand these things when you’re implementing them hands-on. I’d love to know more insights from you when you do this implementation. Maybe we can have another session, another podcast where we discuss about how you implemented those metrics and what rewards you got out of those. So, great. I think, it was a great, great talk. And before leaving, I would love for you to give parting advice to our aspiring leaders and aspiring engineering managers who are listening to this podcast, how they should move ahead in their career.
Glenn Santos: So, one of my big pushes really is, and you can see it in my LinkedIn that I want developers to become leaders. We don’t have enough engineering leaders actually, and not enough developers are interested in leading. So, my advice is for people to try it out. You can pedal back if it doesn’t really fit you, but it might be another way for you to grow. So,, right out within your own company, maybe you can help another startup out. And when you’re going through this career journey, it’s not really for you to compare yourself with others. Other people would have done pretty well and other people might have really not progressed that quickly, but don’t compare yourself to them. Compare yourself to what you were, like maybe one year ago, five years ago. As long as you’re, like progressing in a good pace, I think your career as an engineering or engineering leader or an engineer would really go far.
Kovid Batra: That’s really great advice. And I think the best part I felt is that you said, “Keep on trying it with other startups and companies.” So, I think having that hands-on experience and being in those situations would really, really build that quality in you. Like, reading books or just listening to a few podcasts might give you some initial framework on how you should do it. But the real belief I would say comes in when you have done it hands-on multiple times, probably.
So, great advice and thank you so much for this amazing, amazing discussion. I would be more than interested to talking to you again about your experiences of implementing DORA and handling your team, maybe six months down the line, how it went down and how it went up. So, let’s get in touch again. Thank you for today. I’ll see you soon.
Glenn Santos: Thanks. Thanks, Kovid. Great to talk to you.
Kovid Batra: Thank you.
In the latest episode of the ‘groCTO: Originals’ podcast (Formerly: Beyond the Code), host Kovid Batra engages in an insightful discussion with two dynamic engineering leaders: Francis Lacoste and Miroslaw Stanek.
Francis has formerly worked with Heroku and Salesforce & is now a VPE and CTO Coach specializing in scaling up startups. Miroslaw is the Director of Engineering & the PL Engineering Site Lead for the Poland R&D division at Papaya Global. He’s also the author of the newsletter ‘Practical Engineering Management’. Explore the theme of ‘Leading Dev teams through acquisitions’ by delving into their real-life experiences.
The episode kicks off with Francis and Miroslaw talking about their personal lives and hobbies. Moving on to the main section, they dive into the acquisition experiences and the pivotal hurdles faced by the engineering leaders in their respective organizations. They stress the importance of swiftly merging company cultures post-acquisition while addressing challenges in navigating the ‘us’ versus ‘them’ dynamic. The conversation also explores strategies for maintaining engineering team efficiency without sacrificing value delivery.
Lastly, Francis and Miroslaw share parting advice with engineering leaders who are navigating similar challenges.
Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today, it’s a unique episode for us and we have some special guests. In fact, we have two amazing guests with us, Mirek and Francis. Both of them are accomplished engineering leaders. But they have one thing in common, their passion for contributing back to the engineering community. And that’s why we connected. So, Mirek has been on our show previously, but let me introduce him again. He’s the newsletter writer for Practical Engineering Management. He’s the Director of Engineering at Papaya Global. Francis is coming to our show for the first time. He’s an Engineering Leadership Coach. He’s a seasoned engineering leader and has worked with companies like Heroku, Salesforce and more. I’m glad to have both of you on the show. Thanks for coming. Thanks for joining in.
Francis Lacoste: Hi, Kovid.
Miroslaw Stanek: Yeah, thank you, Kovid. Hey, Francis. Thanks for having us.
Kovid Batra: Great. Francis, Mirek, it’s a basic format, like before we jump on to our today’s topic of leading dev teams through acquisition, I think it’s great if you could share some of your hobbies, some personal things about yourselves with the audience so that they know you a little more. So, we can start with you, Mirek, would you like to go first?
Miroslaw Stanek: Yeah, yeah, sure. Yeah, like Kovid said, it’s my second time in this podcast. but, for new people listening to us, my name is Mirek Miroslaw, depending on which pronunciation you prefer. Like Kovid said, recently I’m the Director of Engineering for the company Papaya Global. I’m also the site leader, leading the Polish R&D side of this company. And I also write a newsletter ‘Practical Engineering Management’. Basically, I try to help engineering leaders to maximize impact of their work and make their teams successful.
Personally, I’m the father of a three-year-old daughter. So, showing her the way, exploring the world, answering all of the questions. And, recently I’m also becoming a professional athlete. Yes, even after being 35 years old, you can still apply for the license. So, I’m an obstacle race runner. I have some aspirations, maybe, you know, not the box on the Olympics, but still, you know, I’m enjoying the ride and then hopefully, we’ll be able to share some successes over time. Yeah, so, thanks for having me.
Kovid Batra: All the best. All the best. All the best. Thanks, Mirek. Thank you so much for this lovely intro. Francis, your turn, man.
Francis Lacoste: So I’m Francis Lacoste. I’m based in Montreal in Canada. I’m an executive coach working mainly with CTOs and VPs of Engineering at startups. I help them specifically when they need to scale their team. And this is where we, they need to get really deliberate with culture. This is my passion, really making sure that teams have a great engineering environment like I’ve experienced. Before that, I was an Engineering Leader at Salesforce and Heroku and started my leadership career at Canonical, which was an open-source company, the one that made Ubuntu. And this is where I started learning remote management back in 2000.
Outside of work, I play in an electronic ambient band. I play a hands-free instrument, the Theremin, which is the space sound music type of sound that this instrument makes. Also, I have a long practice of meditation and I now also teach meditation with the Buddhist geeks, which is an online organization.
And it’s a pleasure to be here, Kovid. Thank you for inviting me.
Kovid Batra: Great, Francis. Thank you. Thank you so much for that lovely intro. I would love to hear you sing and play the music sometime.
Francis Lacoste: Well, we have a Bandcamp and we’re on Spotify, so I can give you the link in the show notes.
Kovid Batra: Oh yeah, that’s cool! Great. Francis, Mirek, we are here today to discuss around the challenges that engineering leaders face post-acquisition. And both of you come with immense experience. You have spent time in different-sized organizations. You have had startups, worked with companies as big as Salesforce, Francis, as you just mentioned. I’m sure you have had experiences of acquisition, right? And various types.
So, to start off, tell us about what kind of acquisition experiences you have had. And what were the biggest challenges as an engineering leader or as an engineering team you saw for the company getting acquired?
Francis Lacoste: Well, at Salesforce, we had many, there were many acquisitions. I came in with Heroku just after they had been acquired. And the Heroku acquisition was kind of a weird one because it took like that very long time. It operated somewhat independently. That was part of the main challenge. You know, the challenge is how do you integrate the culture? You know, it’s an integration problem. The big challenge was the ‘identity’ one. We’re identified as Heroku, but Heroku is now part of Salesforce. How can we be seen? How can we embrace the bigger identity of Salesforce? So, that’s how I would characterize its essence, the challenge we faced. And, it was not inside of it, but concise on, there were many other acquisitions, some more rapid where kind of you’re acquired and then there’s.. It’s a technology acquisition, so the product kind of shuts down very rapidly, things like that.
Those are other challenges, but there’s still this identity issue that’s very present there because usually people are not happy when losing identity.
Kovid Batra: Sure. I think we’ll come back to you for more details on that and discuss more things in depth. Mirek, what about you?
Miroslaw Stanek: From my side, basically the company I’m working for recently, Papaya Global acquired the previous company, Azimo, where I worked for almost eight years. What was the challenge of the acquisition? I think that the merging process in general, yeah. So, my role in the company was like, I would say, middle-level manager as a Director of Engineering who leads leaders who lead individual contributors. Basically, our main challenge was to make sure that the entire know-how which was acquired by, you know, by the bigger company is utilized because we came with know-how, we came with, you know, experience, and then the long stories, ways of working, but this is still in the sphere of, you know, of the potential which you can give to the company. And as a leader, as a manager, you need to be sure that this potential is somehow utilized. So, I think this is the biggest challenge. So, finding good places for the skills which we are bringing with you and you know, it opens all of the challenges around that. Yeah so, the ones about the organization, the culture, the team structure, and everything. So yeah, this is how it looks like in the general view.
Kovid Batra: Makes sense. Diving deep a little more into this challenge, how on a day-to-day basis are you navigating this situation? And Francis, please feel free to share your opinion or Mirek, please feel free to discuss anything that you feel should be known to the community also which you are facing as a challenge today. And, Francis comes with a lot of experience. I am sure he would have certain advice on how to navigate this situation.
Francis Lacoste: Yeah. I mean, I’ve coached people who went through acquisition as well, so that’s another source. I think one of the things that is very important to get going is to know what the context of the acquisition is. You know, there are multiple reasons for an acquisition. I’d say there are three main ones. So, the first one is usually a strategic product acquisition. Your business is acquired because, it’s seen as complimentary. I mean, there’s two, actually, there’s two there, you know, it can be because they want the revenue. So you’re in the same space as your competitor. And they just want, I mean, the one who’s acquiring is kind of a competitor and they’re kind of getting your customers and they want to add their customers there. That’s one strategic acquisition.
The other one, which was more like Heroku and I think in Mirek’s case here, is there’s a complementary product. You know, so it’s kind of Salesforce wanted to expand its reach in the developer space and Heroku was very at good traction in the developer space. So, it was okay work. And, and you’ve seen that in Salesforce. You know, we have a portfolio of companies they acquired, exact targets to add, like marketing capabilities to the CRM, Tableau to add analytics. So these are kind of products complimentary. And the idea is that when you go to sell to customers, you have, like a more comprehensive solution to sell them. So, that will drive more revenue.
Kovid Batra: Right.
Francis Lacoste: So, this is like the strategic acquisition and that will be very different, how it goes and how it will go away than these other two, which is ‘higher acquisition’, you know. So, you’re acquiring a company because of talent. You, you want to usually this will be as you acquire a small startup where you’re not really interested in their product or that technology.
Kovid Batra: It’s just the team that you need.
Francis Lacoste: It’s, “I want the team.” You know, there’s this, and usually it might be one person in the team. You know, there’s like a, somebody has like a very deep expertise. They’re not willing, they have a stake in the company, they’re not willing to jump ship. So they’re going to buy the company so that they can work for the bigger corporation. That’s a very different context than the first two.
And the third one is a tech acquisition. There, it’s not like you don’t really have traction. It’s not about your customers or things like that, but there’s complimentary technology. So, they want that tech. You know, you’ve solved one problem for them and instead of building it by themselves, they will buy you. And depending on that context, it will change a lot of how the acquisition will go.
But, what’s your experience with it, Mirek? Is it like, was it more technology acquisition, a talent acquisition or a strategy acquisition?
Miroslaw Stanek: Well, You know, in the, I think in the end, it’s those types of acquisitions, they have a lot in common because yeah, you can acquire the product, but in the end, you know, there are people behind the product. So even if you have this piece of technology, you still need to have those talented people who can maintain that, who can plug it into, you know, into the new structures and who can continue the growth. I think that, we are kind of mixing both things. Obviously, we expanded the new company’s portfolio, but we also brought, you know, fresh talent, new perspectives and fresh know-how to the problems which can also be the strategic problems for the company, yeah? The company wants to grow. The company wants to expand their portfolio. So bringing, you know, fresh talents who spent years building this or that can be a part of this acquisition.
Kovid Batra: Cool. Francis, do you have any questions that you wanted to ask Mirek?
Francis Lacoste: I think Mirek is right here in the sense that these three types that I said, or four, you know, if you split the first two, they will often overlap. This is what is always interesting about the Heroku acquisition, you know. Heroku was a strategic acquisition. So, what it means is that the first thing that they do is they will usually give autonomy to the product because you don’t want to kill the golden goose. And that creates a challenge because then it will mean that you will have, like kind of two independent or semi-independent organizations going by and in Heroku’s case, it took basically seven years to complete the integration. Actually, that’s not true. Like, five years after I joined, for the first five years, the technology team, I mean, Heroku had its own CEO and it was reporting to the product organization. So, the Heroku engineering organization was totally separate than the rest of the sales force and our engineering organization. And what we’ve seen is that when they did other acquisitions, that changed. You know, in some acquisitions, the technology organization is trying to be merged, you know. And this is where you kind of get these processes because you need to.. As if you’re independent, you can have these processes going on here and these processes going on over that place. And that’s fine. I mean, unless you need to align roadmaps, there will be friction, but those are the frictions you need to deal with. Whereas, if you’re acquiring the technology, then the first thing that we’ll do, or the talent, it’s kind of, we don’t care about how you’re working. Usually, the way it goes is that they will kind of say, “Here’s how we work, and you need to align with that.” Sure, we’re open.
And then, there’s a challenge of how we can influence the culture as per the acquisition, because you have good things. And there’s a size, you know, so it’s usually the smaller ones to influence the bigger one, but that’s very hard. And it will really depend on how you’re able to hook in into the process, build the relationships, all of these things.
So, even though all the problems will happen at some point, the schedule on which they will happen, these integrations will differ based on the integration type because the first thing they do when it’s a product, you know, at the acquisition, usually you can expect like they will merge the sales team rapidly. And in Heroku’s case, that took a while. But in other acquisitions, first thing, it didn’t take long. That the sales team at that exact target or the sales team, the go-to-market of Tableau were integrated in the go-to-market, the general go-to-market because you want to go to the customer with a unified product offering, even if the tech, I think the customer experience is we’re using two different products here. You know.
Kovid Batra: Right. Coming back to Mirek’s challenge after the acquisition. Having the capacity utilization done properly. Is that something that you have also experienced and is there anything specific that you have done at that point of time? Because I can also feel this that as soon as an acquisition is done, there is a lot of context to gain. There are a lot of things for people to first get on board with and then see how teams can be utilized at every level. And the operating style of every company that comes in would be different, right? So, there are multiple areas where you need to first get yourself onboarded after that position and then, ensure that everyone is utilized in the right place. So, Francis, a question for you. Have you experienced such a thing? And how did you navigate that situation?
Francis Lacoste: Yeah, I mean, Heroku’s, acquisition was kind of special in that case, you know, because these questions really took years to materialize. So, Heroku Engineering and Heroku Product were split, you know. And then, Engineering went into to report into the general Engineering org and same thing with Product. And then, these questions started to happen.
And then, there’s these things. Okay, well, is that capacity here? Can we use it for something else? You know, again, do we want, this is less prioritized and the challenge there was kind of often there’s not a lot of knowledge or you have to explain how your product and your technology fit together. And you have to understand how you need really to dive into the understanding of each part.
Kovid Batra: Yeah.
Francis Lacoste: And especially in a big organization, the decisions are made without really the details of the context. So they will say, “Oh, we can cut that.” You know? Or, we were going to ask them, but then it has a huge impact on the product because it’s..
Kovid Batra: It is not looking into deeply. Yeah.
Francis Lacoste: This is critical infrastructure. I mean, it doesn’t seem to be much, but if we don’t develop this, then we’re going to have problems or these things are going to have problems, things like that, dependency. And at the same time, there’s often, like not a lot of understanding of the other side of what it is trying to achieve. So, the advice I would give is really understand, if you’re being acquired, you need to understand very rapidly what the business of the acquirer is, you know, the company making the acquisition, how the tech fits. And now, you fit into that because you cannot really rely on them understanding what’s going on, you know.
Kovid Batra: Exactly.
Francis Lacoste: So, you need to understand them so that you can make your case to them, you know, in the terms that they understand.
Kovid Batra: Right. Right. Mirek, for you, after the acquisition, you were heading the engineering team there. When you moved here, the developers, the team members who were working with you, did they have an expectation from you, or were they looking up to you to sort their lives into this new space? And what exactly you did, like, I want to know, like your first-hand experience there, like what exactly did you do to solve these problems of them and for them and help them get on track or maybe you’re getting them on track right now, I don’t know, just share that experience with us.
Miroslaw Stanek: Yes. So, one of the biggest challenges for me as a, you know, not the senior manager, like I said, just the mid-level manager, is that I got a lot of questions with the expectations that I could answer all of them which obviously, wasn’t true. So, obviously, when the company is acquired, I assume that on the strategic level, you have a product. So, this new management thinks about how to use this product in their strategy. You have pool of talents. So, they think about how to use, utilize those talents. And they think like long-term. My role was bridging this gap between those strategic decisions which were still, you know, in discussions basically. My work was to bridge that with leaders and the engineers, to translate that into their, basically day-to-day you know, activities. It’s very similar to the things which you do as a fresh manager in a company, yeah? So, what you’d need to do in the first 100 days, for example, yeah? So, I assume that you need to learn as much as possible about business or the product. You need to understand what are the problems of the company that you need to solve. And then, looking at your team, at the individuals, you need to find the best fit for their skills in the scope of problems that the company has. Like I said at the beginning, we are joining the company with some experience, with a track record, but, you know, we need to somehow build this credibility because this is just the potential and we need to find a way to utilize this potential, how to start providing the value.
So, basically, my 100 days were full of 1-on-1s with people in all of the positions, from software engineers to their managers, to the directors, to also product people, marketing people, data people and others, to build context. For example, one of the projects which I led at the very beginning post-acquisition was building front-end infrastructure because we realized that with the monolithic system which we had back then, we couldn’t move as fast as possible. And actually, this was one of the, you know, know-how which we brought to the organization because we did some kind of that stuff in the past. So, you know, next to those big strategic things, the product and the entire talent pool, we also brought some, you know, very specific experiences. And actually, there was a problem in the company which we could solve with that.
One and a half year later, I can say that our entire front-end application is built on top of micro front-ends. We have tens of those compared to the single one, one year ago. So, this went well. But, like I said, it had to start with understanding that this is the real problem of the company and we have resources, we have experience, we have people who can address just that. So, this was one of the two experiences I had at the beginning of the acquisition.
Kovid Batra: Perfect. I think, great job there, first of all. And, one thing that I feel is that when you have traveled this journey, there is always some looking back and saying, “Okay, I could have done this better.” Right? So is there anything of that sort, Mirek, which you think you could share as an experience with the audience that this is something that you could do better? Like broadly, I feel you did the best thing. And as Francis also said, first you have to understand the business, understand the need. That’s the very fundamental. And you got to that point rightly, having 1-on-1s and aligning the teams, bridging that gap, bringing everyone on board, right? So, this is amazing. But if there was anything else that you could have done, and whatever you did, if you could do it better in some or the other way.
Miroslaw Stanek: I think that one of the super-important things which I underestimated at the beginning is the quick merger of the, I would say, companies’ culture. So, as long as you have ‘us’ and ‘them’, and we work this way and they work that way, it’s super hard to navigate, yeah? So, you know, the truth is that usually bigger organizations that are more bureaucratic, more formalized are acquiring smaller organizations that usually move faster. But also, you know, they are moving faster and breaking.
Kovid Batra: Yeah. Yeah. Yeah, there are pros and cons.
Miroslaw Stanek: Yeah. So, I think that those are the, you know, non-technical challenges that you should address from day one to bridge this gap, to stop talking ‘us’ versus ‘them’, to see how quickly we can become one organization focused on a single goal because rather than, you know, expecting the company to adjust to us, we need to find a way to influence, to bring our experience, to help change the culture which works for all of us, rather than saying, “Okay, we work this way. And then, now the new way is not that effective. So I cannot, you know, push anymore once a day because of this or that or that.” So, I think that my role as a leader would be to answer all of those questions. Why we cannot push as fast as we did in the past? Why we have more compliance rules? Why this or that? I think that this is the thing that I should do more at the beginning of that position. Just provide all of the needed context to the former team or the organization to help them become, you know, good, empowered employees of the new organization. This is it.
Francis Lacoste: I agree completely with what Mirek said, you know. I mean, and this is similar to what we would have done differently. I think for us, it took really, too long. We stayed like ‘us’ with ‘them’ for way too long. And I mean, it was still going on, you know, when I left Heroku. In my last year, it was kind of, this was what I was trying to get to the team. It was, we were looking, we don’t know what is Heroku’s mission. And I was kind of, look, we get briefed every year at the company kickoff, which is this big event that sells for us where we have the strategy of the year, you know, and we want to know what our business is. We need to listen to that and tell how we fit into that, where, what is our contribution. Salesforce is in the business of digital transformation. How do we help customers with their digital transformation? And they were cool as a big part to play with, like at development there, but the ‘us’ and ‘them’ is strong. And this is where I said at the beginning, you know, it’s an identity problem. And there’s kind of a, the acquisition, the fact that you’re successful because you’re, you know, you’re at an exit. Especially the funders are having a dip there. Usually you’re bought, you know, I mean, even if it’s not for the valuation you were expecting, you’re still, “Oh! We’re a big deal. We got acquired.” You know? And at that time, like I said, I wasn’t there at the acquisition, but when Salesforce had acquired Heroku, it was a big deal. I mean, in Acre News and all sorts of that, people were saying, “Oh, Heroku is acquired by Salesforce because it required a lot of creds.” And I’ve seen other acquisitions where there’s some sense of pride and arrogance as being the smaller being and, “We are a startup”. “We’re nimble”. We’re really, I mean, “We have traction.” “This is why we got acquired, so they should listen to us.” “We know a lot. They don’t.” You know? So, there’s some arrogance and pride there. But the truth is, you know, especially, the bigger the differential, we need to get some humility and really start to get interested around, okay, why is there this? Because bureaucracy, it’s, I mean, it’s funny. When I was thinking, well, Mirek, you know, usually what is appreciated by the startups is the HR policies of the bigger corporations because they have more formal, you know, they have better insurance, health insurance, all that. That’s usually, “Oh, this is great!” But then it says, “Okay, this is how you should deploy to production.” Because there’s compliance issues and usually the bigger one will have to deal with this. Oh no! So, we need, as startups entering this world to kind of really get the humility of, “Okay, we probably have something to learn from them and it’s on us to tell, to understand what are the pain points and how we can solve it, probably.”
I loved Mirek’s story around the front-end development. It’s a great example. There was a thing and this is how we can solve it. I mean, Heroku was not successful in that way. You know, I mean, we kind of knew how to do deployments and all of that, but we were not really able to solve the deployment problem for Salesforce as a whole, you know. And so, Salesforce created its own Heroku, you know. And because Heroku, we were not interested. So, the arrogance is at the leadership level. So, you need to be able to jump shit and.. That was ‘ship’, I’m a little sorry. You need to jump shit in a way and embrace the new culture because otherwise you become like very protective of what you have and that’s, I mean, down the line, it’s not good. I mean, you see it, usually people will stick for their golden end, their leaders stick for their golden handcuffs and then they leave, you know, because they were not able really to integrate and find the value in that. And the people who stayed are kind of miserable. So it’s, yeah.
Kovid Batra: Totally, totally. One thing you just mentioned around, like how that cultural difference plays a role at different aspects of how you are operating. So, it could be something related to the hierarchy. People moving from a team which is small to a large organization would be happy about the HR policies, as you just mentioned. So, I have had an experience of working with an MNC and I have had an experience of working with a startup, right? The problem is that everyone, even the MNCs want or a large-scale organization wants that the team should move faster, right? Of course, without breaking things. And startups usually move faster, even though they break things, but they move faster. So, when this cultural shift happens, a startup gets acquired by a large-scale organization, keeping the team motivated that has been, like working with such a good pace and releasing features, having that clarity on what they are doing, seeing that impact, how does that transition work? Like I need to understand some detail around that part, maybe. Francis, Mirek, any one of you can answer that, like how do you keep your teams motivated with the fact that, okay, now we were running at 100, it’s going to be 50 now, right? That things could slow down for us, and still you need to keep them motivated on that journey. How would you do that?
Miroslaw Stanek: So, from my experience during the acquisition, as an individual contributor, you either join the existing team. So, this is basically like you would be hired to this company. Or the other way is you stay as the entire team, as the entire entity, and you build your stuff and your job is only to expose an interface or any ways of integrating your stuff with the rest of the product, with the rest of the business. I think that the second scenario is easier because you can still build things in your way. You can still have your, you know, ceremonies, ways of working. Sometimes you even keep the entire, you know, SDLC process or the tech stack. This is nice, you are just taking care of exposing the API or the contract or whatever.
When you join the team as an individual, I think it’s a good exercise for the company which acquires to see how their onboarding processes worked for this particular person. So, I personally look at the things of.. How quickly you can commit to production? For example. How much you need to learn? Do you have those materials which you can learn from? And then, how can you utilize them to push even a one line change to production? If you touch the production, it’s a success because you went the entire way and then you can start generating the real value and expand.
Yeah. So, I personally assume that the best motivation to people is to give them the possibility to generate value. And like I said, those are two ways of, I would say, maximizing that, yeah? And this is basically my experience from the last one and a half years.
Kovid Batra: Totally. Totally makes sense. Yeah. Yeah. What’s your take on this, Francis?
Francis Lacoste: Yeah. I mean, I agree here again, you know. The choice between the two will depend. It’s not necessarily in your hands, unfortunately. You know, I mean, if you’re able to maintain autonomy, it will depend more on the context of the acquisition or if it’s like, “We want to keep this product.” And so, they won’t refactor the teams or they will try to maintain the team’s autonomy, at least for a while so that the product can continue to grow and develop, you know. If it’s, like more technical or a hiring acquisition, then you cannot really expect autonomy. And then leveraging the onboarding process and that. And it’s hard because I mean, you’re really changing things for folks. And the trick is that even with the autonomy, there’s a clock ticking. You might not be aware of it because there’s autonomy, but autonomy is, as always, an expiration date, you know? At Heroku, it was like a lot of years. For most of other acquisitions, usually it’s more like a year, 18 months, 6 months, you know, and then, there will be, you’re on a timeline. And what is tough there as a leader is that you’re expecting to continue building the product as you are and you’re expecting implicitly or explicitly to integrate with the rest of the engineering org. You want to get ahead of it. Even if it’s, like just in six months or a year, you want to start building the relationships to.. How is it that you’re doing planning? How is it that you’re pushing to production? What is the integration aspect? And while at the same time, keeping your team autonomous. But you want to initiate these relationships. Get ahead. I mean, this is what I would have liked to do.
Kovid Batra: Yeah, yeah. I understand. And I think it’s good actually. See, setting the expectations brings a lot of more certainty to the situation and people get prepared for it. So, it definitely makes sense. First is that you give them that positive side of being there, keep them motivated and set the expectations right for the future so that they are prepared for it. So, I think that’s one good way of moving around like that.
Francis Lacoste: There’s something I want to add, you know, because I think I didn’t feel I really answered your question, initial question, which was about how we maintain the speed and agility, you know, of the original context. And this is the truth there, unfortunately, is that to maintain speed, you need autonomy. If you’re trying to centralize everything, this is when you centralize decision making, that things get slow and you get bogged down in, like, all of the coordination processes to make a decision. And this is what’s plaguing larger organizations. And so, there is an organizational philosophy at management. So, there is an uphill battle there because larger organizations that can move fast will add a lot of autonomy to the decentralized decision making. And that’s not really what is, like the common thinking in larger organization management. So, this is why it’s often unsuccessful. If you add up like the centralized decision making and the centralized process, you end up with these slow things. And that’s just the nature of it, you know, kind of. So, that’s the challenge.
Kovid Batra: Yeah, looking at the bright side would be the only option, like looking at the HR policies.
Francis Lacoste: And I mean, there are various.. The trick, and this is why I insist on relationship building because I mean, especially the larger organizations, the more they are, you can build some autonomy. Even though officially, there’s only a single way to do it, in practice, there will be multiple ways because of the history of acquisition and all of that. So, you can, if you know this, if you have the relationships when you did your training, your inventory of the lay of the land, then you know, okay, well, I can gain more time here and help steer that part of the organization into something that is more sane, you know. So, you can influence the culture, but you’re not going to transform it, you know, six months here. It’s like you’re starting a journey to nudge a little bit, the larger organization to work as a saner practice. We saw that at Heroku, especially around remote work. When I joined, it was to build a remote culture there. And when the pandemic hit, at Salesforce, the larger Salesforce organization, there was a lot of interest. Oh, what can we learn from Heroku? They’ve done that. So, our experience was welcomed and we were able to shift things, you know, in that area around remote work a little bit like Mirek was able to do around, like the front-end development. So, this is why understanding what the pain points are where we can contribute can help these micro-shifts.
Kovid Batra: Yeah, yeah. Makes sense. All right, moving on to one last piece of our discussion today around the acquisitions. This is a time of transition, turmoil, leaders themselves are figuring out that space, that foot into the new organization and trying to set up things with the existing team and the upcoming team. At this time, how do you think you can look at the efficiency of an engineering team? How can you go about measuring it? Or maybe, you should not measure it because there could be other aspects to look at at that point of time. How do you ensure that the people who are getting paid are delivering the value in that moment of transition? And how do you ensure that people are efficient?
Miroslaw Stanek: So, from my perspective, I take into consideration those four stages of team development, yeah? So, we have forming, storming, norming, and performing. And I assume that if the company is acquired, it’s major enough, fast-moving enough. So, I assume they are close to the ‘performing’ stage, yeah, where you measure the efficiency, speed, you can implement DORA metrics, you know, measure the number of deployments, whatever. But when you are acquired, I assume that you are coming back to the forming phase. So yeah, obviously, if you stay as a single team, single entity, you still can move really, really fast. You can keep deploying your stuff, you know, every single day to production. We are moving fast, but the question is if we are moving in the right direction, yeah? So, that’s why you can still keep measuring those things.
But I think that at the beginning, you know, of ‘forming’, you need to get to know people, company, business and everything. So, you understand how you can contribute to the company’s success rather than just moving fast in a totally random direction. So, I would come back to my answers from a few minutes ago. I would measure the onboarding time, basic stuff, how quickly you can, you know, come into production because, you know, you need to get access to your repositories, you need to go through all of the documentations and stuff like that. In the meantime, you know, just learning the company, learning the teams, your, you know, colleagues and everything. Then obviously, you will go to the ‘storming’ phase where everyone is debating on the ways of working and why we don’t work this way, but that way and so on. But, you know, after this turbulent time, then you can come back to the performing phase where you are optimizing, but only when you know that you are going in the right direction.
Kovid Batra: Makes sense. Perfect. Perfect. What’s your take on this, Francis?
Francis Lacoste: Well, what I’d add, again, it depends, you know. It’s really understanding how the acquiring organization answers that question because they probably already have a framework of how they’re thinking about performance, how they’re doing performance management, for instance. That’s also one of the usual sources of friction. We like the HR process, but not necessarily the performance, the way they do performance management, you know, because they have a very formalized one. Our smaller organization was always smaller. So in a way it’s kind of understanding how these questions are framed and processed at the bigger level. And then seeing, okay, how is that compatible with us? How are we going to need to adjust? And if you’re already doing that, you know, so that, because that will be an impedance mismatch that will need to be negotiated. And if you want to negotiate it, you’ll have to get ahead of it because otherwise the expectation will, you’ll just use ours.
Kovid Batra: Yeah, yeah.
Francis Lacoste: That’s very tough. The other around that question often it will be removing duplication. You know, it’s not so much, it’s everybody is busy because I mean, everybody’s busy in our company. Now, the question, like Mirek said, is kind of, “Are they busy on the right stuff?” And this is where I always recommend looking more for output, you know, what the outcomes are. I mean, not output, actually outcomes more than, like the busyness, you know, or our people’s time sheets or, you know, that, you know, oh, the number of pull requests or number of lines of code or all of these metrics which are kind of irrelevant in many ways.
But really, how is the business? Are we meeting our business outcomes? Giving transparency on how we’re making progress on those so that they can have conversations. But often, what happens is more kind of, you have a Platform Engineering team in your startup and we have a Platform Engineering, so we’re just going to merge those, you know, because obviously you should not have two Platform Engineering teams. I mean, that’s kind of naive, but it’s also a source of multiple confusion. But this is also a conversation you need to have, they’re going to come. So, you want to say, “Okay, what is this Platform Engineering team doing?” “What is their charter?” “How is it compatible with ours (or not)?” “Is merging really the right thing?” So, getting these collaborations going between peers at the startup and the bigger. If the teams have talked and have kind of an idea, when the Execs come in and say that you need to merge, you can actually say, “Well, actually, this is how we think we should be doing it.” And then, it’s much easier because the people with the maximum understanding of the context of the deals are able to weigh in on the decision.
Kovid Batra: Yeah. So here, let’s take your example here, Francis, when Heroku merged into Salesforce, there must be certain performance practices you would have already taken up, right? And then, there must be something that Salesforce enforces on the team, right? There must be some clashes over there. Can you give us an example of that? And how did you, as a leader, navigate your team and align them with that? So, it completely changes the way you are thinking, how you’re incentivized to do something in a team, right? And if that happens, it’s a big shift, according to me. How you handle that would be something that I would like to know.
Francis Lacoste: Yeah. I mean, two examples of that were, like the performance management, which I mean, Salesforce didn’t have a very formal one at the beginning. It came in later. But it required this one. The way they do promotions and things like that. So it’s kind of, okay, we need to align more with that. And it was about understanding this process & understanding how we do things. And then, there’s a phase where it’s about how we can continue to keep the spirit and the principles we have in that different process and hybridize the two. Another one was the career ladders. So, we had our own career ladders. And then, there’s kind of the, okay, well, these are the different roles. Harmonizing that. Often, I mean, the biggest job was managing expectations on both sides. Basically what we had was like an interpretation. This is that level. Here’s what that level means here. And you were seeing that even though officially, that’s kind of, you should not be doing that. I mean, the HR folks really hate that. But in practice, contexts are different and you need to have that adaptation. So, even though it was not recognized, it was happening all over the organization. It’s not like just a group who were doing that, but other teams also when they’re, kind of doing commentary on the official career ladder.
Kovid Batra: Yeah, of course. That’s there. Great, guys. I am out of my questions for now. It was lovely discussing all these challenges with you and having a discussion on all those practical tips that you shared. Any parting advice from both of you for the engineering leaders who are in a similar situation, what they should be doing, what they should be taking as next steps?
Miroslaw Stanek: So, from my perspective, I would say that your role as a leader is to find a good match between the skills you are bringing to the new company. You know, your team, the know-how the solutions, the product, to the problems which the new company has. And start, you know, start by doing that. Start by showing what’s the value of your stuff in the context of a new reality. And the quicker you sort it out, the quicker you become, you know, successful in a new organization.
Francis Lacoste: That’s a very good tip. So, two things for me. The first, most practical one is get the conversation going, you know, look at the org chart and find people who are in similar roles or where you can see that oh, if I were to look at this and it looks similar and I want to merge these things, start talking with those teams to get your team to actually start talking to these teams, just to get to know each other, to learn from each other, that sort of thing. Very informal kind of thing. It is just to encourage cross-organization conversations because that makes everything easier afterwards. You get to know people, you get to relate to them as humans. They’re not like a dam who wants to eat you or things like that. So, just encourage, multilateral conversation between similar roles and similar teams, between engineers, well, across the org. So, conversations. Then, same thing with the leader.
The other aspect that I say is kind of, keep in mind that there’s an identity shift that needs to happen, you know, from “we are this company” to “we are this bigger company”. The mission is changing, that sort of thing. And when there is an identity shift, there will be a grieving process, you know, because you’re losing an identity and you’re embracing a new one. So, be prepared to accompany the people in that journey, you know, of kind of losing the, “Oh, this is how we were.” And, “This is our startup times.” And things like that. The loss of that, because it’s a real loss, it will be an emotional impact. And then, so kind of acknowledging it and normalizing it, supporting people through it and embracing, helping them to embrace the bigger identity, “Hey, this is the new mission. This is bigger. We can do more things together.”
Kovid Batra: Totally. I think both of you, thanks a lot for such great piece of advice. Can’t thank you enough. Let’s keep this passion of contributing to the community going and let’s build great dev teams together, man.
Francis Lacoste: Thank you so much, Kovid, for providing this space.
Kovid Batra: Thanks.
Miroslaw Stanek: Thank you.
In the recent episode of groCTO Originals (Formerly: Beyond the Code: Originals), host Kovid Batra welcomes Lubo Drobny, Software Engineering Coach at Cisco. With an impressive professional background at Seimens & SAP Labs, Lubo also actively contributes to the tech community through blogging, hosting podcasts, and organizing meetups centred around product and software engineering topics. Their discussion revolves around ‘Building teams from scratch vs branching’.
The episode begins with Lubo sharing his love for programming, hiking & gardening. He also gets into the details of a life-defining moment in his career that shaped his current coaching style.
Moving on to Lubo’s career progression, we get a glimpse of his journey from Slido to its acquisition by Cisco, highlighting the key differences between a startup & a corporation. He also shares strategies for team building through hiring, onboarding & training while focusing on delivery.
Lastly, Lubo highlights the key engineering metrics for assessing team excellence and their impact on delivery and quality, while underscoring the importance of prioritization.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest who loves to organize meetups with product and with tech fellows. He loves to organize engineering podcasts. He has 16 years of engineering and leadership experience. Currently, he’s serving as a senior engineering leader at Cisco. Welcome to the show, Lubo. Great to have you here.
Lubo Drobny: Hi! Hi, everyone. Thank you for having me. I hope you will enjoy this episode.
Kovid Batra: Of course, we will. And I’m sure you would have a lot of things to share from your journey at your startup and acquisition by Cisco. So, we’ll definitely enjoy this. But before we get started on that part, we would love to know you a little more. So, if you’re comfortable, can you just tell us about your hobbies? What do you like? Some life-defining moments for you? That would be great.
Lubo Drobny: Yeah, perfect. When we’re talking about my hobbies, I would say that my first hobby, uh, programming, I think this is not a surprise. This was probably also kind of a life-changing moment. So I was just 11-12, teenager and I got my first computer at that time. It was an 8-bit Atari XL and I fell in love with this machine, not for games, but for the, let’s say, the possibility of creating new stuff, programming stuff and so on and so on. This was a very important moment for me.
But another one, it was, um, I would say, and a life-changing moment probably was when I was at a Swiss company, RSD, and my boss was a very good mentor. So this is something I probably never felt before, or didn’t have the experience when your manager or your leader is also a great mentor and helping you to grow. And this was very, very eye-opening for me. And it worked well.
And then about my hobbies, um, I like hiking. Uh, usually in Slovakia, we have nice mountains, but also around Europe, for example, Italy, the one, it’s Austria, uh, very nice mountains. Uh, I like gardening. So, this is also connecting to nature. And I like to play in my small garden. And I’m a proud father of three kids. It’s not a hobby, but something which defines me.
Kovid Batra: That’s great. Thanks a lot for sharing that. And you mentioned that your mentor, your boss at one of your companies was a really, really good leader and he guided you well. Can you tell us more about that experience of yours?
Lubo Drobny: Yeah. Uh, it was I think about 10 years ago or 12, I don’t remember exactly. And I was switching my role from technical developer to manager or engineering leader, and what needs to be said, it is a different role. It is not like evolution. So we go step-by-step. It is kind of a different role to lead the people, manage the people. Uh, it’s different than coding because computers do what you want, but people are very different. And for me, it was very important to tell him that okay, I’m kind of new to this. I would need help because otherwise, it could be a disaster. And he was very open and he, what was important was that he discussed a lot with me what he plans to do, he asked me a lot of questions, how I would approach those problems, what needs to be done, but he also really comforted me, okay, well, this is good, done. And he helped me to have focus on important stuff because at the beginning you cannot keep all balls in the air. When you are juggling, some of them could fall, but he always, we talked about it and he always told me, “Okay, this is not important. Don’t focus on it. It’s okay. You are doing good. It could be better, but we need to.” So, he was very encouraging. And this is a kind of quality. Usually, a lot of people kind of only criticize. But he was also very encouraging, very helpful always for me. So this was a very nice experience. And I think it really helped me to survive and grow as an engineering leader. Probably without him, I would, I would go back to coding and engineering.
Kovid Batra: I think that that’s a really great example. And when you, when you find someone at that stage of your life when you’re actually growing or making such transitions and somebody guides you well, you’re tend to actually learn from them, that trade and you yourself try to implement it. So I’m sure that today your team members who are looking up to you as a leader, are sharing the same emotion and feeling.
Lubo Drobny: I hope so because I think I copied kind of this coaching or mentoring style of management. So I’m, I’m not very direct. With my team, I usually talk to them trying to find, uh, the answers, the questions. So I’m not bringing the solution upfront, I’m trying to help them to find it. And I try also to coach them or mentor people around me to grow, not only as a team but also grow, uh, as persons. So it’s very important for me because if you have good people on the bus, uh, it’s, it’s a perfect setup.
Kovid Batra: Yeah, right. Absolutely. Great, Lubo, I think it’s a really great start. And talking about compassionate leadership, empathetic leadership, I think is very important these days. So let’s, let’s get started. Let’s look into more of your journey as a tech person, as a tech leader. Your stint at Slido was quite long. You spent almost six years scaling that startup from zero to one, and then this acquisition also happened. And then, you moved to Cisco. So this journey is quite interesting, at least from the outside. You tell us about your role at different points of time and how, how you took the team from zero to 50 members. And then, how did this acquisition happen where now, you are serving at Cisco as an Engineering Leader, how have things changed for you from Slido to here? I think it’s a big question to answer. You can take your time and let us know some interesting facts from the story.
Lubo Drobny: Yeah. So I hope that it will also be interesting for the audience. But in general, I joined Slido, I think seven years ago. Uh, at that time, it was a promising Slovak startup and there were around 40 people. But only five, uh, developers and two students. But at the time it was like, yeah, this could be interesting because they started to make some profit and the Slido application, if you don’t know, it’s about engagement in meetings and conferences. So, it’s a polling and questions and answers tool. So the presenter can communicate with the audience. The presenter can see the questions online. It’s soft real-time or can poll again in a soft real-time manner, uh, audience and see results and so on and so on. And looks that, uh, this is an interesting niche at the time and it could, it could grow and also the leader or CEO at the time, but the company decided that, yeah, this is a good time to scale the team and try to push more on, uh, also on engineering.
And my role since then has been the same. So, build world-class engineering and world-class products. So this was kind of the mission from the beginning. It’s kind of cliche, of course, but, this is usually the mission of everyone at a startup. You would like to build something great. But, to build something great, you need very good or great people. So as I said, it’s very important who is on the bus with you. And, so my first, of course, my first role was to start hiring and put together, let’s say, a solid process. And there were two levels to this. So, um, once it was, let’s say, kind of short-term, so find the gaps in the team, double the positions, so we are, we are strong and double the team, um, kind of in short time. But on the other hand, also think on, let’s say, mid or so, a long-time period. But we discussed that we should also build some awareness in the engineering community that, uh, we are good because otherwise nobody knows. So, um, I was focusing with the HR team on typical hiring. So, looking for the people, prepare the process, stages and all the stuff. But also we worked on some, let’s say, ‘engineering marketing’ or ‘advocacy’, how we call it. So we started to write some blogs. And we started to be more visible on meetups. Uh, lately we’ve started to organize meetups. So today, I’m helping to organize the product meetups in Bratislava, engineering, uh, meetups here in Bratislava. Uh, we started to be visible at conferences because we believe that it’s important in the long-term also to increase the awareness that we are here and we would like to build a great team. So, this was at the beginning.
Uh, then the next challenge, I would say, was finding a good structure for our teams and deciding how we would like to work. What we put together also with product leads, is that we would like to have small teams because they are, um, in our point of view, most effective for what we need. So, up to 8-10 people, not bigger. And we would like to have cross-functional teams. So, product parts, we call them ‘discovery’. So, it’s Product Manager, Designer, later also, User Researcher. And then, a ‘delivery’ part, which is the Tech Lead, engineers, front-end, back-end, and a tester. So it’s, it’s kind of a typical setup, but we’re experimenting, uh, let’s say, with the size of the team, with the roles. But in the end, we found out that this is probably the best template for us, how to create a team with it. Of course, few mistakes. Maybe the big mistake was, for example, starting the new teams from scratch because usually, we lost the culture thing. And so, therefore, we decided that it’s better, for example, to start the new team by splitting from the older one, which worked better.
Kovid Batra: Sorry to interrupt here. I have a question. You had this great strategy of, um, hiring the right folks by creating that awareness. So you started this community aspect, right? So, from there to hiring more people, you were like, it seems that at that stage, hiring becomes the highest priority, right? You want to scale, you want to grow and everything is going on. At that moment, when you are hiring, new people are coming in, the time period of onboarding somebody easily, like if we talk broadly, it takes 8 to 10 months for somebody to actually show you something productive coming out because the person would come in, gain the context and then get familiar with the things that are going around. So then, at least it takes eight months for somebody to come out and deliver something. And in a stage where you are fast-growing, how did you manage to deliver alongside hiring such folks and training them faster if you are doing that?
Lubo Drobny: I understand the question. The first point was that, uh, we were focusing on experienced people. So let’s say, seniors because usually they are able to be onboarded faster. So..
Kovid Batra: Yeah.
Lubo Drobny: So, for example, in my experience, how we did it, uh, when someone senior joins the team, the first month, okay, setting up everything. But we are in a startup. We don’t need a lot of permissions. So it’s very quick. This is your laptop and accessories. Uh, then we have, I think one or two weeks in general onboarding to the product, uh, to the company, everything. And then, after one month, I was like, “Okay, guys, what I expect is that you will do the first small release to the production.” Because we are a web application, we can release very quickly. We are using a common tech stack for the web, it’s TypeScript, Node.js, React, or Angular. And when we hire people who are proficient in those technologies, that is great. And we are not using some internal special frameworks or something, you know, you need to figure out how it works. And also we have very, very light processes. So, even when we hire, for example, a Java Engineer, after three months, they will be ready to code, ship, and deliver. So..
Kovid Batra: Oh, that’s great.
Lubo Drobny: But the best guys, in one month, they did the first release. So it was very quick, but we were focused on seniors. Then there was a question, okay, uh, what about the juniors? Because it’s, you can’t hire only, only them (seniors).
Kovid Batra: Right.
Lubo Drobny: And, what would I really like? We started the internship program which remains. And so, we decided to do a three-month summer internship for full-time and paid internships. Usually, four or five people join. And then, if they decided to continue part-time, it was really great. We were focusing on university students, of course. And this was a very great way to find very, very good junior people who are on top level, I would say. So I can recommend the internship program also for, for others. It is working for us very well.
Kovid Batra: Yeah. I think hiring the expert folks, having your tech stack pretty common and simple and sorted, having the least number of processes, and having automation in the right places can really accelerate that process of onboarding. And hence, when you’re hiring someone who is good, you can get the productivity as fast as possible, right? So..
Lubo Drobny: Yeah.
Kovid Batra: That, that really worked well for you there. So, I think that’s a good piece of advice to keep such things in mind when we are proceeding to scale, at least at that point when you are navigating towards two different goals. One is, of course, bringing in people and then training them and hiring them. And at the same time, delivery. This could work out really well. And I think the point which you started that also seemed very interesting. Like you said, we thought of not hiring people and putting them into new teams, we just branched out, uh, new teams from the existing teams itself. So, this seems to be a very interesting strategy. I think you could just continue on that. So, I’d love to hear more.
Lubo Drobny: Yeah. Because what we, what I, or what we realized, when we started teams from scratch, they came with some culture or habits from previous companies and they started to replicate this thing because they didn’t have, uh, let’s say experience from our teams, our culture and the way we work. And in the end, we realized that this is not the, this is not the best. And maybe it is more clever to, for example, we have a good team, we can hire a little bit more people there, and then, turn around and split them. It’s also easier, also for the team and to keep the culture this way if you already work in a good team and you understand how we work, what are the habits, what are the things, what is important for us, you can easily continue. So, uh, this is the, let’s say, mechanics, how it, how it works for us. I think it’s, it’s better, at least in our practice.
Kovid Batra: Definitely.
Lubo Drobny: But, of course, sometimes you need to start from scratch if you do not have, let’s say, the skills, technology, or you started with something really new, so you cannot pick it for everything. But let’s say, if you would like to have the new team with the same tech stack and the same culture, this is the better way from my point of view.
Kovid Batra: Definitely. Even I agree with that point. All right. I think, apart from this, when you scaled up and, uh, I’m just going back to that piece where the company got acquired. The way you were operating at Slido and now, working as an engineering leader with Cisco. How have things changed? Like, give me some examples, like, okay, this is how we used to do here. And now, things have changed for the better or maybe for a little worse here.
Lubo Drobny: Yeah. Of course, something changed. The thing is that, uh, we joined a very big company, a corporation. And also, corporations focus on security, definitely. So, what definitely changed was that we had to implement more certifications around the ISO, 9000, 27000, and also, another American certification for software development, security and quality. This was kind of challenging for us because we didn’t want to sacrifice, let’s say, our way of work, but we had to change some processes, of course. But we didn’t want to slow down our, let’s say, release process and our possibility to be, to be fast. Um, therefore we had to implement a lot of automation and we had a lot of discussion with the experts in this certification, how to do it. It is compliant and it is okay from the security point of view or quality point of view. But we had to do some sacrifices, I would say. So, it is not the same as before. But on one side, we, are, uh, shipping more secure products, so it’s, it’s not bad.
Kovid Batra: Yeah. Yeah.
Lubo Drobny: On the other hand, we joined Cisco as a business unit. So, they didn’t change the way, how we are organized, how our teams work and Slido is still continuing like a standalone offer. So, also, the Slido brand still exists. Also, this is kind of different, so they didn’t swallow us, I would say, but we are still living as a Slido, which is kind of, kind of nice. And therefore, we are keeping some autonomy, which is good for us to some extent that we can continue working, you know, let’s say, the way we consider them the best force for Slido. On the other hand, as I mentioned, Cisco brought on to us more focus on security and quality, of course, because, um, this company requires high levels of that and more opportunities in, uh, let’s say, integration. Integration way. So, we started with integration with Webex, of course.
Kovid Batra: Yeah. Yeah.
Lubo Drobny: This is a Cisco tool, but then we continued with the integrations with also other video tooling. But, in this cooperation, with Webex teams, gave us a lot of experience, how to do it right way and so on and so on. So, and of course, they gave us the opportunity to reach a broader audience, especially in an enterprise environment where usually the startups are not, let’s say, uh, preferred
Kovid Batra: Yeah, I know.
Lubo Drobny: Usually, corporations would like to buy tools which are strong with the maintenance and all that certification and all the stuff.
Kovid Batra: There is one more important thing that I just felt like asking. When you were building Slido and you were an independent company, the level of impact you would have felt that you’re creating with the product that you’re rolling out and then, integrating with a tool like Webex and then reaching out to like millions of users, right? So, that changes the overall feel of how you’re building it, how you’re doing it. So I think that that must have been a good experience.
Lubo Drobny: Yeah. This is, uh, this is definitely the positive thing that, uh, we were able to, to put Slido in the hands of the enterprise users, like the Webex or another integration. So this was definitely, definitely very positive. We were able to do it because otherwise, probably, we would not have gone in this direction, definitely.
Kovid Batra: Of course. I mean, even if you reach so many people, it would have taken a few years to reach there, right? So that’s, that’s a good jump there. Cool. I think that that’s interesting.
And now, the last piece that I just wanted to understand here. When you are operating with 50 developers with you, I am sure being, uh, an empathetic leader, you are trying to understand every aspect of your developer who is part of the team. But how do you exactly measure their overall excellence? How good they’re doing? How do you measure their work? How you measure their achievements is what I want to understand from you.
Lubo Drobny: Um-hm. So, what is most important for us is the product itself at the end and the value that we are bringing to our customers. So for example, if we build something in time, in high quality, very secure, but nobody’s using it, in the end, it is a failure even if we did a good engineering job. But if it is not working for our customers, we will scratch it or discard it or trim it on the part of the product. So, in the end, it’s, um, this cooperation with the product is very important for us because we are a product company. And also, my evaluation of what we are doing is connected with this, that at the end, when we’re doing and delivering something, we believe, of course, that Product did their jobs and they, they suggested a good feature or, or product to build. Uh, but this is still a very important part of, uh, let’s say, also evaluation of what we are doing in engineering. If in the end, what we built is used and it is built the way that people can use it. So in this case, the second important thing for us, it’s quality and usability, which reflects, for example, uh, net promoter score or statistics like this. So you can, uh, you, you want to measure that these deliver something, that it is a good idea from the product side, but it also on the other hand, it is delivered with good quality because we have experienced if there is some big bug, uh, in the product and our NPS is going down next week.
Kovid Batra: Yeah.
Lubo Drobny: It’s, it’s very connected, it’s, it’s very connected. And for us, it’s a, it’s a very important metric. So, it’s NPS. Then, of course, what we’re evaluating is, uh, the quality by measuring, for example, the total number of bugs or trends. So if we are able to keep it in the, let’s say, a reasonable level, so we have kind of a ‘zero medium +’ bugs policy. So, we are okay to have small hiccups in the product and we are, uh, we are okay with it. But we would like to fix, let’s say, medium, medium bugs as soon as possible. So, this is important for us. Then, uh, for us, is important, deployment pace, that our CI/CD and all this, our continuous integration, and release process is fast. So, there is no problem, that test automation is working well. So, we are measuring weekly deployment strength. And again, if we see that there are some problems or, uh, developers are complaining that something is taking too much or if the tests are unstable, we would like to very quickly fix it and address it, because this is very important for, let’s say, developers’ experience. If you have eight people, A-class people in the team, they just want to release it. They don’t want to wait. They don’t look for some..
Kovid Batra: Reviews or anything.
Lubo Drobny: ..Some excuses why they want to push it. And they want to see their work outside. So, this is very important for us.
Kovid Batra: I think this, this brings me to one important point. Like you said, you look at the bugs rate and, like you have this policy, like, as soon as there is a medium-severity bug out there, you have to resolve it as soon as possible. See, these things ultimately tell you that, okay, this is the problem, like this is a symptom kind of a thing, right? But at the end, when you have to drill down and understand what is the core, like is it a bad review process or is the initial code quality not good? Then how do you end up finding it? Uh, like, of course, you can go by the brute force method, but I’m just, uh, curious to know how you do it.
Lubo Drobny: For more, let’s say, some critical bugs or some high-severity bugs, uh, we are doing, um, postmortems. It’s usually a very interesting process. Uh, usually takes two, three weeks. So, if something happens, there is an owner of the postmortem. So, it is not about who is guilty or not. There is someone who is the owner, who is able to put it together. And it usually is investigated because, uh, you need to, you need to check the log files. You need to talk to people about what’s happening. You need to check the slight communication and you put together, let’s say some scenario, what happened before, what happened during the incident. And you would like to evaluate more things, how we reacted, if our reaction was good or it was slow, um, because maybe we could do revert or we could fix it. And, you know, there is a lot of, a lot of nuances. You can evaluate it during our reaction to this bug or to this problem. And then, of course, there are some five ‘whys’, this typical ‘why is this happening?’ and why, why, why, why. And you asking yourself more than five times to really find a good, to find the root cause of what really happened. And then, you would like to suggest a good, let’s say, some short-term fixes and maybe also some long-term, because you maybe need to just fix some code because there is a bug. But maybe also you need to fix the process or you need to fix some communication issues. You need to fix something else. Because sometimes, some problems happen. But, if you are able to react in seconds or minutes, It’s perfect from some point of view. If you can improve from, let’s say, reaction time in hours to minutes, it’s also a good deployment. This is what I want to say.
So for us, it’s also improvement, uh, important in this. Uh, time to detect the problem and, uh, time to fix, of course. And if we are able to increase those, uh, decrease, decrease those times to a minimum.
Kovid Batra: That makes sense. Perfect, perfect. Great, Lubo. Uh, this was really interesting. And, uh, when someone shares like these level of details, but with some examples, I think that’s the best part and I loved that while discussing this with you. So, I’d surely love to have another round of discussion with you on other topics related to the engineering channel sometime.
But today in the interest of time, I think we’ll have to call this short today and thanks a lot once again for giving us the time and sharing your learnings and experiences with the community.
Lubo Drobny: Okay. Thank you again for having me. I really enjoyed it. And I wish you the best.
Kovid Batra: Thank you so much. See you.
Lubo Drobny: Bye bye.
In the latest episode of the ‘groCTO: Originals’ podcast (Formerly: Beyond the Code: Originals), host Kovid Batra welcomes Jörg Godau, Chief Digital Officer at Doctorly and one of the founding members of The EL Club in Berlin, Germany. His vast experience includes valuable contributions to renowned companies such as VRR Consulting UG, Nortal, and IBM. The discussion revolves around ‘Leading with Empathy & Compassion’.
The episode kicks off with Jörg discussing his hobbies and life-defining events before delving into his role and daily challenges at Doctorly. He emphasizes leveraging user insights and business understanding for software development and aligning individual career aspirations with organizational needs during team scaling.
Furthermore, Jörg explores measuring engineering team success both qualitatively and quantitatively. Wrapping up, he shares his final thoughts on remote work.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have an amazing guest who is the founding member of the Engineering Leadership Club, Germany. This is a group of empathetic leaders who believe in supporting and mentoring other engineering leaders to lead with compassion. He has 20+ years of engineering and leadership experience himself. He’s currently working as a Chief Digital Officer at Doctorly. Welcome to the show, Jack. Great to have you here.
Jörg Godau: Thank you so much, Kovid. It’s great to be here. Just to be clear, one of the founding members, not the only founding, don’t want to take credit for everybody else’s great work as well.
Kovid Batra: All right. All right. My bad there. Perfect. So, Jack, I think before we get started and have a lot of things to learn from you, I would first want you to introduce yourself with some of your hobbies, some of your life-defining events, so that our audience knows you more.
Jörg Godau: Sure. Yeah, I can do that. And, my name is Jack, but actually, my name is Jörg. I was born in Germany, a long, long, long time ago, and then immigrated to Australia as a very small child, and I lived there for about 30 years. And the umlauts and the pronunciation were not possible. And, people in Australia don’t have umlauts. They don’t have it on the keyboard. It’s not compatible with the Australian way of saying things. So I gave up and said, right, “In English, just call me Jack.” Um, lived in Australia for almost 30 years. Got married there and then moved to Berlin for one year in 2006-2007. I plan to register at some point with the Guinness Book of Records for the world’s longest year, because I’m still here. And now I have, I have two kids, and live here happily with my wife and kids in Berlin since also a long time now, when I think about it.
As far as like hobbies, relaxation, I very much like going for hikes. So like long distance walks. So we’ve done the Camino, we’ve done the Tour de Mont Blanc, also with our children, both. And, this year we’re going to do the Fisherman’s Trail in the South of Portugal. So, and that’s two weeks where you like, we carry all of our stuff. So it forces me to not carry a laptop or other things. So I, in that time, I also can’t work. So it’s a, it’s a very good way to switch off and have a bit of digital detox.
Kovid Batra: Perfect, perfect. What about some of your life-defining moments? I mean, anything that defines who you are today.
Jörg Godau: I think I really like this move to Germany and this plan to like, you know, travel around Europe and do random things for a year. That was a big difference. Obviously as a parent, like having children, you know, every parent will tell you like children change things quite a lot. I think most recently, like probably actually joining Doctorly and having the chance to really almost build something from scratch in a startup environment and really like be able to very directly shape the organization and shape the way things move. These are all like, and they’re on different levels. No one is like.. Personal, travel, seeing the world, experiencing different cultures. One is more like the family life and the other is, is certainly the work life.
Kovid Batra: Great. I think, I totally relate to it. I personally love to travel. I though don’t have a kid right now, but I definitely feel so that it changes your life completely. So I totally relate to that.
Jörg Godau: Yeah. And for us to Australia, like my wife is also like, was also an immigrant to Australia. And, for us, Australia is very far away, right? Like, it’s far away physically. It’s far away in terms of its involvement with world politics. Like in Europe, like world politics is like two hours drive away is the next country, right? Like in Australia, two hours drive away, like that’s a trip to see your friends, right? It’s not like, it’s just not the same.
And also in terms of cultural access. Yes, like people go to Australia with art exhibitions and cultural exhibitions and concerts, but even for those people, it’s a lot of effort to go. So it’s less accessible. Right? In Europe, if you want to see anything, like cultural concerts, ballet, art, it like, there’s just so much here that it’s, I think actually impossible to see it all, which is a different approach.
Kovid Batra: Yeah, absolutely. I agree to that. Great, Jack. I think thanks a lot for sharing that with us. And now, moving on to our main section where we would love to learn a lot from you, but keeping the time in mind, let’s start with something very, very basic. Like you are currently working as a Chief Digital Officer at Doctorly. So, tell us what does Doctorly do, what is your role there and what are your daily challenges?
Jörg Godau: So, Doctorly’s vision is to enable people to live healthier lives. This sounds beautiful and like, you know, cloudy, but like, okay, how? And so, when the founders of Doctorly originally started the company, they looked at what are the real problems in healthcare and in Germany and probably in many other countries. So the problem, one of the problems is the communication and the digitalization of healthcare. In Germany, patients become data mules. You go to a doctor, they give you a piece of paper, you carry that piece of paper to somewhere else, they give you more paper, you carry it back, and you end up with like these massive folders of paper which you probably don’t understand and don’t want. If you lose it, they get very angry at you because you have, they have to print it again or something. So, this process is terrible. So we thought, okay, let’s build something for the patients to improve it. But you can’t because it’s not the patient’s job to put this data. The doctor has to put it and the doctor has to get it. At that point, we realized that the source of the issue and the core of the problem is doctors are confronted with very old-fashioned software. The software that doctors use in general in Germany today started to be built in the 90s, the 2000s. If you’ve been around for a while and you can recognize a Delphi application by how it looks, this is how they look. They look like Windows 95 Minesweeper. Gray bevels. Push the wrong button, it explodes, right? Like, it’s really, really bad. And they run it on computers in their office. So, backups, security, any of these topics, super, super challenging, right? Because like, while they do do backups, they never test the restore. If you don’t test the restore, you haven’t done a backup, right? Like, it’s like, so all of these things led us to start building the core Doctorly product, which is Practice Management software for German doctors, fully cloud-based. They don’t have to worry about anything. They get updates every night, like, they get, like, data backups. We do it. It runs on a professional data center, with professional people supporting the machines. And so, they just don’t have to care. So they can concentrate on the patient. But now already, the data is digital and the data is somewhere central. So we have the first step in being able to transfer the data. And in the next, in the next period of time, we’ll start also building the patient app and a platform and a marketplace so that the patients get control of their data and can say, Hey, I want to send it to this other doctor, but we have to start with the doctor first. That was the real core of us.
Kovid Batra: That’s great. I think that’s a good finding there. Yeah. Please continue. Sorry.
Jörg Godau: Sorry. My daily business, I run everything to do with technology. So the CTO reports to me, the developers, scrum masters, QA, architecture, cloud, all of this is my responsibility. And it goes a little bit further. And as the Chief Digital Officer, I’m also responsible for security, data privacy, and topics like this. So it’s managing all of the software development, delivery, and running of the software for the doctors, but also making sure we’re doing it in the right way that it’s compliant with regulations. And it’s Germany, so we have many, many, many regulations. I think if you print the regulations and the source code, the regulations will be bigger.
Kovid Batra: Yeah, that could be possible. One interesting question here. So, are these doctors ready to use your software immediately or there is an adoption challenge and like, do they pay for it?
Jörg Godau: So the doctors pay for the software, yes. Our prices are very similar to the prices that they normally pay for what they’re used to at the moment. A lot of doctors are ready for this because if you go to a doctor’s office and ask them, “Do you like your software in Germany?” The answer will be no, but they have very little choice. There’s not very many companies that do this. And some of the big companies actually have six or seven products. So the doctor can switch from one product to another, but it’s actually still the same company in the background.
Kovid Batra: Yeah.
Jörg Godau: And one of the things that these companies also do very badly is, you know, updates we’ve seen, they send like not floppy disks, but CD-ROM disks to the doctors and the doctor then has to install the update. Or like some of them you can download the updates. But if somebody accidentally clicks ‘update now’, then the practice can’t work for two hours or three hours. It’s like, and you’ve got all these angry patients who want their like treatment and your computers are just effectively broken.
Also, terrible customer support is another problem. Like, we have very good customer support. We have people who actually used to work in doctor’s offices working in our customer support. So they know, like when somebody calls up, they know what this is. They know, like how important it is and they can actually really help these people. So, doctors are ready. There is an adoption challenge because we have to get the data out of these old systems into our system. That’s the biggest challenge. So lifting the data from, like in the physical office. And if the doctor has, we have it sometimes hundreds of gigabytes of attachments that they’ve kept over the last 20 years, and a very bad internet connection. It takes a long time to upload. Yeah, but that’s just the feature of Germany and its internet providers as well.
Kovid Batra: But as you said, like, doctors are not very adaptive or receptive of the new tools. First of all, uh, I really appreciate the fact that you bring in a lot of business side information, user side information to your job, being a digital officer, a technology officer, I really appreciate that you have that business perspective in place and what exactly do you think you do with all this information and understanding of your user when you build your product, because that’s very important. Like, when you’re building technology, if you have that level of empathy, that level of understanding for the users, I think you can do a tremendous job at building the software right. So can you just give me some examples? Like, yeah.
Jörg Godau: So, we actually have partner practices which we work with and they work with us even before we’d launched. We worked very closely together with our partners and our product owners, our designers were able to go to this doctor’s office and sit with them and watch how they work and watch what’s not working in the old software or watch what is. And the old software is not all terrible, right? It’s old, but it’s not all terrible. It works. And some things are actually quite good. So they were able to go there and see what are the processes in the office of the doctor and where can we have the biggest impact. So our aim is to actually reduce the admin of the doctor like by building systems that reduce the admin by 40-50% so that they can treat faster and the limited time they have, they can focus on the patient Average German doctor’s visit for a normal patient- six minutes, including ‘Hello’, ‘How are you?’, ‘Goodbye’, ‘Here’s your medication, take it three times a day.’ And in that time, the doctor also has to write down all of the billing information. So, making all of this admin stuff easier means that in those six minutes, at least the doctor then can concentrate on the person in front of them and what they need. So this is super important.
Kovid Batra: Makes sense. So, what are the biggest challenges you see today in your role that you are tackling and has the biggest impact?
Jörg Godau: Right now, organizationally, we’ve reached a point where we are now focusing more on scale. So, having great software that does the right things. That’s certainly like an essential first step, but now we have to focus on scale. So, instead of adding 10 customers a month, adding a hundred a month, adding a thousand a month, what processes do we need to make sure that each of those also gets the same great support that the first 10 got? Yeah. Like, so, because if you have 10 customers and you have one customer support person, okay, he can talk to all 10 every day for an hour. Like, and it’s fine, yeah? But if you have a hundred, a thousand, 10, 000, it becomes much more about processes for scale, giving people access to their own support. So, self-service support, really clear instructions, or even better, building applications where you don’t need instructions for. And this is super important that it’s really intuitive, that it’s very easy.
On the other side, as we’re thinking about platform, integrations, marketplace, how do we enable somebody else to build plugins for our product? Like, I don’t want to build everything myself. There are, like different medical image formats. People have built great viewers for this that display all information with different colors and everything. It works. They’re really, really good. How can I enable that company to build a plugin that integrates with my software so that it runs, and the doctor can go to like a marketplace page and say, “I want to use this viewer.” “I want to use this telemedicine thing.” “I want to use this prescription stuff.”? And they have a choice then, but they don’t have to use 12, 15, 20 different products because they don’t like that because the products don’t work well together. So this integration and scale challenge, those are the biggest topics that we’re working on this year.
Kovid Batra: How do you exactly tackle this problem? So, if you could give me an example, I think I would be able to relate more here. Let’s say, we talk about having integrations, right, with third-party software. So what kind of challenges do you really face on the ground when you go about doing this? And you as a team leader or the like the whole organization, technical leader, what, what steps do you take to enable your team to do that efficiently?
Jörg Godau: Yeah. There’s all of the usual challenges, like when you integrate with a third party, like, how do you exchange information with them? How do you actually, like assure that the data is travelling in the right ways, that the data security is met? This is something where we have to be very careful when we’re integrating with third parties that, like, they don’t do things in a way that is against German regulations or against data privacy regulations. So for example, even if you take something as simple as appointment booking, right? Like, the patient wants to book the appointment. The doctor wants the patient to book the appointment. But, which data is shared? So, if you book an appointment with a psychotherapist, this already gives quite sensitive information about you as an individual, right? Like, you know, because somebody can, from just the calendar entry, understand, hmm, Jack has booked an appointment with a psychotherapist, maybe there’s something, like, wrong with him. So, we have to be very careful about those regulations. And then, it’s all of the standard stuff. How can we secure the communication? How can we, like make sure that the data is transferred accurately? How can we keep the systems reasonably decoupled? Yeah. Like, you don’t want to be reliant on somebody else and they don’t want to be reliant on you, like building these principles of decoupling. And then, those are the architecture challenges. And then you have on top of that, how do you share authentication? How do you validate the users? Where’s the primary source? Like, is the primary source our system, the other system, how do you match? You know, many people have the same name, right? So like, and even the same date of birth. And Germany has a population of like 80, 90 million people. A lot of those are double ups, right? We have a lot of like Müller and Schmitz. Yeah. And like, so you have to be very careful, like how you, like you don’t get the wrong appointment with the wrong person. So, some things that seem simple, become then bigger challenges at scale.
Kovid Batra: Makes sense, totally. When you encounter these challenges, these are some things that are to deal with the product and technology, right? Along with that, I’m sure you’re handling a big team there. There are people challenges also. So, this is one important topic that we usually discuss with the CTOs and other engineering leaders who are on the show. While you’re managing people, it is very important to see as your company scales, the people progress, right? And when you’re enabling a team, you need to make sure that people take the right career path. Like, you wouldn’t want a person who is aspiring to be into management or let’s say, Engineering Manager, you push them towards taking some technology role. So, you need to find that alignment. How do you enable your.. And you can’t go to each and every person and then talk to them and understand everything. When you are at scale, you have hundreds of developers, team members working with you. How do you impart that thought into people so that they make their decisions consciously of what do they want to do? That makes your job easier. But I think that’s very important for them to understand themselves also to align better.
Jörg Godau: A lot of this comes from company culture and values. If you set up the right company culture, the right company values, then you are actually in a very good place to allow people to grow in the right way. Doctorally, even though it’s a startup and I think altogether, we’re about 70 people now. Development about 30, 35 or technology, let’s call it technology, 30, 35, a lot of other people in sales, customer onboarding, support, you know, like these other organizational roles. So, we have four values. ‘Excellence’. People should strive to do great work. Yeah, like, fairly normal. ‘ Integrity’. You must do what you say that you’re going to do, or try to do what you say that you’re going to do. And if it doesn’t work, you must tell somebody and not, like, just hide it, yeah? It’s fairly normal as well. ‘Kindness’. Yeah, this is super, super important. And this is not just kindness to the employee, but kindness to the customer, kindness to the patient who is sitting in front of our customer, like kindness to each other, how we talk to each other and how we, like behave if you make a mistake or if you accidentally, like talk to somebody the wrong way. Go and say like, “Hey, I’m sorry.” Right? This is part of it. And, ‘Ownership’. So taking ownership of the work that you do, being responsible for the things that you do and accountable for the things. And using these four values, we talk about them all the time. I refuse to let them be written on the walls. I think once you start writing them on the walls or putting them in pamphlets, values are no longer useful.
I did this actually, we had a, I went to a, like a presentation and gave a talk in front of a bigger group of people and I asked, you know, “A show of hands, does your company have, like values?” And most people put up their hands. I’m like, “Okay. Do you know the values?” And like, half the hands, they go down. At Doctorly, every single person knows the values because we try to refer to them always and we try to use them in our daily business. So we say, “Thank you.” Thank you for taking ownership. Thank you for like, you know, doing this work. Thank you for like, you know, being kind, to like help me. And that’s really important. And when people feel comfortable and safe, then you can talk about personal growth. Do you want to become a better technical expert? Do you want to become a manager? Are you happy doing what you’re doing and we don’t, like need to move you anywhere? It’s also people, like sometimes they’re just happy doing their job. You know, like, and sometimes people don’t want to be something else. They just want to be good at their job and do this. Of course, in technology, everybody must still continue to learn because the technology changes, so you can’t be completely static. But if somebody is a great backend developer and they want to continue to be a great backend developer, and they have no vision for themselves for leadership, why should I force them? It just hurts them and hurts me in the end. So, this is really important And then, taking the time to talk to people, you know? Those are the secrets. Like, I think we all know them. It’s the doing that’s, that’s harder. Yeah.
Kovid Batra: Exactly. I mean, I was just about to say this, that even though every time you mentioned, that, okay, this is the value, pretty common, but the important point that I took away is that you are not putting them on the walls and you are bringing them into the discussions on an everyday basis when you’re working. And I think that’s how the human brain also works. Like, you have to do that reinforcement in the right way, so that people live by it. So, I think that’s pretty good advice actually.
Jörg Godau: It’s like learning a language. If you don’t use it, you can’t learn it, but you can study it and it’s okay. But if you don’t use it, if you don’t live with the language, it’s not possible to really learn it. And if you have values that you don’t use, what’s the point, right? Like..
Kovid Batra: Absolutely, absolutely. Perfect. So I think with this, one question that comes to my mind is that when everything is aligned on the cultural and values part, you’re doing good. You know, you get that feel from the team that they are very integral, they’re putting down their best, right? How do you exactly measure their success? Like, for an engineering team which is basically enabling the product, how as a technical leader, you define the success of an engineering team so that they also remain motivated to achieve that, right?
Jörg Godau: It’s super difficult, right? Like, metrics, measurements, super difficult topic. And it’s one that we’re just revisiting ourselves as well at the moment. And we’re considering what do we measure? So, at the moment, we are measuring very obvious things, customer bugs, customer satisfaction. This is quite simple. If there’s no bugs that customers find, it doesn’t mean your software is good, but it means that it’s working in a way that they expect, you know? So that’s one very easy thing. I think all development companies can measure this.
The other thing that we’re trying to do is we’re giving the teams when we ask them to build something, we actually ask them, “Okay, you tell me how long.” And they get to choose. Will it be four weeks, seven weeks, five weeks, eight weeks. And then we measure, did they get that right? So, are they able to deliver at the time when they say they want to deliver? And if not, then we have to look at what causes this, obviously. And this is a big change. We used to work using Scrum, two week sprints, deliver every two weeks something. We don’t do that anymore. Now, because the things that we build are either too small and so two weeks is too much, or too big and it takes many months. If we have a new complicated regulation that we have to implement, you can’t do this in two weeks. And you can’t, like, yes, you can build it iteratively, but it provides no value until it’s finished. And thus, you have the certification. So you can never give it to a customer until you have the signed piece of paper from, like the regulatory body.
So in this sense, we’ve now aligned our development process more to how the real world expects us to work. And that’s been a big change, but I think overall now that it’s been going for a few months, that’s been actually quite good.
Kovid Batra: Anything on the DORA metrics piece that you have seen, being implemented or thinking of implementing in your teams? Like particularly, let’s say, cycle time or change failure rate so that the teams have visibility there, or do you just think that these metrics put in the right process, which you’re already measuring would do the purpose, fulfill the purpose?
Jörg Godau: We do measure some of these things. Deployment frequency for us is not relevant because our customers don’t want the software to change during the day. You’re a doctor and you’re using the software. It should not change.
Kovid Batra: Yeah. Yeah.
Jörg Godau: Oh, they’re like, you know, if you’re Amazon or eBay or something and you have customers 24/7 and you can, like do like different things. Yeah, fine. But for a doctor, if he’s in the middle of making a prescription, and the form suddenly changes and there’s a new box, it’s like, no. So deployment, our deployment frequency is one, once per night. Finish. So then, there’s no point to measure, you know. And, obviously when there’s something that needs to be deployed, but otherwise that’s, so that path for us is useless.
What we do measure is if there is a critical bug. So, something that is stopping a doctor from doing something that’s important for the patient. These ones we want to solve on the same day so that the patient can get his medication or his sick note or whatever they need. And this is something that we track the resolution time on the bugs. So, critical bugs must be resolved within the one day, and that’s working very well. Other bugs, we want them to be resolved within the times that we, like the SLAs that we give. So we track the SLA resolution on this. But, if there’s a spelling mistake, you know, if it says ‘calendar’ with like, double ‘a’ instead of double ‘e’, nobody cares when this is resolved. Yeah. It’s an example that I’m pulling from nowhere, but it’s not important because everybody still understands it’s the calendar. They can find it. They can use it. Everything works. So these ones we don’t care about. So any of the low-level bugs, we don’t track the time on these. They have to be done. Yeah, it’s wrong. Yes, must be fixed, but it’s not such that people can’t work. So, low-level, we ignore in terms of tracking metrics because it just adds effort. Every measurement that you make costs time. Every time you look at the measurements, “Oh, we’re not resolving our low-level bugs in 16 weeks.” Yeah, and? Like, well, what does it matter?
So, this is the important thing. When you’re measuring something, you must determine what are you going to do with the answer? So, if you’re measuring a piece of wood, you’re asking the question, is it big enough to make what I want to make from this piece of wood? Yeah. It’s a very specific question. If you are measuring development teams, it’s much more complicated, obviously, but what do you want to do with the answer? If you have no, like, if you don’t know what the answer is for, you shouldn’t measure it.
Kovid Batra: Absolutely. I think it’s a very valid point that, DORA metrics or in general, any engineering metric that you’re looking at, it’s not going to be same for the other team that is working on a different product, right? Every organization, every team has their own areas where they need to focus. And you have to choose these metrics rightly so that you can make an impact rather than just putting down all those gazillion metrics there and overloading the team with something which is completely unnecessary. So I totally agree to that point and it makes sense. The deployment frequency was a very good example. Like in your case, it doesn’t make sense to measure, right? You can deploy only once.
Cool. I think that that’s really great. That was something on the quantitative part. You’re looking at engineering efficiency here. But another important aspect is the developer experience, right? Uh, you have to be empathetic of your team, trying to understand what do they feel. What are their basic needs if there are any kind of challenges? So, do you do any measurements or pulse check-ins there to understand what they need as a team, as an organization to work swiftly?
Jörg Godau: So we do the usual things like we do like 1-on-1s, we do skip-level meetings. So, managers talk to them. At the moment, actually our CEO is in South Africa. A lot of our team is actually based in South Africa. And he then met personally with all of the people in South Africa.
Kovid Batra: That’s great.
Jörg Godau: We have twice a year we have events where people come together. Our team is very distributed. So we have Germany, East Europe, Lebanon, South Africa. But twice a year we bring people, not all together because we can’t afford flying 20 people from South Africa to Europe or vice versa. But we have one event in South Africa, one event in Europe, and people get to spend time with each other. This is very important for the feeling. And we do, measure employee NPS. So internally every month we send like a very quick survey, like just three questions, you know, NPS-style survey. And then once per quarter, we actually do a feedback cycle, like a proper feedback cycle where people get feedback from their peers, from their manager, from their direct reports. So, and we gather all of this feedback and the managers then look at it together with the people and say, “Hey, this is the feedback you got. Like, your team members are really happy with the way that you work, but not so happy with how you communicate. So what can we do to help you, like communicate better?” Or, ” You’re doing good work, but your colleagues don’t like the way that you like, sometimes don’t write enough unit tests. So, what can we do to help you write more unit tests?” Like, so, like very specific conversations can then happen out of this.
And we also then rate the employees, like how well are they doing now and what’s their future potential. So we have a like a grid system. Are they doing really well now? What’s their potential like in the future? And we reward the ones that are doing really well with extra shares or opportunities to do more work or not more work, but like to like grow in their career in different ways. So if somebody says, “I want to become Senior Engineer.” Or, “I want to become Team Lead.” We then try and look at that with them together and say, “Okay. So, what are the steps that we need to take? What’s the path?” And have very clear discussions with them.
Kovid Batra: That’s really amazing. And managing remote teams like this is kind of necessary now. And if not done well, I think you will not have the right team with the right enthusiasm in place. So, totally appreciate that.
Perfect, Jack. Thanks for sharing all these insights and learnings with us. I hope our audience would love it and thanks a lot once again.
Jörg Godau: I’m very, very happy to have this conversation. Thank you for giving me the opportunity. I think just one last thought on the whole, like remote work point.
Kovid Batra: Yeah.
Jörg Godau: There are a bunch of companies now that are saying you must come to the office two or three days or like some rule for coming back to the office. For me, I think this should be taken under the premise that as a management team, as a leadership team, we cannot support you remotely. It is not about the employees, but it’s about the organization can’t do it. If you force people to come to the office because you don’t trust them, you can’t see their work, you can’t measure what they’re doing, this is not their fault. Now, like you have to find ways to actually be able to do these things remotely. It is much more work as an organizational leader, as a team lead, as a manager, to have a remote team. Because if you have a local team, sure, you walk into the office, you look, “Ah, Mary, she looks a bit sad.” “John, he seems like he’s not having a good day. I’ll talk to him.” Remote team, you have to actually spend time. You have to talk to them. Not every day, maybe if you have too many people, but regularly or in group settings. And you have to provide this. And that means you as a manager have to find somewhere the extra hours to do it. And this is the thing where I think companies are misrepresenting. This is like, ah, we like, need it for collaboration. It’s very good if the people can meet and collaborate, making like, we have it to like, we make hackathons, but the people can participate remotely, so they’re able to collaborate, able to work together or we have these events where people come together. These work, but if you force people to go to an office and sit at their desks, especially if you’re an international company, what am I supposed to do? I make the people in South Africa go to the South African office to have a video call with the people in East Europe. What’s the point? Like, this is like, it’s like at this point because we’re so spread out, it’s now like obvious that it won’t work.
Kovid Batra: Yeah.
Jörg Godau: So, I think that’s super important and we’ve seen a lot of, like news, big companies forcing people back to the office full-time, part-time. I think that this is a failure of people to adapt and not of the individuals, but of the organizations. And this is something that I’m very passionate about, like holding up a flag for.
Kovid Batra: This is a little counterintuitive thought for me, but I think it’s very true, actually. It’s the organization that has to take care of it, not the employees.
Jörg Godau: And if, if I as a manager can’t do it, if I’m not capable as a manager to manage a remote team, that’s okay. But I have to say, “I, as a manager, I’m not capable to manage a remote team. So you must all come to my office.” It’s not his fault that I can’t manage him when he’s two hours away. Right? Like, or her fault. It’s my fault because it’s my job as a manager to manage these people. And some people are not good at remote work. There are individuals who, if they work from home, they don’t perform. Yeah? But you have to either help them to learn how to work in this way or they have to find a job where they go to the office. Yeah? But it’s not like, it’s not every employee’s fault that one manager is not capable. Yeah. It’s like if you think about it this way, like if there’s 10 people and one of them has a problem and nine don’t, which one is most likely have to change?
Kovid Batra: The organization, probably. Yeah.
Jörg Godau: Yeah. Cool.
Kovid Batra: Perfect, Jack. Can’t thank you enough for all the insights and learnings. I would love to have another show with you and share more details on how to manage these remote teams better because that looks like a very interesting topic to me now.
Jörg Godau: Yeah. Thank you very much, Kovid. It was a real pleasure to talk to you and certainly very happy to talk again in the future. Yeah, thank you.
In the recent episode of ‘groCTO: Originals’ (Formerly: Beyond the Code: Originals), host Kovid Batra welcomes Ricardo Castro, Principal Engineer, SRE at FanDuel. He is also a co-organizer of the DevOps Porto Conference and DevOps Day Meetup, as well as an ambassador of the Continuous Delivery Foundation. The discussion centers on ‘DevOps, SRE & Platform Engineering’.
The episode kicks off with Ricardo shedding light on his personal interests and transformative life experiences. He imparts valuable wisdom on differentiating between DevOps, SRE, and Platform Engineers.
. He also advises adopting best practices for implementing CI/CD pipelines in startups, medium-sized enterprises, and large corporations and presenting a robust framework for cultivating effective DevOps teams.
Lastly, Ricardo provokes thoughtful reflection on whether deployment frequency truly encapsulates DevOps efficiency, or if the focus should shift towards the value delivered.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest who is an expert in Platform Engineering. He’s a co-organizer of the DevOps Porto Conference. He’s a co-organizer of the DevOps Day Meetup. He’s an ambassador of the Continuous Delivery Foundation. He’s currently working as a Principal Engineer/SRE at FanDuel. With a total of 15+ years of experience in DevOps engineering and leadership, we are happy to welcome you, Ricardo, to the show. Great to have you here.
Ricardo Castro: Thank you very much for having me, Kovid. I’m really excited to have this conversation with you.
Kovid Batra: Perfect. Perfect. So, before we get started and deep dive into Platform Engineering, DevOps, and Site Reliability, I would love to know more about you, Ricardo. Our audience would be interested to know more about you. So, tell us about something that you like outside of work.
Ricardo Castro: Yeah, sure. The people who know me know that I’m an avid music listener, so I just love music, mostly metal music. That’s the thing that I listen to the most and everything around guitar, I love as well. I played guitar for many years and it’s something that I’m trying to pick up recently, so it’s something that probably in the next few years I’ll be ramping up my skills. Also, I enjoy sports, doing sports. I practised Taekwondo for more than a decade. And now I want to try something different. So, I’m doing CrossFit and I’ll probably try some martial arts in the next year, probably Jiu Jitsu. That’s what I’m going for.
Kovid Batra: Oh, that’s so cool, man. Music, Taekwondo, from where are you getting this energy and what is the motivation to learn all these things?
Ricardo Castro: I just usually like to challenge myself. If I want to learn something because I enjoyed it, I just try to do it, even if I don’t have a lot of time. And if I really suck at something, I try to at least get to some level of proficiency, not like going to a guru or on something, but try to at least get some understanding of that, if at the very least I have some interest on that topic. And that’s how I usually try to approach it.
Kovid Batra: That’s cool. That’s cool, man. All right, moving on to my next question. Anything that inspires you or defines you in your life, any, any life-changing moment or a life-defining moment that you would love to share with us?
Ricardo Castro: Sure. So something that I really like doing is to help other people or other teams. So, before I got into tech, I worked as trying to help kids in school to overcome challenges at school in terms of, so they probably, they were bad at math or something like that. I worked at a company for a few years like that. And it’s something that I always enjoyed to get to help other people achieve their goals. So for many years in the beginning of my career, I was a traditionally a software engineer, just building features, building product, and then eventually I migrated into a more of an operational role. And I think that now we talk about a lot of Platform Engineering, but it’s something that I believe that once I went into more of that operational role was something that I always tried to do, like to build tooling and to build platforms that other teams could use. And I don’t have to be in the middle. So I’m there to help, of course, but it’s something that my goal was always to, if you don’t need me because I built you the tool or you have something that you can progress on your own, that’s cool. I don’t want to be an impediment for that. So, it’s something that usually inspires me. So, how can I get out of the way of what people are trying to do. That could mean building documentation. That could mean building a CLI. That could mean building an API or a platform or whatever it is. And my goal is always to empower you to do whatever you need to do with the least impediments possible.
Kovid Batra: More like automate everything theory, right?
Ricardo Castro: Yeah, yeah, yeah, yeah. We always find new things to work on. So, I don’t, at least for now, I don’t have that fear of getting myself out of a job. Because as soon as I finish something and I deliver something, there’s 10 other new things that pop up. So, it’s always that, like, automate, give the tooling that people actually need. So if they don’t need me, I shouldn’t be there in the middle of just to click a button or to run some command because people are responsible. People are grownups. So, here are the tools. Progress on your own. If you need me, I’m here to help.
Kovid Batra: No, absolutely. I think, it’s a little counterintuitive for a lot of people. They try to create those dependencies so that they have the security probably, but I think the right way to grow, even I believe so, that you should make up time for yourself. And to make out time, you just have to get out of those situations where you are doing just the redundant job for people. So..
Ricardo Castro: Yeah, exactly.
Kovid Batra: Yeah. Yeah. Cool, man. I think this was really interesting. It was great knowing a little bit about you. Let’s move on to our next section which is more around DevOps, Site Reliability, Platform Engineering, your area of expertise, basically. So let’s start with the very basics. DevOps, Site Reliability Engineer, Platform Engineer, I would love the audience to know from you, what’s the fundamental difference? And with each of these roles, there are some responsibilities coming into the picture. So share here’s some thoughts about those responsibilities that you see as a DevOps Engineer or a Site Reliability Engineer or a Platform Engineer. And then, what are the challenges associated with it? So, it’s a big question. You can take your time.
Ricardo Castro: Yeah, sure. I’ll try to compartmentalize that into, like DevOps, SRE. So let’s start with probably the concept that people know for them, a longer period, which is about DevOps. So, if we go back and we start seeing the origin of DevOps, the movement started to form around 2007-2008. And it had one goal, right? It was to bridge the gap between dev and operations. So, we had devs on one side. We had ops, traditionally SysAdmins, back in the day. And there was a conflict between this group of people. So, engineers want to be, or product engineers, software engineers want to deliver features, want to deliver, put stuff in production in front of customers. SysAdmins or operations people, let’s call them operations people; their responsibility is to make sure that the systems are working as they should. So, if you introduce change to a system, there’s a very high likelihood of that system having some kind of failure. So there’s not an incentive alignment here.
So on the one hand, we have, you have people that want to introduce changes to a system. On the other hand, you want people that just want to make sure that the system needs to be stable. Don’t mess with it. Just, just leave it be. And this becomes a problem because to continue growing, companies need to continue to deliver features, but then you have probably two of the most important teams in the company that are not aligned in the same objective. So that’s where, where, what DevOps try to bridge that gap. It’s around, okay? How can we get these two areas aligned into common goals? Of course, over time, we realize that it’s not only Dev and Ops. There’s a lot more Quality Engineering, Security and so on and so forth. You have to involve Product. So, DevOps nowadays, I think it’s a lot more than just Dev and Ops. There’s more disciplines that need to be brought to the table around this. But DevOps in the beginning and when the term was coined was in 2009, was never very prescriptive in terms of, “Oh, this is what exactly what you should do.” But the problem with that is that on the one hand, it gives you a lot of freedom. So, the main goal is to bridge the gap between all of these disciplines. How do I align those goals? On the other hand, some, most companies are like, okay, but I need some, you need to tell me something that I need to do to actually do that. So, what we’d started seeing around DevOps was a lot of work around how do I deliver features faster? So, it was stuff around CI/CD. How do we automate all the things? So, DevOps in the last decade started to migrate a lot into, I can build some automation around, for example, how do I, how do I build resources with tools like Ansible, Terraform, whatever tool you, you decided to use and a lot about CI/CD. How do I automate the build, deploy, test process to get stuff into production?
Site Reliability Engineering, probably a lot of people don’t know, actually was created inside Google many years before DevOps, which is kind of weird because we only, like in the last three, four or five years started hearing about Site Reliability Engineering. But, it was around 2003 when Google was facing the same problem, right? Devs, Ops, Engineering, this doesn’t work. Google was growing like crazy. So they were like, “Okay, so we need a better approach to do this.” So they tasked a team. What would happen if we take a bunch of software engineers and put them in charge of operations? And that’s the, like the gist of what happened with Site Reliability Engineering. So Google created this practice. It was made popular by the book that they released in 2016 where Google revealed what for them is Site Reliability Engineering.
Something that we need to keep in mind is that that book came after, like more than a decade of experience. So what Site Reliability Engineering was in the beginning at Google and what was in 2016, it’s not the same thing. There are continuous learnings and continuous approaches, but it’s a lot about going from production backwards, right? So, something that people know a lot is about SLO. So, Google created something that would allow them to define what reliability means. It’s not like I think reliability is this. You think that reliability is that. No, we need a common language where, where we say, “Okay, this is what reliability is.” SLOs. That’s a framework. Okay. Once we have that, we can start working backwards. So, are we achieving our targets? Are we not achieving our targets? If we’re not, what do we need to do? Of course, these two disciplines can.. DevOps and SRE can somewhat meet in the middle, because if we start from production backwards, we will probably arrive at a point where we say, “Okay, so probably one of the biggest problems that we have is that my deployment process or my build process is not reliable enough. I’m introducing a lot of problems. So, let’s automate it. Let’s improve that.”
And of course, recently we started hearing a lot about Platform Engineering. Although again, although people think it might be a new thing, it is not. If you learn, if you read, like the ‘Team Topologies’ book, which is like four or five years old, they already talk about Platform Engineering. And if you worked at a big company, like 15 or 20 years ago, you already had internal platforms. So, the concept of Platform Engineering, it’s absolutely not, it’s not new. The thing is that the advancements of the cloud and all of these new technologies that we have started to democratize how platforms could be built, making it easier, making it that companies, smaller companies, or even startups can build their own platforms easier. So, that’s why we’re starting to see a lot of involvement in Platform Engineering, which is awesome, which is good. It’s about building some kind of abstraction where, for example, software engineers have a standardized way to deploy stuff, to observe their services, how to get them running in production. There’s a lot about golden paths. So this is like the preferred way for the company to actually build and deploy services.
One common pitfall that I see a lot with Platform Engineering and I’ve been writing about that recently a lot because I see this problem happening a lot in many companies. It’s about platform teams building stuff in isolation, right? So we, you create a platform team. They go into their room. They do their thing. And then they say, “Oh, here’s the platform.” If you don’t treat your platform as, let’s put it like, as a product where you have customers, which are other engineers in your company, you’ll probably have a lot of trouble because you probably built the wrong platform or at the very least, something that is not aligned with what people are expecting. You’re probably not solving their problems. You’re probably creating some roadblocks. You don’t have the vertical or the business knowledge, the business domain knowledge that those teams have. So you’re probably building, “Oh, so here’s a nice way to deploy this kind of application.” They’re like, “Okay, yeah, but I have this requirement and that requirement and I can’t do that with your platform.” So, that’s probably the most common pitfall.
So, just to summarize Platform Engineering, you should look at it as some kind of a product where you have customers, which are other engineers, and then you have to build, like any other product, the features that they need. Of course, every once in a while, you need to risk it. You need to try new things and you need to put new stuff in front of your engineers. Sometimes we don’t even know what we need, right? It’s like product development and the customer only knows what he wants when he sees it. But if you have customers like your fellow engineers and they have problems, the platform should be aimed at solving those problems. Maybe deployments are too slow. Maybe every time that I need to create a new project, it’s a hassle. So if I have an easier way to do that, it would be awesome. Maybe I don’t know how to observe my application. Okay, so my platform could build some automation and I get that for free. All those kinds of things. So you should be building iteratively and should be solving problems and making your teams faster, not trying to build a platform and then force it into your teams. And then at the end of the day, you will not be happy because adoption will not be great. Your teams will not be happy because they will be forced into doing something that is not helping them.
But Platform Engineering, I think it’s probably one of the biggest advancements that we’ll have in the operation side of the things because it allows you to automate a lot of stuff and it allows product teams to actually build faster because okay, I know exactly how to deploy my application, how to observe it. It’s easier. I need to focus or spend more time fixated on the problems that the business want to solve and not how I’m going to operate this in production.
Kovid Batra: Right. Makes sense. One question, regarding Platform Engineering and Site Reliability. So, the people who are actually on this team, who are taking care of, I would say developer experience, because ultimately you are impacting the developer experience with it.
Ricardo Castro: Yup.
Kovid Batra: How does a day-to-day basis, the role of a Site Reliability Engineer differs from somebody who is involved in DevOps. Like, what I could understand from your explanation is that both of them have the similar goal of taking care of the teams. There should be things running, it should be in line with automating or improving the overall acceleration or velocity of the team, right?
Ricardo Castro: Yup.
Kovid Batra: So, both seem to be similar levels. How does their role on a day-to-day basis differ from each other? And yeah, I think first is this.
Ricardo Castro: Yeah, sure. So, it is, of course, will be different from organization to organization. There is no silver bullet and you have to adapt to your own reality. What I see most often is that when you’re talking more about DevOps or traditional, I always struggle with the term DevOps Engineer, because again, I think DevOps is culture. You don’t need DevOps engineers, but let’s go with what the industry has come up with. What I usually see with DevOps teams is that they usually are responsible for some part of the automation. So probably they build, I don’t know, they build your servers or they build your Kubernetes cluster, whatever it is, they help you automate your CI/CD pipeline, for example. But then it’s probably up to you and your own responsibility to just, okay, so you have all this tooling, just go do whatever you need to do. Site Reliability Engineering usually starts to focus on production, right? So they start looking at production. You’re like, okay, what does reliability mean? One of the first things that site reliability teams do when starting to build this culture inside a company is, okay, we all have a different opinion of what reliability means. Okay, so let’s build a common understanding. Is it SLOs or whatever framework you want to do to make this definition? Once we have some nice definition, do we have the observability that we need to actually understand if you’re being reliable or not. So, site reliability engineers usually are very focused on observability. We have the metrics that we need. We have the logs that we need. We have the traces. We have whatever we require to actually inform that reliability and say, “Okay, it’s good.” “It isn’t good.” “Are we achieving it?” “Are we not being reliable as our customers need us to?” Usually only, only then they start to tackle more reliability issues in terms of unless there’s something glaring in your system. So, let’s say that you build an API or build a site and it’s constantly down, right? So, probably the first thing that the Site Reliability Engineer or engineering team will try to do is around, okay, let me like try to mitigate this or make it less painful, let’s put it this way. But if you’re getting, if you already have a, if you’re decent, you probably want to get from decent to actually meeting customer expectations. So that’s why you need a reliable framework. That’s why you need an observability platform, whatever it looks like in your organization to actually understand, okay, I’m meeting these goals or not.
Usually where these two DevOps engineers and SRE teams meet, it’s more or less right in this, in this, at this point, right? So you’ll probably realize once you have the observability and SLOs, that you could improve, for example, the way that you deploy applications. The way that you are running in production, you probably need, I don’t know, maybe you need a circuit breaker. Maybe you need to implement rate limiting. So, SREs can help with that. And the other way around. So once, DevOps engineers have a lot of, a lot of this in place, they can start then operating with teams. But I would say that these two approaches usually start at different spectrums. And then, eventually meet in the middle. So again, just to summarize, SREs are usually a lot involved, at least in the beginning of about defining what reliability is and what it looks like, a lot about observability. So they need to understand what is happening in your systems and as DevOps engineers are usually in the beginning focused a lot about automation, building CI/CD pipelines, and then eventually converging. Of course, just to finish on this, what SRE looks like in Google and in other organizations will be completely different. So, people need to take that into consideration because it’s tempting to just look at the SRE book and say, “Oh, I need to do this exactly as the book says.”
Kovid Batra: Yeah.
Ricardo Castro: We don’t, so the book is quite big. So there’s a lot there to learn from. And of course, companies like Google, Amazon, Meta, they have probably challenges that, I don’t know, a handful of companies, in the world have. So they need to tailor those solutions to their problems. But we can do the same, right? So we can see, oh, this is how Google does things. So, do I have a direct relationship between what they do and what I do? If not, are there similarities, are there differences and make that adaptation?
Kovid Batra: I think that makes a lot of sense. And the point that you mentioned here, you have to treat, if you are an SRE or let’s say, a DevOps Engineer, you have to treat other developers as your users and the platform as your product. So while you are building that, you have to have that ideology in mind to actually improve the overall experience, impact the overall velocity of the team, the quality of the work they’re producing. And I think most important part comes into the CI/CD pipeline itself. Like that is one critical portion of the whole delivery pipeline, I assume. So, you are an expert at it. What I would want to learn from you is what are those best practices or what is the ideal way to implement CI/CD for a startup, for a medium-sized company, let’s say who has 100, 200 developers, and then we move on to a larger size company where you have, let’s say thousands of developers.
Ricardo Castro: Yup.
Kovid Batra: Of course, For each stage, there should be a different set of practices. There’s a set of considerations that have to be taken while implementing that CI/CD pipeline. So, can you just throw some light over there?
Ricardo Castro: Yeah. So I think that overall, the problems are the same between your either a startup or a big company. So if you think about CI/CD, it’s the concept that we want to integrate code as fast as possible or integrate regularly. Let’s put it this way, regularly. And about continuous delivery. It’s about you’re getting stuff in front of your users. At least that, that’s my definition. And what we see a lot in the literature, some people, and this is a caveat, think about CI/CD as just automation. And what I would say to that is that if you have an automated integration step and an automated deployment step, but you’re not integrating regularly, it’s not continuous integration, because if I have a feature branch that spawns, I don’t know, a week, a month, and then eventually I integrate, that’s not continuous integration. That’s automated integration, but it’s not continuous. And the same thing with deployment. Yeah. For me, continuous deployment is putting stuff in front of your users, not just getting to the point, “Oh, this is in the process of being released.” And then it stays there for a week, a month, six months. It’s like, okay, I’m not putting it. I don’t even know, if it works or not. I like a lot of the philosophy of Charity Majors. She usually says that if you don’t put stuff in front of your users, you don’t really know if it works because probably we’ll discover problems with that.
So, what I would say is that independent of the size of your company, what you want to do is to make it faster, right? So, I’m a developer. I do a pull request. It is reviewed. I want to get feedback as fast as possible. Of course, that for smaller companies, they don’t have the budget in terms of either money or engineers to implement a lot of that themselves, so they can rely on SAS services if they have the budget to automate a lot of that stuff. And now, with the CNCF, we have a lot of tooling around that that can make it really easy.
As you start getting bigger and bigger, you probably will start to have more requirements. So, you’ll probably start having the need of more custom things. You’ll probably have more systems. You’ll probably have legacy systems where just using a tool out of the box doesn’t work. So, you’ll probably start to have to build some stuff internally. What I would say is to continue to leverage open-source tooling as much as possible. That’s always a business advantage because you won’t get stuck or you won’t get pulled in into a specific vendor. And then, yeah, all of your things are on top of that of that platform. It would be a strategic advantage. But the goal is the same, right? I want as a developer, I want to get feedback as fast as possible. So, I want to submit something and I want to, I don’t know, that my tests run faster, run fast. I want the deployment to run fast. So as an engineer, if I’m put into a place where I do a PR is merged. And then it takes one hour for the tests to run, one hour to deploy something. So I’m just sitting there like for a couple of hours like, “Okay.” And then to have something and I am like, “Oh! Actually, there’s a problem.” An automated test run or a user complaint. And it’s something very simple. And then I have to spend like two or three more hours just waiting for that whole process to finish, of course, when you’re probably a smaller company, you won’t have a lot of this, a lot of these problems because usually your systems are small. But again, that’s one of the differences between.. Usually, what I see with startups and bigger companies is that your system starts getting bigger and bigger and it’s easy to start having these delays, right? So I submit a new change and it takes a one hour, two hours, three hours for my change to get into production. So again, the goals are still the same. You’re just facing different problems in terms of size, scale. Bigger companies probably have more custom things that they need to do and they have bigger systems. So, they have to invest more in terms of time and money to actually fix those issues.
Kovid Batra: Yeah, Ricardo. I think that that’s really interesting. Now, looking at certain practices that you need to, like adopt before going ahead and solving those problems for the team. So, is there a specific framework that you follow when you do it in your teams? Any kind of philosophy that you adopt before approaching, like one you already mentioned on a broader level that you should treat them as your users and platform as your product. But is there anything else that goes into building some really good DevOps teams there?
Ricardo Castro: Yeah. So something that probably people know and have seen in the industry is a lot of talk around DORA metrics, right? So, for people who don’t know, it’s a set of metrics that allow us to understand the level at my organization or my teams are at. It’s a kind of a standardized way. It has been done, if I’m not mistaken, since 2014. There’s also a great book, which is called ‘Accelerate’, which explains the origin of where the metrics came from and the, the whole scientific approach around it. And it’s probably the best way that we have right now. Maybe we can come up with something better in the future, I don’t know, but it’s probably the best way that we have right now to actually understand at what level, in terms of proficiency, is my organization. And those metrics are deployment frequency, lead time for changes, time to restore a service and change failure rate. And now, I think last year, a new metric was introduced, which is reliability.
So essentially, it’s some centralized ways that I have. If I measure these things, I can understand if I am an elite type of team or I’m at a low level. So something that we’re doing in our organization is measuring these things. For example, that we were talking about CI/CD, if my lead, my lead time for change is more than six months, I’m at a low level, right? So it means that I have some change. I want to introduce that change. And it takes me six months to get that into production. Also, it allows me to compare between organizations. Of course, this needs to be taken with a grain of salt, right? So we can compare ourselves, like blindly. But it allows me to understand, “Okay, if my company takes six months to take a change to production, I can’t be at the same level as a company that deploys software continuously every single day. And the same thing for time to restore a service. If every time I have a problem, it takes me I don’t know, hours, days to fix it or to mitigate it, I’m not at the level that I want to be at. So it’s something that we’re doing internally. It’s something that I’ve done in the past and I think it’s a good idea to at least analyze the DORA metrics. See if it makes sense in your organization. Of course, they’re not the only metrics that you should look at, but it’s a standardized way. And it’s a good starting point because we have a lot of data from the past. I think the respondents in the last few years have been in the order of tens of thousands. So we have a lot of data that we can rely on and to be sure that these metrics are actually relevant. And these metrics are something that can allow me to understand, “Okay, if I’m at an elite level of deployment frequency, I’m in a good place. If not, it’s something that I probably need to work on and improve.”
Kovid Batra: Totally makes sense. I have one question related to this. One of the metrics, that we usually measure, which is deployment frequency, and you have just mentioned about it, a lot of engineering leaders to whom I’m talking, sometimes they challenge this thought that why is it even important? Like, we are doing it once in a week or once in 15 days. And if we’re rolling out features at the pace that we want, the deployment frequency doesn’t actually tie to that because ultimately it’s the value you want to deliver. If you are delivering it in small chunks or you’re delivering it in one big packet within 15 days, it’s the same. So measuring deployment frequency and understanding the efficiency of a DevOps team or a dev team on the basis of deployment frequency is probably not the right way. What’s your thought on that part?
Ricardo Castro: Yeah. So, I’ll start with the caveat and then I’ll give my opinion. So there are some cases, for example, there are services that I don’t know, don’t have a lot of development, right? So it’s a service that is old or is a service that is very stable. So then, there are no new features. So it’s normal for those services or that, that group of services to not have a lot of deployments. So, that’s the first thing. So, it’s not like a one size fits all. Maybe I have a service that I don’t know, deals with authorization and I’m, I’m done with authorization. I don’t have a lot of things to do that. So it’s perfectly normal that I don’t do deployments on that service every day.
That said, now there’s what you were talking about. If I’m delivering, for example, let’s use the timelines that you said. What’s the difference between me developing or delivering something like every day or delivering like the entire value once every two weeks or once a month. What we’ve seen and that’s why it’s important to have all the metrics and not one of the metrics in isolation is the fact that, for example, if you do a deployment every two weeks or a deployment every month, you will probably have more time with the other metrics. So you will probably be introducing more changes at once. So you will probably introduce more failures because it’s one of the, if not the most common thing to introduce a failure in a, let’s say in a system. It’s to introduce a change. And a deployment is a change. So the bigger the deployment, the bigger the likelihood of that problem of you introducing a problem in, in the system. And of course, time to restore will be impacted because if you introduce a small change, you have it in your mind. You introduce it every day. You just work on that code. You can understand it better. It’s like, “Okay, so I introduced the change and it was a failure. Okay. Let me look at it.” You probably get around much faster saying, “Oh, the problem is here. It’s fine. I’ll fix it. Deploy it again.” If it’s a big change, you’ll probably take a lot longer to get there because there was a lot of code that you put into production. What is happening? You have to pull in a lot of people. So you work on this piece, you work on that piece. What the hell is going on? Most likely your time to restore will be impacted because you will take longer.
And of course, lead time for changes will also be impacted, right? So if you introduce a small change every single day, deployments will be a lot faster. If you introduce a big change that is in a lot of services, deployments will be more complex. That’s another thing actually interesting to measure. It’s about the complexity of the deployment. If I need a coordination between services, if I’m introducing a big change, it’s something that I need to take into account in this consideration.
Of course, something that people usually tell is like, oh, okay. But for me, for actually to introduce smaller changes, I need to write more code. Oh, because maybe I need like some feature flag or something like that, or maybe I need to introduce somewhat of incomplete code just so that I can guarantee that it’s working in production. That’s true. But it’s usually at a very small scale, right? So maybe you need to, just to ensure that even if the feature is not complete, that the code that you’ve written doesn’t break anything that is there. Right? So maybe you need to put some defensive measures, like, for example, a feature flag just to make sure that no request passes through that code. That’s true, but it’s usually very small in terms of scale, and you can revert it back really fast. Reverting a big change is much, much harder.
So, just to summarize around that, I understand the concern, but it’s what we usually see. And when you use these metrics as a whole, it’s that when you introduce a bigger change, usually other metrics are impacted because you introduced a big change into a system. You’ll have more problems. You’ll take a lot more time to restore. And if deployment frequency is usually higher, it means that you’re not introducing big changes every single day. You’re introducing small changes, and you can recover much faster and deliver it at a higher speed. And what we see, actually, it’s something that there’s always a discussion about if you’re going faster, you break more things. If you look at the data from the past six or seven years from the DORA metrics, that’s actually not true, right? So, the teams that actually deliver faster and they’re deploying more frequently, take less time to restore service and have less failures.
I know that this might sound counterintuitive, but it’s what the data shows. It’s not like us saying, “Oh, this is like a utopia.” No, it’s what the data shows us is that if I deliver smaller changes more frequently, I actually introduce less failures into my system. And when I do, I’m much faster to recover.
Kovid Batra: Totally. I think it makes sense also, even though it might sound counterintuitive, as you said, but it definitely makes sense. If you’re bringing in a small piece of change, the error percentage, keeping it the same, the amount of absolute error would be much less. So, of course, it definitely makes more sense to deploy frequently.
I think the challenge comes in with the part where people want to set up, need to set up that pipeline for automatically deploying and doing it fast. That’s where the sluggishness comes in. But I think it is very important to have such a system in place if you have the bandwidth and the right team to do it.
Ricardo Castro: I understand that that’s an upfront investment, but it’s something that we can look at the data because again, it’s not me and you just having a conversation and sharing our opinion. It’s like we have data. We have data on that that actually can tell us, yeah, this actually works. So, although there’s an upfront cost and an upfront investment, the data tells us that at the very least at the medium term, you will start getting a lot of benefits. And if you’ve been in the industry for a few years and you have the chance to actually work in this kind of way, you start to realize that yeah actually, it is, right? So it’s not something that I heard someone talking, like someone from Netflix saying that in their organization, it’s awesome. No, I actually experience that on a day-to-day basis.
Kovid Batra: Yeah, yeah, yeah. Makes sense. Great, Ricardo. I am totally infected by the energy you have and the way you explain things. There’s definitely a lot of depth in what you are saying here, and maybe these 30 minutes are not sufficient. We might need another session for deep diving into certain issues like that. And I would love to have you for another show sometime again.
Ricardo Castro: Yeah, that sounds great. We can arrange something like choose a topic and go deeper into a topic. I’ll be very happy. I’ll be very happy to have that discussion with you. It was a very nice conversation that we had today.
Kovid Batra: Great, Ricardo. Thanks a lot. I hope our audience likes it too. Great. So I’ll see you soon and keep you posted.
Ricardo Castro: Thank you very much, Kovid. Thank you very much for having me. It was a really nice conversation. I think it’s something that is on top of everyone’s mind. People hear about DevOps, SRE, Platform Engineering, CI/CD. And it’s good that we see like-minded people just having discussions. We agree on some things. We don’t agree on something. But it’s out of these discussions and out of this brainstorming that we can actually, can start to get solutions with our organizations. So, I think it’s nice that we have a broad spectrum of opinions because again, my company will be different from yours and probably, what works for me might not work for anyone else. So if we have a broad spectrum, we can say, “Oh, actually what Ricardo was saying applies to my company.” “Oh, actually what Kovid was saying actually applies to me.” And people can, can make their own minds.
Kovid Batra: Absolutely. Absolutely. Perfect. Great, Ricardo. Thank you. Thank you so much once again. Great to have you on the show.
Ricardo Castro: Thank you very much for having me. Thank you.
In the recent episode of ‘groCTO: Originals’ (formerly: ‘Beyond the Code: Originals’), host Kovid Batra welcomes Claus Höfele, Head of Engineering at On and the author of the newsletter ‘Drawn to Leadership’. He has a rich technical background at the Doctari Group, eBay Classifieds, Sony Ericsson, and more. Their conversation revolves around ‘Engineering Leadership 101: Key skills and transition tips’.
The episode begins with Claus sharing the core function of his company ‘On’ and the inspiration behind his newsletter. Following that, he explores his definition of ‘Leadership’ and describes his journey from a software engineer to a leader. He also offers insights into his role as a Director of Engineering, managing multiple teams, context switching, and escalations, particularly in lean structures or during hiring phases.
Lastly, Claus delves into defining success for engineering teams and discusses his significant success as an Engineering Director and the contributing factors.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have an interesting guest. He’s the author of ‘Drawn to Leadership’, who summarizes leadership concepts through sketches. He’s currently working as an Engineering Director at On. He has 15 years of engineering and leadership experience. Welcome to the show, Claus. Happy to have you here.
Claus Höfele: Thank you for inviting me, Kovid. Great to be here.
Kovid Batra: The company name is really interesting, “On”. Could you tell our audience what does it do?
Claus Höfele: Yeah. Yeah. So, the company produces, well, running shoes, sports apparel, etc. So, I think maybe you’re switched on or it’s switching on the exercises and movements. Um, so it’s a company, coming out of Switzerland, but I’m based in Berlin where they have a tech hub, and, yeah, where I’m supporting different cross-functional teams, software teams, working to make logistics and yeah, producing the right types of, of shoes.
Kovid Batra: That’s so cool. Nice. And tell us something about your newsletter, the blog that you write, the sketches that you make. I checked them out and those are really interesting. For our audience, we’ll share the link in the comments when we post this out, but tell us about from where did that inspiration come in and what was your thought while bringing this to the audience.
Claus Höfele: Yeah. So, when I was a software engineer, I often went to conferences and shared my know-how about software development. And then, I got into leadership and I’ve been doing this for a while. And then recently, I felt like, hey, I could maybe do a podcast or maybe share my knowledge in a, in a newsletter. And I thought sketchnotes is an interesting twist to it because you can summarize different concepts in a very good way. It’s maybe sometimes a kind of a visual aid, like to memorize the concepts. Sometimes it’s, you know, bringing the gist out of these concepts on point and yeah, I’ve started sharing this in a newsletter. I’m pretty active on LinkedIn about, you know, sharing my trials and tribulations of leadership. I felt I always received really good feedback learning from others, so I wanted to share something as well. And the sketchnotes, they are hand-drawn on an iPad. And I think, you know, it’s in a way also fighting my perfectionism, because hand-drawn is always a little bit imperfect or imprecise. And I think this balances out, you know, the world we live in. It’s often very digital and very, you know, exact and blue. And this is a bit more a playful way to approach leadership, which is important to me. I think we don’t have to take leadership too seriously. It is a big topic, but having playful ways to learn more about leadership, I think that’s important to me.
Kovid Batra: No, that’s actually cool. And I’m sure these visuals leave a very good impact on your memory. So, remembering those is much easier when you, like, listen to it on a podcast or maybe read it. For me personally, I would say the visual things are more impactful in terms of learning and remembering as compared to maybe listening or reading. Of course, reading brings a very different angle where you can have your own imagination; that can be good for a lot of people, but I really appreciate this way of learning. But, I’m more interested in from where this inspiration of sketching came into the picture. Like, is it a childhood hobby that you had or you recently developed it somehow?
Claus Höfele: Yeah, I think I’ve recently developed or found that kind of a skill or, for me, it’s a way to, to maybe live out my creativity. I like to write and also sketching is a bit, you know, maybe something I can’t do super-great, but you know, it’s always, you know, the process that I enjoy doing. And, yeah, it’s, it’s basically an outlet for my creativity.
Kovid Batra: Cool. Nice.
Claus Höfele: Fortunately, with the iPad technologies and good drawing applications, it’s also become much easier to do this sort of thing. So, on paper, it’s even, even harder, but with the assistance of an iPad and good drawing programs, it’s quite doable to learn this.
Kovid Batra: Yeah, I mean, using an iPad is absolutely cool because in the age of AI, when we are writing our articles with the help of ChatGPT, which definitely increases our quality of writing, reduces the time to write it. Similarly, I think that technology works for you, man. I really appreciate using such productive tools, for sure.
Cool. All right. So this was a great thing that we got to know about you. Apart from this, do you love travelling? Have you travelled to different countries?
Claus Höfele: So I, I used to live in different countries. I used to live three years in Japan and five years in Australia. So, I have bit travelled the long way around to Berlin. So, I’m originally from the south of Germany, but then spent nearly a decade abroad and then came back to Germany and since then, I’ve been living in Berlin. It was an interesting experience. So, my wife is from the UK, so we were also looking for English-speaking countries and I took some opportunities. So, Japan was an opportunity that I had working for the right company and being at the right place at the right time. So we spent a bit of our time working and living abroad.
To be honest, now that I’m back in Germany, it kind of calmed down a little bit. I mean, COVID also helped, but now I’m feeling like, hey, Berlin is great. There are lots of things to see and do here, so I’m not travelling that much any longer.
Kovid Batra: Cool. Japan, Australia, back to Germany. I’m not sure how Australia and Germany would be a different experience for you, it sure is, but Japan would be a drastic culture change, right?
Claus Höfele: Yeah. Yeah, definitely.
Kovid Batra: And I have heard a lot about Japan. So, any specific learnings from your experience at Japan? Where were you working? What were you doing there?
Claus Höfele: Yeah. I was working for a joint venture of a Japanese and Swedish mobile phone manufacturer. And, so they were kind of, they had people from a lot of cultures, right? And yeah, I think Japan was a very interesting experience. So, I mentioned that my wife is from the UK, so Australia was a little bit more planned and thinking, hey this could work out also with, with the language, but coming to Japan, it was yeah, I want to say super-exotic, very different experience. I was super-curious, and learning and getting to know the culture. So they have a, have a very strong work ethic, but fortunately, also for maybe foreigners, they take it a bit easier on you. So I really had a great time getting to know the country. In the end, I didn’t speak the language too well. I started learning, but of course, it takes some time. So, in the end, it was something we did, but then moved on to Australia.
Kovid Batra: I think learning different languages impacts your processing, the brain processing in a very different way. Did you experience something, like when you were learning this language, how is it different, and how it impacted you when you were trying to speak in that language, think in that language?
Claus Höfele: Yeah. I felt very inspired by also the the, the Japanese script. I mean, they use like, different alphabets, at least two alphabets and also Chinese symbols, right. And Chinese symbols, maybe this, you know, ties in with the sketchnotes, you know, it’s very, it doesn’t exactly say.. It has a kind of an implicit meaning, right? That, and I, had a really interesting book, like also trying to, you know, see the meaning of the Chinese symbol inside this symbol, you know? Maybe it kind of mimics a bit. “Tree” would kind of mimic sort of the shape of a tree. So, it’s a much more intuitive approach to, to writing, to reading and writing, that felt very strange to me, but also super-interesting.
Kovid Batra: Cool. Cool. Coming back to your blog, newsletter, sketching, it’s all about leadership, right? You’re guiding people who are aspiring leaders for tomorrow to lead better teams, right? So let’s start talking about something there, like how do you define leadership? What leadership is for you?
Claus Höfele: So, I think first of all, leadership can happen on any level. Like, it’s not necessarily a position. That said, if you are a manager, it’s hard to imagine being a manager without having leadership skills, right? So maybe for managers, it’s more important, but I think it’s totally true that, you know, anybody can be a leader by showing, you know, by being proactive and kind of guiding other people to put outcomes. And, the way I define myself as a leader is that I have a background as a software engineer, but I’ve been, you know, hands-off from programming for quite a while. So, I don’t feel I want to have or need to have the solutions any longer. I see my job as helping other people to get to the right solutions. So, I’m spending a lot of time also planning workshops or trying out different techniques to involve as many people as possible, um, to have everyone have, have a say, but still, you know, make good outcomes and good progress on the problems that we’re working on. For example, running, like team kickoff workshops, or maybe also online sessions to tackle a problem. And, what’s working really well, for example, is Miro or doing this in-person. And I think these workshops, what they all have in common is that it’s a structured way to kind of channel creativity into really good outcomes.
Kovid Batra: One important takeaway from your definition of leadership is empowering people, like that’s where your success lies and that’s what true leadership is. Cool. I think that’s a very interesting start.
You said your journey started from a software engineer to leadership. And I believe a lot of my friends and audience listening to us are in that journey itself where they would want to know about this transition, how did you make your decision, what was your role and responsibility, probably as an Engineering Manager, and then as a Director now, what kind of things you do, so that the people who are looking up to these profiles, these roles and responsibilities in their companies have a good idea of what it actually looks like. So, can you just tell us about your experience, starting from Software Engineer, then transitioning to Engineering Manager, and then leadership?
Claus Höfele: Yeah. Yeah. It’s indeed an interesting transition because the realization is that management and software development are two different positions. And of course, the domain or the companies that you work in are similar and maybe they have a similar domain, kind of challenges, but what do you actually do day-to-day is very different. So, it was an interesting transition. And it started with me being a Software Engineer. I’ve done a lot of work on mobile phones. And I also programmed a PlayStation game and bit by bit, I kind of became more of a, like a Lead Engineer. I had a very good experience and good success in actually developing different kinds of software. And my first step into leadership and management was as a Tech Lead, which every company defines this differently, but the way it was defined at the time was like, you still had hands-on work to do, but you also started to manage people. And I find this is a super-challenging position because, it involves, you know, two different kinds of jobs basically.
Kovid Batra: Right.
Claus Höfele: But it’s also like interesting because it’s kind of the first step into leadership. So, it allows you to kind of try out, hey, what is this about? Try yourself out and also see if that’s an interesting career for you because I think at some point you need to make a decision: do I continue on the Individual Contributor path or do I continue on the management path? So, I had this Tech Lead position and this was still very involved with my technical expertise of mobile app development. And then, the next step was what I would call an engineering management position, which means that it was a technology that I knew, but wasn’t super-experienced in. And I think this is also maybe a learning from management that you often support different kinds of teams where you understand the general technology, what this is about, but you probably have less hands-on experience than the most senior engineers in the team. And I think as a manager, you need to become a little bit flexible in, you know, what kind of teams and what kind of tech stacks you manage.
And then from there, it kind of evolved into managing multiple teams. So, that’s a bit how the Head of Engineering or Director of Engineering position currently is defined, that I’m supporting multiple teams, we are currently at the brink of also introducing team leads and engineering mentors for the teams, but currently, I’m managing these people directly. So, it’s kind of another level of indirection, right? So, as an Engineering Manager, you directly interact with one team and directly manage people. And then as a, maybe Head of or a Director of Engineering, it comes like a bit more indirect by managing other managers as well. And yeah, it was an interesting transition because I was able to kind of maybe try myself out, also like phasing out the actually hands-on programming, and then bit by bit coming more into this role. But it took, I feel it took like several years to actually, you know, understand what this is about, to find my way, you know, my definition of leadership. And yeah, it was an interesting journey. And it still continues, right? It never ends what you can learn.
Kovid Batra: Thanks. I think, I made you speak a lot on this one, but I have some really good thoughts around the point where you said that when you transitioned from a software engineer to a tech lead, then to a manager, I could see in every expression of yours and the words you said, the role becomes more towards taking care of the people and the technical skillset, of course, carries along because that’s innate to this particular department, or I should say, that vertical of the business where you are leading tech teams. But, as you go up the ladder in this journey of management leadership, is it for everyone, or it depends on company-to-company, how much technical contribution do you put in as a manager, as a tech lead, and as an engineering leader, I would say? Does it go narrower on that side? How does it work according to you?
Claus Höfele: I think it’s what is a tech lead, a team lead, an engineer mentor is, is often different companies have different definitions. And I think if you go beyond maybe supporting four or five people, I think it’s super-hard to still continue to be hands-on with the technology. So, my goal is to understand the problem, the technical problem that we’re working on, but my goal is not any longer to actually be able to solve it myself. And, yeah, this is basically a decision point where you also have to make sure you want to let go of software development because it’s, it’s really an amazing job. Unfortunately, there are a lot of opportunities. Like, if you go into Staff Engineer or if you work as a Principal Engineer, right? There are lots of opportunities to also show leadership, technical leadership on a, on a very high level with a very good pay and position, maybe online with different management.
Kovid Batra: Right. I think that’s where you have to take a call, what is your feeling or what is your call that whether you want to go for a technical leadership role or you want to, like actually become an Engineering Manager and then take business-oriented roles.
Claus Höfele: Yeah. And, I think being a software engineer as a background to becoming an engineer leader is quite challenging because we have to let go of quite a few things. First of all, I think you have to let go of this idea that you need to be the best engineer. I think this takes a lot of mental effort. And you also have to let go of, “I’m now the lead.” Or, “I’m now the manager. So, I get to say what people are doing.” I think you have to let go of this thought as well. And, and having a technical background, this is often the challenge I see.
Kovid Batra: So basically, the technical understanding that you gain from the previous experience of being an engineer and then Technical Lead, that helps you as a manager and a leader to probably give better estimates and be more empathetic towards how the work is done, which probably the business side doesn’t understand or relate to in most of the scenarios. So, if I’m not wrong, is it that the main skill set of an engineering manager or an engineering leader is to definitely manage teams better, lead them better, bring in the cultural aspect that motivates them, keeps them satisfied, and along with that, be properly answerable to the business by understanding the context of technology? Does that sum up the overall role of an Engineering Manager or an engineering leader in an organization?
Claus Höfele: Yeah. What’s the difference between management and what’s the difference between leadership, right? And the definition I really like is that leadership is all about people. So what you said the culture of working together, the cooperation and managing is about things, you know, timelines and money and projects, right? And I think as an engineering leader, you need to handle both. But you can’t mix, you know, both sides need different approaches. So of course, what I’m doing day-to-day, a lot is also, you know, hiring new engineers, making sure we hire the right talent, also making sure that teams are set up for success. I work with the teams on, yeah, maybe kicking off things or also handling conflict. And also, maybe celebrating. I think it’s end of the year, it’s really important to also celebrate the achievements. I think this is all about the people in the culture side. And then, the management side is, of course, also about, you know, budgets and being able to handle head counts and maybe HR wants you to fill in certain forms, and of course, also with dealing with a stakeholder. I would define the role of a Director of Engineering, maybe as a translator between the two kinds of worlds. So maybe, translating technology problems into a language that business can understand and vice versa, understanding their point of views and translating that into a language that technical teams understand. And then, on my level, it’s also a lot about maybe working at the overarching problems, like maybe defining a technology roadmap that affects multiple teams. So rather on a team level where the team directly works, maybe with the business department, I’m more looking, you know, how are the teams generally set up, how does the collaboration work and what is maybe the technical roadmap that affects multiple teams.
Kovid Batra: Right. Makes sense. I think one very important point here, you mentioned that right now you are leading, you’re Director of Engineering. Ideally, it is supposed to be a bunch of managers and tech leads working along with you to deliver, right? But in this stage, you are directly dealing with multiple teams. And I’m sure this is a situation with a lot of companies where Directors of Engineering are directly involved with their companies. Maybe they’re hiring right now, or maybe that’s a lean structure that they’re following due to cost-cutting. The most important problem one could face is context switching, right? Different teams are working on different technology, different problem statements. A lot of things get escalated in that form. Of course, there would be some people who would be, like Senior Software Engineers, but would be helping team members to solve those technical challenges. But what happens if in this, a lot of escalation comes to you, how do you handle that? And along with that, you have to do your own piece of work also, right? So, managing all this as a Director of Engineering where you have to handle multiple teams, how is that experience coming out for you?
Claus Höfele: Yeah, definitely. The management, a manager’s schedule is very super-fragmented, right? I try to block out some time also to do some more strategic thinking and have a bit more time to do, you know, deep, deep work, but at the end of the day, a good part of the job is really, like having different kinds of context, which is all over the day. You cannot completely control this. So usually, the way I work with the teams, obviously I cannot attend every meeting, but I usually define with every team a little bit on, you know, how would I be in touch with the team and with the people on the team. So, I have a lot of 1-on-1s, where we discuss potential challenges. And, I also kind of attend a few meetings, uh, one or two meetings for each team, so I get a bit of an impression on how they are working and how they are also collaborating. And, in terms of conflicts and maybe incidents or stuff coming up, I think it’s really important for me and for, for leaders in general that they try to keep the business out of their schedule, right? Like, I see, or I’ve been such a leader as well, where you have from nine o’clock in the morning to six o’clock in the evening, you know, a meeting scheduled every half hour. And, you know, I have absolutely no downtime. First of all, it’s, it’s really bad for, for your mental health, but it also leaves no space for unforeseen things. And I feel you really have to also leave space open in your schedule that people can come to you, “Hey, I have clouds, I have an issue. I want to discuss that with you.” And, to organize your work in a way that you know, you have deep work, you can do this context switches, but also you have time for unforeseen work, which always pops up, right? I think this is a real challenge, but, that’s a bit the way to make this work.
Kovid Batra: Yeah. Yeah, absolutely. I think scheduling your day properly, compartmentalizing things that you want to do would be the first step for anyone to handle chaos, right? So, definitely a good piece of advice here.
Claus Höfele: And in the end, it’s also, you know, if you feel that you have too much on your plate, it’s also about finding people to delegate work towards, right? Like, it’s always a really nice, like a step-up challenge for other people to maybe get into hiring or to tackle important projects. So, I think a lot of leadership is also, you know, if it’s too much, getting too much for me, then I also have to organize my team in a way. And often people feel really great about these sort of challenges.
Kovid Batra: Right. Absolutely. One thing that pops up in my mind is that when you’re leading so many teams, you have so much going on in every team each day. How do you look at their success, like whether they are achieving on a sprint-basis or daily basis or monthly basis? How do you define that success for your teams? And, what kind of methods you use to actually measure that success?
Claus Höfele: Yeah. So, I’m not too much metrics-driven. In this regard, for me, it’s more a bit like a quantitative approach to having checks on the team. So, I’m attending team meetings and I see how the collaboration works. I’m in touch with them on 1-on-1s. At the end of the day, of course, also the business, the stakeholders of the team is a good feedback board to understand, you know, how well, does it currently work. And, I think for me, it’s not so much about, you know, pushing people to work harder and faster; it’s more like setting up a system that, you know, people can do their best work. So, I need to be able to organize, you know, the collaboration, the teams and how they work together in a way that, people naturally will want to do a good job. So, I’m responsible for the system, not necessarily for the day-to-day operations and outcomes.
Kovid Batra: Right. Makes sense. Makes sense. Perfect, Claus. I think that was a great talk and it was really interesting to have this discussion with you. Before we leave, I think it would be really amazing for our audience to know: what could success for an Engineering Director look like? So, just tell us about maybe one of your successes that you feel that you have accomplished so far in your career as a manager or as a leader, and what made you achieve that? Just, if you could think of an experience from your career.
Claus Höfele: Yeah, I feel the major of success of my career was also that I feel I always adapted to new challenges. So I had a really good time as a Software Engineer, but then also I felt, you know, what’s the next thing? And I was a lot into maybe user experience and understanding this kind of perspective. And I got into management and now I’m getting a bit more into facilitation. So, being super-adaptable, understanding that maybe what you have, the kind of approaches that you have used before might not work in the next challenge that you are tackling. And so, always be adaptable and always growing and always learning. I think this is my pleasure as well, because I think learning and growing is really good fun.
Kovid Batra: Cool. So, that’s your success mantra then, “keep growing.” Cool. All right, Claus. Thank you so much for your time today. Would love to connect again, discuss deeper into different aspects of management and leadership. And audience, please follow Claus his newsletter. We’ll share the link in the comment section.
Claus Höfele: Thank you so much, Kovid. It was a, was a great discussion. Thank you.
In the latest episode of ‘groCTO: Originals’ (formerly: ‘Beyond the Code: Originals’) host Kovid Batra welcomes Ariel Pérez, VP of Engineering at Split. He has also previously contributed his expertise to JP Morgan Chase & Co. and Berchbox. The core of their discussion revolves around tackling communication gaps in cross-functional teams.
The podcast begins with a fun fireside chat with Ariel, during which he shares his passion for Latin dance and recounts a pivotal moment in his life. Later in the main section, He delves into his daily tasks and the challenges he faces at Split. Ariel stresses the importance of fostering trust and transparency through open communication channels and streamlining the onboarding process for engineers to better equip them for problem-solving within complex team structures. He also sheds light on assessing engineering success by not solely relying on DORA metrics but also addressing the age-old question, “Are we building the right things?”.
Lastly, Ariel offers parting advice to the engineering leaders, encouraging them to recognize environment-building as their primary responsibility.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest who has 20+ years of engineering and leadership experience. Currently, serving as VP Engineering at Split for Measurement and Learning. Welcome to the show, Ariel. Happy to have you here.
Ariel Pérez: Thank you for having me, Kovid. I’m glad to be here.
Kovid Batra: Great. So Ariel, today I think we’re going to have a good time, good talk with you regarding your experiences throughout your career, engineering leadership, but before we jump into all that, I would love to know more about you, our audience would love to know more about you. So, we have this quick fireside chat wherein we’ll ask you two or three questions from your personal space. I hope you would be comfortable answering them.
Ariel Pérez: Absolutely. So let’s dive right in. Go ahead. What are your questions? Shoot.
Kovid Batra: All right. So, let’s start very simple. Your passion, your career is all around tech, right? But there must be something that you love outside of tech. What is it?
Ariel Pérez: Outside of tech, if I were going to say, two things. One of them is people understanding, how people work and understanding how people think and feel and get motivated. So that’s a big piece there, people in general, understanding what makes people tick. The other one is actually dancing. I have been, you know, not as much recently, but for the past 20 years or so, a little, actually more than that, I’ve been a professional dancer, primarily in Latin dance, Salsa, Cha-Cha, Bachata, Afro-Caribbean dance.
Kovid Batra: Oh, nice. That’s really nice. Great. Next question. How has your interest in doing what you’re doing right now evolved over a period of time? Like, whether it be dancing, whether it be tech, how have you seen that evolving over the years?
Ariel Pérez: I think, you know, in the early part and, you know, I can say this is probably similar for many people. Of course, I’m basing it on my experiences. It’s trying to get better, trying to get proficient at the thing I was doing, whether it was dancing and trying to get really good at dancing salsa and getting better and better and better. So, going very deep in salsa. And then later on trying to get some breadth. I think the same thing in my professional career, you’re trying to get better at software development, trying to get better at coding, trying to get better at coding practices, individual coding practices, and then going deep on, let’s say Java or C++ at that time. And then as I built more skills, it wasn’t as much as going depth, but building breadth. And the breadth on this, on the engineering side was everything from different technologies, different parts of the stack to different domains and more complex domains. And then further than that more about people management, leadership and product. So, along three different axes, he’s building breath and becoming more T-shaped, I would say.
Kovid Batra: Oh, that’s a good thought actually. So, what did you learn when you started, let’s say they talk about salsa, right? You said going into that depth on like initial day or initial months of your learning to becoming a proficient salsa dancer. What was your thought change around that dance form?
Ariel Pérez: I think for me early on was, well, it was something I enjoyed doing. It was something I could go out social dancing and enjoy at a club beyond just learning in a class and practicing. I think for me early on, it was, ” Why does this work this way?” I think there was an aspect of my, the engineering mind and, you know, background and training and, you know, and engineering and university. I wanted to know how things work, not just, “Here’s a movement, here’s how you do it.” It’s like, well, hold on. Why do we do it that way and not this way? Why did my feet have to be here and not there? How does the timing work? Why is it on this timing versus that timing? That was a lot of my initial focus, because for me, those were the core basic fundamentals that were required, not just learn a bunch of moves which a lot of people do. It’s like, well, hold on. I want to have the basis and the foundation to then build moves on top of that because that foundation never goes away. That foundation becomes the way for you to really put things together later on. As opposed to learn this, learn this, learn this, learn that, but you never learn the ‘why’. So I think that’s been a very important piece, the ‘why’ of why we do certain moves. And then after that, once I had that strong foundation, completely flying through and building the repertoire, here’s another move I didn’t know. Here’s a different move I didn’t know. Learn from this instructor, learn from that instructor. Add these to that foundation that keeps getting bigger and bigger, but it allowed me to go faster and faster through learning each of those things because the foundation was there.
Kovid Batra: Cool. Nice. I mean, everything that you do, be it a hobby or anything, I think this approach would be really nice to have, actually. And I mean, that helps us keep going. Great. I think amazing.
One last thing, what has been your biggest life-changing or life-defining moment? Of course, there would have been many, I mean, we are not just formed out of one experience, but just one which comes to your mind right away.
Ariel Pérez: Um, The birth of my son. My son was born in 2017 and I had just taken on a new role. I think what I’ll say about that in terms of life defining is in many ways it changes my perspective on how I prioritize, how I make decisions, how I have to care even more deeply than just what’s necessarily good for me, thinking about what’s good for my entire family and how is that everything I can do, at the end of the day builds a better life, a better future for my son now. And thinking from that perspective not that things that are important to me are no longer important, but now I have another angle to look at things from. And also, even a longer term perspective than, you know things beyond my own lifetime. Like, that’s something, that’s something, that idea that changes in your head, like not only am I thinking about my lifetime, I have to think about beyond my lifetime, and what do I, how do I prepare my son for things that will happen beyond my lifetime, because ideally, of course, I expect that his lifetime will extend past mine. So it changes the time horizon of the things I’m thinking about and considering.
Kovid Batra: That’s super cool actually. I mean, I am not a father, but I have spent time around kids and I definitely can just relate a bit to it, like when you transfer that learning of your life to the person, to the child, and then help them grow and learn in certain direction, caring about them, understanding their emotions, even when they’re not able to express it the way you, you might understand. I think a lot of things change when you have a kid around yourself. So cool. I think that that’s true.
All right. Thank you so much for this beautiful, beautiful intro. I think let’s jump on to the main section where we get to learn more from you about engineering and leadership. So let’s start with your current role of VP Engineering at Split, right? What’s your day-to-day responsibilities and to-dos look like and how do you navigate through them?
Ariel Pérez: Yep. I mean, I think my day-to-day revolves primarily around creating the right environment for my team to grow and develop, make the best decisions that they can, feel unblocked on any decisions that they need to make, and at the end of the day, can deliver value to our users. That’s primarily, you know, that sounds very generic, but that’s really what my day-to-day focus is on. It’s creating an environment, that’s the big pieces. My job is to create the environment for success. What does that mean? In many ways, it’s, you know, discussing and really being on the same page with the SVP of Engineering and look at engineering as a whole. It means meeting with my managers on a regular basis, understanding how their people are doing, how the people are progressing and growing and understanding blockers and challenges. It means connecting and regularly meeting with my product peer, then to co-create strategy, understand strategy, what are the biggest problems and where we’re going and leverage all that information to really, you know, prepare and enable my teams to achieve success.
Kovid Batra: So, as a VP of Engineering, when you say your primary role would be to get software delivered from the software teams that would take care of the business as well as the tech strategy, right? So it’s a kind of a role where you bridge the gap between the tech teams and the business teams to head into the right direction for the company goals. While doing this, I think one important thing you just mentioned about managing the people, right? Making sure that they are having the right context, right mindset to deliver, right? If I understood you correctly, this is what you mentioned about, like when you’re talking to your managers and then trying to understand whether people have the right direction and context or not. At scale, I hope I got you right over there?
Ariel Pérez: Yeah. Well, there are three things that would change there as actually, or slightly adjust.
Kovid Batra: Yeah.
Ariel Pérez: One of them, while this may happen in many organizations, it’s something I’ve, you know, I think I tend to focus on and it ties back to what I said. One of my other big passion outside of just my day-to-day work is how people work and what makes people tick. So because of that, I don’t necessarily see myself as the bridge between technology and product and the business. I am one of the people on that bridge, but in reality, my job is to make sure that my entire team is on that bridge and is connected with the business day in and day out. So, I think that’s a key part of how I think about the enablement of my teams, because then I don’t become the bottleneck. Then I don’t become the translator of from the business perspective over down to the engineering teams, which happens in many organizations, right? There’s an engineering chain. There’s a (quote unquote) “product” or “business” chain and never shall the two speak, except at like management and leadership levels because of that, your teams, the people on the ground lose a lot of context, lose a lot of understanding, and they’re forced to go through translation layers where you lose things. So that’s one of the big pieces. I am not the bridge. I am part of that bridge. I enable that bridge to be built. I enable that bridge to become much more open. And I create the environment for my engineers, especially to be in that bridge on that bridge all day, day in and day out as part of the work they do.
Then the second thing I was going to say is like, you know, when you were saying, yes, the important, my job is enabling to create a context for my teams. That’s part of it, but it’s really more about not creating context. That’s an aspect. It’s removing all the impediments, all the roadblocks, all the challenges that stopped them from doing the best job that they can. That’s, I think, even more important. Context fits within that way of thinking about it.
Kovid Batra: It’s one part of that, yeah.
Ariel Pérez: Context is one part of that. It’s like whatever stops them from solving the right problem, that’s my job to deal with, remove that impediment. And that impediment can come from anywhere. And that’s the key piece. It doesn’t stick to just the engineering realm, just the coding realm, just the technical decisions realm. It’s anything that stops them from doing the best job that they can. That’s my job to get rid of and figure out how to get rid of.
Kovid Batra: Totally. Makes sense. I think I was about to ask the next question that, at scale, how do you handle this where you can actually bring context to the complete themes and actually bring them onto that bridge where you stand. So, I think you answered it in a way for me. But I think I’d love to take a deeper dive into this where I would want to understand from you with certain examples of execution that you have done to bring the teams onto that bridge with. In general, what I hear is that only the leaders are doing that job. So, yeah.
Ariel Pérez: Yeah, absolutely. So, I’ll keep going back to this idea, it’s like my job is to create the environment, right? So, one approach that I’ve seen very often, right? It’s like I speak to my engineering managers. Those engineering managers speak to if they’re, you know, depending on how deep the stack is, they might be speaking to their engineering managers. And those people speak to the engineers. And I set strategy as a whole. I set processes as a whole. I set guidelines as a whole. And I don’t do it myself, right? I get it from the ground up and understand what’s necessary and working with my team. So, we figure out the strategy and then communicate it downward, right? So that’s one way, one approach, right? And I’m not saying that’s my approach. I’m saying it’s an approach you see very often. So I work through my managers to really set strategies, set goals, set approaches and understand what is needed, and I communicate context and vision and downward.
Now, an alternative approach is the following. I lean on my teams to figure it out. And that’s not, you know, that’s easier said than done to say, you know, it’s not saying, “Hey, here’s no context. Here’s no help. Figure it out.” Right? You figure out the business context. You figure out how to work. You figure out what are the problems and you figure out how to solve them without any empowerment, without any enablement, without creating the right supporting structures for that. The key piece that I focus on and really care about in execution aspect is ensuring there’s always a two-way street of communication up and down. That’s one piece of it. And it’s free-flowing information and creating the trust and transparency necessary for that. That takes some time and effort. Make sure that people feel always confident in escalating issues, challenges, concerns, and blockers upward and also down, you know, across to each other. And then I think the key piece is asking a lot of questions. Even if I might feel I know the answer and I often feel, you know, often as leadership, we often feel we do because hey, we’ve been through this. We’ve seen it. We’ve seen a lot of things. We feel we know the answers, but it’s important to listen a lot more than we speak. And I struggle with that, right? And 100% honest, right, I struggle with that. It’s important to listen more than speak. So, ask a lot of questions of your people in terms of, for example, how would you do this? Why is that a problem? Why is that a problem right now? Who does that affect? You know, what would you do about that? And then if they propose solutions or alternatives, well then what might go wrong with that alternative? Are there other alternatives? How many alternatives have you considered? There’s an aspect of just helping your people think through the problem as opposed to giving them the answer or giving them the actual solution, helping them work through the problem and actually saying that is the way we work and have however many levels down, have your people be very good at doing the same, driving downward on asking a lot of questions, helping people figure out the answers. for themselves. Why is that important? It creates an immense sense of ownership across the entire stack up and down. It creates an immense sense of involvement and beckoning inclusion and saying, “I had a part in this. I’ve been listened to.” And taking that back to when I thought about dancing and the importance of fundamentals, the importance of building the basic blocks, that aspect of people feel empowered, people feel included, people feel listened to, people feel like they have ownership; that is an important and critical building block for anything you want to do.
The other key building block is trust and transparency. And that’s hard to build, easy to lose. Building trust and transparency, we can speak openly about challenges and issues. We can challenge each other and question each other. But at the end of the day, we do that to make sure we get to the right answer, to the right solution or to the best answer and best solution we can together. We’re on this boat, we row together, and that’s how we figure things out. That becomes the basis for then all the hard things you want to do. This is hard on its own, but none of this is even about this technical problem or that business problem. This is all about building the right foundation as people to collaborate and work with each other and trust each other and depend on each other day in and day out.
Kovid Batra: Right. Now, taking this piece of collaborating with people day in, day out and working easily, probably within one team, you can set some structures, drive them towards certain aligned goals. And of course, like for a company, there would be specific goals that you’re achieving and then that translates into individual team initiatives and their goals and their results, right? But, when it comes to collaborating with cross-functional teams, like. engineering coordinating with product or engineering coordinating with design; at that time, as teams scale, I mean, this is kind of inevitable that that communication gap comes in, right? And there are a lot of other problems that start popping up. How do you deal with that at scale? How do you make sure that collaboration across teams when you scale is handled well?
Ariel Pérez: So, I’ll talk about two different kinds of collaboration across teams that needs to occur. One side is whether it’s product, design, engineering, which in my mind actually, those shouldn’t be separate teams ever. Those are the same team, right? Where some places call it the three in the box, some places call it the triad, but those three must be part of the same team, regardless of the management chain. But in, you know, in many places those are siloed. So, that’s one side of the question. The other one is different engineering teams cross, you know, collaborating with each other, right? So those are two different aspects.
Let’s talk about the first one. The first one, how would I solve that? One of the first things I aim for, push for it as part of any organization, ensuring that there is no division from the aspect of how these people work together, that these aren’t treated at separate pillars and silos. It means that product, design and engineering is one of the things I push for from the beginning. From wherever I am, either I join a place that already has that, or if they, if I’m joining it’s one of the conditions, I’m like, this is what’s going to happen and it has to happen, is that product, design & engineering must work together as a single team at all levels. And something I drive, whether it’s my peer on the product side at the executive level and work down with every team, I challenge my teams, my managers and the individual engineers to also push for their same with their peers. So, we push for this at every level and drive saying that communication barrier has to disappear. We work as one team all the time together. And that can take many flavors.
The other side of it is different engineering teams working together. And these can be engineering teams within my org or give me engineering teams across the org, right? You can think about vertical product teams. You can think about horizontal platform and enabling teams. One of the biggest ways, and I found, you know, found this to be very successful, especially in my own orgs is as much as possible, erase the boundaries between individual teams. Now that might sound almost like blasphemy, right? You might have, there’s an accounts, let’s think about the financial. I mean, there’s an accounts team, there’s a payments team, there’s an investments team or e-commerce. There is a, you know, a products team, there’s a subscriptions team. And you create those teams because you want long-lived teams that have, own a vertical slice of functionality end-to-end. And that is what we’ve learned for so long that is the best way to build things. The problem that occurs is that when one team depends on the other, the system breaks down very fast. And I’ve rarely, if ever been in any organization where any team is working long enough without a dependency on one other team, at least one other team, dependencies become one of the biggest blockers to progress because team one has their goals and their priorities. Team two has their goals and their priorities. When they need each other, the system breaks down because whose priorities matter more? And you can try to solve this at a higher level and say, well, let’s make sure we co-create priorities. But you’re still working from two separate places. So one of the things I’ve done with my teams in the past, you know, few years, especially at Split, and I’m not saying it was easy, is using an approach that blends the lines between teams and at the end, creates what’s called the more ‘super team’, which allows you to scale almost indefinitely. What does that mean? The team definition changes from an individual squad of let’s call it a ‘two pizza team’ or like a six-person team or nine-person team, right? The traditional size of team that we think about. And instead say, we have a superstructure of a fluid team, which is 30 people, 40 people in a fluid team. But now how does this work? Like, how do you create a team of 40 people? The idea is this. As the work comes in, as the priorities come in, that structure of 40 people fluidly breaks into smaller teams as necessary to attack the work. They might become three teams of 13-ish people. They might become seven teams of about six people. But the teams reform dynamically around the work that’s coming in. And they form dynamically around the work that’s coming in to make sure that they can actually adjust and take on dependencies. So, if you are going to work on something in a traditional structure, where one team depended on another team in this structure that doesn’t exist because those two, the folks from either side come together and they form one new team that now solves this problem holistically across the domains. So we can go, dive into this in so many different ways, but it’s dynamic fluid reteaming out of a bigger team, that bigger team creates the cohesion, the home, the static, a long-lived nature, but they can, they can reform and adjust and adapt to the problems at hand to get rid of dependencies as one part. You know, one particular outcome is get rid of dependencies, but there’s so many other outcomes.
Kovid Batra: Sounds really, really amazing to have such an ideal structure and I’m happy to hear that you are working in a similar style. My first question on that is that if these are the teams, any engineer joining the team would have to gain a lot of context before you can actually say that this person is equipped to handle any problem, right? So..
Ariel Pérez: Absolutely.
Kovid Batra: I broadly have an answer to my question, but still would love to hear from you. Like, don’t you think you would have to invest more time in the learning of anyone who is getting onboarded here?
Ariel Pérez: I’ll say yes and no to that question. One is, do I have to invest more time in learning? Absolutely. And yes, across my entire team, we have to continually invest on learning and that only pays massive dividends over and over. So that’s why it’s not a problem that I have to invest more in learning.
Now, in terms of onboarding someone new, that specific question, someone new comes into the superstructure of a team. The superstructure of a team has to figure, you know, someone coming in has to figure out the broad array of your domains, have to figure out all the services, all the technical aspects, has to figure out the interpersonal relationships. The way you help solve for that is, one of the things that’s hard to do in many organizations for many reasons, but it’s, well, in reality, no individual person works on any one thing by themselves. What do I mean by that? One of the things that happens in many teams, regardless of whether you’re doing Kanban, or Scrum, or XP, or whatever, you know, flavor of project development, project management style you have, this happens very often. Here’s a piece of work we have to do. It’s broken up into five pieces. We have five engineers. We’re going to get five engineers working on five things, right, on the five pieces. That creates many, many problems, many, many silos and knowledge and it creates many challenges with now we all depend on each other because this person can’t complete it with that person finishing. This person needs a PR review before people are working. So, how do you potentially solve for that problem? More people working on less things and working on them together in real-time. At the end of the day, what is that? It’s either a lot more pair programming and a lot more ensemble program.
Now let’s talk about where the question started. That one person that comes in and how do we get them enabled to understand the whole domain? One, immediately pull them into pairs and ensembles of programming because they gain a lot of context very fast from other folks. Number two, you start learning the team’s practices, the team’s techniques, the team’s shortcuts very fast, and you start becoming a lot more embedded into how we work and what we do and our domains. And you do that continuously and regularly. Why is it that that happens when you have an ensemble or when you have a pair? Because you have hands-on, real-time knowledge transfer between folks. But here’s the other piece. When you get into that level, you realize that one person does not ever have to have the full context of everything that happens. The context is shared across the team. Across the team, you have context of the whole thing. One person might have context of the whole thing, but you don’t need that because you don’t have single-person dependencies. The team as a whole understands the entire domain. And that’s the key piece here. That makes it easier to onboard the ensemble and pair programming, easily pulling you in, merging in, but also immediately ensuring that you’ve set the expectation that I don’t expect you to ever have the full context of the whole thing. You don’t ever probably ever have to have a full context of the whole thing, but the team as a whole does. That 40 percent superstructure of a team, that entire superstructure of a team has context over everything. That’s the key piece.
Kovid Batra: Totally get it. I think this is an amazing way to operate in here, starting with the very first thing where you not only bring context to a lot of people, which brings a lot of accountability also when you’re working on a day-to-day basis, but it also makes it easier for the organization, I feel, to deliver at a much faster pace and maybe not delivering too much, but delivering less with more effectiveness, I think. So, I think the structure really, really works well, I hope.
And with that, I think one question that comes to my mind is that when you’re looking at making the engineering team successful, what are your parameters of success for an engineering team and how do you go about measuring those?
Ariel Pérez: Okay. Awesome. Assuming we have the piece of trust and transparency and the constant working and collaborating closely together. That’s one aspect, right? Like, how easily does information move around the team? How easily does information move up and down? That’s one aspect. And how you measure that, that’s hard, but part of it is constantly speaking to people. And actually, me as a leader, skipping levels and talking directly to folks at every level and making sure I can also hear them. So there’s a question of triangulation of the flow of information. That’s one side of it. I don’t know if I have an exact measure of that, but there’s a sense and a gut of these things don’t line up. Now, moving beyond that, right? Assuming that the communication lines seem clear and open and there’s transparency and candor. Then I start thinking about, as a baseline, you know, my engineering metrics. And I, you know, there’s no need here to reinvent the wheel. I do think, you know, the DORA metrics are a really good starting point. What the DORA metrics help us measure and understand is how good are we at shipping quality code regularly. That’s the way I’ll call it. I didn’t say solutions. And I didn’t say definitely like value because there’s no guarantee in that. But, can I get really good at shipping code regularly without breaking things? I think the DORA metrics are really good for that. Right there you have the deployment frequency. There’s a lot of practices that have to go into, come into place and really be in there for you to deploy very frequently and do that without breaking things where that’s the guardrail of your change failure rate. So I’m deploying frequently, but I’m not breaking things. Great. That’s awesome. It means I’ve built the engine to pivot very fast to deliver on value very fast, or if something comes in, I can react to it very quickly and ship it. Then there’s also the lead time for changes, right? How good am I from something new coming in to be able to get that out? So many practices that have to come into place to make that much more effective and efficient. And then the last one, obviously it’s the beyond the change failure rate, it’s the mean time to recover. Um, they are the mean time to recover. How good am I at fixing problems? If there is a problem, how good am I at fixing them? So all these things really tell me that the engineering team is humming, it’s buzzing, and it’s getting really good at shipping things. But here’s the problem with that alone. You have no guarantee that you’re shipping the right things, right?
Kovid Batra: Yeah.
Ariel Pérez: That’s only telling you that you’re shipping things, right? But it’s not telling you’re shipping the right thing. So then what do I do then beyond that? Well, then I start thinking about a measure of how many experiments are we running and why do we care about experiments. And ‘experiment’ not to use that word broadly, but how many things are we shipping for the purposes of validating that we understand what the customer wants? How good are we getting at putting things out there and collecting feedback and gathering feedback from customers? How good are we at learning from that feedback? And how do I know we’re learning potentially? One way is saying, “Well, over time, are we getting better at delivering solutions that the customer loves, that the customer finds value in? Are we getting better at shipping solutions that don’t degrade value, that don’t reintroduce friction, that don’t cause challenges for our customers?” So there’s a question there of over time, are we getting better at increasing value and reducing the destruction of value? That’s what I care about the most when we talk about “Are we building the right things?” And that aspect is often missed out on many teams. That’s where you get to effectiveness because if you can ship the right things, then you can continue focusing on shipping the right things as opposed to fixing the wrong things.
Kovid Batra: Absolutely. One thing that I feel that when you set these metrics for engineering teams, everyone is looking at those metrics as performance indicators, right? They look at that whether they’re doing the work, quantity of work, they’re producing it right or not. But as you said, like you want your teams to have the right context every time from the business side. So if engineers on one side would be aligned towards improving those KPIs, how would you bring that focus or how would you bring that intent into the engineers to focus on delivering the right value also? Like for efficiency, you have metrics in place they can see, but then how are these engineering teams relating to the business context by saying that, okay, we are delivering in the right direction, we are delivering the right value or not?
Ariel Pérez: Yup. Awesome. So, I think the first part of that is ensuring that it is a cross-functional team and product and design are embedded and working very closely hand-in-hand as an actual part of the team. It is not product and engineering, it is a cross-functional team. So that part is absolutely critical and essential. The second part is this is through these conversations with coaching and asking questions and working, you know, up and down and down and up the stack, some of the questions, you know, to work on with the teams is the following. Ensuring that every engineer on the team, when there’s something to work on something next, one of their first questions is, why are we doing this? What problem is this solving? Do we know that this is solving that problem? And do we know that that’s the right problem to solve right now? If you can actually help engineers, not only ask that question regularly as a way to learn, but also be as a way to really challenge assumptions that are often, not always, but often coming from product and design, It really helps the engineers have a very strong ownership over what they’re working on. And it also helps them in some ways protect their own time, not because engineering time has to be protected, but because you want to ensure that you’re always working on the most valuable thing. And if you don’t understand the value of the things, it’s really hard for you to ensure you’re working on the most valuable thing. It also ensures that our product and design partners are really working really hard to help figure out, “Is this the right thing?” “Is this the best thing?” And get really good at communicating that and very clearly laying out the value of what we’re doing. So, that’s the first part to start with. The engineers getting really good at asking those questions. That’s then bolstered and supported by continually and regularly communicating, not only from product and design, but also from engineering leadership, what is the vision? What is the strategy? How do we get there to that vision through that strategy? And what are the most important customer problems to solve? That needs to be communicated regularly to the point that every person on the team understands the vision, understands how we get there. That’s a big part of context building.
So I think it’s two directions. Continually communicating that to make sure it’s there. But the second part is really enabling and empowering your people and expecting them to always ask, “Why this? Why now?”
Kovid Batra: Totally. I think, I would love to talk more, but in the interest of time, I think we’ll have to take a pause here. The discussion won’t end because this is one of those podcasts where I didn’t realize that 35 minutes have passed and I’m just talking to you. It was really interesting. Appreciate you for executing the way you are doing. I’m really amazed and would definitely love to have another show with you. But for today..
Ariel Pérez: I’m looking forward to it.
Kovid Batra: But before we leave today, I won’t let you go without a parting advice for our audience, the engineering leaders, the upcoming engineering managers who are listening to this podcast. What would be your parting advice?
Ariel Pérez: My parting advice would be, especially as a leader, your biggest responsibility is to create the environment and the system that allows your teams to thrive. That is your biggest responsibility. It’s your teams that are the most important. And in order to help them get really good at that and at really good at thriving, how do you ensure that you’re constantly removing blockers? Rethinking the system in which they work in to remove dependencies. And then most importantly, how do you empower and enable every single member of your team to be able to make the best decision possible for the company and for the organization without you having to be there day in and day out. That’s the key piece. How do you enable and give them that ability to make decisions independently on their own and feel like they own that decision in the service of your customers and the strategy of your company. That’s the key piece. Think about that day in and day out. How do you create that environment?
Kovid Batra: Amazing advice. Thank you, Ariel. With that, we will say bye to you, but we’ll see you soon again.
Ariel Pérez: Thank you. Kovid. It’s been a pleasure, and I hope to talk to you again.
In the latest episode of ‘Beyond the Code: Originals’, host Kovid Batra engages in a thought-provoking discussion with Sebastian Heide-Meyer zu Erpen, VP of Technology at tonies and a professional mentor at the Mentoring Club. The heart of their conversation revolves around ‘The power of insourcing and self-determination’.
The podcast begins with a fun fireside chat with Sebastian, allowing the audience to see his candid side. Later in the main section, He delves into the transition from an IC to a managerial role, sharing insights into his daily tasks and the hurdles he faces. Sebastian provides insights into the criteria to build a strong team and the strategic shift towards insourcing over vendor diversification. He also sheds light on four crucial dimensions for defining and measuring engineering success: outcome, output, tech health and team health.
Lastly, Sebastian underscores the significance of self-determination theory, advocating for an outcome-oriented approach and value-driven delivery model within tonies.
Kovid Batra: Hi everyone, this is Kovid, your host, back with another episode of Beyond the Code by Typo. Today with us, we have an amazing guest. He’s a believer of self-determination theory. He has 18+ years of engineering and leadership experience. He’s one of the renowned mentors on mentoring club. Currently, he’s serving as a VP of Engineering at tonies. Welcome to the show, Sebastian. Great to have you here.
Sebastian Heide-Meyer zu Erpen: Thanks for having me. Glad to be here.
Kovid Batra: Thank you so much for taking out this time. And today, we’re looking forward to learning a lot of things from you, whatever you have done in your career, in your personal life. And to start off, I just wanted to touch base first on the personal life so that our audience knows you more. So, there’s a quick fireside chat we have for you. I’ll be asking a few questions there. Should we go ahead?
Sebastian Heide-Meyer zu Erpen: Sure.
Kovid Batra: All right. Thanks a lot. So, first question. Apart from technology, I’m sure you have been a techie for so long. I am sure that’s a passion for you, but apart from that, there must be something that really excites you. Can you tell us about your hobbies, things that excite you outside of tech?
Sebastian Heide-Meyer zu Erpen: Yes, of course. And for sure tech is one thing that, that excites me still. But it is still, I’m still into music a lot. So when I was younger, I was actually, like DJing and was also a music producer and, yeah, there was a time when I had ample spare time. Since I have kids, I have much less, so hence less DJing and music production, but I still enjoy music very much.
Kovid Batra: Cool. So what kind of music you’re into?
Sebastian Heide-Meyer zu Erpen: Yeah. So I was, like into Caribbean music. So, there was dance also reggae, and also mixed with more American style hip hop and other more modern musical genres later on. Yeah, so that was the basic picture that I was into.
Kovid Batra: Oh, that’s so nice. Cool, man. That’s an interesting hobby.
All right. Moving on to the next one. Now, as you said, like, tech is one of the passions. I wouldn’t skip that thing for you. Tell us about your first experience, your first coding experience. How was it and what did you write?
Sebastian Heide-Meyer zu Erpen: Yeah. So, and the thing is, I don’t actually remember the first thing that I wrote. But the first coding experience was a basic summer course that I did. And, I was so fascinated that later on the first thing that I can actually remember that I built was a context manager where you could enter basically a first name, last name, address and phone number and such things. And then store it on your hard disk was, all, I think it was still MS-DOS based and was only text interface based, but I liked it so much that I even started to pitch it to my family. So if they wanted to use my context manager, that actually never took off, but, I was really into that. And then what I liked about it was that I could build something, very, like, exciting and professional-looking out of nothing basically. So, that I really enjoyed it.
Kovid Batra: Hey, I totally feel you there. How old were you by the way at that time?
Sebastian Heide-Meyer zu Erpen: That’s hard to, to say probably around 11, 12-ish something.
Kovid Batra: Oh, that’s, that’s pretty early actually. My first line of code was probably at around 17-18. But yeah, that’s nice. Nice to know that.
All right. Apart from your experiences, right now today you are at such a position in a company where you have to take a lot of decisions and anyone who is taking so many decisions, I’m sure has to have a source of learning so that your decisions are good. You have the right mental model in place. So, I would love to know what are you learning these days. What are your learning sources? Any specific books that you are reading?
Sebastian Heide-Meyer zu Erpen: Yeah. So I’m actually reading less today than I’m listening. So I’m listening to audiobooks, actually a lot also for, for learning purposes. And the last audiobook that I listened for learning purposes was on systems, I forgot exactly the name, but it’s one of the standard books on systems in general, how do systems behave and scale, and such. But, I also actually occasionally listen and re-listen to learning fast and slow. Sorry, is it, how was it?
Kovid Batra: Thinking fast and slow.
Sebastian Heide-Meyer zu Erpen: Thinking fast and slow. Yeah.
Kovid Batra: Yeah.
Sebastian Heide-Meyer zu Erpen: This is one that I occasionally re-listen to because there’s always elements that I take from that I like. But I have to admit that my general learning is more now focused on other channels or ways, or I think I learn different, um, topics in different ways. Actually, when my kids were younger, I rarely had like 30 minutes of uninterrupted time. And that was a time when YouTube, actually started to become a part of my life because YouTube videos are very short, right? And I can take in information in a very short amount of time. And, even YouTube shorts nowadays can be quite good. Yeah. So, I still do enjoy these tutorial videos. Fireship is a good channel. Primogen. So, these standard coding channels I like. I do read Gergely’s newsletter, ‘Pragmatic Engineer’.
Kovid Batra: Yeah, I know.
Sebastian Heide-Meyer zu Erpen: Yeah. This is a really good one. So, I really enjoy it every time. ByteByteGo is a good source to basically refresh on some concepts and strategies, right? But then I still read a lot on LinkedIn and get a lot of new content. But also my teams, quite frankly, they catch new technologies and I learn from them. And, podcasts. So these are the main learning sources for me.
Kovid Batra: Cool. Thanks. Thanks for sharing all your learning sources secrets with us. All right. With this, we move on to our main section where we will be talking about how and what did your journey look like from starting from your developing days to a leadership position.
So, before we jump into that, I just wanted to know one more thing from you. This is of course related to your career. This decision of moving into leadership and management as compared to somebody who is at the core, a very techie guy, not moving to a Principal Engineer kind of a role; was that a conscious decision or it just happened to you?
Sebastian Heide-Meyer zu Erpen: Yeah. It’s part this and part the other. So, let me explain. So, when I joined my first company, actually, it was in the middle of an Agile transition. So it was just starting, or had just started with Scrum and had reset basically and restarted Scrum. And, in that period, they, for the first time, really placed a role called Scrum Master. So they didn’t have that before. And at the time they introduced it. And because I didn’t like my first boss, I had the urge to do something else and I saw a chance at being Scrum Master. Right. And then, yeah, I was chosen as one of the two Scrum Masters of the company. So, became that. And, was Scrum Master for a couple of teams and still a Software Engineer in one team. And at some point, they asked me, “Okay, decide for one. So, you can only be good in one. So, decide for one.” And with a tear in my eye, I made the decision to focus fully on Scrum Master because I felt I worked with three different teams. I helped solving them more of these like organizational problems, but then also like helping improve the relationships with the Product Manager. Still was, supporting on the tech side occasionally. So it felt like my scope and my impact was way bigger than pure coding. And that was basically when I made the decision and later on, then turned to Team Lead and whatnot. Yeah.
Kovid Batra: That’s cool. I think for a lot of folks, to whom I’ve talked, who have moved into management or leadership, this is one of the most important reasons for them to switch to that. They see that impact. They see that adrenaline in them when they are managing teams and getting more people empowered to do more. So yeah, I think that’s so cool.
All right, Seb. Tell us more about your experience at tonies, your routine. What are those important responsibilities that you hold as a VP of Engineering at the company? And what are the challenges that come along with that? So it’s a big question, actually. You can take your time to explain it. Yeah.
Sebastian Heide-Meyer zu Erpen: All right. So I, I’ll try to make it short. So first of all, I think I need to explain what the tonies are. So tonies are the producers of a small audio player for kids. Unfortunately, I don’t have one right now with me, otherwise I would show it to you. It’s a cube basically that looks cute. And then on top there, go these little figurines that you can place on top and then it plays the audio that’s connected with this little figurine. So, we have lots of Disney characters and Paw Patrol. So, all the stuff that kids know, but you can basically use this as a creative one is what we call it. You can put your own stuff on it and it plays, what’s on the Tony. And kids can use it from the age basically of one and a half to, because it’s so easy to use and it’s more natural to them than, I don’t know, using a CD player or whatever if, if it’s existing in households anymore, right? So yeah, and that’s what we’re building. So, basically we have this tech device, right? We have the back end. We have obviously an app with which you can control it and buy additional content. We have a shop. We have other outlets, basically. And that’s within the scope of responsibilities for me.
And quite frankly, what my job has been at tonies, but also at other companies is always like looking that everything is moving in the right direction, right? So nothing is crashing and we are really making progress on the things that we need to. And then, I’m going deep on one or two topics that are really important or really complex where I support with my expertise and my also connections, quite frankly, in my understanding, to move these topics forward, right? And I always constantly, and this is a big part of my job, try to combine the.. I have a very broad overview of what’s happening in the company. I talk to many stakeholders, but I then try to deliver this broad perspective to my teams and then get the deep perspective that they have on the specific technical topics that they own, in order to formulate the best decisions as a connection between the broadness and the very deep expertise. So that I would say is pretty much describing my job and my day-to-day routine.
Kovid Batra: Cool. Cool. I think what I’m interested in knowing is the challenges that you see. Of course, these are your responsibilities. And I totally understand, as a decision maker for the whole team, you have to get down to that each and every integrity. I have a lot of questions on how does this device also works. But, let me just start off with the challenges that you see in the responsibilities that you have taken up. What is the most difficult thing for you in day-to-day?
Sebastian Heide-Meyer zu Erpen: Yeah. So, this has shifted massively over time. So when I started, the team actually was probably 60 percent external. So, because the product itself was invented by folks that have been working in agencies, and they have been used to working with agencies, so, all of the IP, all of the knowledge and quite frankly, the effort was outsourced. So external partners were doing the work, right? This is a good idea short term, but long term it’s quite expensive and also risky because, if you are, and we had situations with one of the suppliers who were suddenly saying, “Hey, we want more money. Otherwise, it’s not working out.” And then, we had very tough negotiations. So, uh, what we did is we started to insource, basically, the development massively and have flipped the script or basically actually most of the development now is done by FTEs within the company and the, the know-how and the IP is generated in turn.
Then the next thing was, um, During COVID, we had to navigate also supply chain issues. Quite frankly, there was a chip provider that told us, “Look, we can deliver, like the next nine months of the quantities that you need, but then we will not deliver meaningful quantities.” So, we had nine months to rebuild the whole hardware around a new chip, which means basically you have to rebuild the whole thing. And that was very short notice. I turned grey during that time. I learned a ton about hardware development and firmware development. And then, also tried obviously, my, like very Agile-driven, software engineering background to bring this in. So how do we do shift left quality assurance? How can we test, as small of a unit as possible to keep feedback loopers, loops as short as possible, right? And then, like have different layers of tests. And I think we learned a lot and we built a team along the project. So we started with external providers, but built an in-house team, and created the knowledge in-house. And now we have a really good, like foundation to, yeah, build basically future devices that we’re working on in the future.
Kovid Batra: Cool. So I think this is very interesting, Seb. When you scale a small team from a few single-digit folks, the number to 60, 70, as you said, in this time, of course, that knowledge creation, that culture creation, everything becomes important. I think very important is the first step, which is hiring the right folks. So, tell me about how did you start hiring. What were your criteria there? And how did you build this strong team of developers that are working on hardware as well as software, as I see? So please go ahead.
Sebastian Heide-Meyer zu Erpen: Yeah. Yeah. So, the number one thing for me is obviously I scale or through my expertise only with people, right? So if I have people that are very aligned with me and I am aligned with them, then we can scale better. So what I did was at first I made with the existing, we had existing leads, I made my expectations towards them and their expectations towards me very explicit. So, had a role description, that I agreed with them and then I held them accountable and they really liked it. So then, because we were growing in size, right, I hired a bunch of new Engineering Managers. Some of them I actually knew from, from past companies. So, I had already a great trust relationship, knew how capable they were, right? Some of them were new and some really surprised me at what they basically were able to deliver and how also some of the internal folks that have been there have been growing time was really, uh, amazing. So with that in place, a great team, I could then use them to scale. And we hired a bunch of folks into the teams and invested heavily in select areas. So, as I said, right, due to the supply chain issues, we had to invest heavily in the hardware and embedded space in order to insource the IP production and also be capable of building new products ourselves.
And then, also we did a similar thing in the app. We had a, like reasonably, no, actually a mediocre app before, wanted to build a top-notch app and had to build a team from scratch, basically. Had no single mobile developer or only one, when I joined. So did that there, hired a great leader for this team, scale the team. And now, like there’s this flywheel that’s always starting to flow, right? Because the leader is like working with the team, I’m working with the leader and then they’re bringing in new expertise and new practices. And this then sets something in motion that the team understands, “Okay. If we do that, then we get faster or quality gets improved. And we get more freedom, get more time and can do more.” And that’s what’s happening, and that’s what we’re seeing, all along the teams basically.
Kovid Batra: Cool. Perfect. Yeah. I think holding people accountable, giving them autonomy, and yes, of course, hiring from some known folks and references always works better, probably. And that really helps it because at the end of the day, it boils down to trust. And people whom you know, their working style. And once you are comfortable, it really becomes a motion where all of them are pushing towards one thing. So that’s really cool. That’s a great piece of advice.
Seb, one thing that you just mentioned, like during COVID times, there was a supply chain issue and we know that this chip industry was really taken back at that point of time. And it’s not just tonies, probably a lot of such companies who were dependent on hardware were struggling to source chips, right? At that moment, you decided to build things in-house, right? Usually, this is a question that I ask that ‘buy versus build’, right? At that time, why didn’t you think of probably going down to a few other vendors if one vendor was moving away from commitments? Then you could have two or three in the pipeline supplying you the same thing so that if one fails, you can rely on the other, because I mean, I have had that personal experience of dealing with such hardware vendors. And this is what we did. We didn’t start building things in-house. But your story is different. Can you tell me some rationale behind taking that decision?
Sebastian Heide-Meyer zu Erpen: Yes, of course. And also, to be fair, we did not build the hardware in-house, entirely. So it was rather done by a supplier as well, a different one with support from our in-house team. And we anyway had the plan to build a second source. So we knew we were dependent on one chip supplier, on one like development partner, right? And we wanted to have another chip supplier build a second, also, development partner in order to do this or be prepared. Unfortunately, it hit us and we weren’t prepared. So, we had to do this on the fly.
However, what I insisted on at that time is that we build the firmware in-house because what I wanted to do is to iterate as quickly as possible, as much of the feature set as possible. And, what we were doing is we made the explicit decision. The app should be the new basically digital centerpiece for, for the interaction with the product, which is natural. If you have an IoT device, then you usually control it with the app. And this is the panel for the parents. And we also wanted to get In touch with the parents more often via the app so that we have a touch point with the parents via the app and with the kids via the device, right? So, we invested heavily in making the app better and more appealing to parents and also more useful. Quite frankly, we focus on the jobs to be done by the parents and make better offerings in order to help them overcome these kind of get these jobs done basically. And by doing that, we also want it to be able to enable parents of doing certain things in the box that they couldn’t do before. And in order to have this cycle as short as possible, we wanted to have all the capabilities that we need, including the firmware capabilities in-house to really basically make all of this one month at best from idea to production. And what better way than having everything ideally in within the company, very closely connected, right? And that’s how we ultimately, came up with this setup.
Kovid Batra: Yeah, I think I get your point here. It’s more around the concept where you want to deliver value, you know that part of your value chain, your supply chain, how much is it going to impact the overall delivery of that value to the customer. And, that’s when you decide how much control you want to have on it. And probably from there, you decide whether we should have it in-house or probably get it outsourced. That’s cool. That makes sense. Perfect.
Sebastian Heide-Meyer zu Erpen: Quickly, if I, if I may add, like, worldly maps are a great tool to basically do exactly this analysis that you just did, right? So the more, the closer something is to the customer, the higher, the, the basically impact, that you can have on like developing pieces, closer to the customer in-house. And also the, the closer something is to your IP, meaning to an innovation. So, the more commoditized it is, the, the less like differentiation you can have as a company, but the closer it is to an innovation, the more differentiation potential there is, right? And that’s how we approach the, the whole thing as well.
Kovid Batra: Totally, totally makes sense. I think that’s a very good way of looking at and making a decision about whether to buy versus build. Of course, it comes down to the capabilities also, how much capital you have, how much it would take in terms of resources. Of course, that also matters, but ultimately the decision-making should start from this point of how much control you want to have on value delivery there, and then probably, think backwards. Makes sense, Seb. Great piece of talk.
Another question that I have here is that when you are owning so many things, uh, you have such a big team, everyone is autonomous, you have given them that accountability. There is a possibility that some small fuck ups happen, right? Sorry to use that word, but yeah, that happens, right? At such a scale, the impact of such failures is very big, right? And you need to have an eye on that. How do you deal with such situations? How do you make sure that you proactively control these situations? How do you do it in your company right now?
Sebastian Heide-Meyer zu Erpen: Yeah. Yeah. The good thing actually is that with our, like product, we have resilience built-in because we always have this, this audio player that works on its own. So, if you put a figurine on top that already has been played on the player, it is stored on the player and it will just, just play it from, from the disc. So there’s not even a connection to our system. So if the box itself is functioning, no battery problem or whatever, right, then it will generally work. This already, like makes our overall offering quite resilient. However, there’s obviously still like a lot of systems that can break. We have lots of microservices that fortunately have a limited blast radius, but that can break. And this occasionally happens. So, what we do there, so we have an extensive set of metrics that we’re monitoring. And so we focus, a lot on observability in general. And we also like, use more and more business metrics so that we basically, whenever something breaks, we, we catch it, even though we might not measure the specific or see the specific technical metric go out of bounds in a range, right? But we, we see the, the business impacts, quite frankly, we also have customers that are very quick in letting us know when something is not working, so we detect it very fast usually. Yeah. And then basically the incident management process run. So, we have an incident manager that is defined. It’s usually the Engineering Manager from the area of incident that, that sort of responsibility where the incident happens. Then we have kind of a war room chat where folks get together. Everyone who thinks who can contribute is welcome to contribute there. And it’s actually an all-hands-on-deck situation. So whoever can support should be also there. Then we do root cause analysis the normal stuff, right? So we try to find out okay, what, what is actually the root cause of what, what’s happening there. We focus on mitigation, try to basically build hypotheses, follow these hypotheses, validate them, invalidate them, come back together. And then, once the root cause hypothesis is validated, we will think about how can we mitigate it. And once it’s mitigated, then we have a post-mortem where we discuss how can we A detect this sooner and even more important, how can we prevent this from happening in the future, right? So pretty much standard, but it’s working pretty nicely. And usually, our incidents are quite short, luckily.
Kovid Batra: No, definitely. These processes, these tools definitely help, and you just have to have that discipline in yourself. And I’m sure teams who are using these things and following these things are at a much better position as compared to those who are always firefighting. So, cool. I think that answers my questions really well.
Apart from this, what I think is that when you’re leading a team, there is a sense of accomplishment that you feel when your teams succeed, right? It’s not just limited to yourself, it’s for the team. So, how do you define that success for your team when you feel that, yes, they are succeeding? What are those ways you measure it? How you define it, first of all. Measuring is probably second. First, how you define it for them in your company.
Sebastian Heide-Meyer zu Erpen: Yeah, yeah. So ultimately, when defining success, I’m looking at four different dimensions of basically, yeah, measurements if you wish. So I’m looking at the outcome, which is ultimately what we’re striving for, right? So, we want to have an outcome that’s good for the customers of the company. Hence, it’s good for the company, right? And hence, it’s also good for the employees and blah, blah, blah.
So, the next thing I’m looking at is output actually. So, this is purely the amount of work that flows through a system. Because like over the years, right, you can measure, the size in T-shirt sizes. You can do story points. You can, whatever, right? I tend to follow the idea of trying to make stuff small. And if you try to make stuff as small, so units of work as small as possible, then you can simply just measure the amount of units of work that are flowing through a system. Law of big numbers. If you have enough units of work that are flowing through, then If the amount is not going down, then it’s a good thing. So it doesn’t always have to go up, right? And you don’t need to measure 10-minute units of work, right? But as long as it’s not going down, then it’s a rather, rather a good thing.
Then there’s obviously tech health because we like producing output in order to generate outcome. We also want to do this sustainably and therefore tech health is important. So we’re looking at the amount of incidents, mean time to recovery, but that general DORA metrics would be helpful there. Tech debt should be also assessed, analyzed, ideally measured in some form, right? And then, not to forget, team health is super important so that the people, the folks in your organization are actually engaged. They feel committed to what they’re working on, uh, aligned, right? And they’re, I’m a huge fan of the self-determination theory, which pretty much says, okay, you have this relatedness, you have, the mastery. And you have the, the autonomy, which are the three main like, big dimensions, when it comes to motivation and, and this motivation that leads to, to happiness and ultimately, engagement. Yeah.
Kovid Batra: Perfect. I think that sums up a really good vision for us to drive or tell the audience how to drive tech teams, actually. On the very first point when you talk about, like talking about the autonomy, looking at the outcome, right? You talked about outcome. In that moment, leaders, managers still align with that. But I have felt, of course, it could be a different scenario at tonies, for sure. But with developers, this comes with a difficulty, right? They just write code and they really don’t, like most of the time they don’t tend to see the value they are delivering through that code because it is, I understand it is indirectly related. You first write code, then the product works and then the product is adopted and then the features are adopted, people use it. But we definitely know that if the developers, the teams themselves are so aligned with the outcome-oriented approach while writing the code, that makes the best mix for a team, right? Do you practice that or are your developers already trained in that mindset? How it looks at tonies? And if it is not like that, how are you working towards making it work?
Sebastian Heide-Meyer zu Erpen: Yeah. So, it’s not equally distributed within the org. So for example, we have one team that is focusing on the so-called IoT platform, which is the backend that the Tony boxes, our audio players are sending their requests to, like if they request new audio or whatever, right? And those engineers are a little bit further away from the product than let’s say, those who are producing the actual box, right? Or those who are working on the app, they are consuming their product themselves, right? They’re interacting or are much closer to the customers when developing their product, right? However, that being said, I mean, we have one big advantage in that we have lots of young parents who have children who have the Tony box at home, which makes it very easy to connect to the product, right? But even if this weren’t the case and for many folks, this is also not the case, they don’t have kids and they are not so well connected, right, but we’re always trying to focus on the ultimate outcome for the customer. So, that’s when we talk about a new feature or a new, like let’s say epic, that, that we’re kicking off, right? And we are always talking in like starting from what’s the value for the customer that we are planning to generate. And we’re actually trying to do the discovery already with engineers so that they ultimately are part of selecting the solution. Exactly. Because it’s ultimately always like starting from the jobs to be done, right? You have an idea of a job to be done that’s unmet not, or undermet, in terms of offerings, right? Then you’re trying to validate this idea first. So, is the problem that you’re trying to solve actually the right problem, right? And then, you’re trying to come up with what’s the quickest solution for this job to be done. So, what’s the fastest way to build it in order to then validate it, right? And now, we’re trying to include the engineers already in this discovery phase so that then by the time we’re actually building it and rolling it out, we have the minds of engineers already on the consumer problem. So they are like, strongly connected.
Kovid Batra: Perfect. I think this is a very good idea, actually. Involving people from the design process itself would really help them connect, looking at what those jobs are to be done by the user and then probably have that relatedness while writing the code. So, that makes sense. And of course, as you said, for tonies, it works even better because they can use their own product and see what needs to be done. So, cool.
Great, Seb. I think it was a very good talk and thank you for sharing such in-depth things that you’re doing at tonies and giving us that insight. So, I would love to have another chat with you sometime again on another episode, maybe because I see that these 30 minutes are very less for me to know what you have in your work and in your mind. So, cool. We’ll look forward to connecting again and thanks for today. Thanks for taking out the time and sharing your thoughts with us.
Sebastian Heide-Meyer zu Erpen: Thanks for having me. It was great. Great fun. Thank you.
Kovid Batra: Thank you, Seb. Have a great day. See you.
Sebastian Heide-Meyer zu Erpen: You too.
In the latest episode of ‘Beyond the Code: Originals’, host Kovid Batra welcomes Eric Heikkila, Technical Lead at Ford with a rich background in organizations such as Arbor Insight, Gene Codes Corporation, and more. Their conversation revolves around ‘Pair programming, remote work & developer well-being’.
The podcast starts with a fireside chat with Eric, giving us a glimpse into his journey. As the conversation progresses, he delves into the transition from working at a startup to his current leadership-cum-IC role at Ford. Further, he shares effective strategies for remote team management and the pivotal role of pair programming and DORA metrics in ensuring team success and developer well-being.
Eric concludes by offering parting advice to the audience, emphasizing honesty, embracing failure, and learning from mistakes.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest. He has 30 years of engineering and leadership experience. He has been the founder and ex-CTO of Arbor Insight. Currently, he’s working as a Technical Leader at Ford. He’s also an active Modern Agile community member. Welcome to the show, Eric. Great to have you here.
Eric Heikkila: Thanks. Great to be here.
Kovid Batra: So Eric, thanks a lot for taking out time and coming to the podcast, sharing your thoughts with the community. They’re really looking forward to it. But before we jump into that, we want to have a quick fireside chat with you to know you a little more. Are you comfortable with that?
Eric Heikkila: Absolutely. Yep.
Kovid Batra: All right. All right. So let’s just start with your hobbies maybe, outside of work. What do you love?
Eric Heikkila: Sure. I love building things. We do, you know, all day is mental work. So, doing things like, you know, woodworking or putting up drywall, even painting, love doing all that. Just something tangible that, you know, after all day working on stuff that doesn’t exist.
Kovid Batra: What was the last thing you built?
Eric Heikkila: Recently I took up leatherworking. So I built a prototype really for a dice pouch. My son is an avid Dungeons and Dragons player. He’s at college right now. So building him something to take with him to his gaming sessions.
Kovid Batra: Oh, that’s so cool. Perfect. All right. Tell us more about, something about your life, some life-defining moments.
Eric Heikkila: Yeah. I guess for me it was right after 9/11, I really wanted to just, you know, drop what I was doing and go to New York and help out. But I couldn’t do that. I have a small family, I had a job at a startup as it, as it were. I found out a company in Ann Arbor was working on DNA matching software. So a fellow I used to know, got me an interview there, started working there, and then spent nine years working on software to not just do identification of 9/11 victims, but also to help fight child trafficking using forensic work, used to help, like in the Thailand tsunami. And that’s when I discovered I could use my skills for, you know, it may sound corny, ‘for the greater good’ as it were. And so since then, I’ve always kept an eye out for any of the opportunities that come along to make sure that I was still fulfilling that, that need to, uh, you know, help not just, you know, someone with a counting software, but, you know, somehow contribute to bettering everyone.
Kovid Batra: Oh, that’s so nice. Great. We’ll definitely talk about this more.
Apart from that, like it’s been almost 30 years into engineering. I just want to know, like, how was your first experience with coding or maybe your first experience with your computer? Tell us something about that.
Eric Heikkila: Yup. So my dad was an elementary school teacher and when I was seven, he brought home an Apple II, uh, to do grading. They gave him to do grading. And I was just fascinated. And so I bought a book on quick basic and taught myself how to write code. It was really terrible, but, you know, I was able to do, make a character generator for Dungeons and Dragons. Cause you know, that’s where my son gets it from, I’m a big gaming geek. And so, that was, that was my first foray into that, getting the computer to do all the dice rolling and then eventually print out all the character sheets. I wouldn’t have to write them out by hand.
Kovid Batra: Oh, that’s so nice. Perfect. Thanks a lot for sharing all this with us. Now I would like to move to the main section, where I would want to know your journey from a tech founder at Arbor Insight and then moving into a leadership-cum-IC role at Ford. So tell us about this transition, like what you used to do at the startup when you were working there. And then now you have transitioned to this leadership-cum-IC role. How is it different? How is it better? How is it bad? Just tell us about that.
Eric Heikkila: Sure. Yeah, it was definitely a transition. So at the startup, which was a lot of nights and weekends and all the time I wasn’t at my day job and we had a fairly small team, so I wasn’t just setting, like building roadmaps and, and setting technical direction, it was also, I had my hands in the code as well for a lot of it. But then moving from, from that to not just another programmer, but certainly not a, you know, not high up in the executive food chain, say at a large company like Ford. Definitely took a bit of time to get that mindset of, yeah, I’m not setting the direction technically. But their team is really good. Our leadership is very supportive. So I’m still able to bring in ideas and techniques and tools and say, “Hey, we should try this. We should try that.” I’ve got the leeway to experiment with on my team and then bring that to the broader technical leaders. You know, once I’ve kind of vetted it with, you know, on a team, a project and go from there.
So that transition was, you know, interesting in a number of different ways, but while I’m, you know, not at the top of the food chain now, it’s also a lot less stress because I’m not at the top of the food chain. So it was a nice kind of, you know, mental break to get back into more just, you know, more day-to-day coding and still making technical decisions, but, at a smaller scale than at the, uh, like the CTO-level.
Kovid Batra: Makes sense. So basically, all these years where you have worked, you wanted some break from the stressful situation or stressful work that as a CTO you would be doing at a startup. Now you wanted to move to something which was less responsible, right?
Eric Heikkila: Right. Yeah. Yeah. And the, and our, our startup had gotten acquired. So it wasn’t good to stay with that company in particular, but, yeah, I definitely needed something a little more stable for a while anyway.
Kovid Batra: Totally makes sense. Perfect. So tell me more about your role at Gene Codes Corporation, right? You were Head of Software Engineering there. What exactly were your responsibilities in day-to-day and how did you used to execute your routine, the challenges that you faced at that time? Can you tell us more about that?
Eric Heikkila: Sure, sure. And that was the company where I was doing the DNA matching software previously. I had left explored some other, other jobs and then ended up going back to that company after the President reached out to me and said he needed some help. One of the really interesting challenges was only two of us were in the same time zone and the rest of the dev team was 8 time zones away. So there’s a lot of, you know, get up at six in the morning, get into work, have a couple hours of overlap time to go over what the team had done, you know, the previous day. And then I’d spend the rest of my day working on technical feasibility of what they were doing and like how they could move forward to the next step and what the, you know, direction to give them on the stories that they were going to pick up when they came back online. And then at the end of my day, I was offloading that to them and then going home and, you know, coming in the next day and finding out how it went. So that, that lag was definitely interesting to deal with. That was pre-COVID too, so we weren’t used to working remote, but, that certainly helped me anyway, when we transitioned to more of a remote work environment, having that experience with a team, you know, many timezones away.
Kovid Batra: I think still, I mean, a lot of companies were already before COVID were working remotely, and post-COVID it has become even more normal to have a remote team. But I’m sure you have been doing that, now at least at Ford it’s not a remote role, right? Before this, you have been in a remote role, right?
Eric Heikkila: Currently Fort is, is remote.
Kovid Batra: Oh, that’s also a remote role?
Eric Heikkila: Yeah, yeah, it’s all remote. We do go into the office on occasion, if we want to do like some whiteboarding in person or get a couple of teams together and, and brainstorm some things. But day-to-day, on the team I’m anchoring, we’ve got people in California and Colorado, New York, you know, kind of spread all over the place.
Kovid Batra: My question was actually that if you are working as a remote leader of a team and you’re working as a remote IC, like these two roles working remotely, there is a whole lot of a difference. As an IC, like you, you just have to do your own work most of the time, right? So it’s okay for you to, like be remote and do it. You are motivated enough and you are so senior that you know what to deliver, when to deliver. You remain committed to that most of the time. But, if you look at it from the leadership perspective, that the role that you are into and handling teams remotely, I’m sure it would have been a little difficult compared to having people in-person, like keeping them motivated, checking on what exactly their enthusiasm is when they’re at work because it changes when it is remote. So, at that time were you using any specific tactics or I should say, strategies to handle your remote teams better and take care of their well-being as well as their overall output of the work?
Eric Heikkila: Yeah, we didn’t get into too much of that with the Software Director position at Gene Codes. Currently at Ford though, in my position, the team around, we set up, our core hours to make sure we had at least six hours of overlap regardless of where we’re located. And then we’re always pairing our ensemble programming.
Kovid Batra: Oh, that’s nice!
Eric Heikkila: And then, so we’ve got, and then we moved stand up, so now we do that just before lunch so that we have some contiguous time in the morning with everybody. And then, just before we’re going to take a break anyway, do a quick stand up and then after lunch, continue bobbing, ensemble programming, pairing. And that seemed to work out pretty well. And then we’ll for like morale building, we’ll do like, you know, once a month or so just to have like a couple hours of, you know, playing some online game together or one time, we did a ‘ask me anything’, but it was around each of the individuals and you could put, like two or three questions that you want to ask the other person. And we did sort of like a lean coffee on that and, and got to know some interesting things about our team members.
Kovid Batra: Cool. So when you are doing it remotely, even right now at Ford, as you said that you have this setup where you try to overlap and do pair programming, this experience of pair programming, how do you find it? Like, is it beneficial in terms of getting more or better code done? I understand the point that if you have an overlap, at least you get to know each other, you stay connected. But if you look at the core work done through pair programming, what’s your thought on that? When you’re working individually, you are more focused and you deliver more quality, how does it work out? I’m interested to know that.
Eric Heikkila: Sure. Yeah, for me, when I’m, when I’m not pairing, I’m way more stressed at the end of the day. Whereas when I’m, if I’m pairing all day, I’ll be mentally tired, but not stressed, because, I’m not alone, right? I’m always working with somebody, you know, sometimes two or three somebodies, at a time. So it’s, we never get into a place where I’m stuck, I can’t move forward because we have, you know, multiple brains all working in the same context and the same goes for either motivation or energy level. If I may be, you know, starting to flag, my partner or the rest of the mob may be, you know, on the upswing. So it’ll balance a lot of that, a lot of that out as well. And then just the knowledge transfer, right? Just being able to, you know, it doesn’t matter if I’m pairing with somebody who’s senior, somebody who’s junior, someone who just came in from college who doesn’t know what they’re doing. I still can learn from them, depending on, you know, what we’re doing, maybe some shortcuts in the idea that I didn’t know about, or maybe some new TDD tool or a different way to look at an algorithm. And so there’s a lot of a lot of give and take, and I find a lot of value in pairing, and, or, ensemble programming, especially for onboarding. Like on any of my teams, day one, you are committing code, right? It’s not, “Oh, welcome to the team. Spend three months reading the manual over there in the corner. And then we’ll get back to you later.” It’s, you know, hands-on right away, get in there and get some work done, which, uh, I think is beneficial. And so far I’ve heard nothing but positive feedback on that from the people coming into that environment too.
Kovid Batra: Yeah, absolutely. I think that really works there also.
Cool. So now, coming to this point where we are looking at pair programming, helping teams become more productive, in general, in so many years, you would have worked with different teams, build different teams, right? But the most important question always comes, as a leader at least, how much effort the team is putting in? How much effort is aligned to the business goals? How would you define the success of your engineering team, right? And as a leader, you have to take accountability and responsibility for that, right? So, tell us about different experiences with different companies, of course, the way you have defined success for your engineering teams and how do you go about it?
Eric Heikkila: Right. So I guess it depends. Like at the startups, it was very much, “Are we getting the features out that our customers want?” Because they’re waiting for it, right? They said, “Here’s what we need.” We don’t have any time, get it out the door so we can get it in their hands. And a lot of that ties into the metrics that, you know, DORA, tracks and, you know, supervises. And then, for me, the time between when we, you know, put pen to paper and say, “Here’s an idea.” to when that gets, you know, not just deployed, but released out to the customer. That’s really, one of the main metrics I look at. And then also, you know, number of defects that get released and, and things of that nature. So I’m not, not so worried about lines of code, not so worried about, you know, effort or how long does the story take, but really, are we, are we generating value for our customers? And, that may not be writing code necessarily, depending on what the feature is.
Kovid Batra: Cool. So even now, when you are part of such a big organization, right, we see a lot of frameworks, a lot of engineering metrics coming into the picture. So for smaller teams, when you have almost complete visibility, like what people are doing, what is getting delivered. I personally feel that this approach of setting the fundamentals of delivering value as a success for the engineering team is perfect, right? But, when the size becomes bigger, like you have so many people working along with you, having clarity for yourself as a leader and for the person who is working as an IC, as a developer, on a day-to-day basis, it’s very difficult to keep them motivated just with this long term vision of delivering value, right? On a daily basis you’re writing code, you really need to have a push where you know, “Okay, I need to do this today” and you have to win every day, right? Not every day at least, but you have to put in that effort. So a lot of companies we see putting metrics in place, right? Putting certain KPIs in place. What’s your thought on that, or for that matter, how do you do it right now with Ford? Are you guys implementing something? If you’re comfortable sharing, please do.
Eric Heikkila: Sure, sure. Yeah, we’re, yeah, it’s, it’s interesting because we’re kind of going through that phase of, yeah, “What should we be measuring? And how do we communicate that to the teams? And how do we break it down at an executive level and at the next level and get on down to the developers?” So what we’ve been trying to do is create, you know, objectives at a, like a division level, you know? And then, and then at a more like a product line level. And then from there having each of the teams in that product line look at those, OKRs and then say, “Okay, is that something we impact?” You know, is it? Then, “How do we impact that?” And then, you know, generating their objectives and, and the metrics for success based on how they think they measure up to the, the overall objectives that the, you know, the company has set. So, doing a little bit of top-down and then a little bit of bottom-up. Hopefully, they’re kind of meeting in the middle and making sense.
Kovid Batra: Making sense. Yeah. Yeah, absolutely. Is it okay for you to share any of the examples that you have recently seen getting implemented at your organization or somewhere else where you can actually tell us with clarity which metrics would be suitable for what kind of measurement? Do you have an example in your mind?
Eric Heikkila: Oh, yeah, part of the problem, especially at Ford, it’s kind of a moving target because they’re, you know, changing technologies, you know, partnered with Google now and, you know, things are kind of moving at a, at a fast pace for the, the development teams. So we’ve been looking into automating more of the DORA metrics, but like actually tying that into, to get for, so we can track commits and tie that to stories and then track that, you know, through its life cycle, it’s a bit of a challenge due to the different technologies in play right now. So hopefully, they’ll settle down and then we can get some of that automated. Right now there are some dashboards in place, using a tool like Datadog to be able to generate metrics and then post them someplace that’s, that’s visible. So we can track, yeah, a lot of the not necessarily velocity, but you know…
Kovid Batra: Production failure, basically the observability there, right?
Eric Heikkila: Right. Right. Yeah.
Kovid Batra: Makes sense. Makes sense. So I think this is also a very important metric to, I think one of the most important metric to track because ultimately it links to customer satisfaction also, wherein if there are more bugs, more failures on the production, then the customers would be dissatisfied. So cool. I think, yeah, that’s a very relevant example.
Eric Heikkila: Yep. So we’re going and we’re taking not just that, but looking at, okay, how can we make that predictive? So, you know, starting with, you know, measuring uptime, downtime, but then, working on instrumenting it so that we can tell, okay, it’s about to fail.
Kovid Batra: Yeah.
Eric Heikkila: We need to intervene before it impacts our SLAs.
Kovid Batra: Perfect. Perfect. Absolutely. Apart from looking at the efficiency, I think one more important thing which has recently become very important is looking at the well-being of your team members, right, their experience. So how do you guys do it at Ford or how you have been doing it at other companies where you have worked? Can you just give us a few examples, like how you executed developer well-being, probably if there were some metrics you were looking at to ensure that people are feeling happy, motivated?
Eric Heikkila: Sure. I mean, one of the big things is, we do a retrospective. It’s about once a month now. We did it for every two weeks. That was a little much for the current team size. So we pushed it out a little bit longer. But on that, we have a, a wheel that has all kinds of emotions around those around the side. And we’ll, you know, put a dot vote those.
Kovid Batra: Okay.
Eric Heikkila: And then we’ll just go through it and say, “Okay, I’m feeling excited because we’re working on this project. I’m feeling worried because we said we’ll get this done by the end of the quarter. And, you know, maybe I’m tired because we’ve been, you know, working extra hard because of the worry around what we promised.
Kovid Batra: Makes sense.
Eric Heikkila: So a lot of that, and then spending more time on the retrospective on the, more like emotional or personal side, rather than the technical side. We’ll save, you know, the technical stuff for the day-to-day standups and interactions. But, really for the retrospect, we try to focus on, you know, like you’re saying, well-being, how are people feeling, you know, what should we try changing to, you know, maybe reduce some of the stress or, you know, at least spread it evenly across the team.
Kovid Batra: No, at least the important point is that the teams, the organizations should have a focus here. There could be multiple ways to do it, but at the end of the day, if you have an intent to actually take care of your teams, they would reciprocate back in terms of the output that they’re bringing in the value they’re creating. So it is cool. Like, everywhere I see these kinds of things happening where there could be pulse check-ins, there could be things like what you said, that there is this dart you put on, different emotions and try to understand. So that makes it more gamified and interesting for people to express themselves and come up with things that they are feeling. So, really cool for sharing that with us. I think we’ll try that in our company too.
Eric Heikkila: Cool.
Kovid Batra: Cool. Eric, I think, more or less, these are the questions that I had, but before we let you go, I would like you to share some advice from your 30 years of experience that you would like to give probably to your younger self or the audience who is coming into this role. Any parting advice from you would be welcome.
Eric Heikkila: Really the, some of the things that have, that helped me out, also got me in trouble is being honest, just be completely open and honest and, you know, and say, here’s, here’s exactly what’s going on, right? Good or bad. You know, I just need to have that honesty and the other, the big thing I’ve seen too, especially from people new to the industry, they’re so afraid to be wrong. It’s like, go ahead and be wrong. It’s okay to be wrong. We’re wrong all the time. We don’t know what we’re doing. Welcome to the club. Be wrong, fail fast, but be able to recover from that. So do, you know, make small mistakes. You know, go ahead and make mistakes. Just make them small and then learn from them.
Kovid Batra: No, that’s a very apt, perfect advice. I think someone who comes in to the system and this is what the first time they’re working in a particular role, they are too conscious to fail. They’re too conscious to express themselves as being wrong. So people get into that different direction if they’re trying to defend themselves. So, it’s a very good advice. And honesty is definitely something I personally appreciate. When you are transparent, when you are telling what the exact situation is, people around you feel more comfortable, take better decisions and it becomes easy for you and the other people around you to operate in a better way. So, great piece of advice, Eric.
Thank you so much for taking out this time and sharing your experience with us once again. Looking forward to having more discussions with you in the coming time.
Eric Heikkila: Sounds good. Thank you very much.
Kovid Batra: Thank you, Eric. Thank you so much.
In the recent episode of ‘Beyond the Code: Originals’, host Kovid Batra welcomes James Samuel, Software Engineering Manager at Reddit and author of the blog ‘Effective Software Leads’ with a rich background in organizations such as TIER Mobility and AlphaHill. He engages in a compelling discussion focused on the theme of ‘Driving success with dev autonomy’
The episode kicks off with a fun fireside chat with James, followed by an insightful discussion on the core responsibilities of an Engineering Manager at Reddit. Further, he imparts valuable wisdom on striking the balance between technical leadership and effective people management and sheds light on encouraging developers to think like Product Managers and the critical pillars of building high-performing teams.
Lastly, James provides actionable insights into effectively measuring team efficiency and performance using DORA metrics.
Kovid Batra: Hi everyone! This is Kovid, your host, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest who has 12 years of engineering and management experience. He is the author of the ‘Effective Software Leads’ blog, which totally focuses on the difficulties of building and leading software teams in the 21st century. He is currently working as an Engineering Manager at Reddit. He’s also been ex-Head of Technology at TIER Mobility. Welcome to the show, James. Great to have you here.
James Samuel: Thank you so much for having me today.
Kovid Batra: So James, today, I think we’ll have a lot of questions to ask from you, a lot of things to learn from you, but before we get into that, I would love to know more about you, the audience would love to know more about you. So, we have this ritual of a quick fireside chat where we ask questions from our guests which are outside the scope of the work that they do so that we know you more. Are you ready for that?
James Samuel: Yeah, absolutely.
Kovid Batra: Great. Thank you so much. So, let’s get started. Let’s start with a very simple question. Tell us about your hobbies that you really like to pursue.
James Samuel: It’s an interesting question. I enjoy a variety of sports ranging from tennis, badminton, and sometimes volleyball. But one thing that I really like so much is playing tennis. In my free time, you either see me playing tennis or badminton, you know, either of the two.
Kovid Batra: Perfect. And tennis is a fit man’s game, I’m sure. I have tried it multiple times, but I’ve never been able to hit the ball inside the court, either it’s outside. Cool, cool, cool. So, do you play like state-level or something, or it’s just a hobby?
James Samuel: No, it is just a hobby. Something that I spend time with friends, I kind of like play, in my free time. Not really a professional level.
Kovid Batra: Okay. Got it. Got it. Got it. Cool. Perfect. I think this, this another thing, which probably is a passion for a lot of techies, like, you get started at an early age. Most of them whom I am talking to on these podcasts that they start early-age, coding or early-age interaction with computers. What was your first experience? When was your first time with the coding and the technology?
James Samuel: Yeah. great question. How I moved into programming or coding was really an interesting story. And it began around 14 to 15 years ago during my second year at the university. I was studying industrial chemistry. So, a friend of mine was also studying computer science at the same university. So one day, he came to my hostel and was writing some code on his computer. Later, I knew what my friend was writing was C++ and around this code and I saw the output and that piqued my interest. And I started to ask questions. How did you do it? Like, because it was just so, it was magic, you know, writing something that doesn’t make sense and then you could compile it and run it and then you see the output. And that day, I picked my computer, installed everything that I needed, and a week later, I bought a programming book and started practising. And I discovered that I really enjoy writing code and seeing the output of the code that I wrote than actually studying chemistry that I was doing at the university. So..
Kovid Batra: That’s quite a transition actually, from chemistry to actually coding, I mean. But, I think for a lot of techies, this early-age experience with coding has always been magical, right? I mean, which was your first code that you wrote, if you remember?
James Samuel: Yeah, so it was a game. I was trying to write a game where you kind of like guess a number. So it’s going to give you a box where you can input something and then you put the number and then it will tell you how far away you are from the number, how, how many. And if you get the exact number, you win. So, that was a very simple game that I programmed.
Kovid Batra: But back in that day, I’m sure this would have been another magic trick for people.
James Samuel: Exactly!
Kovid Batra: Cool. Cool. Cool. How old were you at that point in time?
James Samuel: So I, I think I was around 18-19 years old at that point in time.
Kovid Batra: Cool.
James Samuel: Yeah.
Kovid Batra: Perfect. All right. Moving on to my, my next question. What is that one quality about you that you really feel proud of or you think that this is something that you have really accomplished?
James Samuel: Yeah. If I’m going to look back, I’ll say kind of like pushing myself outside of my comfort zone. I’m kind of like, I tend to, I can, I get bored easily. And one of the things that excites me is trying something that I’ve never done before and kind of like pushing myself outside of what I’m comfortable with and kind of like testing new things, taking new challenges, and all that. And this has really been an interesting one. It has really helped me right from the beginning, even from pushing myself outside of, you know doing chemistry and moving into programming and finishing programming, trying to create software and moving from one school to another school to sell the software that I built. And at the same time, also kind of like pushing myself from, from one city to another and ultimately from Nigeria to Germany. So kind of like trying to, you know, find a new challenge and pushing myself outside of the comfort zone.
Kovid Batra: So, is it the curiosity in you that pushes you outside of your comfort zone? Or is it something like that when in needy situations, you push yourself out of your comfort zone, you get great rewards, and now you are trained, your brain is trained in a way that every time you have pushed yourself out of the comfort zone, you achieve something. What is it actually? Is it like innate curiosity or is it the reward mechanism that actually made you move in this direction of moving yourself out of that comfort zone?
James Samuel: Yeah, I think it’s a mix of both. At first we start with curiosity, being curious. How does this thing work? And what would this thing feel like? And then when I become curious, I tend to venture a little bit. And, when I get there, I’m challenged. I want to see this to the end. I want to do this. And half of that, the rewards that come kind of like something that helps me to keep doing that over and over again. So I would say a mixture of both, curiosity is there and also the rewards you get when you try something new and then you can say, “Oh, I’ve done that.” Yeah.
Kovid Batra: I think that’s amazing. And having a mix of both is actually cool because if that innate curiosity is missing, there are more chances of not letting you move out of that comfort zone for a very long period of time. So if you have both the things in place, probably it plays a much stronger role and then can take you even farther than compared to somebody who has either of those. So, cool. Cool. I think that’s nice. It was great knowing you, James, and thanks for sharing all this with us.
And now I think, we, the audience are eagerly waiting to talk to you about what you have done in your career, take some learnings from there. So, you have been an EM in Reddit, right? And you have been into this role and responsibility for, for quite some time now. So tell us about, let’s start with this. Like, tell us about your daily routine. What are your core responsibilities? And then you can tell us about the challenges that you see.
James Samuel: That’s a great question. Yeah. One of the things that I do at Reddit as an Engineering Manager, it depends a lot on the day and the challenges of the day or what my team is trying to achieve. I work on the core consumer product at Reddit and a typical day for me at Reddit could be hiring and interviews, for example, trying to fill the open positions that I have for my team. And, it could also, after I work also spend, I spend a fraction of my time sourcing candidates for those roles as well. And also reviewing a couple of codes sometimes, and also the experiment my team is running. At Reddit, we have a culture of experimentation, how do you kind of like build something and see how users react to it. So, we experiment a lot. And sometimes, it requires digging deep into code, looking at the data and see, the output, the impact of that feature we’re building. And, it could also be meeting with managers of other teams to sync on what we need from them, or what they need from my team as well. And also, partnering with stakeholders like Product Managers on defining the strategy, the road map for the team as well. And a huge percentage of my time is also spent in 1-on-1s, trying to kind of like, you know, coach the engineers, my team partner with them, support them as well, and also kind of like growing them because one of my roles is to make sure that I grow every one of my teams and understanding their strength and also leveraging their strength as much as possible and also helping them to level up where they need to improve as well.
Kovid Batra: Cool. I think there are quite some responsibilities that you have here in this role, but I’m very curious about one question here. A lot of EMs remain in this dilemma of, uh, taking up that technical lead kind of a role also, responsibility also in the team, while also managing people and taking care of the project deliverables. In your case, how do you manage or how do you keep this balance in place? Or do you even think that you should be moving in the technical direction where you are taking the decisions, the technical decisions for the team? So, you just gave me an example that sometimes you are reviewing the code. Is it something that you think the EMs should be doing on a regular basis and how do you do it? So can you just tell us about that?
James Samuel: That’s a great question. And it’s also something that I struggled a lot when I ventured into engineering management early. So one thing that I, I think that I used to assess myself that I think managers also assess themselves is whenever there is a technical task, ask yourself, “Is this the most important and the most impactful thing I could be spending my time on right now?” And this question, if the answer is yes, then go for it. Most of the time you might find that the answer is no. And the couple of reasons why it could be no, for example, there might be a strategy problem that your team might be having, the direction where the team is moving, the technical direction, that could be the most impactful thing an Engineering Manager could be spending his time on. And depending on the state of the team, it could be filling a critical position in the team. So if you kind of like line all of those things up, with reviewing code with, you know, making technical decisions, most of the time you might find that there might be something that is (more) impactful than doing that. And the second thing that I also try to do is if you are the sole decision maker for your team, technical decisions, then you are not growing the people on the team. So, you want to make sure you build a team that is able to function without you. Let’s say, you are only there for a month, the team should be able to run and still drive you back.
Kovid Batra: Right.
James Samuel: And by, by empowering them, you allow them to take decisions and support them from behind, from the back.
Kovid Batra: That really answered the question well. Realizing the impact of your involvement in the technical decisions would be the answer to take it up or not take it up. So, I think code reviews on a daily basis would be something that I wouldn’t do as an Engineering Manager, but if that particular code review is so important that it is going to impact, let’s say, or it can create a lot of technical debt or it is misaligned from that particular technical strategy that you have decided for the team, then probably reviewing in that particular week or in that particular month for the things that people are working on would be important for sure.
And apart from that, how do you, like as an Engineering Manager, I know that my team, like the business counterparts, basically the product team, right, they have certain expectations from me if I’m an Engineering Manager. What do you feel as an Engineering Manager is your core responsibility? Are they looking into this technical decision-making quality of yours at all the time, or are they relying on you to give them clear timelines, keeping the team happy, delivering projects with quality? What exactly is there in, in their mind as an expectation from you?
James Samuel: Yeah, that’s an interesting question as well. And before I answer it, one thing that I have seen in the past having worked with different Product Managers is expectations of Product Managers can be different, depending on where you are, depending on the team, depending on the company. And one thing that I try to do is to get together in the same room. Hey, what do you expect from me? How can I support you? Sometimes I see a little bit of differences between what the Product Manager might expect from another one, but overall it’s usually, there are usually some key things that I see across the board. And one of them is they also want to know the timeline. When is the project going to be ready? And sometimes they want to know how complex, should we build it or should we not? Usually there are a lot of computing priorities with different costs, engineering costs. So, they want to know these ideas that I’m thinking of how expensive is it going to be to build? And they also want to know how the project is going, regular updates. And at the same time, they also want input. Usually engineering would know how, uh, maybe if it’s expensive to build, if it’s not expensive. So they want to be able to know, get input from the Engineering Manager, like how expensive it is. Is this something that we can do? How feasible it is. And usually, these are things that I see across all Product Managers that I’ve worked with, in terms of expectation, what aligns.
Kovid Batra: Makes sense. Cool. So, I think here automatically there is a certain expectation from you in terms of timelines and to have those timelines, obviously, you cannot have clear timelines every time but to even have a tentative idea of what things look like you have to have a good understanding of what’s going on in the team, how this module which you would be working on could impact the other module which is already running, right? So, you have to have a good context of the code being written, how it is being written, where things are moving. My question to you is though both the things are required, creating that balance, taking out time to read about different technologies and to that depth where you are able to guide the people in the right direction, how much time do you attribute to this in a week or in a month?
James Samuel: That’s a good question. If I’m going to put a time on it, I think a huge chunk of my time is also trying to figure out what is happening across my team. And this goes around how the engagement of the team, what is the adrenaline, and also understanding what is happening in the code base that we are working in. All of these impact the timeline of what we’re building, like you mentioned as well. If it is very difficult to deploy, or maybe there is a bottleneck elsewhere, it will also impact the lead time delivery. So, most of my time in 1-on-1s, I try to understand how is the person in front of me feeling. Are they feeling engaged? And what are the bottlenecks, they are having right now? What are the technical challenges? What is wrong with the environment they are working on? And all of this kind of like, help me to be able to know how early is this team and at the same time, helping to know our throughput basically. Yeah, and I could go for that in terms of how I actually measure these, the dimension things that I look at.
Kovid Batra: I think we’ll, we’ll definitely come to that as well. My thought behind asking this question that how much time you attribute to learning new technologies is probably to find out how much a team needs from an Engineering Manager in terms of those decisions, right? So let’s say, you know, that your responsibility is to have 1-on-1s because that is very important to have a connection with the team to understand their problems, as you said. So you are allocating a certain amount of your time in that particular month or week for these activities. Do you dedicate time to such technical reading that really helps in taking those decisions, adopting new technologies? Maybe you are not building something from scratch, you are adopting something which is already existing, or it could be you’re building something on set, but the thought of bringing that piece into the architecture, into the code, into the day-to-day technical strategy, how does that work for you?
James Samuel: Yeah, that’s interesting. I think as engineers and Engineering Managers, I think technology evolves a lot and we need to constantly keep ourselves up to date. For me specifically, I spend a huge chunk of my weekends and maybe after work reading technology blogs, reading books, and also reading about emerging technologies. And it’s a little bit complicated because when you are a full stack Engineering Manager, you also have to read about mobile, iOS, what is happening in the Android world and what is happening backend infrastructure-wise. So there’s a lot, I spend a huge chunk of my time learning this and I also actively encourage my team members to kind of like go for conferences, buy books, even recommend books and things just to kind of like, you know improve, and then how can we apply new ways of doing things to how we work.
Kovid Batra: I think when, when you want to empower your team to like perform, deliver, right, they, they look up to someone, they need that figure in the team. So, probably when you have the context of how the business has to run, how things have to be delivered on that end along with the technological understanding, I think that inspires the developers the most probably.
And, I was recently, like reading this article and then I shared it through my LinkedIn post also. It was about that most of the high-performing teams are those where developers actually are able to think like Product Managers. They don’t have to do that exact role, but at least if they have empathy, if they have an understanding of what value they are delivering through their code, I think that’s the best scenario to be in. So as an EM, you can actually inspire your team to do that. And with that, I want to know, like how you actually bring in this practice into your team, into the developers and how do you, what’s your style of building that high-performing great teams at Reddit?
James Samuel: That’s a good question. So, there are two things here. For example, how do I enable engineers to think like Product Managers? Kind of like reason about the impact of the code, right? And how do I build high-performing teams? Those are really great topics that are actually very close to my heart.
So, one of the things that I do when I onboard a new engineer to my team, I start to let them know this is not about the code you write, it’s about the impact you are going to create. So when you assign a task or you are to do something, don’t think about the end goal, me writing the code and deploying, that it doesn’t end there. It is me writing the code, what is the assumed impact that this is going to bring to the company, and also seeing it through to how customers are using it and also tracking the metric to see if it’s actually bringing that in part. And one way that I try to build this is through performance reviews and all that. Rather than looking at output, we look at the impact you’ve created. And also enabling the team to kind of like if you are going to pick these tasks, what impact will they bring to the team? What impact will they bring? Will they kind of like maybe move us closer to our KPI or the goals that we’ve set?
And to the second question around building high performance, how performant is the team, I think there are four critical pieces that I think are crucial to build a team that is high-performing. One of them is something that I call ‘synergy’. And, one thing if you see a team that doesn’t have this, you see people moving in different directions. I like to use an analogy of a football, if you are a soccer fan. So one thing you see everyone’s playing, the goalkeeper knows his role. The striker or whatever, they all, everyone playing on the field, you know, supporting each other. And at the peak performance, one of the things that you see is that everyone is in sync. They all know their role. And this is where the peak performance happens. In software as well, synergy has to be there. It has to be working towards a common goal. Everyone has to know their role, what role they have to play in getting that. There has to be a clear direction.
And then the second one that I think is crucial is a culture of continuous learning and improvement. So, one thing is no matter how performant your team is, there’s always going to be a time when they will drop the ball. Something will happen. So, for them to continue to perform is to learn from that mistake. Can they reflect on things that didn’t really go away, improve on those things and keep moving? I think these are, these two key things are very crucial in building high-performing teams.
And another one is also ‘autonomy’. Something that I call empowering engineering teams, kind of like similar to what I mentioned. If you are leading a team that cannot exist, they can’t do anything unless they have their leader, then that is not a team that is empowered. You want to make sure that you take yourself outside of the job. Can you empower them, allow them to be able to own things end-to-end in such a way that if you are not there, the team is still working and working? And this is about allowing them, empowering them, supporting them from behind and not being a sole decision maker. Help them even to come to you, help them to reason how they can, help them to arrive at the decision, not to make the decision for them and this, I think is very crucial in building high-performing teams.
Kovid Batra: Cool. I think these are very good points. Having that synergy, autonomy in teams is very crucial. And I think, engineers themselves are, I believe intelligent species, right? They, they like that autonomy. They like to question things. So automatically, if you are imbibing that feeling of questioning things, what is the impact of what you are doing, if you’re just reinforcing it time-to-time, bringing synergy amongst them to deliver towards a similar goal, I think that really really works well for the team. So great piece of advice, James. And I think you are driving some great teams at Reddit right now.
Cool. With that, I think one last question I have. So, I’m sure there would be people who are directly reporting to you, right? Then there could be some indirect reportees too, right? So, in those scenarios where you have indirect reportees and you don’t have direct visibility, you can bring in that culture, give them goals, do the right hiring, right, set great examples. But I feel on a day-to-day basis when you’re running your sprints, right, when you’re seeing the performance over quarters, you just have to make sure that teams are being efficient, right? You don’t want to, like stress them out with too much work, but you want to see them being efficient. And of course, you have to take care of their wellbeing. How exactly do you gain that visibility when you are not talking to those five folks, there are indirect people also working along with you whom you’re responsible for, what are your ways of looking at and measuring that efficiency for them?
James Samuel: Yeah, that’s also a very good question. So when I was Head of Engineering at TIER, so I had this problem a lot. So I was managing 4 teams, engineering teams. And each team has an engineering lead directly working in this team. So, one of the challenges that I had is getting to know what is actually happening in all of these teams that I don’t directly manage and to be able to know how to support them as Head of Engineering. And there were four key frameworks that were really, really crucial in gaining this visibility. I do think for managers, leading teams that they are not directly managing, they need to get both quantitative and qualitative data that will help them to know or understand how these teams are building what they are building on time and within the budget they have. So, I call this ‘process’. And they also need to be able to get data that will help them understand if the things that these teams are building will continue to run at this higher level of performance and reliability, and they will continue to do so in foreseeable future. I call this ‘operation’. And they also need to be able to get quantitative and qualitative data that’ll also help them to understand the people building all of these things. Are they engaged? Are they happy to continue to build it? And they also need to get data that will also help them to understand if users they are building all of these things for, if those users are getting value and deriving satisfaction from them. And I call this ‘product’. So, these four pillars are very important to have visibility into teams that you don’t directly manage. You want people to know how are they approaching the software they are building right now. What is the process? How do they come across? How do they decide what to build and what to work on? How do they do prioritization? And you also want to be able to understand the state of the software they are building. Is it reliable? So what is the SLO like, and what is the infrastructure like? And then you also want to be able to understand the people that are building it. Are they engaged? Are they working on things they are interested in? Is someone about to leave the company? So, and you also need to be able to understand the people you are building for. If engineers are super happy, they are building that thing. And they are building it with all the reliability and performance you can think of. And at the same time, they have strong process. They can deliver, they deploy on time, and at the end of the day, users that you are building for are not getting value. They don’t like the product. You see no one. So, you need to be able to get data across all of these to know to be able to support the teams effectively.
Kovid Batra: Is there any specific tool or any specific method, any specific metrics that you are using to track all this? Like, some things are very qualitative, I’m sure those cannot be measured through objective numbers, right?
James Samuel: Yeah.
Kovid Batra: Like, how they’re prioritizing or how they’re making their decisions is something which you can understand through 1-on-1s or through pulse surveys where you can, like gather feedback from them on different questions, but is there anything else that you look at objectively when you look at the efficiency of the teams or the performance of the teams?
James Samuel: Yeah, that sounds good. When it comes to performance and productivity of the teams, one thing is certain, it cannot be measured through one single dimension. So, there are people who just look at, like how many times do you deploy in a day? And that’s it. How many pull requests? How many lines of code? It can be a tough one to measure, but one of the things that we’ve used or that we use a lot that I’ve used in the past is DORA metrics. And this can be very, very important because it allows you to get data from multiple dimensions to understand how the team is doing. And this is how a lead software engineer or software teams use to kind of like measure their performance. And one of them is the deployment frequency where you measure how frequent or how often do you release code to production. And this is about how fast can we get value to users. And when you see a team maybe deploying once a week, there’s a chance that the process is not right or something is wrong somewhere. And another one is the lead time, the amount of time it takes to get a code into production. How long does it take to deliver value to users? And there could be a lot of things responsible for this. It could be that the team is spending time, you know, not breaking the work into smaller, they are not doing rapid iterations, like small iterations. It could be a number of things that could be responsible. And another one too that I look at is what percentage of this value, of this change we are making is effective. And this is change failure rate. If we are trying to be as fast as possible, deploying as fast as possible, and at the same time it’s getting to production and it’s defective, then something is wrong with the process.
Kovid Batra: Right.
James Samuel: And yeah, and the last one is the time to restore service. No matter how, how great a team is, there’s always going to be a time when something will not go right. You will have an incident. So, and what matters is how long does it take an organization to recover from the failure when it happens, how fast can we get back up running?
Kovid Batra: That’s cool. I think that was a very detailed view of how you’re using DORA metrics and I’m happy to see that you’re using it to the fullest in terms of understanding not just one metric and looking at it from one dimension, but correlating a few things to actually understand the picture. So I think James, what I should call you, a ‘super EM’ then? No, actually this, this was really cool. I think, at your age, the level of experience you have, the kind of thoughts that you have of leading the teams, I feel are amazing.
So, thanks, James. I think this discussion was really amazing. There was a lot to learn from you and I think this 30 minutes of discussion is not sufficient for me to get all the things that you have experienced and implemented to make great teams at organizations, wherever you have worked. So, I would love to have you back on the show sometime again and talk about these topics in more detail, probably.
James Samuel: Absolutely. Thank you so much for having me as well.
Kovid Batra: Thank you. Thank you so much for your time. Have a great day, James.
James Samuel: Yeah, you too. Bye.
In the latest episode of ‘Beyond the Code’ Originals, host Kovid Batra welcomes Andrei Gavrila, agile coach and Fractional CTO at Pentalog. He has also previously contributed his expertise to Eurofins Group, Trace One, and Accenture Technology Solutions. The core of their discussion revolves around assessing, adapting, and transforming tech teams.
The podcast starts with a fireside chat with Andrei Gavrila, providing us with a glimpse into his personal interests. As the conversation progresses, he takes a deeper dive into the challenges faced by fractional CTOs in startups and large-scale organizations. Further, he sheds light on implementing agile at scale in large organizations as well as measuring the success of engineering teams, especially when determining team structure and topology.
Lastly, he discusses the ‘Maturity Model’, a valuable tool for engineering leaders and CTOs aligned with an agile mindset.
Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today we have a special guest from Romania with us. He has 16+ years of engineering and leadership experience. He’s working as a fractional CTO with Pentalog. He believes in consulting, and not just consulting, but then implementing solutions with the clients. He does technical audits, MNAs for all the tech teams. And he’s one of the highly recommended mentors on MentorCruise and Plato. Welcome to the show, Andrei. Happy to have you here.
Andrei Gavrila: Happy to be here too.
Kovid Batra: Great. Thank you so much for taking out time. And before I get started and our audience gets a lot of learning advice from you, I would like to know a little bit more about you, the audience would like to know a little bit more about you and we can, like start off with something like, how do you, how do you unwind your day? Where do you spend most of your time when you’re outside of work?
Andrei Gavrila: Good. So, I like to spend time with my family, so that would be number one. Then, I relax through learning. Maybe that sounds funny, but not to me. I really enjoy learning. So, usually at the end of the day, I am trying to squeeze one, one hour, maybe half an hour, so that I learn new things and I also like to play video games.
Kovid Batra: Oh, nice. Video games. So, this is like a childhood thing and is it like something which started very early on?
Andrei Gavrila: Yeah. Yeah. I started playing, I think, video games when I was five years old.
Kovid Batra: Oh yeah!
Andrei Gavrila: I don’t even remember what the name of that computer was, but the first game that I played was called ‘Prince of Persia’.
Kovid Batra: I remember it completely, man. All right. Which one are you playing these days?
Andrei Gavrila: Nowadays I’m playing a game that’s called ‘Total War: WARHAMMER’. It’s a strategy game. I think it works really well with the role that I’m doing that has a very strategic part. So yeah, I enjoy strategy games.
Kovid Batra: Perfect. Perfect. That’s an interesting find about you. All right. Apart from like unwinding your day with games and maybe taking some learning from there, what are the other learning sources that you have in your life? Like, do you do, read books or watch videos, listen to podcasts?
Andrei Gavrila: So, I’m trying everything, but maybe what the best learning tip that you might get from me is that not necessarily sources, but the way that I learn. So to me, first of all, learning is not reading or watching videos. To me, learning means changing behaviors. When, when we do that, the learning cycle, in my opinion, ends. And I think a lot of us associate learning with maybe reading or watching videos, but I think until the moment that your behavior doesn’t change or you don’t change anything, uh, I wouldn’t call that learning. And one of the things that I do to learn is I use a framework that’s called the 70/20/10 that says that for every, let’s say 100 hours, you should try to learn 70 of them through experience. So your job, the regular day-to-day stuff, 20 of them by learning from peers. Even what we do now, I would call it engagement learning from peers. So, it doesn’t necessarily need to be too formal. And 10 of these hours, learning in a structured way. So things like books, videos, podcasts, exactly what you said.
Now, if I were to recommend some of the let’s say some of my learning sources, there are many. I will share with you and maybe the audience, Trello board that I have where I’m keeping track of the learning that I do, but most of all, I would like to say that since I’m using ChatGPT many times a day, I feel that that boosted my learning significantly. Sometimes I even do let’s say, interviewing styles with ChatGPT where I’m asking it to ask me questions about a specific topic or a book I might have read. I think that’s really, really amazing.
Kovid Batra: Oh, that’s really interesting. We have always been asking questions to ChatGPT, but we never asked ChatGPT to ask us questions so that we are able to learn more. That’s, that’s very interesting. I would love to see that Trello board also. So whenever this podcast is going out, I’m sure, in our comment section, we would love to see that coming from you.
Andrei Gavrila: Sure. Definitely.
Kovid Batra: Amazing, Andrei. And, thank you for sharing your personal way of learning and some thoughts on that.
Let’s move on to the main section, uh, where we would love to know what you do in day-to-day as a fractional CTO, like things like how you’re managing your teams there. First of all, I just wanted to understand, when you work as a fractional CTO, right, are you specifically working with small-size teams or is that these large-scale organizations? What kind of organizations do you work with?
Andrei Gavrila: Yeah. The term ‘fractional’ can be confusing. Sometimes it might be confused with just ‘consulting’, sometimes it might be confused with ‘interim’. We will not get in the depth of the term because I don’t think it’s that interesting, but I like to work with all types of companies. Most of my experience is around, let’s say medium to larger companies. In reality, the term ‘fractional CTO’, I think works a bit better for startups. For example, you can be a CTO for two to three startups and you’re fractional there, fractional there, fractional there. But me, my, the things that I enjoy most doing is work with bigger companies that have problems around scaling, that see opportunities around these economies of scales delivering to millions of users that are looking for more efficiency, that are looking for predictability, they try to mix a world of legacy with the innovation that we can do today. And they are working a very fine balance between, let’s say those two domains.
Kovid Batra: Makes sense. Perfect. So, when you say it makes more sense with startups, I think you must have had some experiences with startups and you must have seen the challenges of being a fractional CTO with these startups, right? And I’m sure if you, if you got a chance to work with large-scale organizations, there, there would be a different set of challenges. So let’s start with the startups first, like what kind of challenges do you see and how do you tackle them, and then maybe we can discuss about something, for large-scale organizations, how to effectively build teams there and, like execute with teams there. So..
Andrei Gavrila: Sure. I would tell you first that in Pentalog, we define a CTO assessment. So, because we work with so many CTOs and we see the role implemented differently, we said we would like to help people better understand what the role of the CTO is, how it should be done and what different implementations of this role we see in the industry. And because of that, we define services around that. One service is CTO assessment, helping CTOs understand how they’re performing their roles. This is used both for growing or for recruitment. Then we have services around mentoring and a lot of the consulting that we do, also helps this role. But the idea is that in general, what we see is that in the startup world, the role of a CTO is more, is closer to a technical lead role, right? So, somebody who is coding and driving the technology very hands-on. So, sometimes the startup CTO is the person that has the most development experience, somebody who will code the hardest parts. And that’s normal because that’s what startups do. They try to put a product in our hands as quick as possible. You want to create the product. But, they are in a way exposed to the risk of missing the strategic part of the role of the CTO. So things like governance, things like how do we make sure that the decisions that we take today are still in control and will still be in control, once we succeed, once we want to scale, once we reach a phase of hyper-growth. These kinds of things are not really the best things that technical lead or startup CTO could answer. So, that’s the kind of work that I do when I work with a startup CTO. So, bringing more of that strategic governance, efficiency, decision, cost of ownership review.
Kovid Batra: Great. Perfect. But don’t you think, like with startups, which are in early stage figuring out product-market fit the strategic thinking could not be very, like long-term, right? Because they don’t know what they are going to build. Sometimes it happens, the customer itself changes, right? You shift from one segment to another. So, in that scenario where there are so many uncertainties involved, maybe you yourself would want to keep things streamlined in terms of strategy, but how do you communicate that and create a balance with that dynamic environment?
Andrei Gavrila: Yeah, that’s a, it’s a really good question. It’s not about bringing the kind of order that you would find in medium or larger enterprises, but it’s about finding the right balance as you say. I would give you an example. Startups usually decide without really analyzing and really understanding their decisions because they are in this space where they need to take a lot of decisions and there are some decisions that can really impact the long run. And also there are some decisions that become a problem after a while. One of the things that I do when working with startups, I’m saying we can decide whatever we want, but how about we try to keep track of the major decisions, and to explain it to our future self, why we took them in this way, and maybe when this decision will expire, or we need to revise it because something happened. I think this gives a lot of clarity in the life of a startup because it allows it to plan the development. So for example, you would take one decision around hosting or infrastructure or several capacity. But if you don’t specify that that decision will no longer work when you reach 10,000 users, you might reach 10,000 users and face that problem just then.
On the other hand, if when you decide, you know when that break up point might be, maybe when you go towards the 10, 000, you go close to 6, 000, we’ll start working on that because you have this clarity around what you decided and when these decisions are not working anymore, right? This is the kind of, let’s say, strategical or governance-thinking that is not natural for, uh, as I said, the startup CTOs, because their context is much more now let’s put the product with the right set of features in the hand of our users, but nevertheless, they decide and sometimes these decisions don’t remain in control.
Kovid Batra: No, absolutely, I get it. And it’s, it’s more about just taking a conscious decision whenever you are moving ahead. And at least you would be prepared, you would take a few better steps to handling the future problems also. So, it makes complete sense, absolutely.
Other than that, like moving on from startups to some, let’s say large-scale organizations, you mentioned in our last conversation, when we were talking that you take care of the agile, implementation of agile methodologies in the teams and you do that with different companies, right? So when it comes to large organizations where you see these methodologies are being wrongly perceived or people are executing in a wrong way, how do you bring that agile transformation with such large organizations where there is so strong cultural set up already there when you are entering as a fractional CTO? So, is there a good piece of advice for people who are looking to implement agile methodologies at scale?
Andrei Gavrila: Yes. I hope I got your question right. I will try to answer it and let me know if you, I understood it right. A lot of companies today are in a state of continuous transformation and constantly wanting to do more and better. I think the term ‘agile transformation’ has its benefits. I think it has less and less benefits, because kind of gives this impression that there is a finite thing that needs to happen and then we are transformed somehow. I think the context today is much more one in which this constant adaptability to what happens around us is permanent. And I think we are less in a phase to speak about agile transformation than speak of somehow the new normal, which is, how do I make sure my company is fit so that it can adapt no matter what happens somehow?
Kovid Batra: Exactly, exactly.
Andrei Gavrila: And a lot of companies that are maybe trying to work on that now are going through two main ways, especially the big companies. One which is the ones that we see most often where their transformation is very tied to frameworks and methods or topologies or in a way, processes, if you want. So a lot of companies are saying, “Let’s put Scrum in place or let’s put SAFe in place.” So that’s, in my opinion, most of the industry, that’s what most of the industry is doing. And that’s one way to approach that.
The second way to approach that we also see in the industry is something around culture, something around the way that we look at problems, mindset. A lot of companies will speak about proximity to customer, which is really nice because in a way that’s what agility is. But, a lot of companies are approaching that transformation saying, “Let’s try to change the mindset, the culture in our company to be closer to the customer.” And these are the two big ones to do, the two ways that companies today are approaching transformation and the reality is that to some, I wouldn’t say most, it could be a debate if it’s somewhat most, it’s not really working. They are not seeing benefits. This is why in Pentalog, what we do is we go to a third way which it’s not that obvious in the industry. And this third way, it’s about structure and government. Maybe I’ll give you an example so that everybody understands what I’m trying to say, but our idea is what kind of rules do you need to respect in order for you to be adaptable?
So, let’s give an example for the these three ways of doing it so that it’s a bit more clear. As I said, for the first one companies would say, “I’m going to be more adaptable because I’m going to use Scrum/SAFe, and this is a structure that allows for adaptability.” So if I’m having the structure, then I will probably adapt. That’s the, the philosophy there. The other one says, “I’m going to try to change people’s mindset, the way they approach things. And they maybe try to go then to a process of training, a process of understanding better, how things should work, speaking more of a customer, placing customers closer to the way that they will, they work.” That’s how they think, it will go. And in our case, we come and say, “What kind of rules do we need to respect?” And one of that rules could be that I’m having cross-functional teams so that I’m all over the organization, I’m having teams that don’t depend on other teams to deliver value. and that’s, for example, one of the, that’s the way that we do transformation, which is in my opinion, working much better than the other two ways.
Kovid Batra: Perfect. I think this is a very relevant example and the thoughts that teams should look into and probably when, when we talk of agile, we probably always look at speed, implementing certain practices like scrum, but the core fundamentals that need to be implemented are around customer-centricity and bringing adaptability with the change. And I think one of the ways that you suggested right now perfectly fits in.
So, cool. This was, this was really nice. But, there is one more question, like quite unrelated, but I feel that when you’re working with large organizations, you divide them, you decide the right structure, topology for the team you’re working, But, at that such large scale, one thing that goes missing is how do you look into whether the teams are succeeding or not, right? Engineering teams are succeeding in what they want to do or not. So, what kind of framework or methods or let’s say the metrics you would use to understand that? That whether these teams are succeeding or not succeeding, how do you define success for them?
Andrei Gavrila: Yeah. I’m really passionate about that question and I think we could talk about it for hours. I will try to answer it maybe in the next two to three to four minutes.
Kovid Batra: Sure.
Andrei Gavrila: The thing that’s most important to me is that a lot of companies are asking that question, how do I know if my teams are efficient? How do I know if my teams manage to do what, what we need them to do? And the approach to that is usually to define KPIs and see if the teams reach those KPIs or not. Some companies look at velocity. I don’t recommend doing that. Some companies look at output. Some companies look at impact, outcome, that’s much better than velocity, outcome and impact. But to us in Pentalog and to me, the question is not, how do I know if my teams perform? Right? The question that I like to ask first is how do I know that my teams are in a context where they can perform efficiently, where they can be excellent? So instead of asking, “Is this team performant?” I like to ask the question, ” Is this team in a context that allows for performance?
Kovid Batra: Makes sense. Perfect. I think that that’s very relevant. So Andrei, that’s a really cool advice. I think setting the context right is more important than looking at metrics probably because that sets the fundamentals. But I would love to know how do you do that in your teams? Like, can you just like deep dive into it a little bit more so that we have some examples? Yeah?
Andrei Gavrila: Yeah. Sure. We are using something called maturity models. Maturity models got a bad reputation, some time ago, because they were used in a very heavy way, very, let’s say, non-flexible way. But we developed some maturity models that are really aligned with this agile mindset and are really one of the best tools that CTOs, engineering managers can use to answer those questions. Am I in the context where my team could perform or not? And these maturity models are very simple to understand. They contain items that you can say they are done or not. And the whole idea is that it will help you understand in which one of the four states you are on a certain dimension.
So, let’s pick security just as an example. You have a software development department, multiple teams, and you are asking yourselves, “Where are we on security?” So, with the help of our maturity models, with which are, as I said, very easy to use, you’d be able to say, if you are in a state of ‘starter’, that’s what we call it. And if you are in a state of ‘starter’, it means you are in a significant risk of failure. Or you could be in a state of ‘almost good’, which usually means that you are no longer in that immediate risk of failure, but you have a lot of waste in the process. And then, there is this column that’s called ‘good’, which means that you’ve passed that wasteful moment, and now you are actually working to optimize the system. The last one is called ‘very good’, in which if you are, you probably have competitive advantages because you do more than what your competition is doing. And you can think that we have these maturity models for everything, security, but we also have them for people engagement and now if you want, we can try to create such a very small maturity model between ourselves around people engagement. So, what is one thing that you think companies should do to no longer be in an immediate risk of failure around people engagement? What, what do you think companies could do to no longer be in an immediate risk of failure around people engagement?
Kovid Batra: Like, they, first of all, like they can go back to the people and understand from them that what are those different areas where they feel uncomfortable, what are the things that are making them not perform or not be the best version of themselves. So we can go and understand from them.
Andrei Gavrila: Exactly. That’s the kind of item that you would find in that column where we are not necessarily going to tell you how to do it. We’re not going to tell you, do it and ask them these questions and check these answers. But we would say, if you’re not asking periodically, asking your team how they feel, do they like what they do, what are their biggest problems, then most probably in terms of people and people engagement, you are an immediate risk of failure, meaning people might leave tomorrow because they are not happy with what they do. They don’t feel respected or this kind of stuff. So this is exactly how our maturity models are created and are populated by these kinds of items.
Kovid Batra: So I think that’s, that’s perfect. You said there are four dimensions, right? So, one is security. One is people. Can you just name the other two? I think I got the context of what you’re saying.
Andrei Gavrila: The dimensions are, are these columns like ‘starter’.
Kovid Batra: Oh, okay. Got it.
Andrei Gavrila: The second one is ‘almost good’, which is waste. The third one is ‘good’, which is efficiency. And the fourth one is ‘very good’, which is a competitive advantage. So, all the maturity models have these columns, but then we have maturity models on people engagement, on skills, on security, on data, on architecture, on infrastructure, on testing, on engineering practices and many more.
Kovid Batra: Yeah, right. I think I got your point. For every, like there are a lot of aspects of an engineering team. And for an engineering team to be successful, all these areas which we define, they should, like keep improving in these segments that you’re talking about. So..
Andrei Gavrila: Exactly.
Kovid Batra: Perfect. I think that’s a very relevant thing. And I’m sure this comes with a lot of experience.
Andrei Gavrila: Yeah. So, last thing that I would want to add here is that when people ask me, how are my teams performing, I feel that they are not efficient or they are not working out. First thing that I do is say, “Let’s try to fill this maturity model, and to understand where we are. And then once we fill them, I’m saying, see here and here and here.”
Kovid Batra: Right.
Andrei Gavrila: You are way below, let’s say safety. So in a way, until you manage to fix this, you will have maybe just marginal improvements.
Kovid Batra: Totally. Great talk. Great talk, Andrei. I think thanks a lot for sharing all these insights and relevant examples. I would love to have another session with you sometime because I think these few minutes are very short for us to learn all those things that you have done in your past. So, we are trying to do that 70% bit from the experience, right? So, cool. I think we’ll connect again for sure. Thanks a lot for taking out time today and talking to us.
Andrei Gavrila: Sure. Sure. It was really great being here. Thank you for the invitation. Have a great day.
Kovid Batra: You too, Andrei. Thank you.
In the recent episode of ‘Beyond the Code’, host Kovid Batra welcomes Sayak Saha, Director of Engineering at AUTO1 Group, with a rich background in organizations such as Wipro Technologies, Amazon, and Dell. He engages in a compelling discussion focused on the theme of ‘Can AI tools drive engineering success?’.
The episode kicks off with a fun fireside chat with Sayak. As the conversation progresses, he addresses the key considerations for scaling a development team. Furthermore, he explores strategies for fostering seamless collaboration among engineering, design, and product teams to enhance product development efficiency, particularly amidst challenges such as ambiguous requirements and communication barriers. Sayak also shares valuable perspectives on integrating cutting-edge AI technologies like GitHub Copilot and ChatGPT into existing legacy codebases, addressing concerns such as tool fatigue and optimizing resource allocation.
Lastly, Sayak talks in great detail about ‘Build vs. Buy vs. Run’ framework and essential benchmarks for evaluating the success of an engineering team.
Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have our special guest who loves to talk on podcasts, share his knowledge with the community. He has 16+ years of engineering plus leadership experience. And he’s one of the engineering directors at AUTO1.
Welcome to the show, Sayak. Happy to have you here.
Sayak Saha: Hey. Hi, Kovid. Thank you for hosting me and looking forward for a nice conversation with you today.
Kovid Batra: Thank you, Sayak. Thank you so much for taking out this time and willing to share your thoughts with the community. So, before we get started, there is a quick fireside chat, where we talk to our guests about their personal space so that the audience knows them well.
So, are you ready? Can we get started?
Sayak Saha: Yeah, sure.
Kovid Batra: All right, perfect. So, let’s start with your favorite travel destination.
Sayak Saha: Okay. I love to travel a lot, but especially seas because you have a chance to, to mix, play sea sport and enjoy good food. I think my favorite destination is Langkawi and to be honest, any sea beaches.
Kovid Batra: Cool, cool. We meet another beach person then. All right. Perfect. What about your heavy days? How do you unwind yourself at the end of the day?
Sayak Saha: Okay. So, my day starts with my daughter. So in the morning, first thing to drop her to school. Okay, so that’s how the day gets started.
Kovid Batra: Okay.
Sayak Saha: And after that, it’s like reading some books or news and then having a coffee and starting the day with a walk. And then I don’t know how the day just gets going.
Kovid Batra: No, that’s cool. And what do you do usually at the end of the day? Like, let’s say it’s a hectic day. How do you unwind?
Sayak Saha: Okay. Generally, if it’s nowadays I started doing is like in between meetings, I am always keeping 5 to 10 minutes, uh, to do a a bit of reset because that helps you to focus in your next meeting or whatever you are doing. Okay and apart from that, I love to play chess and this is something I started this year.
Kovid Batra: Oh, cool!
Sayak Saha: So, I try to play at least two to three games a day.
Kovid Batra: Cool, cool, cool. That’s nice. What was your last book that you read and could you share some learnings from there?
Sayak Saha: Okay. The last book I read a little while ago, maybe a few months. So it’s ‘Measure What Matters’ by John Doerr. He is a famous venture capitalist and engineer. And this book majorly talks about how you set your priorities and you drive things and basically setting up OKRs and KPIs. We talk about OKRs, KPIs a lot, how this translates to engineering organizations, how you measure it, how you can define your stuff, right? So, this book talks in more detail about it. And there are actually classical examples, how Google, Microsoft, Amazon, they did it for themselves. Okay.
Kovid Batra: Oh, okay.
Sayak Saha: And John Doerr himself, he’s a board director in this company. So he has guided that how he convinces people and how he improvises OKRs and stuff. So this is a great learning because as engineers, we often see that there are company goals that, hey, I want to increase revenue stuff and all, but how this translates to engineering orgs is something that gets lost, and this book is a great guidance for that.
Kovid Batra: Amazing. I think we’ll talk about this in the later part of the show also. I think I have a few questions there, but let’s get started. Thanks. Thanks for sharing your personal space with us, telling us about yourself. I think that was quite good.
We can move on to the main section. And in this, we would be talking about challenges that you see with a growing team. And of course, there would be a lot of other questions that might not be related to it. But, I think what we want to learn from you is what you have experienced in your career so far.
So, probably starting off with something that is related to the topic of challenges that we come across when we grow as a dev team, right? So, what are the important pointers that one should keep in mind when they are considering to scale teams? Because let’s say you have raised your Series A, and then you already have found a first-level of product-market fit. And now you know that, okay, this is the trajectory for next one to two or three years where you want to scale the dev team. What are those important things that you as an engineering leader would take care of?
Sayak Saha: I think this is a very difficult and easy question both way, okay? Because everyone has done it probably at our experience the same thing in their course of life, right? But I think the major challenge, right, what happens is every company has their own culture and their way of doing work, right? And probably the example which you have mentioned that when you are a small company, you might have a small engineering team who are doing a great work, right? Every member in the team is super contributing. They are taking charges and stuff, right? So, when you scale team, you think that, “Hey, I will have another super-awesome team just be there. We’ll be performing in the same pace, the same motivation.” Right? Or maybe two, three, whatever. But, when you scale teams, right, that gel or that thing doesn’t happen that way because you have to build organizational hierarchies, the communication path changes and all.
So I think in that way, right, there are probably top 3-4 things that we look into. One is find the magic what works for your team, what is working for your current team, what is the team composition, right? I mean team composition means that composition of the developers, like how many front end developers do you have? How many back end developers do you have? Or how many product managers do you have? Do you need an engineering-focused product manager? It depends product to product, right? Okay. So find the right composition for your team. That’s first.
The second thing is that what would be the communication model for your team, right? In small organizations, generally, it directly comes from the founders that, “Hey, I want to try this experiment. Let’s do this.” Right? When teams are small, generally the founders sit with the developers, maybe in some cubicle and start saying, “Hey, let’s do some whiteboard, blackboarding, whiteboard sessions.” And we start doing it. But when you scale teams from maybe 20 to 50, 100, doing such whiteboard sessions always is not possible. So, how you set up the communication model to flow the ideas top-down and effectively that, that matters. Okay.
I think the third part is we scale team with some hope that I will meet some goals, right? It’s important to set up those goals and objectives and set up clear expectations before the teams that, “Hey, I expect this from you.” Otherwise, the objectives are lost at the point that we have the big team and then start saying that the priorities change. What is like the ‘must have’ vs ‘nice to have’ somehow gets diluted when, when teams grow. So setting up the right OKRs, KPIs, these things matter, right? And I think the other part is that when you are small, your teams at times are very autonomous. So, it’s very important that how your team composition and this communication and leadership is structured so that the autonomy of the team is not lost.
Kovid Batra: Right.
Sayak Saha: It should be very hierarchical and stuff, right? And apart from this, I think the other thing comes up, right? When your teams grow, there is an inherent challenge of bottlenecks, right, with the DevOps, IT, and, and others’ things, right? And the things whether we’re, we are supporting a 20-member dev team is much easier or much easier than when you have a 100-member or 200-member team.
Kovid Batra: Correct.
Sayak Saha: Which asks for automation. So, which means that an early stage, if you look for all those automation scopes that, that these are the areas, these are the things I need to automate, it’s not only about the CI/CD pipelines. It can be as simple as onboarding a team member, right, onboarding a team member and creating his accounts across all the systems, right, how you can onboard him, that simple. I mean, what are the dev tools you can support, how quickly a developer can onboard, because someone cannot sit next to him and all. So, I think building that automation around it. So I think these are the major things which people learn while doing like when you are really scaling the team. Definitely there are other challenges like hiring, the internal conflicts, growth and other stuff. But I think these are the major things that I have faced.
Kovid Batra: That makes sense. Yeah. I think one point really intrigued me, like when you’re, when you’re scaling, you just have to make sure that the processes, the communication together should be like shaped up properly when the team is scaling, right? It is very important. But, how would you define that you don’t end up overdoing something, right? So, while you’re scaling the teams, that’s not the only goal. The goal is also to deliver the products, the features, right? At that point, you also have to be cautious about that you don’t end up doing or overdoing things, right? So let’s say, how would you approach this part where you have to ensure there is automation at the right places, there is a communication channel set up in the right mode? So, can you just give us a few examples how you dealt with some of this situation, like just to get more relatability in the situation?
Sayak Saha: See, to be honest, there are different ways to do this. There are different approaches, right? And when you get in leaders, like when you scale teams, when you get in leaders, it’s always not so good that you, you force some specific processes on them, right, that maybe you follow Agile, Kanban or this metrics and all. But what I feel is that when you say this entire process, right at the end of the, what is it? Like, it’s like, there is an idea which comes. Someone needs to define that idea that what I want to expect from it, maybe some mock up, screens and all. Then you define some KPIs from it. Then there’s a tech spec, design, testing and finally get it released doing some A/B testing, right? So, in order to define that what are these phases for your company, and based on the size of the idea, maybe a short, medium, large, how much time this idea should, should spend in each of these phases. Let’s say, ideation phase can be two to three days for a small scale feature, but maybe two weeks for a big size feature, right? If overall I’m having, let’s say 20 ideas which are cooking.
Kovid Batra: Right.
Sayak Saha: Different phases. Each phase, it should not spend beyond this period. If it is spending more than beyond this period, then that means the process is overkilling there and this requires some optimization.
Kovid Batra: Makes sense. Perfect. I think that’s a very relevant example.
Sayak Saha: Because finally if you look at any CEO or any Co-founder, right, what they looked at, how fast I can make this feature live. I mean, I have an idea, how fast I can do it. So if the expectation is to make it live in, let’s say one month, it means that how much time each of the slices, windows should have.
Kovid Batra: Yeah, the process should support it basically, and that’s how you should plan for it. So I think from this, I’ll move on to like one important point that I have always been struggling with, right? This is more around collaborating effectively in these times. So, engineering teams collaborating with design and product teams to define smooth and effective product development. And there are always these fights, back and forth communication, the requirements have not been defined properly, this PRD is not up to the mark for us to like start working on it. On that note, I’m sure you would have also faced a lot of challenges. Just give us one good example from your journey where you actually ended up solving such problems and things were working smoothly. I know that would be very idealistic to say working smoothly, but still, yeah, what was your contribution in your team to solve for this process?
Sayak Saha: I think the first and foremost is that let us accept the fact that things will not be smooth, right? When you’re moving fast, It’s very hard to accept that I will get something really in a very neat manner and stuff. This won’t work, to be practical because each of the actors in this process, right, whether it’s designers, developers, none of them know the entire thing, right? The designers know how a good interaction can be, right? Maybe the QAs or the PMs they know the product the best, how users will use it. The developers know how to code and the challenges of the system.
Kovid Batra: Right.
Sayak Saha: It’s good to build but what are challenges in my system, right? So, in a way to build anything, you need skills from all of these places. So, I think fundamentally the first and foremost, I think is like the team need to have a nice bondage and they should start feeling that it’s a shared success, right? Because unless each one of them help each other, right, this thing will never be successful. Okay. So, that initial gelling and building a team bondage, I think is the first and foremost thing. There is no other recipe for, for, for it. Okay.
The next part what I think is like for each of these things, right, when the design is built, involve everyone in these phases, let’s say involve the devs, involve the PMs, involve the QAs. Run, run these mocks with them to understand because the mock phase is very important, ’cause when you run the mocks, you understand the bottlenecks of the system, right? And, and run it as a perfect user. Maybe at times it’s, it’s, it’s okay to run it with an actual end user and ask him for feedbacks that, “Hey, this is what we’re planning to build. What do you think?” Does it make useful for him, right? And, and even it’s useful that you run the mocks with the operations people, because finally you might have a product, but when the final reconciliation or stuffs are getting handled from operation standpoint, or maybe if some complaints are coming from customer support, right? How they see this data? Maybe there are like they should have sufficient logs and all these things so that they can debug those complaints. So, involving every stakeholder while designing a product, maybe the big products I’m saying or big features, it is very important because when you identify it early, it’s always important, right?
And second is developers, you will see they always have a mentality that “Hey, I’m not comfortable delivering something every two days or three days. Let me build everything in two weeks and I will dump you, or three weeks.” They, they try to, I mean, there is a general in, I mean, tendency of people that I will not make incremental commits, but I will make a single commit. I think this is culturally one of the things if a team can develop, it’s like having incremental commits and, and see that how it works with the big picture. That solves a lot of problems.
Kovid Batra: Yeah, I think probably 70-80% work is done when people start believing that it’s a, like wholesome success, right? It’s not one team’s success. So, the main thing is done there. It’s more about, like the teams which are working smoothly, I should say I have seen that thing, which you just mentioned, like there should be a cooperation there, there should be a feeling of success together. So, I think only then things work out. You will have that patience. You will understand other standpoints. So, things would work better that way. Makes sense. I think a pretty good advice there actually.
Sayak Saha: And also one last thing is actually, most of the times, right, if you see that teams, they got bit they’ve shared very like stiff deadlines and stuff, right, because there is a sense of fear. I think from leadership side, if, if they can be given a comfort that, “Hey, even if you fail with the commitment or if this feature fails or if the deadline slips, it’s okay if there is a valid reason.” So, I think when teams have this comfort, they just outperformed. So..
Kovid Batra: Yeah.
Sayak Saha: Comfort needs to be provided to the teams, the comfort and trust.
Kovid Batra: Totally, totally. Makes sense. Moving on to one important topic related to how we end up implementing technologies and now, because you have this ChatGPT coming in, all the AI wave going on, right? And there are a lot of changes happening. You have suddenly so many tools around you that already tech teams were having this tool fatigue, but now you see developers using things like GitHub Copilot and people are talking about it, let’s implement it. So, how do you use these technologies and how do you implement it when you already have such legacy code implemented? What is the overall process and as an Engineering Director or as an Engineering Leader, how do you make sure that it is utilized at the right point of time and in the right spaces?
Sayak Saha: Okay. So first of all, if you look at, uh, with the introduction of ChatGPT and Generative AI in the last 6-8 months, it has been a total disruption, right?
Kovid Batra: Yeah.
Sayak Saha: All these days, what we have been hearing of AI from some, from some very specialized teams, this is no more a specialized team. Now it is everyone started using, exploring and every, every morning when you open LinkedIn, you will see that someone posting that these are the top 20 AI tools to be used, right? So, there is a, like a huge blast of ideas and usage. And to be honest, no one, I think everyone is adapting. So, there is no defined strategy as of now that if you follow this strategy, this will give you success or this results you can achieve. So I think at this point, what is important is identify first of all, for your organization, what are the bottlenecks and where you think AI can optimize, okay? So, let’s say the example which you said, we all are thinking that it’s code assistant, it can be Copilot, or AWS CodeWhisperer or anything, anything else, right, that we all think that this will help developers code faster, easy and stuff. Okay, we don’t know the real benefits yet. So, I think what the best thing is to run a pilot project within the company. And end up any of these tools and see how useful it is. So let’s take an example. Let’s say for example, if you are using any of these tools ideally what these tools are doing, so they are providing you two types of course, one, they already have a learning based on the course in the internet and other repositories, and this like code on that, right? So, this is a one set of output which they give you. It can be as simple as, “Hey, give me a code, to drop a file in S3.” or “Give me a code to read a file from S3.” You get all these things. Or, or it can be any other cloud providers or, or any other use case.
The second is what, where it’s more tricky. There are organizations which are enterprise organizations. They might have a large code base of several years, legacy code. And many companies use their own customized libraries, right? So if I need to code, I need to code using those libraries. So, can this code assistant work with this? So, many of these code assistants are saying that their LLM models can learn the internal code base and suggest code snippets according to that, right? So, the best part is that it was a pilot project. See how this works. So one of the ideas which we are trying to do is that, I would not name the vendor that they have a metric which suggests how many snippets of code are accepted by the developer, right? It will suggest, but you need to accept it, right? Accept it. Overall I have X commits happening through these things, then it’s a productivity improvement, right? And the other part is that the second measurement is that the code which we are accepting or getting accepted, how much it is custom code, means which are very internal libraries or internal to the organizational code it’s suggesting versus very generic. Can we get a metric very detailed to that level, right? So this is another thing which we are trying to measure.
And, and also a few aspects to look into is like many of these tools, this might be very accurate, but there is a software licensing issue, right? So, because they can pick code from Apache license or some other licenses. So as an organization, do you support all this licensing stuff? What makes sense? So, you need to do that right mapping also.
Kovid Batra: Yeah, yeah, yeah. Absolutely!
Sayak Saha: So this is one of the things which we are trying to adopt and learn. But in general, there are a couple of low-hanging fruits, let’s say, from operation side. They’re doing some translation service or some, someone collecting feedbacks and summarizing the feedback trains. So, these are pretty classical use cases, which ChatGPT is doing wonderful, right? So in, in this case, it’s important that people learn how to write effective prompts. So this is another skill set now.
Kovid Batra: Exactly, exactly. Right.
Sayak Saha: So prompt engineering is another important part. So, so this is, I think this is, these are more like operations or used to stuff, but what’s important, I think was what’s very, uh, there are other use cases coming up, let’s say you have an incident management, right? So, often we have repeated issues having the same cause. Can AI solve it, right? I mean, can I have, can I make my LLM learning happen on my all Slack messages for last three years and make it learn that in future if a similar issue happens, these are the steps to be done, right? So, so we do not spend time or at times when you have an issue later when you do an RCA, based on the chat history and stuff, can the AI summarize it, so we don’t spend time in building a RCA? Okay.
So, AI is more like a tool now. So, how we use it matters. So I think one to, to summarize, I think what’s important is that we need to, to make the engineers learn what’s available in the market, these are the things available and make them decide that what’s more effective for them, instead of building a strategy that, “Hey, I want to onboard this 4-5 tools and this is what, what I want to achieve.” There are a lot of tools. Now it’s better that you, that the teams understand what’s best for them and then start getting a result out of it, because once you see the results, it matters. And then, definitely I think one of the things which is deviating people that there’s so many tools right now, jumping on a tool and tying up with some vendors or company probably is not the right thing. First internalize.
Kovid Batra: Yeah, we should understand the need first. Like, if there is a real problem that needs to be solved and.. Correct.
Sayak Saha: Yeah. So, understand your problem, maybe explore a few tools, build an internal team or a pilot team, see how it works for you, and then go for a commitment in terms of money, effort, and everything.
Kovid Batra: Makes sense. Totally. Perfect. I think with this like we are talking about GitHub Copilot and there are other, other tools out there in the market. There are a lot of times, not just with AI, but even before that, there is always a question of whether to build something. Let’s say you have a problem, you want to like solve it with productization, you want to have a product for that. How do you go about making that decision of building in-house or buying it from a vendor? How do you take that decision usually?
Sayak Saha: Okay. So, probably I will frame this question a bit more.
Kovid Batra: Yeah, yeah. Please go ahead.
Sayak Saha: It is like build vs buy vs run, okay? Because when you maybe buy a software intruder, you are also running the software for a longer term, right? So there is a cost in running the software, whether it’s built in-house or out. So let’s come to that point.
So first of all, like whenever you build a product or build a tool, right, I think what’s important is that every company has its core offering. Let’s say, if there’s an, it’s an insurance company or a fintech company, that’s their core, right? But, as a general IT company, nowadays we need to do a lot of generic functionalities. Let’s say, you need a, let’s say a message provider which is responsible for sending SMS or maybe WhatsApp messages, emails and stuff, right? So, do you need to build it in-house or do you want to tie up with some company and use their services for the same? There are many such things. It can be a payment gateway, it can be a, this kind of a messaging service, email service provider and whatnot. So, I think what’s important is that it’s a fundamental strategy that, that as a tech company, I will only solve my core problems or my core business cases and rest all I will outsource, or I will tie up with something, someone else, right? Because this helps in prioritizing your focuses. Okay. So, this is one of the strategies which can help, right?
The next point is that, okay, you strategize it. The second point is that how much cost it takes, right? At times there are solutions which can be built in-house and it’s much cheaper to build. So, it might be worthy to build it in-house. I can take a small example, like a tiny URL. So if you’re building emails and you need a tiny URL, there’s a cost. It’s a very minimal cost, but you want to build it in-house, right? I mean, the cost value proposition, like is it really worth it? Okay.
I think the third part is, which I was saying the run. When the organization is small, if you take a software, it often won’t pinch you much. Let’s say, you buy a software for some for 50, 20 developers, 10 euro per month, it’s great. But, when your organization scales to 500 developers..
Kovid Batra: Then it’s going to be..
Sayak Saha: It starts pinching you, right? So this is something strategy that if you really have such a growth strategy and you feel that this might be a pinch, it’s a decision, how you want to plan that, okay? And this has a cherry on the top in recent years, when because of business decisions, let’s say if you need to shrink your organization, this, this gives a different perspective because you, you make a commitment that, “Hey, I’ll take your license for 500 users for next three years.” But, let’s see if your organization shrinks to 300 users, then you’ll need to still pay the same money to the external vendor, right? So how, how you plan these things, so these are the aspects which I think one should consider.
Kovid Batra: Yeah. Makes sense, totally. And last thing that I just want to discuss with you, like when you are using these tools, bringing in automation, using AI, ultimately we are trying to impact the overall productivity of the team, right? The question that arises from here is that how you are defining that productivity and even I should like take a step back. I should ask how do you define the success of an engineering team? Because productivity, I’m sure it’s, is a very core part to it, but in general, how do you define the success of an engineering team? How do you measure productivity? How do you measure success is what I would love to hear from you.
Sayak Saha: It is a wonderful question. So if you look at right as an engineering leader, I mean, the best part is that you start talking with the other peers in your organization or in your company, and they might not be tech. So, everyone is trying to promote the good work of their part. It can be from finance, it can be from business and everyone. So, when you are in that kind of a forum, what matters is that finally how much revenue you are adding to the company through your team’s work or how you are building in optimizations and cost-saving initiatives to save cost, right? So I think these are the, for any two teams, these are the main two factors, which, which comes out, which drives benefits.
So now, the question is that how these two things can be related to engineering teams. So, what we do is that as an engineering team, we, we develop multiple features, right, features or products and stuff. So, so for any of this, right, when you deliver a feature, we start, we actually measure the ROI of these features that, hey, this feature, if it’s built, this is going to bring so much revenue for me, for my customers. This can bring in so much new customers or so much new business. This is, this is one way.
The other can be, let’s say it’s a, it’s an experience that if I build this experience, let’s say I limit my customer journey from 10 clicks to 7 clicks, it’s a better customer experience, right? If I can reduce my number of app crashes, it’s a better customer experience. It will improve my customer NPS. And maybe in turn, this will reduce my customer churn rate. So what I said that first is definitely increasing revenue. Second is customer churn. And third is the cost savings. Like when you build softwares and stuff, there’s an operational cost of running it, running the software, which is purely an OpEx cost. I mean, which involves OpEx cost spent by the developers. It is OpEx cost of the of the hosting the software. It can be in cloud and in-house. So, what are the optimizations can be done to, to save those costs around because, I mean, because as developer teams, they, they keep on adding features, right? And if we keep on in consuming the hardware resources, this cloud cost, your cloud cost be also linear and it would happen, right? Because every organization needs to limit the cloud cost, so that we limit our cloud cost to some budget.
Kovid Batra: Correct.
Sayak Saha: Right. So, what are the optimizations which can be done to limit those? I mean, there can be strategic decisions that, hey, we will build services with serverless vs microservices, based on the volume and other tech factors, right? So these are the aspects which needs to be taken into. So anything when we build, I generally try to categorize into these three buckets. Right.
And, also the third part is, I think is innovation because innovation can give you something which you cannot maybe measure upfront, maybe the code assistant one, which we discussed, right? We don’t know the direct outcome of it right away before investment, right? So we should keep some bandwidth for innovation because otherwise, you might lose the train. It depends from organization to organization, but I believe at least 10-20% efforts to be spent on innovation so that we don’t miss the bus.
Kovid Batra: Totally. When you say these goals are kind of, I would say broad goals to understand, and of course, everyone should have a realization towards it. First question that comes to my mind is that when developers are actually working towards building the product, and product is of course related to these business metrics of customer satisfaction, revenue, saving cost. Maybe saving cost is something that they can also see in the GCP bill or the Azure bill or AWS, right? But the other two factors are kind of indirect, right? Like when you write the code, you complete your sprint. You don’t really end up looking at the goal of customer satisfaction immediately because the feature is rolled out then you will get. So, the feedback loop is first of all, little time taking and then it is kind of indirect also. So, how do you, like motivate developers or like ICs for that matter to be feeling the same as a product guy would feel or a sales guy would feel in a business? What do you usually do to do that?
Sayak Saha: Okay. I think I got it. But I think, I think that what’s important is, right, that every individual in an organization, they have some counters and metrics to measure for their work, right? So, what we do is let’s say, in my previous company, let’s take an example. We were managing a payment gateway, right? So, in the platform, if everyone is doing payments every day, it’s all good. I mean, it’s like, you’re not making a lot of changes in the gateway every day. So, the motivation level of people comes down that, “Hey, it’s a software. It’s running as usual. What new shall we do here? Or what, what’s the scope, right?” What we started doing is that we started developing the funnel, the gateways, how many people are adding their items in the cart, then clicking in the car details and finally making a payment, and then the successful payment at the end of the day, right? It’s a funnel with the full steps, right? So, we started measuring that in this full funnel, what’s my, uh, expected daily users in each of the stages of the funnel, okay, and average it out over a month. So, and every day, if any of these counters are dropping, then there is something wrong. Let’s say, if I expect 200K people to visit my payment site, right? Okay. So, if all of a sudden I have a 10K, then there is something wrong. So we had counters, like I expect so many successful payments per day, right? And this will be my success percentage. So end of the day, this report comes in that hey, my conversion should be 80%, payments should happen successfully. So all of a sudden, if it’s 67%, that means there’s something wrong in the platform and the developers are responsible for it. Okay. And this in terms comes to the operational metrics, right? The system uptime, the API, success rate, the TPS of stuff and all those things. So, what I try to mean is that if you give a user experience metric and then let developers decide that what are those internal metrics in the tech architecture they should measure. It can be the APIs, it can be the Google events, it can be anything. But, let them take that call. Don’t tell them how to do, but tell them what to do.
Kovid Batra: Yeah. Cool. I think that makes a lot of sense. So I think this is great. Maybe one, one last thing that I just want to talk about is how are you looking at the in-general efficiency of your engineering team members. So, defining success with these goals and OKRs and initiative OKRs, right? So, that’s I think setting the fundamentals for anyone to be motivated and deliver towards what the business is actually needing. But, do you follow any practice? Like, I should change my question, actually. Do you follow any practices or do you do the efficiency measurement using metrics like DORA or something?
Sayak Saha: We don’t do any specific those kinds of metrics. But, what we try to do is that, generally like we were saying that, that in a quarter, we have an expectation that in a quarter, we will deliver so many features, right? So many large size, so many yes, blah, blah, blah. Right. So we try to expect that if a team is able to deliver that, okay, those main signs, so that’s more important.
And then the other part is that, as I said, that since we try to just get the developers, PMs all together, the focus is more towards the outcome.
Kovid Batra: Outcome. Makes sense.
Sayak Saha: Right. And I think that motivates the team more instead of forcing that, “Hey, I developed so much story points, velocity.” Because at the end of the day, if there is no outcome, nothing matters.
Kovid Batra: Right. No, totally makes sense. Cool. I think this is amazing, Sayak. It was a lovely chat. I think I learnt a lot and probably our audience, also learnt a lot from it. So, what we can do is we can have another session with you sometime, like where we can have a part 2 to this episode and talk about more such engineering topics. It was really, really nice talking to you.
Sayak Saha: Thank you so much, Kovid, for hosting me and these were tough questions and all these questions are very close to my heart and it was lovely sharing with you.
Kovid Batra: Your insights were really amazing. I must say. So, thank you. Thank you.
Sayak Saha: Have a nice evening. Yeah, bye.
Kovid Batra: You too. All right, see you.
In the second episode of ‘The DORA Lab’ – an exclusive podcast by Beyond the Code, host Kovid Batra engages in a thought-provoking discussion with Marian Kamenistak, VP Engineering Coach and former VP of Product Engineering at Mews.
The discussion begins with Marian elaborating on two key terms – DevOps and DORA metrics. He then explores the application of DORA metrics within teams and their significance. He provides examples of how DORA metrics can pinpoint team issues, such as utilizing change failure rate to gauge team satisfaction.
Lastly, Marian offers valuable insights into strategies for engineering managers to tackle inefficiencies beyond DORA metrics and navigate execution steps when tackling challenges like high cycle time or low roadmap contribution.
Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have an interesting guest whom we loved so much that we had to call him back. Our engineering metrics expert from Prague. He has 15+ years of engineering leadership experience. He has been former Vice President at Mews and currently a Vice President Engineering Coach.
Welcome back to the show, Marian. Great to have you here.
Marian Kamenistak: Greetings all! And thank you Kovid for having me once again, looking forward to it. It will be a ride today.
Kovid Batra: Absolutely. So Marian, like today, the discussion topic is all around engineering metrics as last time, and our audience loved it so much that we wanted to deep dive into certain topics. And touch the fundamentals of DevOps, DORA, and discuss more on such topics with you with certain examples that you have implemented or seen as working well for different teams.
So, before we jump into the metrics and how to implement those, the first fundamental questions that I would like to have a clarity is what is DevOps? And, what is DORA?
Marian Kamenistak: Okay. So, let’s start with the DevOps first, I guess. So, the way how I perceive DevOps really is some sort of a system, how to build software faster, like the operational side of things, really. So, to be very specific in that, it encompasses the for example, you know, the configuration cycle, the release cycle all together monitoring and the tooling that we can combine all together. So, in other words, it saves time and, make our developers much more efficient as opposed to taking care of the, you know, low level stuff, let’s put it this way. So, in other words, DevOps saves usually the time to engineers and, increases dramatically their efficiency and basically their time to value.
On the other hand, when it comes to the DORA metrics itself, it’s basically, some sort of representation in numbers, how we can measure the team’s efficiency, making sure that we, unlock the potential of our teams. And, keeping our teams on, let’s say, you know, on a high-performing level, right? And, there is a bunch of indicators. You might be talking about, top 5, top 10. I would be honest, it might be like up to a hundred different indicators. Nevertheless, in DORA’s case, it’s just four basic indicators that we talk about. And we could cover that in much more in depth, you know, at our session.
Kovid Batra: Perfect. Perfect. So, to begin with, I think when we are talking about DORA metrics, can you give some example where exactly you feel that DORA metrics really fit for a particular team? What is the importance that this DORA metrics bring to the table? And like, what results can we get if we work on them?
Marian Kamenistak: Okay. So, I would say these days, DORA metrics is some sort of a standard or established standard due to the fact that there has been a huge research coming from Google. What are the, basically the most impactful metrics that we might want to follow, right? From my own perspective, out of the four DORA metrics themselves, to me, the most important attribute of that or indicator of efficiency is, for example, deployment frequency, where basically we are saying how much time it takes us to basically turn our efforts into a value, to be very practical to basically to move our new feature set into production, for example, right? And the reason why I think this metric is, I would say the most influential is, you know what, let’s put it in a very simple example. If our team goes dark for three months, and all of a sudden they release something, you know how it goes. We’ve all heard the story, right? So, they want to shake their hands cause it’s a huge success. But on the other hand, the Product Manager is saying, “That’s not really what I wanted.” The stakeholders are sort of, you know, reluctant to that. The clients might be saying like, you know, that’s not what we meant to receive underway, how we work with. And there’s a bunch of bugs for another two sprints out of it, right? I think we’ve all experienced this story.
So, in the end of the day, what we want to see is that our deployment frequency’s sort of frequent in a way that we release our increments in an established cadence, I would say, right? Here, I want to, basically pay attention to one of the things, which is usually we have to take into consideration the difference between, let’s say a large corporate company and a small startup, where, for example, speaking of the threshold, it’s totally fine that I can imagine that in the startup environment or scale of the environment, we can have the deployment frequency about, let’s say that we release twice a day right? That’s totally fine. While in the, for example, regulatory banking business, if we release something on a monthly basis, that’s a hell of a good achievement, right? So, including the whole testing, the regressions and you know, regulatory constraints and so on and so forth. So, we always have to take the context into consideration. So, don’t mix, you know, the startup metrics with, with the corporate ones, right? So, that’s so much about the deployment frequency, in my opinion.
Kovid Batra: Right. Actually the, in not just the team size, I think it’s about how you function in, what domain you are and what exactly you’re working on. These metrics could vary for you and the benchmarks could vary for you. So, I think that’s a very good point that you touched on. And I mean, we also generally look this from a very deep lens that, okay, what exactly is needed for this team, how they’re functioning right now, what should be the benchmark for this particular team if they’re working on the front end back end. So, of course that matters a lot. So, deciding on a particular metric and then setting up benchmarks is not just straightforward. Like, you just go and say, okay, we want five deployments for a week and then we are sorted. That’s not something we..
Marian Kamenistak: Yeah. And if I may add another two cents to the story, Kovid, what I really found out is that actually what worked the best is that we set specific thresholds for specific teams cause you might have different teams that work on the platform or enabling teams or basically the new vertical teams and so on and so forth. Some of the things might have a high amount of dependencies and so on, or there is a high amount of, for example, unplanned work due to the maintenance and, other things.
So, it’s really great to basically set up the different expectations or thresholds for the different teams. And the way how I do it, I ask the teams to come up with their own proposals.
Kovid Batra: Oh, great!
Marian Kamenistak: And it works because you don’t break the principle of ownership. So just take it aside as a small tip and we’ll come back to our story for sure.
Kovid Batra: Sure. Sure. Absolutely. Marian, can you give me some other examples around how we can use these metrics to understand the problems of the team? Like I, just to give a head start there maybe. I’m looking for something that if we can understand how the code review process is going on in the team, or how does the velocity of a team looks like, or how does the collaboration looks like for a team. Can we identify such kind of inefficiencies and problems in the team using these metrics? And if you know, like, can you give an example?
Marian Kamenistak: Yeah, totally. Let’s be honest, we can measure like dozens to hundreds of different things, but that’s not very wise, right? We have to start from somewhere. So, usually the way how I approach it, especially when a company invites me to do some sort of internal efficiency audits, there are two types of inputs. First, the first input is really like talking with people with the right people and, you know, open their heart and get all the insights as much as possible. And of course, the second element of that is data itself. So, looking into the data, seeing the improvement opportunities there and digesting the data the way that you can identify pretty well what might be the, the, the top root causes of why the machinery is sort of slower than expected, right?
And here to be very specific, the one metric that I love looking at usually is the change failure rate, which is part of still the DORA metrics, where basically, the change failure rate can be translated as in my opinion, team satisfaction. If we don’t have a team that is satisfied, then we can hardly achieve some sort of a, you know, highly performing team or environment. And the reason why I think there is a correlation between the two is that if me as a boss, I’m coming to my team every second time after they release something and I’m telling them that, you know, they didn’t do the best job. And, you know, the production basically is full chaos. There was a failure and, there was an outage. Then of course, it doesn’t contribute to their satisfaction after they expect some kind of words from my side after releasing some sort of expected functionality, right? So, having the change failure rate pretty low, meaning, so let’s say, 5 to maximum 15 percent that says that, you know, there’s a certain, although yet minimal probability that things go wrong after doing something, that’s quite important to see.
There is a story that I’m usually saying that my developers, they live out of motivation and satisfaction, right? So, the motivation is basically why we are here, what mission we contribute and the satisfaction; what do we get back after we accomplish our work. So again, the change failure rate is something that is, I, in my opinion, highly underrated. And, some people don’t see the correlation between the satisfaction and the change failure rate itself, right? So, I think that this might be yet another practical example how to think of the metrics and translate that to the real world, because without the true culture and, you know, the satisfaction, you cannot achieve some sort of a high efficiency levels of your teams.
Kovid Batra: Yeah, absolutely. I mean, this is a very good example actually. When you look at change failure rate, the first thing that would come to your mind is like, this metric can tell us how satisfied our customers would be. But looking at it from the other perspective where you’re looking at team satisfaction, it makes a lot of sense actually.
Marian Kamenistak: It’s bidirectional.
Kovid Batra: I had this, one of our podcast guests, with whom, I was discussing these metrics. So, he mentioned about using two metrics. One is comments per PR and then comments after PRs are raised for review to understand whether the teams are collaborating well and whether the initial code quality is good or not. And it was amazing. When I looked at the thought process, how he approached that, I was like, pretty amazing. That opened a few more doors of understanding how these engineering metrics work.
Marian Kamenistak: Right. And thank you for introducing this example, because usually, you know, the people are getting crazy about the DORA metrics. In my opinion, it brings certain value, but, we need to read from the context. There are some, I would say, preconditions and better opportunities to check before we start, you know, moving to DORA.
What I mean to say, and again, another practical example, is that I might have all the DORA metrics sort of in a positive threshold and that might signal us that, you know, the team is hopefully highly performing. Nevertheless, if the team or my teams don’t work on things that matter the most, meaning the roadmap, then we go belly up, right? So, what, I rather prefer looking at is, you know, the let’s say the portfolio investment, how much of our, you know, efforts or talents, efforts goes into the roadmap, into the product roadmap or technical roadmap or business as your meaning of roadmap or another, I’ll say improvement initiatives, new features and so on and so forth.
And usually, my advice is that if we speak about, we talk about the, let’s say product engineering teams, the teams that are basically implementing the new functionality. There, I want to see that these teams, usually they contribute to the roadmap at minimum 60 percent of their time, right? So, that makes me sure that actually, I’m basically investing their talent wisely.
Kovid Batra: Right.
Marian Kamenistak: If I have on the other hand, all the metrics that, you know, the velocity and, you know, all the, as you’ve been saying, all the pull requests and comments, seems great. But if they don’t work on things that matter the most, again, we are not gonna shake our hands together. And, that’s a waste of time. And, uh, the funny thing is it’s not the fault of the team. It’s the fault of me as their manager, of the manager of the team, not of the first line manager, that I haven’t taken care of that. So, don’t.. Let’s don’t use excuses about like, you know, this team is, you know, it’s my team, it’s not that highly performing and so on and so forth. It’s bullshit. Sorry to put it this way. We are responsible for making sure that our teams work on the right things that we are able to accomplish our roadmaps and our strategy. Period. Yeah.
Kovid Batra: No, absolutely. I think this makes a lot of sense. What I have felt so far talking to a lot of people about the metrics is that people do know about DORA metrics. They understand what engineering metrics are and measuring seems to be very obvious to, like everyone. It’s just the engineering department, where we are having these kinds of debates, on social media, how to measure developer productivity or how to look at these engineering metrics.
Marian Kamenistak: Yeah.
Kovid Batra: If we talk about other departments or business units of a business, like there are strong measurement tools in place who are using to measure the efficiency of, let’s say for a salesperson, maybe we have tools like salesforce, right? It is one of the renowned examples. You can understand a lot about individual person on what he or she’s doing, how they’re performing.
Same goes for us, but here the challenge. So the main point that I’m trying to bring up here is that the challenge is that probably the engineering community is finding it difficult to make sense out of these metrics to solve their problems. And hence, I mean, this could be just my perception after talking to a lot of people. But, this is what I have felt. I’m not sure what’s your opinion on that. I would love to know it. The biggest challenge is of course how to use them and if you don’t understand how to use them, automatically there is an inhibition to not implement such things. And then, the bias goes towards, why to have these metrics? We should just look at the happiness of the team and that’s all about it. If they’re motivated, we are good about it. So, I mean, this is my observation. What’s your take on that?
Marian Kamenistak: Yeah. Yeah. That’s a very good topic. Thank you, Kovid, for opening that. Sometimes I, although, I see a huge impact as well, which is like, you know, we implemented certain metrics, engineering efficiency metrics, in the company. We turn these metrics into basically, OKRs or indicators that are tied with the bonus, for example, which is crazy because people start to get gamified, if you know what I mean, and it all goes belly up. So, that’s really like the, the, I would say the most severe anti-pattern I’ve experienced, right?
And, to comment on your situation, actually, or your scenario, actually you are disclosing a very good point that I see happening.
Kovid Batra: Yeah. Basically, It’s an implementation challenge. Like, there is a challenge with the implementation. I mean, you must have faced different kinds of situations where there would have been an implementation challenge. So, I mean, I just wanted to have your opinion on that. Yeah.
Marian Kamenistak: So, right. The most, I would say, challenging situation while implementing these metrics is that usually companies start from the middle. The way how I see it, and that’s one of the, you know, the most frequent anti-patterns is that let’s implement a certain solution out of the box that implements DORA, SPACE, or whatever that is. Of course, we have to adjust our existing Jira and to do some cleanup. That’s a secret story and it takes some time, right? To comply with the standards. Then, all the numbers come up, right? And you have a great dashboard with great colors and everything.
But the challenge is exactly as you described, Kovid is to make a decision. What are out of this 20 different indicators, the top three or top four that we really want to focus? And how to set the, the thresholds properly, so we know what it means if it turns, you know, what’s the severity of that metric if it turns from green to orange or from orange to, to red, basically, right? So, without having this exercise and the decision making about like, you know, what are the main indicators that we really want to follow instead of like, you know, you have the full dashboard. It’s your responsibility now as a, as a new team leads to have all these numbers green, right? So, and these guys, they are basically lost in that, right? So, that’s one of the things.
I want to add another, example, which is, you know, basically what I’m saying to the companies and to the clients is that implementing metrics or certain efficiency indicators, it’s one third of the story. Another two thirds is how to adopt these metrics into the company, right? It’s not about like, you know, we just did a Jira. We signed a contract. Here’s the dashboard. From now on, you are good to go and blessed to, uh, be a high-performing team because of the numbers, right? It doesn’t work that way.
So, making sure that people understand why we want to implement these metrics, what’s the motivation, and explaining and massaging them all the time about like, what’s the purpose of that. Because usually, you know, let’s be honest, what’s the most frequent phrase we hear from, for example, the developers or team leads. Usually they are telling us, you know, get screwed with your metrics. You want to basically micromanage us, right?
Kovid Batra: Exactly. Yeah.
Marian Kamenistak: And, turning that, let’s say that change, because we talk about the change management in the end of the day. It’s not about changing the process, but also changing the people’s mindset and their perception on this matter, on this subject.
So usually, what I advise the teams and the companies is to change the narrative from, you know, we want to micromanage you and making sure that you are highly performing to stick to basically two principles. The first principle is transparency, meaning it’s even better if it’s part of our values or openness or something similar to that. Cause in the end of the day, I want to see and have a way to, where to look, to see real time data, which team is highly performing or which is not that highly performing, right? And it’s fully transparent. This is what it is, guys, and let’s digest it and let’s improve, right? The other thing is the other principle that I want to follow is prevention, basically.
And here, the metrics themselves, I’m gonna use some curse words, sorry for that, but it saved my, it saved my ass quite a lot of times. So that’s the fact, right? When I saw that, for example, some of the, some of the indicator goes totally down or belly up, or something is happening with the culture or relationship with the manager, when it comes to some sort of, you know, happiness indicators or that the number of frequency go, you know, it’s getting worse or, you know, the change failure rate is like, you know, moving up to, let’s say 40 percent in the last two months, then that’s an indicator that something is fishy there. And if I have, if I, if I wouldn’t have these numbers, I wouldn’t be aware of that situation. I wouldn’t be able to react. I wouldn’t be able to ask the team lead, my team lead, “Hey, Mike, please, in the next 1-on-1 with all the guys, please don’t ask them the same question. What’s going on? How we can improve it or what’s, what’s happening there? If I don’t have the numbers, I cannot basically, uh, react. And eventually I might end up with a totally deteriorated team and that I will have to rebuild and it will take me another half year. So, what I’m trying to say is having well-established metrics is something that really pays off in the end of the day when you compare it with, let’s say the waste of the time that some sort of inefficiency can create and having the situation when the team is sort of rotting and underperforming. So, that’s usually what I see.
And, uh, the third thing that I want to open here. Kovid, sorry for speaking too much.
Kovid Batra: No, no, please go ahead. I think it’s very interesting.
Marian Kamenistak: Sometimes, while implementing the indicators, sometimes I see that people look at these indicators as sort of KPIs, as opposed to indicators only. So, what I mean to say, you really need to be careful about how we translate the numbers. To be very specific, for example, if I see that one single individual contributor has a low amount of pull requests, right? And we are two weeks before, let’s say the performance reviews, review process. So, what do I do? Do I come up with a number and say, “Hey, Patrick, you, you, you are screwed.”? Or do I take the context into consideration by knowing that Patrick is a senior developer, and his strength is to enable other people. Therefore, what he’s doing for me is that he’s pairing with other guys, right? So he’s sort of, I would say, invisible in the process. But his value is amazing and it’s great, it’s huge, right? So, always take these numbers into consideration, that’s my, it’s indicators. So, be careful about how you, how you basically treat these numbers and how you communicate the numbers.
So, my message would be make sure that you stay on the positive line all the time. Everybody is able to shout. I would be really careful about it. Yeah.
Kovid Batra: Totally. I think, and one more important thing, like you, you mentioned about what kind of prerequisite in a culture you should have, and then how you should go about looking at these metrics where you tell everyone what is the motivation behind doing it. You answer the ‘whys’ for the people and bring in that innate motivation for everyone to look at those metrics as indicators of how work should proceed or how efficiency should look like. And I mean, I totally agree to that. From your experience, can you tell us is there an average time for a team to adopt these metrics? Like, how much duration should people wait for having these phases of implementation? Because I personally have seen with Typo that we are implementing with teams. And sometimes what happens is like, a few teams do it within one to two months of implementation, like they bring in the dashboard and they just have certain goals set up for the team, they identify the issues and they start up with it. And sometimes it takes more than three months also for teams to get gelled up with it. What’s your take on that part? Like, how much time does it take for, usually for the teams to?
Marian Kamenistak: That’s a great topic. And thank you for opening that. My experience tells me that usually it’s roughly three months to onboard, all the teams, let’s say 6 to 10+ teams, towards the metrics to explain them, like what’s the reason behind how to use them, how to translate them and so on and so forth.
Plus, let’s be honest. Implementing this functionality or indicators into the efficiency process of your company, as we are saying, it’s not just the change of the process, it’s also the mindset change, right? The best thing is really to, for example, you know, involve, for example, the team leads into this transformation early on, right? So, they are part of these conversations. Explaining them the motivation once again, making sure that they are in the center of our decision-making process. For example, I may be coming from my internal audit with, let’s say, out of the 15 with the seven or top eight different indicators that I think that are the most influential ones, right? And, but, it’s them who are saying in the end how they see it from their own perspective, right? And what are the, let’s say the final top four that we will start with, right? When it comes to the implementation, of course, the implementation, that’s the hard work. And as I was saying, the dirty secret is that you have to do a clean up of your ticketing system because, because, you know, if your data is screwed, your numbers will be screwed as well. No surprise here. And, in the end, of course, it’s about, you know, doing some sort of, I would say town halls and workshops with all the teams, including the product managers, the developers and others, so they understand the numbers and everybody’s on the same page, right? Including that.
And again, the trick that I’m using quite a lot is that actually, I’m not saying what are the thresholds. Of course, I’m sort of, I would say lobbying for what the thresholds might be, but I’m asking the teams to come up with their own thresholds, right? As a proposal. Of course, we challenge each other. And this way I make sure that basically they own it from zero, from day zero, right? Or day one.
Kovid Batra: Yeah, absolutely.
Marian Kamenistak: And that’s a trick that, that I use, quite often. And that being said, if I see, for example, to be very practical, if I see one of the teams that’s not like, you know, taking up fast enough, basically the agreement is, okay, take it easy. No worries here. Usually there is another, let’s say, situation that is not technical. Maybe it’s cultural or maybe it’s a personal situation. That’s my experience. That makes numbers go down, right? And, we invest a certain time to improve, you know, the root cause and, or to basically work on the root cause. And after the number starts to, you know, go to a reasonable level, then we say, “Okay, this team from now on is enabled and is using the metrics, you know, in full functionality, basically.”
So, what I mean to say, the anti-pattern in other words is say, okay, so these are the generic metrics. Let’s do it without, you know, having the context about what the team is about and, or, and the other anti-pattern is basically to say like, you know, this is the start, and from now on, everybody has to be compatible with the thresholds, which, you know, sometimes, there are, let’s say interpersonal reasons or some sort of cultural reasons why things might not be working as expected.
Kovid Batra: Yeah.
Marian Kamenistak: And here I want to basically double down this message, because usually, you know, the CTO is saying, “Okay, let’s implement the metrics. And from now on, you know, I will have high-performing teams, right? But, if you have a rotting situation or the Product Manager is not in synergy with the Engineering Manager or whoever, and, there’s some toxicity, let’s be honest, in the team, no metrics will help you. So, using the excuse of, you know, “Here’s the numbers.” And, you know, “Work your ass off.” Never helps.
Kovid Batra: Yeah, absolutely. I think I can’t agree more on that. I think once you have this implementation in place, I’m just moving on to the next piece where I, I see teams implementing it, spending those one or two months or three months of time to get that into the picture where everyone is aligned.
Now, how does this process of, identifying different areas of inefficiency starts? And, just for example, like if I have a problem with the initial code quality in the team, or let’s say if I have a problem of deliverability in the team, where, maybe we are taking too long to deliver epics. And, uh, if there are like too many bugs coming in and there is high resolution time for the bugs, right? So which is directly impacting the delivery of the product with the customer. So, there could be a lot of areas where we can just start off. Like today, I’m an engineering manager. I might get overwhelmed with areas where I can work on and I will not be sure that, okay, which metrics should I choose?
So, can you give some examples which not only include DORA, but maybe we can just look at things beyond DORA and find out areas where an Engineering Manager or an Engineering Leader can get help on understanding where things are going wrong and how exactly one could improve on those?
Marian Kamenistak: Okay, perfect. Yeah, that’s a great topic, Kovid.
So, surprise, surprise! In my opinion, the most crucial indicators are not part of DORA. First of all, I want to make sure that, one that the teams, do know what they are supposed to work on and they are able to get focused on that, right? DORA says nothing about it. And usually, that’s one of the most frequent root causes that I see in the companies. To be very specific, the situations that I see the most often is that when we start to measure the, I call it roadmap contribution, meaning how much time we spend, our talent spans on the roadmap, on the things that matter the most. If we start to measure it, and you can do it very simply, you just, you know, put the tasks or stories that are part of, of the roadmap. Usually they belong to certain increments as epics, right?
Kovid Batra: Yeah.
Marian Kamenistak: You can label these epics by, let’s say the, the quarter or something of, of that year, year 2024 Q1 or whatever, right? Okay. So, this way you can distinguish, you know, whether that increments belong to an epic or not. And, if I have a task that has a parent epic with that label that clearly signals me that it contributes there, right? And just measuring, for example, the cycle time as a of these tasks, that’s the basic unit meaning, you know, how much time it takes from start, how much time it’s the ticket is in progress. And, comparing the summary of, you know, the total amount of, of the cycle time in the last three months, for example, with the ratio of only the cycle time of the tasks that, that contributes to the roadmap. That’s already a hell of a good indicator. And, as I was saying, usually I want to see that it’s roughly about, let’s say if we, if we have a, let’s say high-maintenance team, of course, it might be like, you know, just 30 to 40%. I understand that because there’s quite a lot of bugs and support tasks getting in, right?
On the other hand, if we have a, let’s say a small startup team, there I want to see that the contribution, the roadmap contribution is close to 90%. The reason why is that they have no production bugs. They have no production support issues and so on and so forth, right? And if we, let’s be, let’s be real. If we are something about 55 to 60%, and we spend most of the time on things that matter the most with our teams, then that’s a good achievement. So what I need to say, the situation usually is that after we start measuring these things, we find out that our teams have a scattered focus and, you know, there’s quite a lot of unplanned work coming in. And, actually the roadmap contribution is let’s say 35 percent only, and everybody gets surprised about it, right? Nobody has measured that. So the, the top managers, they think that, that our teams work on the roadmap. Product Manager is still complaining that, you know, he doesn’t get enough attention. The support is complaining that, for example, you know, the amount of bugs is still increasing and so on and so forth.
So if you at least, create some sort of expectations and, basically the balance between that, that’s a hell of a good regime already. And say clearly that, for example, yeah, for this quarter, I want to see that this, this quarter we spent 55 percent on, on the, let’s say product roadmap. 25 percent on the technical roadmap and let’s say another, the rest which is 20 percent on the off road map, right? Usually again, if you start measuring it, you will, you might get surprised that the off road map piece is 60% or 65%. Tell me how the DORA metrics can help you if you have this issue. So that’s one of the things that I want to highlight.
The second indicator is focus. No surprise. How much able, uh, my teams are to keep focused, right? For example, what I’m measuring, what I, what I love observing is how many tickets in progress per person in a team we have. You would be surprised how high the correlation is between the, you know, the focus factor and the efficiency of the team. In terms of the focus, I want to see, for example, I’m telling it as a story. So I want to see that, each single person has maximum two tickets open in progress in parallel. I want to see that the whole team has maximum two increments or epics opened in parallel. You might be saying like, why two, why not three? There’s a third hidden epic, which is business as usual, the off road map. Take that into consideration. I want to see that, on the, let’s say department level, we work maximum on two large initiatives, right? On the company level, I want to see that we work maximum on 2 OKRs in parallel, not 5, not 10, right? That creates focus. If you don’t have these sort of work in progress limits, you cannot make sure that the focus is there, right? So, just making sure that this one works, all of a sudden you would see that the teams can start to breathe, right?
So, because the anti-pattern usually is that we have a team of five people and each and every person is working on a different increment, on a different epic. Tell me if this is a team or is this a bunch of individuals, right? There is no teamwork in my opinion, there is no knowledge sharing. You can’t help each other. You cannot, you know, start finishing. You just, or, you know, the system doesn’t work. It’s broken.
Kovid Batra: Yeah. Yeah, absolutely.
Marian Kamenistak: Again, DORA metrics in this case won’t help. Or pull request metrics, whatever metrics based on pull requests will not help us here, right? So, that’s one of the things. Another thing, or the third thing, I’m sorry, Kovid, once again for being too much talkative. This is the one that I love talking about. I will describe it as a story, right? Sometimes I get invited to companies and, I hear that, you know, my teams haven’t delivered on the roadmap for the third quarter. I don’t know what to do. Please have a look. Usually, you know, it’s not about the delivery. Usually the teams are performing pretty well. Of course, you can improve certain things and ceremonies and the flow and improve the overall efficiency of the teams by, let’s say, 10 to 30%, which is pretty nice. Okay. Sometimes what gets broken is, the discovery, meaning like, you know, the specification or, you know, the purpose on what are the things that we have to work on or we want to work on and what’s the most valuable thing that we have to work on? There is some sort of disconnect between the product and the team, the engineering team. So again, you need to rather work on the continuous delivery and these things. That’s what helps the most, because if you, you know, the story, “trash in, trash out”, right? So again, I’m telling the story, why the heck do you do, do you pay high-performing teams? And these teams are usually very expensive. If you throw trash on them, it’s, it’s not worth it. It’s not worth the investment, right?
And the one single thing that I wanted to highlight is synergies. To be very practical, I can increase the efficiency of a team by, I’d say dozens of percent, right? By measuring things that matter the most. Nevertheless, if we create a synergy between the Product Manager and our Engineering Manager and the whole team, then all of a sudden we are getting 300 percent boost. So there is what I mean to say. There is something more than numbers. Surprise!
Kovid Batra: Yeah, yeah, absolutely. There is.
Marian Kamenistak: So, these are the things that I usually, you know, observe. So it’s part of the numbers, the data, talking with people, the culture, the synergies that tells us the most, right? And only after we start to pick the most useful indicators, such as roadmap contribution or focus time or epic cycle time or team satisfaction and so on and so forth. So that’s, that’s my advice. Yeah.
Kovid Batra: Totally makes sense. And I think looking at epic cycle time or roadmap contribution gives a lot of clarity on how, what we are exactly doing and are we headed in the right direction or not. These are two very good indicators. And I think very good for anyone to start off also, like for anyone to start off looking at what are the metrics which we should focus on at this point in time. As a startup or as even a midsize team, this makes a lot of sense, actually.
Marian Kamenistak: Right.
Kovid Batra: One more thing, just,I just want to discuss on this part is, like when we are looking at these metrics, there is of course, not just things around deliverability. And once you understand that part, what are the next steps that you have to take? So, I get to know that, okay, my team has lower contribution towards roadmap or our epic cycle time is high. So, what kind of execution steps should we take there? And are there any metrics involved that could help us understand whether the execution towards those is going right or not?
So just to give you an example, like, epic cycle time is too high for my team. And I started to look at what, where is the problem. And I found out that one of the biggest bottlenecks was my deployment cycle. And every time a PR was ready to be merged to the production, everything was there. The builds took a lot of time. And every month, almost 15 deployments were being done. Whereas, the PRs were already pushed at, let’s say in six to eight hours or 10 hours of time. So basically, what happened was that every month we were wasting 50 percent of the time in getting those deployments done swiftly. And ultimately, this became a reason for epic cycle time to be too high for the team, right? And if you look at it on daily basis, you might feel as an Engineering Manager, there is a bottleneck. But when you look at it from a quarter’s perspective where you see your epic cycle time for a lot of epics was almost two to three times of what you were expecting, you would be amazed to see that. And you would want to take certain steps. So, I just wanted to understand like today, if I understand roadmap contribution is low, what steps should I take and how even the metrics can help in that situation?
Marian Kamenistak: Okay. So, we might picture a couple of scenarios here, right? You described pretty well the epic cycle time and what might be the root cause. And usually we, you know, no surprise, here we talk about our ability to do a drill down just to analyze where this number is coming from, and so on and so forth. Exactly as precisely as you described, if the epic cycle time is, is too large or too high, I want to see what are the specific, sub-sequences in the cycle time of implementing certain increment as an epic. It might be either the deployment time or the testing or, or the adoption and so on and so forth. And, uh, if we identify what’s the, you know, the root cause or what’s the largest chunk that basically consumes most of our effort, then we can again narrow down, what that root cause and, do some sort of, adjustments and basically, healing scenarios, just to make sure that things work, and it might be either some sort of automation steps or making sure that we improve the whole process. So overall, either manually or by the process, or as I was saying, the automation, or basically we say, like, you know, we can have a, let’s say, software constraints in certain scenarios when we, for example, release only some sort of Betas or MVP and so on and so forth, right? So, we don’t have to have or a complete checklist of definition of ready to production, right? In this case. So, there are certain scenarios how to, how to treat these things.
The other example that I find quite useful. For example, I want to close the loop and we started with, with the satisfaction of people. Here, of course, there’s a couple of tools and ways how to basically measure the team satisfaction. And again, this is one of the surprises that, that I’ve discovered, and I was really astonished by that to see how much such a metric can help me to make sure that my teams stay on a high performing level and the culture is existing there. Well, to be very practical, if I have a tool that tells me that, you know, the score from, let’s say 0 to 10 in terms of the relationship with the manager or relationship with the peers or the satisfaction or the wellness is roughly about, let’s say, 8 to 9, that’s totally fine. But if I see a drop from 8 to 2 with the relationship with the manager, then and it’s me being a manager, then I know that there is something that I should be eventually working on, right? So, and again, it’s a great act of prevention. And without this data, sometimes we don’t have the wake up call, right? So, that’s yet another example how we can help each other.
And again, if I see this number, then of course, what we can do is again, to narrow, to do the drawdown, to ask the people for the feedback, to ask for the data, and so on and so forth, because in the end of the day, the data is what matters the most, right? If, If we, let’s say, on the cover, our hypothesis by data, then, we’re probably strong into our assumption and we already know what might be the root cause and how to basically prevent the situation from rotting and destabilizing the whole team or the whole department. So these are usually the scenarios that I see repeated, quite often.
So, the message here is once again, as we said from the very beginning, don’t treat these indicators as KPIs or harder data. Make sure that you understand the context first, you do the drill down, you do your homework and only then start talking about it, because if you use it in an incorrect manner, it will bite you back.
Kovid Batra: Yeah, of course, it will. Cool, Marian. I think this was a great conversation. I think we can have many more such discussions and keep diving into different use cases, but in the interest of time and for this particular episode, let’s close it here and look forward to having another such episode where we are talking more in depth about the problems that the teams face with these metrics.
Great, Marian. Once again, thanks a lot for bringing in such practical advice around metrics. I’m sure people, audience is going to love it. And I love it too.
Marian Kamenistak: Thank you, Kovid, for having me here. Looking forward for our next session and, let’s make the world better. See you soon!
Kovid Batra: Absolutely. See you!
In the recent episode of Beyond the Code, host Kovid Batra engages in an insightful conversation with Chris Bee, startup tech advisor and ex-CTO at Lessen. He has previously contributed his expertise to renowned organizations like Zillow, Uber, and Amazon. The central theme of the discussion revolves around bridging the gap between business and engineering.
The episode kicks off with a fun fireside chat with Chris. As the conversation progresses, he addresses the unique challenges he’s faced as a CTO, focusing on three primary aspects of organizations: People, process, and product. Chris talks in great detail about translating business goals into technical strategy and emphasizes the importance of aligning the product development process with stakeholders. He also provides valuable perspectives on goal-setting at both the company and team level.
Chris concludes by offering parting advice to the audience, reminding them not to overlook the importance of having fun at work.
Kovid Batra: Hi everyone, this is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have an amazing special guest who is a seasoned startup CTO/CPO. He has seen a startup journey from a 20 million valuation to a 2 billion dollar valuation with Lessen as a CTO. He has 17+ years of experience in leading software teams and building applications. Currently, he’s working as a technical advisor and consultant with multiple startups.
Welcome to the show, Chris. Great to have you here.
Chris Bee: Thanks for having me, Kovid. Great to be here.
Kovid Batra: Pleasure. All right, Chris. So, we’ll be starting off with a cool fireside chat with you, where I and the audience would love to know more about you through different questions.
Are you ready for the fireside chat?
Chris Bee: Yeah, absolutely! Let’s do it.
Kovid Batra: All right. So, here’s the first question for you. Tell us about the most important event of your life, like that defines you.
Chris Bee: Yeah. Yeah. There’s lots of things I could, I could probably reference. It’s kind of hard to narrow it down to one event necessarily.
But one significant event that I would, I would typically talk about is, moving out west and, you know, took a pretty big leap of faith and left behind a lot of my family and friends back east and really jumped out here without really knowing anyone or much about the area, frankly. But in retrospect, it was a great decision and, it was a huge boost for my career. And, got to work for some amazing companies out here that really didn’t have offices back east where I was from. And, you know, being away also let me focus a little bit. You know I originally worked for Microsoft and then Amazon, Uber and Zillow and, you know, being out here allowed me to have a little bit less distractions, a little more of kind of a blank slate and kind of carve out a new path in life. And, I, that path has been focused around tech and the outdoors and meeting new people, Met some great friends out here that I otherwise wouldn’t have met if I didn’t make the move and actually met my wife out here and started my family out here as well.
So, it’s been quite a kind of pivotal point in my life as I reflect back a little bit when I actually made the decision to come here, but definitely a good one. And, I miss a lot of my friends and family back east very dearly, but, all in it’s been great living on the West Coast.
Kovid Batra: What do you love most about the East that you don’t find here in the West? I mean, I, I’m sure you would have spent your childhood and growing up teenage over there, right?
Chris Bee: That’s right. Yeah. Yeah, I moved out here kind of in my late 20s. So, I had a pretty significant chunk of my life that was, that was on the East Coast. Well, I mean, the family and friends are the main thing and a lot of the people I knew back there. You know, there’s sometimes a bit of a directness about the East Coast that I appreciate. Yeah, there’s a little bit different, food, culture there and kind of cuisine options, although cities have homogenized a little bit over, over the years. But, you know, I think there’s, there’s different food options.
And, I don’t know, I think the main differences are really just around, you know, kind of the general attitude of folks. I think people are a little more laid back here, a little more reserved. They get a little more of that directness on the East Coast, which I appreciate. I think I carry that with me. It actually helps me at times. But, broadly speaking, you know, it’s, it’s the same country. It’s not a wild difference between the two coasts really these days.
Kovid Batra: Cool. Amazing. So, tell us about, uh, your first experience; how did you get into tech actually?
Chris Bee: Yeah. So, I was always inspired by what technology can do. I was an early adopter of the internet back in the 90s, kind of really date myself here. But I studied programming and management in school and more specifically, I got really into software in my grad school years. And, I was actually a DJ during that time, just kind of a source of income when I was, when I was in school and that led me to learning graphic design and then promoting a lot of my events and led me to building a production company that had a pretty comprehensive website of event listings, forced me into learning technology. So I learned, you know, PHP and HTML, CSS, a little bit of JavaScript, and, you know, web servers and analytics and, you know, kind of the, everything I needed to do to basically promote events and keep the website maintained. And I just really became fascinated with what technology can do at that point.
And that led me to go a lot deeper in my studies. I did a lot of like continuing education and you know, kind of nights and weekends programs and got my first job as a Product Manager back in Philly and at a technical company. And I just really kept progressing from there. Every company I joined, I would take on little side coding projects. I still kind of do projects for fun on the side today. And, it’s really a never-ending pursuit. There’s always something new to learn. And, you know, obviously with AI now there’s like a whole new era of things to understand and learn and dive into, which is exciting.
So yeah, it’s been, it’s been quite a journey. But, way back in the day, believe it or not, it was, it was being a DJ and promoting events that initially got me started in actually hands-on kind of coding and building applications.
Kovid Batra: I like that. That’s one hell of a transition. I mean, a DJ turning into a tech leader, if you look at it, I think that’s amazing. I’m sure that that would have definitely brought a lot of different aspect and perspective of how you look at things when you lead teams, when you do your work on day-to-day. I’m not sure how it impacts, but, that’s a different transition that I’ve heard very lately.
Chris Bee: Yeah. Yeah. Yeah. No, it was a lot of fun when I was in college. It was a great job, a lot of the other jobs that my friends were working at the time. And, you know, I did internships in the summer, more professional internships. But, yeah, it was a lot of fun and it led me down the very beginning of this path is kind of where it started when I really think about it. But quickly, the professional world took over and I, a lot of that type of work just really focused on that once I finished grad school and started working professionally.
Kovid Batra: What about now? Do you, do you still play sometimes?
Chris Bee: On occasion. Yeah. Yeah. I’ll dabble here and there just for fun. You know, just at the house, you know, no desire to go play gigs or anything like that anymore. It’s purely just a hobby at this point.
Kovid Batra: So, how do you usually unwind your day? Like how, and there, there is a lot of work, hectic day, then you come back home, what’s your go-to then?
Chris Bee: Yeah. Yeah, it’s varies by the day a little bit, and depending on family activities, you know, can, can change a little bit. But, I guess I tend to be a night owl a little bit more by default. You know, I’ve become more of a morning person with kids, but, I generally like to put some closure to the end of my day. And I actually kind of find it relaxing to work a lot of times when there really aren’t other folks online. And you know, as a busy professional, you can either carve out early mornings or late nights, essentially to focus. I feel like you kind of have to pick one when you’re sandwiched between meetings all day, and you know, usually just bouncing around from conversation to conversation. Um, so I usually find that that time of night and I really like to carve out my next day as much as possible. Kind of prep call notes, set up any meetings that are needed, catch up on the email I might’ve missed, and sometimes do some deeper work, or at least, at least frame it out for the next day is usually what I like to try and do. And what I find that does sometimes is it will sort of allow things to sit in my subconscious a little bit while I sleep and let my mind kind of solve some problems while I’m sleeping. A lot of times I’ll wake up, you know, with the insights or you know, kind of thoughtful approaches to what I was ruminating on.
But I try and stop working at least an hour before bed just to, you know, wind down and you know, usually read before I actually go to sleep is typically my pattern. But that’s based on my routine. You know, it varies a little bit like everybody and I try not to get, you know, super dogmatic about, you know, how I, how I handle it. I think, you know, not putting too much pressure on yourself is also important. But yeah, that’s, that’s the basics, I think.
Kovid Batra: Cool. Cool. Cool. I think it was, it was great knowing you and thanks a lot for being honest here and telling us from where you came, what you did, what you like.
Now, I think I would love to, and the audience would also love to know more about what you did in your career, maybe some successes, some failures, your experiences as a CTO. So, I think let’s get started with the main section where we talk to the new-age CTO.
Chris Bee: Ah, sounds good.
Kovid Batra: All right. So, my first question. So, as a CTO at Lessen, and probably you have been wearing this hat now multiple times, there have been multiple challenges that would have come across when you are into this responsibility and this role. Tell us about some of the major challenges that you have seen as a CTO, and how did you overcome those, and share some hands-on advice there.
Chris Bee: Yeah, absolutely. You know, I think big picture, if you zoom out, you know, the job of a CTO, or any technical leader really is to translate the business strategy into engineering strategy, right? And how you actually do that, I think depends a little bit on the company size and the stage of the company.
I think if you’re in the earliest stages, you know, you’re really going to be operating as a lead developer and a system architect and maybe managing a small team to execute. When you get to that next phase of a growth stage company, you’ll typically be more focused on hiring and guiding the team to follow best practices and, you know, taking on more of a leadership role. And then, as you get to the later stages, I think, you know, it shifts again where, you know, you’re really working with your peers to make sure you’re investing in the right areas, studying the culture, keeping teams aligned, and really working towards achieving business goals in the broader sense. I think you’re delegating a lot more as you know, you get to kind of manage your managers and, you know, department managers and this sort of thing.
But in any of those phases, I think it really breaks down to three primary aspects. The way I think about it is people, process and product. So, ‘people’ is really the most important part, right? The company’s kind of nothing without their people and it can be easy to forget this as a tech leader, especially as you’re deep in the technology. But aligning your team’s passion to the growth objectives with the company is super important. I mean, there’s really no more important job than that. And, you know, focusing on helping people find satisfaction in their work and in their career and really helping people grow in their career is really one of the most important jobs. And I think focusing on that is super important. You know, work is such a huge part of our life. I think you really have to love this part of the job as a manager, and if you don’t, or that’s not appealing to you, then, you know, maybe management work isn’t really the right profession, and that’s okay. And there’s lots of, you know, technical leaders that can lead in other ways that aren’t people managers, but the ‘people’ is really one of the biggest parts. And I talk about that a lot when I’m reflecting on what it means to be a technical leader.
I think the next thing is ‘process’ and kind of setting up the rhythm of the technical organization, you know, aligning the tech team with the broader company objectives, you know, creating a process to set expectations and hold folks accountable. And this can come in the form of goals and OKRs or managing to a delivery schedule that needs to be published by the team or kind of a variety of other ways. But, I do think having a system by which people understand kind of how they’re being evaluated and you know, what the expectations are is really important. And, you know, as a, as a leader, as a CTO, you know, you’re ultimately going to be responsible for kind of setting up, you know, what those expectations are and what the rhythm of the business should be and how you’re going to drive performance in your teams. And, what I found is that high performers, you know, want to be held accountable. They want to know, you know, what the rules of the game are, so to speak. I think there’s nothing worse than, you know, being surprised or not really understanding what your expectations were and having a miss. And, you know, then you’re in a whole, you know, kind of people management debacle that you don’t want to be in. So, I think it’s important to be clear about that and set up a process that works for people to grow within and know what the is expected of them.
And then lastly it’s ‘product’. You know, really leaning into prioritization and having a business lens with it is, is sometimes a new area for, for folks that have really come up from the technical side. But, you have to really be thinking broadly about the organization and the company to help make good prioritization decisions inside your team and what your team’s working on. It’s a lot about architecture and, you know, building the right foundational pieces so that, you know, the platform can grow and, you know, flourish. I think ensuring you have the right investments in infrastructure and DevOps to create a great developer experience so, you know, you’re able to move fast and people feel like they’re working in a system that is modern and doesn’t get in their way. And then, I think just weighing on priorities and making sure that tech debt, architecture projects are fairly represented. And, you know, having that kind of broader view of the product, I think it’s really important as a leader, when you’re thinking about the product part of all this.
And then, there’s some challenges I could probably talk through as well, if that’s interesting or up to you, where you want to take it from here.
Kovid Batra: No, I think the two points that you have touched upon, one is translating the business strategy into a technical strategy and then dealing with people, process and product. Like, these are like quite in itself, quite broad domains to talk about. I’ll try to take them one by one because I have some things to really understand there. And I have been hearing this from a lot of CTOs now, like translating the business strategy into tech strategies, one of the biggest challenges they see.
Just throw, throw some light on how you as a CTO, let’s say, at Lessen or other companies have done that. Can you just give us some example where we could, like the CTOs who are listening to you could relate to that, “Okay. Yeah, this is the scenario we are exactly into. And this is how we can translate some of the business goal and vision into the technical strategy that we are looking at right now.”?
Chris Bee: Yeah. Yeah. And I, I think it really it requires you to kind of take a little bit different view of maybe work than you have in the past if you were previously an Engineering Manager or Engineering Director, and you know, now you’re in this CTO role. And I think there’s, there’s two aspects. One is, you know, looking at it from a business lens that may be a little bit different. I think the other is just really understanding the impact of your leadership and your words and your communication to your organization. On the business side, I think the big change really is that you have to think about the company holistically. You know, it’s no longer just about the technology. And sometimes that can be at odds with how you may have thought about things in the past, because what is the best thing for the overall business may not align with really what you would like to do as a technology leader, or, you know, what you’d like to prioritize or the projects you think, you know, would be kind of fun to work on that no longer is the right lens to really look at things. So, I think keeping the business on block, helping fuel in growth, making sure you make the right investments. And you end up having to look at things from a little bit of an ROI perspective, which I think is a new lens for people, like truly, like how many dollars did we spend to deliver this part of functionality or this part of the platform? And you know, that, that generally isn’t the way in a lot of organizations anyway, how you look at things. It’s more headcount, I’ve got projects and I’m, you know, using Agile, I’m running through my sprints and I need to deliver things by certain dates. But, when you start looking at things from an ROI perspective, and you ultimately own the budget, you know, that’s where I think, you know, your view will start to change a little bit.
So, you know, it comes back to really understanding the business well, like you have to be much more of a business person, I think, than you were before.
Kovid Batra: Right. I think that that’s very true. And I don’t think a strategy, a technical strategy would just come out of two days of thinking and you are through with it; there are a lot of aspects that you need to look into to really say that, okay, we, we have to come up with this strategy and this would work. But, one most important part I feel is the understanding of the business.
So, what kind of questions a technical leader should ask themselves and their business counterparts when they’re thinking on those lines of building a strategy for the team? So, can you just highlight those few questions probably which you would be asking?
Chris Bee: Yeah. I think as you’re trying to kind of make that translation, you know, I’m a big believer in starting with goals, right? And having goals at the company level that are aligned across your peer groups. And that means with marketing, with sales, with your CEO, with, you know, other departments, operations, if you’ve got an operations-heavy style company. And those become kind of the backbone for how you empower your teams. The way I like to operate is to then allow my teams from the bottoms-up to create their goals that, you know, have a level review, but are owned and kind of independent by each team. And then, the projects within should, you know, not be surprises, but generally should be things that are coming from the bottoms-up. So, the teams are figuring out how to get to those goals and how to achieve what you’ve laid out as the objectives for the company. And that framework, I think is the best way to sort of break down the strategy. And then, there’s usually a review process that’s in there, right? If getting into the specifics a little bit, you know, if you’re going on a quarterly cadence and you’ve got quarterly OKRs you’re setting, having teams come up with their objectives, their OKRs at, at the team-level along with the projects they’d like to prioritize, having a review session with leadership, maybe making some tweaks, maybe making some prioritization changes, making sure that the dots are connected between the different teams, because, oftentimes the theme becomes sort of the glue that, that pulls together a lot of teams.
So, I think it’s goals and themes really, I should have mentioned that themes are the other really big part and, and that’s like at the level of leadership you probably want to stop, you know, you don’t want to get down into the weeds of individual projects and, you know, individual work that you want to see done. Sometimes that’s okay. It’s inevitable. You know, if you’re using the product, you know, you’re thinking about all the time, it’s inevitable.
Kovid Batra: Yeah. You gain some context, like you have to understand some of the initiatives that have been taken up. But yeah, I get your point, what you’re saying. Yeah.
Chris Bee: Yeah, you really want the teams to come up with it because I think that that empowers them and gets them excited and gets folks, you know, really eager to work on what they’ve they’ve concocted and what they’ve trimmed up. So, I think that’s important. Yeah.
You know, you kind of also have to understand your impact a little bit as a CTO. I think, you know, one of the biggest changes from kind of the managerial level to the executive level is you have to be a little more thoughtful about some of your decisions and some of your statements. You know, the more senior you get, the more weight your messages will carry. And, it’s important that you’re consistent, right? You need to be a carrier of the vision for the organization. You need to be aligned with your peers and your CEO and how you describe strategy and priorities. I think it’s, you know, a situation where you have to be a little careful about half-baked comments or things that, you know, you haven’t really thought through because people sometimes will take that as direction and as, you know, sort of guidance of what they should be working on. And then, that can cause problems in your organization, especially if you’re misaligned with, say something the CEO said or something the sales team’s talking about, and, you know, that can create confusion and a lot of churn inside the team.
So, you know, it’s, you want to be approachable, you want to be transparent, but you also want to be thoughtful about, you know, sort of giving guidance and direction. And I think sometimes, you know, you even need to specify to say, you know, “This is just a suggestion or a random observation. This isn’t a go-do.” I think actually clarifying that when you’re talking to people from a leadership level, I think is, is actually really important.
Kovid Batra: Totally. That makes sense. Cool. I think that’s, that’s on the, on the technical strategy being formulated. When it comes to like leading teams actually, you have to enable your dev teams, you have to enable your Engineering Managers, your, like senior managers to actually lead their, their teams better. So how, how do you exactly do that? What kind of leadership style do you take up or what process of framework do you have in mind to actually lead and enable teams?
Chris Bee: Yeah. Yeah, absolutely. You know, I’ve been talking about it a little bit already, but I, I really like to lead with the theme of accountability and autonomy.
I think in order to empower teams, there’s really 3 things you have to have. You’ve got to have a system for accountability, you’ve got to have team autonomy and you’ve got to be able to articulate and make sure everybody understands ‘why’, the ‘why’ behind what we’re doing. And I’ll just talk about that last one first, since I haven’t talked about it much. And I think as a leader, you know, that’s one of the most important jobs is to repeat the ‘why’ and really make sure that it lands with people. I think when people really understand the ‘why’, they can work through almost any ‘how’. And that’s, that’s part of your job as a leader so that people feel inspired, so they’re excited about what they’re working on. They understand how their work ties the bigger picture to business goals to hopefully the impact the company’s making out there in the world. And I think you have to deliver that with some passion and conviction. And you need to, need to legitimately feel that way about what you’re working on and what you’re doing. And, and I think when you are able to articulate that and put that out into your organization, you know, people are going to perform at their best and be the most excited. And it’s just a lot more of a fun work environment when everybody’s aligned, you feel like you’re working towards a little bit of the greater good and something that is beyond just the scope of the specific, you know, task or, you know, bug that somebody’s fixing. So I think that ‘why’ part is really important.
And I talked a little bit about, about the autonomy and kind of how to break that down and how to set clear goals at the top and have teams kind of build that from the bottom up. I think, you know, there’s a little bit of, like, just the right amount of pressure in there, that’s important. I think periodically, you know, usually on a quarterly basis, doing some level of sort of public review of our accomplishments from the previous quarter, and what the plan is for the upcoming quarter, I think does add a layer of, kind of a healthy pressure, right? To sort of discuss things in kind of a more public forum. I think demos are another really big piece as well, when you talk about accountability. I think allowing frontline engineers to show off their work, whether it’s weekly or bi-weekly basis to the broader organization. I think that can create, you know, a little bit of a healthy, you know, situation where people feel ownership and feel like they need to deliver something by a certain time.
Yeah, exactly. Exactly. So, yeah, those are some of the big things I think but autonomy and accountability are kind of the themes.
Kovid Batra: Perfect. And now, moving on to the product part. Like, when you are moving down, building the product, there has to be a development process for that. And that has to not only work for the customers, for the consumers, but also for every stakeholder that is there in the system, and that includes your dev teams also, that probably includes investors also. There are a lot of things when we talk about stakeholders there. So, how do you create that product development process that falls in line with each and every stakeholder in the system?
Chris Bee: Yeah. Yeah, I think there’s a couple of aspects to it. You know, and I’ve talked a little about this, but there’s, there’s a combination of tops-down and bottoms-up that I think really needs to be, you know, clearly defined as you’re figuring out how to set up a product development process.
As I mentioned, I think top-level company goals and themes are what leadership should really be responsible for, communicating that clearly, making sure that’s aligned across functions. And from a bottoms-up perspective, I think team goals and timelines for delivery are really, like the responsibilities of the individual teams. And then, as you kick-off individual projects, you know, a system that I’ve developed with some others over the years that I’ve found to be really successful is what I call “the 4 Ds” and, it’s discovery, design, development, and distribution. And for kind of epic-level projects, you know, these aren’t task-level items, but, you know, bigger projects that, you know, usually measured in, you know, one to three months, having projects go through those phases, I think is really important.
And, that point between design and development, I think, is 1 of the ones that needs to be kind of clear and you want engineering involved in the front half of the process and you obviously want product involved in the back half when development’s actually happening. But, there is a little bit of a point there of need to have things clear enough and requirements specified well enough, and technical design figured out well enough before you go off and start coding and building something in the wrong direction. And that isn’t to say that, you know, you shouldn’t experiment or build things quick and kind of get things out and fail fast, like that mindset needs to be there as well. But, I think even in those scenarios, you want to have sort of an abbreviated version of that, where, you know, what you’re building has enough alignment, enough agreement, you know, and that can be done in the course of a day or two potentially. But, there is a clear kind of handoff there where it’s like, okay, this thing’s ready to actually be, be built and ready to be coded.
So that’s like in the weeds a little bit with like the product development process. I guess the other thing I’d mentioned are ‘principles’. I think having principles for decision-making is really important. You know, Amazon is very famous for this and it’s very baked into their culture. But, cultural values are important. I helped create the cultural values for Lessen. And, I think those are really great frameworks to have conversations with people on your team and, you know, as you’re, as you’re considering priorities. And then, I think the other set of principles that’s useful is a set of product principles that help you make decisions and help you make trade-offs because often you’ll be faced with something that has some ambiguity and there’s a lot of different ways you could decide to do something. But, if you’ve got a clear set of principles that help you make trade-offs between potentially opposing forces or different considerations, those can be used as a framework a lot of times to help accelerate decision-making and really push decision-making down.
Kovid Batra: So, you talked about making people in place who are taking the decisions; that’s what I understood from what you said right now.
Chris Bee: Mm-Hmm.
Kovid Batra: How do you prefer that happening? Like, should it be a collaborative effort or should it be an individual person assigned who is gonna be the decision maker taking all the calls there? Probably they’re the Product Managers. How does it work out well and what according to you, you have seen working out well for the teams?
Chris Bee: I actually think that’s a pretty important piece and what I found to be successful is really defining who the ultimate decision-maker is for a given area. I think breaking that down by area is important. You can’t go feature-by-feature or project-by-project, but if you look at a given section of the product, a given group of features, I think it is important, and often as a Product Manager that ultimately owns the decision there.
Another framework I’ve used or have described in the past is sort of this concept of a 49:51. And if you’ve got a, say, an engineering leader and a product leader who own a given area, for certain types of decisions, it’s going to be 51% engineering, 49% product; for other types of decision, vice versa. And, you know, broadly, it’s usually the more technical-oriented platform decisions live with engineering, but you want product involved and vice versa. The more product-oriented customer-faced decisions, ultimately somebody needs to be the decision maker. And that’s usually on the product side. But engineering leadership should be right there. 49 is, you know, not zero. It’s, you know, equal partner, but if it comes down to like, there’s a disagreement, you know, there’s gotta be a clear owner, I think. And that just helps teams stay unblocked and, and move fast and continue to iterate because without that, you can just end up a kind of, you know, analysis paralysis and decision fatigue and a lot of wasted time.
Kovid Batra: One more important thing; I have been thinking about this lately. So, this is an ideal thought process where we say when the engineers are getting down to thinking about product as a Product Manager, then that’s when the best products come out, right? But honestly, I mean, I have definitely talked to a lot of engineering leaders and I have been listening to this a lot. What do you think, what kind of trades are there in those leaders or in those team members who actually exhibit this kind of a feeling where they’re really connected with the product, they’re actually involved in the product development process from the point where requirements are getting defined and then they’re feeling accountable for whatever they are delivering? They’re not just stopping after delivering a feature, they’re looking at what product metrics are moving after they have delivered something. So, just, just let me know. Yeah.
Chris Bee: Yeah. I mean I think it really comes down to the culture that you build in your team and as an engineering leader or as a product leader for that matter.
Again, it goes back to empowerment, I think, you know, making sure that your teams have the, the safety, psychological safety, if you will, to be able to discuss, whatever it is that they think is important for the product, for prioritization that should be worked on. But, also understand the broader business context of what the goals are for the company, what the goals are for the team. And you know, I think there, there is a need for management in some of these cases to kind of be the filter and to be sort of the decision maker in some cases when things need to get escalated. But, you really want folks and engineers specifically to understand enough of the business context to where they can kind of almost make the decisions themselves if they, you know, are able to.
So, my experience has been if teams are moving kind of in their optimal cadence and moving well, the pace of iteration is really fast when teams, you know, are able to make decisions and kind of run on their own. And I think if you can build that kind of culture, and I saw it really at a couple of places that I worked, but specifically at Uber. When I was at Uber, there was really, you know, a lot of empowerment inside the teams and teams were moving super fast, and there’s a lot of freedom to run and build features and create new experiences. And sometimes they worked and sometimes they didn’t. And I think you have to build in that experimentation culture and that ability to test the ideas in kind of the lowest cost way to get it out to customers to get feedback and be able to, you know, make an informed decision with some data.
And then, you know, I think sometimes there is a little bit of subjectivity that comes into play, which isn’t necessarily bad. I think, you know, at some point in the process, you know, it does come down to a decision and there is a little bit of, you know, you could call it bias, but just, you know, kind of subjectivity in somebody’s experience or what they believe to be the most important, you know, direction to go in that comes in. And that’s, that’s okay. You know, not everything can be completely data-driven and completely metrics-driven. You want that as much as possible and you want the anecdotes to match the data is really the key.
Kovid Batra: Absolutely. It’s probably, it has to originate from the kind of culture the leaders, the management pulls in. But, I also feel that when we talk about accountability and giving them autonomy, defining their success as we do for a product team, if we do it similarly for the engineering team would really help. So, I mean, from that, I would like to like, understand from you, how you define the success of an engineering team and how you have seen the best of the teams thriving with what kind of goals and what kind of success metrics, I would say, in the industry.
Chris Bee: Yeah. And I think, you know, again, it goes back to goals, and are we focused on outcomes over output, right? And if we’re moving the core metrics for the organization, for the team, like those are going to be the ultimate measure of success.
And then I think there’s, you know, specific things for the engineering team, you know, the DORA metrics. I think the SPACE framework has, you know, added a more of a qualitative aspect to some of that, which I think is really important. And, you know, a lot of those things, deployment frequency, cycle time, time to restore, failure rate, like those all do matter, I think are worth measuring. I think there’s context that needs to be added to that as well. So, that it’s not just a pure A to B. And you know, if it’s up, it’s good. I think it needs to be considered with everything else that’s happening in the team. And you know, maybe some of the nuances of your deployment cycle or release cycle or what have you.
But at the end of the day, I think, you know, are you meeting your commitments to stakeholders and customers, right? Is what you should ultimately be evaluated on. And if you’ve got good goals in place, you should be able to align the work the team’s doing with the goals that the company has, and the team has, and you should be able to pretty clearly understand if things are moving in the right direction.
I think some other indicators that, you know, or maybe not talked about as much in a business context are the team health. I think, you know, is the team well-being high? Do teams feel safe? Do they feel like they can communicate with one another and speak their mind and have an opinion about, you know, what’s happening in the company or the organization? I think, you know, happy teams are productive teams, right? And you can measure this through things like retention and attrition and, you know, internal NPS. There are ways to kind of measure this a little more quantitatively, but there’s a little bit of just a qualitative kind of feeling as a leader, you should have an understanding of how your team’s performing and how they’re feeling in general. You know, I think that, you know, building a culture where people feel like they can do the best work in their career and they’re growing and they’re having fun along the way, I think is ultimately what’s most important. We spend so much of our time at work and, you know, we should enjoy it. And I think that’s an element too that’s sometimes overlooked in some organizations. So..
Kovid Batra: I’ll just ask one last question that is related to defining the goalsfor the engineering teams. Can you just give us a few examples of those good goals which really seem to have worked for engineering teams?
Chris Bee: Yeah. I mean, I like to organize goals in two, buckets, company-level and team-level. And I think if you start veering into having department-level goals or group-level goals, I think it can get really messy really quick and you can end up with a lot of fatigue around, you know, which metric to pay attention to and who’s responsible for what. So, even as organizations scale, I mean, even, you know, multi-hundred person organizations, I think, you know, you want company-level goals and team, like, you know, atomic, you know, two-pizza team, you know, 10-person team goals.
So, at the company level, you know, there are going to be the business drivers. They’re often going to be related to revenue and growth and retention and churn and, you know, onboarding of, you know, maybe one side of the marketplace or the other, depends on the business, obviously.
Kovid Batra: Right.
Chris Bee: So, those, those are in place. But then, at the team level, the more atomic level, it’s like, okay, I think breaking those down into two buckets is really how I think about it. One is project and one is business.
And, in an ideal world, you have mostly business goals and then the projects are sort of fitting underneath those to drive that metric. And you can get away with that in a lot of instances, but oftentimes, there is a big release, a big new set of functionality, some, you know, very clear customer-driven, you know, new set of features we need to add, and that becomes a project goal. And that’s okay. And having those set up in such a way that you’re trying to get something done in a given quarter or given time period, I think are important, but, you know, I think the business side, if you can break down one of the larger goals to something that your team can directly drive, I think is really important. So, you have to understand what drives, say, a revenue goal or a churn goal or a retention goal they may have at the company level; you have to kind of break that down to its granular parts. And if you’re working on the communications platform, you’re going to have a different goal than somebody who’s, you know, working on an infrastructure platform, than somebody who’s working on, you know, the front end client portal or what have you. Like, it depends a little bit on the team, I think, but being able to have that line of sight between what you’re doing at the team level and what’s happening at the company level, I think is super important because that ties everybody’s work directly up to what is important to the company.
Kovid Batra: Perfect. I think, yeah, I think that’s a good way to define goals for any team and particularly for engineering team also, which most of the time is enabling some product or business metric. So, breaking down into a project and then to associating that with the business goal that is going to get enabled with that is a perfect way to look at it.
Cool! I think Chris, this was a really interesting conversation and I think this is one of my longest podcasts that I’ve had. I would definitely love to have you back for another episode, talk on more topics with you. But for today, I’m really, really thankful, and so would our audience be. Anything that you would like to say as a parting advice to our audience?
Chris Bee: I don’t know, nothing top of mind that we haven’t chatted about, other than to just say to not forget to have some fun at work. I think, you know, we, I mentioned earlier, but we spent a lot of time with our colleagues and with our coworkers, and I think when spirits are high and people are in a good mood and everybody sort of feel like they’re working towards the same mission, it’s just a lot more fun and you get the best work from people and it’s much more enjoyable. And that’s sometimes overlooked, you know, in business context. So don’t forget to have fun.
Kovid Batra: Totally agree, man. Thank you so much. Thank you so much for this advice and for all the insights that you have shared today. Thank you, Chris.
Chris Bee: Absolutely. Thanks for having me, Kovid.
We are excited to introduce our newest addition: ‘The DORA Lab’ an exclusive podcast by Beyond the Code, dedicated to all things DORA and beyond. Throughout this amazing series, we’ll uncover the hurdles, inspirations, and practical applications associated with engineering metrics, essential for fostering high-performing engineering teams.
In our debut episode, host Kovid Batra welcomes Lena Reinhard, tech mentor and advisor with a wealth of experience from renowned organizations such as Circle CI, Travis CI, and BuzzFeed.
The episode kicks off with a glimpse into Lena’s life outside of work. Transitioning to the main section, they delve deeper into what drives teams to prioritize and implement DORA metrics and focus on effectively communicating engineering metrics with non-engineering teams to ensure alignment with business goals. Lena also sheds light on the implementation challenges engineering leaders face with metrics.
Lastly, Lena shares parting advice for engineering communities, emphasizing the ‘why’ and the context behind metric usage to drive meaningful team progress.
Kovid Batra: Hi everyone! This is Kovid, back with an exclusive episode of Beyond the Code by typo. With us today, we have a tech leader who has more than a decade of experience in the tech industry. She has been leading engineering teams at CircleCI, Travis CI. She herself has been a SaaS startup Co-founder. But, her passion for tech industry doesn’t end here. She’s currently serving as a tech leadership coach for many organizations with her expertise in building great teams across the globe.
Welcome to the show, Lena. Honored to have you here.
Lena Reinhard: Thank you so much, Kovid. It’s exciting to be here.
Kovid Batra: Great. You know what, Lena, in the last eight months of building Beyond the Code as a community, starting with these podcasts, I’ve gotten an opportunity to talk with many engineering leaders like you here. And honestly, when I talked to them about engineering metrics and different other topics, particularly what I discovered that engineering metrics was something that they were not comfortable talking about. So, we used to touch on topics like DORA and all, so they were not very comfortable around that.
However, like when I, when I read your LinkedIn post and your articles about engineering metrics, I was like completely moved by the depth you had and like the hands-on experience you had with implementing these engineering metrics. So, honestly, today’s podcast’s topic, which is impact of engineering metrics on engineering success, I couldn’t think of a better guest than you. So, thank you so much once again, to be here. And I’m sure people are going to love this and get to learn a lot of things that they need to implement these engineering metrics in their organizations.
Lena Reinhard: Thank you. And I mean, I honestly will say that, you know, similar to what you’ve described, the articles I end up writing are rooted in the questions I hear from people, and also, honestly, a lot of questions that I’ve grappled with when I got into tech in 2010 and, already had a previous career in finance and before that, and it’s not like I got into the space and had it all figured out from the get go. And so, I’m glad it, you know, it was practical and helpful and I hope we can get a lot of that today as well.
Kovid Batra: Sure, I’m sure about that. Cool. So, like, once we get started it will be all about the engineering metrics. But before I jump into that, uh. I, I would want the audience to know you a little bit more. So, if you’re comfortable sharing something about yourself as a person, what you do, what you love, I would be more than happy to hear that.
Lena Reinhard: So, I’m just by the room around me, I think for the people who are watching this, you can probably tell a bunch of things about me. I love books. You can see, like behind me the, in the shelf, I have a lot of leadership books, but the row at the bottom is actually cookbooks and baking books. I’m especially fond of making pastry and breads. I have, you can’t see, I have a plant or a couple of plants actually standing right in front of me behind the camera. I have too many plants, but it’s become a really fun hobby. I’ve always loved gardening and now that I live in the city that’s the limit of garden that I have, but I really enjoy it.
And I also do a lot of sort of creative things. I paint, I weave, I knit, and do a lot of other sort of textile works. And I think that’s about it. I also love just being outside and in nature. Fortunately, I live very close to park which is really helpful to escape city life a bit. Yeah, those are some of the things that I do. And a lot of that time I also just spend, you know, thinking about that the work that I do because I really enjoy it, and because I really am passionate about, you know, helping people navigate the complexity that comes with like engineering leadership roles. And so, running my own business now I also still try to take breaks, so hope that art and all of those things help me with that. But, it’s still something that’s on my mind a lot.
Kovid Batra: Absolutely impressive. I’m sorry, but I was just going through your LinkedIn profile and I saw that you transitioned from a finance role, then you were a community member, and then, like community builder. So, there is a lot of transition and I’m sure the versatility of the choices that you have here, I can understand.
Lena Reinhard: Yeah, well, I always say I’m just a very, you know, curious person by nature, and I’ve said yes to a lot of things in my life, often without having it all figured out. So that’s, you know, that makes for an interesting CV, but also for a lot of fun. But at the same time, I always also maintain a list of hobbies that I want to take on if I, once I have the time, so I’m also never have enough time for all the things that I’m curious about. It’s a bit of a struggle, but it’s a good one to have.
Kovid Batra: No, that’s cool. I think, uh, this is amazing and great to know you, Lena.
Lena Reinhard: Thank you.
Kovid Batra: All right. Let’s get started. I think before we jump into the engineering metrics directly, my first question it all starts with dev operations, right? DevOps that we say. So, before we jump into how we measure DevOps, let’s talk about what is DevOps in brief. What do you think what is DevOps in brief. And then, what engineering metrics, DORA metrics look like, a bit on that. Yeah.
Lena Reinhard: The “in brief” part is interesting. So, I will say the way I like to, so I’ve been doing a lot of work with, for example, corporations that are trying to integrate DevOps culture or, you know, become more Agile, not just in an Agile with a capital A sense, but more in just in terms of their ability to handle change. And to me, that’s ultimately what it’s about. I mean, the DevOps movement and Agile in particular, I see as huge pillars of this, especially in tech, they originated out of the idea of coming out of the separation between software development and IT infrastructure towards basically integrating those things. That’s where the kind of development and operations DevOps part is coming from. But to me, what’s most important there is ultimately, it’s about businesses’ ability to not just handle change in the sense of being reactive, responsive to changes that are going on in the business world, or just changes that are needed in the software development process at a much more granular level, but the idea that businesses need to ultimately be able to innovate, to drive change, to create change, and not just, again at a strategic level, but just in every team in the organization, in everyone who’s working with them. And that’s where having practices where teams can ultimately… I’ll talk a lot about teams, by the way, because I found that, especially in software engineering, teams are ultimately the core unit where work gets done. I don’t believe in putting too much emphasis in the sense of stress responsibilities on the individual just because software development is in a lot of parts, a highly collaborative process. It’s where the best results are coming from. That also still means you need highly skilled individuals, but not the idea of sort of hero culture and all that.
So, I’ll talk a lot about teams probably today. And so the ability for a team to have ideas, put those ideas into motion, get that work prioritized and ultimately get things shipped. Like, a lot of that is inherently tied to DevOps culture and the idea that exchange ideas, innovation aren’t just generated by, you know, your executive team, but anyone can ultimately bring in the subject matter expertise they have and then make things happen.
Sounds quite basic, especially if you work in a company that does a lot of those practices, it may be, you know, your day-to-day already. And that’s great. But, for a lot of companies, that’s still a process that they’re going through. And even for teams that are working more at the forefront of DevOps agility, those things, there’s still often impediments. You know, like you’re depending on other teams as a classic, or you have security concerns that you need to work through. And so that, but ultimately, yes. So, in my favorite description of it, ultimately DevOps is about making change easier and making change as frictionless as possible for anyone involved in the company.
Kovid Batra: Absolutely. I think the underlying fundamental, probably even if a lot of teams and organizations know that this needs to be done, implementing it is also a very big challenge. So, I’m sure, I mean, I have been part of a few companies in my career and I know how it looks like when the manager is talking about all those values and principles that we need to, like stick to. But, when it comes to work, we are doing a thing, like the innovation is missing, the context of the customer is missing, and then how to collaborate well, make things frictionless amongst the team is something that we really, really need to deep dive and understand and actually believe while doing the work. So, it totally makes sense.
Lena Reinhard: That’s the fun part, right?
Kovid Batra: Yeah. Yeah. Yeah. Right. Absolutely. All right. I think this is a very important and a very good start to our discussion. But, how much important do you think that when these processes are in place, teams are following it, or let’s say trying to follow it how important do you think these DORA metrics play an important role there, what should be the motivation for any team to have these metrics in place, first of all?
Lena Reinhard: So, I think DORA metrics to me are, I, first of all, I think they’re really helpful, but I also think they’re a bit of a problem and I’ll explain why.
So, my approach is always that ultimately teams need to have visibility into basically the work that they’re doing. Like, you need to know how are your services performing? How are you doing as a team? How are your practices working? Like, that’s really important. Like, one of the cornerstones of DevOps culture is the ability to, like learn from mistakes. That’s, it’s really important. And so, in order to be able to learn, you need to know how you’re doing. And I love how you just described earlier the idea between basically the breakdown between the abstract ideals in DevOps culture, for example, versus the day-to-day reality, because a lot of the things that you and I may end up saying today will probably sound very basic and very simple, and we all know that, like, It’s not, like making most things actually happen can be really hard.
And that’s kind of the joy of it, but also sometimes the frustration and so yeah. And so basically, that’s why I also like to start often with like, what are we even trying to do there? DORA metrics are one tool to help you have that visibility to know how your team is doing and to get better over time. I emphasize that quite a lot because we have a bit of a tendency in tech. I mean, I do it too, that we end up making the tool the goal, right? It, it doesn’t become any more about, um, for example, you know, “Hey, we want visibility. Therefore, DORA metrics can be a great tool to help with that.” They’re also not the only tool.
But in especially I found in the discourse about metrics over the last 10 years, it’s very easy to make the tool, the thing where, you know, the conversation then is, “Oh, we need DORA metrics. We really need DORA metrics.” And we tend to forget a little bit why and that’s, so that’s one bit that I find really important. Like DORA metrics aren’t just the solution in and of themselves. They are a tool to help you get the visibility your team needs and to understand how you can get better and whatnot. And that part I find really important. And that also means DORA metrics may not be the right tool for your team.
Kovid Batra: Yeah.
Lena Reinhard: One thing that I have seen a lot is that in the discourse about engineering productivity and developer productivity, we’ve often forgotten that there are other departments around engineering. And now, DORA metrics specifically, I think they can be really helpful for developers and engineers to understand, you know, what are the impediments in the software development process? Where are we inefficient? Where are we not effective or as effective as we could be? Efficiency more towards the deployment frequency, getting changes out quickly. Effectiveness is the more about like, are we achieving our goals? Are we actually hitting, for example, the quality, um, which is baked into DORA that we need?
That’s important. The problem is that a lot of people outside of engineering don’t understand DORA metrics. Aand honestly, they kind of shouldn’t have to because ultimately DORA metrics or, you know, take the SPACE framework or a lot of DevEx discussions that have been going on lately. There are a lot of different ways to look at developer productivity out there.
What I’m trying to say there is essentially that there is an important discussion and I like to call that metrics for teams, like metrics that are to help a team understand how are we doing? They have the subject matter expertise to understand, you know, the impact of deployment frequency, for example. And at the same time, you also need to have conversations with people outside of engineering and convey to them how your productivity is. And if you’re able to translate DORA metrics really well, say for your finance person or for the people who are making the budgets for your engineering department, DORA metrics can still be helpful. But, if you’re working with people who aren’t super-technical, you may have to translate DORA metrics for them in order to represent engineering productivity because those, those are two different, two different problems to solve. One problem is helping a team get better. The other problem is essentially conveying to others how productive your team is. And again, like DORA metrics can be really helpful with that. But keep in mind basically what you’re actually trying to do and what goal you’re trying to pursue there.
Kovid Batra: Makes sense. Lena, can you give some examples? You just touched upon this point, like, if someone has the expertise, subject matter expertise to understand what is deployment frequency, only then it would make sense for somebody to understand its essence and probably abide by things that metric is telling and improve in that direction.
So, can you give such examples maybe for the cycle time, the lead time for change or change failure rate, which are basically the DORA metrics here. Can you give us some examples there?
Lena Reinhard: Sorry, I don’t think I quite…What kind of examples are you looking for? Because you mentioned a couple of really good metrics already around DORA.
Kovid Batra: Yeah, so I’m looking for an example where people would want to implement, let’s say, deployment frequency as a metric to understand teams are doing good or not. And then, translating that into a communication basically for a team, which is outside of engineering, maybe. So, just an example of a metric where teams are understanding how it is being done, why it is being done.
Lena Reinhard: Yeah. Yeah. Thank you. Um so I’ll actually, I’ll stick with deployment frequency. Like one, not just hypothesis, like there’s research behind the DORA metrics, that’s an incredibly good research, is that ultimately, if you have smaller changes, you’re going to increase the ability of the team to handle change. And so, one motivation to look at deployment frequency and implement that as part of DORA can just be, you want with your team to get better at, like making faster changes, you want to, you know, for example, go from just shipping one big merge request, pull request per month to smaller changes to make them more digestible to help your teams, maybe, you know, collaborate a bit more. There can often also be an element of knowledge sharing. So, this can be some motivations for you looking at deployment frequency. And ideally, of course, you have deployment frequency over it, increase over time. And looking at the trying to visualize the graphs in my head.
And, now that you have that as a team, you can learn from the observations you’re making there. You can make process improvements internally. It’s really helpful to just, you know, look at that metric once a week during your planning meeting or during your retros, talk about what are we doing? How is the metric moving? What are we going to do about that? And I found that this bit is always really critical to make, make space for the team to not just look at a metric, but also figure out what action they want to take because otherwise it’s, at some point, it just gets demotivating and frustrating. Like, if you’re seeing a metric that’s trending in the wrong direction every week and no one has the time to do anything about that, well that’s just gonna suck.
So, to the 2nd part of your question in terms of how do you then communicate this? I mean, honestly, if you’re an engineering manager, and you’re reporting up to a CTO, your CTO will likely understand these metrics, why they’re important. So, they may also be able to have some of those conversations with outside stakeholders. But, in terms of conveying the impact of this, honestly, your outside stakeholders probably care about are we achieving our goals in engineering? What are we doing to get better at achieving our goals? And, are we not wasting money in the process? Those are usually the typical questions that business stakeholders care about cause I mean, ultimately, if you’re an engineering leader, that’s also kind of your job to care about. And so, that’s the conversation you can have. You can say, hey, you know, “We are achieving our goals ideally, and we are measuring how efficient we’re being in this process by looking at something called deployment frequency. Deployment frequency means XYZ. It ultimately is a signal to us that we’re able to handle change faster. And, you can also see as a result, our ability to hit our goals has become better or our ability to identify risks.” Those things. It’s not a super big translation effort necessarily. Just basically don’t rely on just saying DORA, um, but build a little bit of context around it.
Kovid Batra: Right. I think it’s more about to whom we are talking to. And accordingly, we’ll have to translate those metrics into that context. And one more thing that I feel is that outside of engineering, anyone whom you talk to, whether it is product or let’s say even sometimes you’re talking to the sales teams also. So, you have to give them a clarity on what exactly is going on in terms of achieving goals. So, do you think, is there a way around where we can have metrics beyond DORA that even the engineering team relates to and,works on it? So, for example, something like deliverability of the team, can it be mapped to some metrics which business and engineering teams both understand? Like, something like maybe customer satisfaction?
Lena Reinhard: Yeah. I mean, I think, I mean, I’ve run a lot of product engineering departments, over the years and ideally, of course, you have no goals that are ultimately about customer satisfaction or specific, you know, access to new features, capabilities in your product, and you’re able to map your engineering work to that. That’s great. If you’re able to say, “Hey, we’re going to contribute to company revenue goals.” Also great. And sometimes you just have to leave a bit of a longer thread there. So, for example, to say, you know, you mentioned to get deliverability, like in the sense of like cycle time or lead time. Ultimately, a big part, honestly, of using metrics effectively is figuring out what is the picture you want to paint and what is the narrative you want to convey. So, for example, say one of your company’s goals is highly relevant to a lot of people at the moment is, like become more efficient. Well, what does efficiency mean for your team? Where are things inefficient right now? Like, for example, you know, you had the deployment frequency example earlier. We’re currently, like your assessment of your team also ideally have a conversation with your team. So, I can look at, like sit together with them, say, “Okay, we have a corporate goal to become more efficient. Where are things not as efficient as they could be in our case? For example, we’re only able to really deploy once a month. There are reasons for that. I’m sure you’re doing that because there are some impediments. What are those impediments? What would clearing those impediments do for the business?” And similarly, if the company get on that efficiency goal, maybe there are things in your process that are really difficult. For example, a case, a lot of teams are dealing with knowledge silos. You have only, you know, one or two people who have core knowledge on the team. Distributing that knowledge is going to over time make things a bit more efficient.
And so, look at the big company goals that you’re getting and then understand what do those actually mean for our team. And honestly, that’s already a really impactful connection to have, because of course, you know, not, not everyone in, say your finance department is going to understand, like deployment frequency, but people understand knowledge cycles. And people also understand if you’re, if you’re basically saying, “Hey, we have this specific thing in engineering, for example, where if our lead, if our cycle time is shorter, or even if our lead time is shorter, we’re able to respond to customer feedback faster.” Just, you know, spin the narrative a little bit further and people are going to get that. So basically, draw the connections for people between, like the high-level things that your company cares about and what they mean for your team.
Kovid Batra: Totally makes sense. I think this is one important aspect of how you communicate these metrics and translate them into something that looks like success, not only for the outside engineering team, but also for the engineering teams.
But, talking about engineering success, I think there is not just one aspect that we can say, okay, this is something that how engineering teams would succeed, looking at the metric of, let’s say, having customer satisfaction or customer retention or relating that to epic cycle time kind of things where you are delivering fast to or responding fast to the feedback they’re getting. I think there are other important aspects to an engineering success. Team satisfaction holds very, very big importance there, I believe. What’s your thought on that? And, how would you as an engineering leader measure it or not measure it? And, how you’re going to do it basically?
Lena Reinhard: I sigh a little bit because I think it’s, this one is such a really important and at the moment, especially such a difficult conversation to have. I want to just briefly zoom out in terms of where we came from in the discourse of developer satisfaction, team satisfaction. Just one cornerstone from my personal beliefs and beliefs as an engineering leader, like team satisfaction is important. There’s very good research that shows that developers having a good connection to mission and vision, the good feedback culture on the team, like the, all the high-performing teams research, that’s been done by Edmondson and others. That is, it’s incredibly important. I also believe in just, like we’re working with humans. And treating each other as well as possible is an important part of that. At the same time, again, team satisfaction is a tool. We’re not just caring about team satisfaction because we want people to do well. And I see that more in this, in the business context now. But there is a point because it helps us get things done because it helps us build great teams. It helps us build a sustainable company, all of those things. And so, like with any other metrics, I found that it really helps the conversations you’re having with other leaders in your company, even within engineering, when we’re talking about why are we measuring those things and why are they really important?
And, you know, all morals and personal values and leadership values and all of that I have a side, which I ultimately to me are the reason we are doing this work. But it also means, just to say it very bluntly, if you go to your finance person and just say, “Hey, we care about team satisfaction.” They’re probably going to say, “Well, team satisfaction, like, your team satisfaction is very, very expensive compared to the team satisfaction in, for example, you know, our sales teams where people often get paid just largely commission-based, based on the impact that they’re having for the company or compared to the customer success teams that you may have.”
And over the last couple of years, we’ve as an industry, when money was still cheap before the layoff rounds that we’re going through now, a lot of team satisfaction is also about ultimately retaining talent, you know, engineering talent was hard to find and was hard to retain. A lot of companies are putting way less emphasis on that right now. I personally think team satisfaction is still really important. All that research on high-performing teams and what not still holds, but at the moment for a lot of companies, the bottom line really matters. How much money you’re spending really, really matters.
And so, that means as an engineering leader, should you care about team satisfaction, how your developers are doing? I personally think a hundred percent you should. And you should look at how are you ultimately, you know, helping people grow in their careers, are you helping them, actually have the impact that they can have on the business? And the latter is the conversation you need to have. So, a lot of components of team satisfaction are ultimately about, you know, alignment, for example, or about having business impact. But a lot of the metrics around team satisfaction are you know, more about feedback culture, for example. So again, look at team satisfaction, look at developer engagement, developer happiness and productivity and connect those things to business metrics, connect them to translate them into examples that the people outside of engineering will understand and will care about. So, you know, look at the team satisfaction components, depending on what you’re measuring there. For example, that is that engineers are aligned with the mission of your company or that there are no knowledge silos or that there’s high business impact of the work that your teams are doing. So, you know, these components of team satisfaction are really important. Connect them to things that are meaningful to your business, because especially at the moment, it’s just going to help you have more productive conversations. Because right now, that’s what a lot of businesses care about. And that still means, again, developer satisfaction is really important. Just figure out how you can talk about it in a way that’s going to resonate with the people around you.
Kovid Batra: I think the biggest problem here is that a lot of engineering leaders might be knowing about this, might be reading about this on day-to-day basis. But, the challenge is when it comes to implementation, they are stuck, right? And, I think we are circling back to the point 1 where we were talking about that, knowing things and then believing and implementing things at work is something that is very, very difficult.
So, in your vast experience so far with different engineering teams, I’m sure you would have seen a lot of such challenges that engineering leaders or teams in general at every level encounter while implementing these metrics. Can you just share your experience? Maybe one or two examples where you could highlight how people ended up implementing these metrics and what challenges they faced during that course, how much time did it take? So that we can set some real expectations for the audience who is listening and really wanting to implement these things.
Lena Reinhard: Yeah, I love that question. So, my first recommendation would be and I’m going to try and formulate recommendations based on things that I know people often struggle with do this with your team.
So, what ends up happening often is that there’s a business demand for, you know, better visibility, more metrics, and whatnot. And a lot of engineers are scared because they’ve made bad experiences and understandably so. And so, that’s where my whole angle of metrics for teams is coming in. So, sit down with your team, say, you know, “I would love for us to better understand how we’re doing to improve together in this and make it a group effort.” Like, I’m pretty sure your developers will have ideas for things that are not going well because it’s going to bug them in their daily work. And so, the more you involve them in this already, the better. So, that’s a really good cornerstone.
The second part, that’s more the metrics and it’s about teams that you may need for business reporting and whatnot, be transparent about those. Say, you know, “Hey, my boss is asking me to talk to them on a weekly basis about the impediments in our delivery or our goal progress.” You can share those reports with your teammates as well while you’re, you know, pushing more information to your boss and giving them the visibility that they need.
Similarly, if you’re getting questions from stakeholders from the business side or from customer success, help your teammates by just sharing those things to the degree that you can, because honestly, many of us have struggled over the last years because I mean, I come from the business background initially, but a lot of engineers never got business training and, you know, became engineering managers and weren’t given the, even just the vocabulary for having conversations about efficiency and effectiveness and whatnot.
And so, like, you may still have to learn some of that. And that’s okay. I have a couple of guides on my site as well. If you want to get more into that. But at the same time, you can use that as a great opportunity to help your engineers understand a bit more of a business background, things to think about, and a lot of, you know, basically framing and vocabulary, the translation function that we talked about. so that’s basically the second piece, you know, keep your engineers in the loop on this, be transparent with reporting and metrics and with the cases you’re making.
I think another part that I found is really helpful is collaborate really closely with your product partners. Like, if you have, you know, if your team has a product manager, if they don’t, if you run a platform team, for example, you may have more of that function yourself, where you need to write business cases for the investments that you’re making. But, like having run a product engineering organizations, I just see a lot of that honestly, the collaboration between product and engineering can be really tough. And that’s oftentimes really, really making things very difficult for everyone involved, and I know that there’s often, you know, like, incentives that aren’t, that aren’t aligned well and whatnot. If you can partner well with your product team and Product Manager, that’s going to go a really long way. Figure out how you can set goals that are aligned because the whole, you know, engineering wants to do this, but product wants to do something else. I understand where it’s coming from and it’s causing so much frustration and so much friction on so many teams and ultimately, impeding your ability to create business impact and so on. If you’re having troubles in those relationships, work with your boss, work with your product partner to figure out, you know, ultimately, you’re all there to do good work for the business. How can you collectively work together to make that happen?
And then lastly, on the, the metrics topic, what I would also say is if you’re just getting started, and you’re not measuring a lot, or there are a couple metrics in place and you’re not sure what to do with them, I always recommend, you know, go to basics, figure out where are we struggling as a team, work with your teammates, work with your boss as well. You know, they may have things that they want from your team, or you have a corporate strategy, you know, I mentioned earlier there are strategic goals potentially in place around becoming more efficient or becoming more agile as an organization. Look at how can we do those things as a team. And then, if you don’t have metrics in place yet, how can we measure those things? We all love a good dashboard. Resist the temptation to measure, you know, 20 things, from the get go, um, because worst case, it’s just going to be overwhelming, and again, like you’re not going to have the capacity to actually address all of those things. So, like instead, you know, start small to use two to three metrics that really capture areas that are meaningful to your team, that are meaningful to your business. And then, iterate from there. Like, you may not need all metrics that you start with at every point in time. At some point, something else is going to become more important. You can focus on that. The really important part really is that you look at those metrics regularly, you talk to your team, you talk to your boss and you figure out how you can make room. And that’s also to the collaboration with product, you make room for actually addressing the issues that you’re observing in these metrics that you’re looking at.
And that honestly, I know a lot of it may sound really basic. I also know that honestly, most of those things are things that any team struggles with, at least at some point in time. And at the same time, it also means you’re in good company and, you know, it can be figured out. Like, go back to those basics and don’t get too lost in, you know, like, oh, you really need to measure DORA or SPACE or DevEx or something else. Figure out what your company and your team needs and what’s meaningful to them. And if you need a starting point, DORA is a good starting point. I also don’t want to just trash on those metrics.
Kovid Batra: No, I think that makes a lot of sense. And I, I mean, I totally understand that this is very basic or something being mentioned every now, here and then, but one very important point that you have mentioned that I feel is that the metrics are not something that are same for everyone. Every team has their own needs and having a collaboration with all the stakeholders is I think the must, because what I have also felt in my journey of learning about these metrics and getting them implemented is the resistance. One is of course the innate resistance of not understanding and where to implement it, but then the resistance from the teams, the cross-functional teams.
So, it’s a very, very good point, actually, Lena, that you just mentioned that talking to your bosses, talking to the cross-functional teams, talking to the developers and making them understand what exactly is needed and why it is needed will bring that alignment in place. And of course, I mean, it would take some time. And what we are doing right now here is talking about it and setting some real expectations because if somebody who is new to this and they think that, “Okay, I would do it in one month.” But, the realistic thing is that it would take three months, right? It would take some time for everyone to come in the alignment and then get it implemented.
So, while we are talking about this, someone who is hearing it would understand that, okay, it will take three months of time. These are the things that I should do. The other thing I should not do and then implement these basics to get the results there. And, I’m sure I have seen those case studies. I’ve seen those scenarios where the teams have really improved their efficiency, productivity, satisfaction, and became successful over a period of time using these metrics.
I do agree that this is basic, but this basic is something that needs a little bit of depth and context for the teams who are trying to implement it.
Lena Reinhard: Yeah, exactly. And I always say, I mean, we’ve all read the books and the blog posts and whatnot, and there are so many good guides out there. And at the same time, I mean, honestly, the work that I do is in translating those abstract, like simple in the abstract things to like, I always say, you know, “What do you do on Monday morning at 9am when you open your laptop?” And you’re like, “Oh, I don’t even know where to start.” Like, that translation or that application is the tricky part. And that’s why even though it sounds so rudimentary, but understanding why you’re doing this, I loved the way you just captured this as well. Like, why are we doing this? What is the point of this? Don’t lose that thread because otherwise, again at some point, all these tools just become self-serving. At some point, you’re just, you know, you’re similar with story points. At some point, you’re just, you know, going through story points as a team, because you’ve always done it. And you just keep on doing it. And then, developers get frustrated and things get annoying.
Same thing with metrics. Don’t lose the connection as to why you’re doing those things. because one, it’s going to help with, you know, team satisfaction, employee engagement, um, but it’s also going to make sure that you’re still on the right path. Because if you keep sight of why are we measuring a certain thing? Why are we talking about this in our retrospectives? You can also then have the conversation, “Well actually, DORA metrics aren’t serving us anymore right now, because we’re actually doing quite okay. And, we need to shift to measuring more in the area of, ‘make something up here’, in the area of, you know, like more Agile metrics, or we need to measure a bit more, focus a bit more on the effectiveness side of things because we really need to, add more metrics around quality that we’re shipping.” Or whatever it is.
But, it’s going to help you, yeah not just continue measuring DORA till infinity because you’ve started it at some point and now you’re just doing it. It’s like, yeah, don’t forget that “why?” It’s probably my biggest thing that I’d recommend.
Kovid Batra: No, I think that’s, that’s really great. And with this, I think, in the interest of time, we will stop here because otherwise we’ll just keep on talking. We have a lot to share and discuss. Maybe we can have another episode on this, but for today, we will take a pause here.
And before departing, I would say if there is, one piece of advice that you would like to share with our engineering community, the leaders who are listening to us, the engineering managers who are listening to us, please go ahead.
Lena Reinhard: I would say, you know, stick with the “why” and context is really key. Like understanding why are we doing things? Why are they important? Like, having that context yourself and then helping your engineers understand it as well. Like, and you may have to talk about this context many times. And that’s because it, one, it can change, but also because, engineers will have to then, you know, wrap their head around what it means for them, for their job. And that “why” and that context is really critical and it’s going to help you, like choose metrics thoughtfully, use them well, use them well with your teams and not just as tool check, surveillance, which they’re often kind of abused as. And ultimately, that’s how you’ll also get the metrics to help you drive the positive change that your teams need.
And when you start small and stick with the “why” you’re going to get there, even if it feels like really big task when you’re just getting started, but you’ll be able to figure it out.
Kovid Batra: Right. And I think if people who are listening to this are getting stuck anywhere, Lena is there. You can reach out to her.
Lena Reinhard: Please do. Yes.
Kovid Batra: Cool. All right, Lena. It was a great, great talk. Thank you so much for your time and sharing your experiences with us. Lovely talking to you.
Lena Reinhard: My pleasure. Thank you so much, Kovid.
Kovid Batra: See you!
Lena Reinhard: Bye!
In the recent episode of ‘Beyond the Code’, Host Kshitij Mohan, founder of Typo engages in an insightful discussion with Luca Rossi, the driving force behind a vast engineering community comprising over 50,000 members. The core of their discussion revolves around implementing a data-driven approach to building efficient dev teams.
The podcast kicks off with a fireside chat with Luca which involves lighthearted questions. Luca then delves deeply into the intricacies of the data-driven approach, emphasizing key metrics for scaling efficient dev teams. He also offers valuable insights on establishing the right processes for code reviews.
Wrapping up, Luca elaborates on a thought-provoking concept – ‘Shift focus from 10X engineers to 10X teams’
Kshitij Mohan: Hello everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by Typo. Today we just can’t hold our excitement because of our guest. He is one of the biggest names today in the engineering leadership ecosystem around the world. He had been a founder, a CTO, and today runs an engineering community of leaders with more than 50,000 plus members.
Here’s to the man himself. Hello, Luca Rossi. How are you?
Luca Rossi: I’m great. Thank you so much for the kind intro, and thank you. Excited to be here.
Kshitij Mohan: Thank you so much, Luca. You have earned it all, so thank you so much for giving your time to us. I would say
Luca Rossi: Thank you. Thank you for having me again.
Kshitij Mohan: Perfect. So we have heard, seen talk, you write a lot about building data-driven engineering teams, and I think this is what we would love to know more about.
But before we jump into your expertise in wisdom, we have a special section for you. Since you’ve been on the show, we had to do something different. So we have a fireside chat for you. It’s a quick series of questions that me, the viewers would all love to have you answer and know the real Luca. So, are you ready, Luca, to get started?
Luca Rossi: I am, yes.
Kshitij Mohan: Perfect.
So let’s get started. Question one, Luca, since you are from Rome, Italy, other than fine wine and football, what else do you love most about Italy?
Luca Rossi: First of all, I confirm that I love wine and football. Like delicious. I love. So many things about Italy, and you know, when you’re from a country, there are some things that you do not fully appreciate until maybe you get abroad or somewhere else. You take them for granted and then you see it’s not everywhere the same. So as for me, I really love how in Italy we focus a lot on good relationships with family and friends and well-being. I mean, well-being is pretty much defined by the relationship with those around you, with your loved ones.
It’s a great thing that I’ve not, I think, appreciated enough, until I was older in age.
Kshitij Mohan: Oh, that’s true to your heart, Luca. Definitely. Perfect. Question two, which role do you love more and why? Luca being the CTO or Luca today running this community?
Luca Rossi: Yeah. Wow. That’s a very tough question.
I would say, I love both for different reasons. I mean, because there are definitely things that I miss from my time as a CTO. I mean, I miss the vibes and the energy of working with an actual engineering right product team, working together on some challenge, seeing how maybe junior and younger engineers grow into fantastic professionals or managers.
But I also love the way I can spend my time these days by doing research and writing and, having great chats with people like you guys, and being able to run and to organize my time the way I prefer. So it’s a tough call. I mean, right now I’m happy with the lifestyle of the lone writer, and I would not go back, but in the future.
Kshitij Mohan: Definately. Question three. When was the last time Luca, you played a video game, and which one was it?
Luca Rossi: I’ve been playing a lot of video games for my, for my whole life and lately, the two things that I’ve been playing the most are chess, with some friends on chess.com and, iRacing, which is sim racing, simulation driving.
I have a simulation set up in my place.
Kshitij Mohan: Oh, seriously.
So you have a game parlor, right at your home?
Luca Rossi: Yes, I have. Yes, I have everything I complete online. I mean, the last few weeks, less than I would’ve liked because of a lot of stuff going on. But yes, that’s a big passion.
Kshitij Mohan: Oh, perfect. You turned out to be a gamer, we never knew. So, yeah. Perfect. Question four Luca. What’s the funniest mistake you think you made as an engineering leader or a manager?
Luca Rossi: I’ve made so many that were not that funny at the time, but now make for funny stories. So I guess that’s the right way of seeing at them.
I think one very funny mistake speaking about it right now, not at that time, I used to run a travel startup where people could book and compare different modes of transport, like flights, trains, etc. At the beginning we just were Meta search engine so people could not actually buy the tickets. And we wanted to prototype this feature first to figure out if people liked it. And so we said, okay, let’s just put a buy button connected to Stripe and then we will go manually buying the tickets on the websites of the providers. And it was great product wise, it took zero time, but then it exploded in complexity.
We had to take shifts so the whole team, night team during the night booking these things manually. Yes. It’s, I mean, it was insane and we could handle it better, but it was also fun. So yeah.
Kshitij Mohan: Perfect. And one last question for you. Why do you think people love your newsletter?
Luca Rossi: I think there are many reasons. I think the major reason is that I try to keep it practical and dense. So articles are short because I tried to think in my own problems when I was a young CTO because being a CTO has been my very first job out of university, and I didn’t know how to do like anything. And I struggled, finding good content around how to run an engineering team, how to hire, how to organize a team. And so I tried to speak from experience and, and try to tell what I would’ve liked to read when I was younger. And so try , to write about real stories, practical tips, not just fluffy theory, which there is a lot about management.And so maybe people like this a lot. And also drawings. Of course.
Kshitij Mohan: No. Perfect. I think real problems create real value propositions, so definitely. Perfect. Luca, thank you. This was real fun. Thanks for being such a sport. Thank you.
Luca Rossi: Thank you. Thank you for the questions that were great.
Kshitij Mohan: Perfect. So now moving to the real stuff, right?
What Luca Rossi writes and talks and has an expertise about. So I think the first thing that always comes is while building and scaling a dev team, how do the leaders, the managers, how do they go about leveraging these data points, these metrics that they have, but they still don’t have, right?
How they can efficiently put these into metrics to build a high-performing team. Would love to know your thoughts on that.
Luca Rossi: Yeah, of course. It’s a broad topic and we could speak hours about this? What I’ve seen talking with leaders is that there is so many information out there, there are so many KPIs they could track that people get easily overwhelmed and they don’t know, how to begin with, you know?
And if they’ve just started, they want to start creating some metrics program or tracking something. What I tell everybody is just start having conversations with your team. It’s like collecting metrics manually, talk with the other engineers or their senior leaders and get their feedback about what they think is working, what they think is not working and then work backwards from there.
Trying to set some very basic one or two KPIs about things that your team think, it’s critical. So that you can start tracking it for real and figuring out initiatives to get better. Creating maybe a small process with periodic retrospectives to discuss the trend, how it’s going, but, Always start with conversations because engineers can even be a little bit scared by the idea of getting measured or getting their productivity tracked.
So trying to really make them understand that you’re on the same ship and you’re trying to, improve things together. It’s very important, so start small and start with conversations I would say.
Kshitij Mohan: No, definitely, and I think very important point that you touched, right? So, whenever there is a talk about implementing this data-driven approach in an engineering team, right?
There generally comes a perspective from the developers. Hey, are we being micromanaged or is someone gonna look at me every day? How do you balance that stuff out?
Luca Rossi: Yeah. That’s a great question. I think that the right approach is approaching this topic from a point of view of curiosity rather than judgment.
Let’s say. So you look at the data, you look at the issues, and try to figure out what’s happening there. Try to build awareness first around the situation, the numbers, rather than jump into I have to optimize this, I have to reach this target, I have to get twice as good or twice as fast at doing this. So using really the numbers, especially at the beginning as conversation starters about how things work in the team rather than judgemental stuff that makes people uneasy. Yeah!
Kshitij Mohan: No, it makes sense. Makes sense. Perfect. And I think just really connected to this aspect of, building the transparency, building the safety, which internal translates to building the right culture, right?
Scaling a team isn’t possible or isn’t sustainable when there is no right dev culture around it. So any specific experiences, thoughts, or processes that takes into building the right dev culture..
Luca Rossi: Yeah. That’s another great question and great topic because I think culture is what enables good performance, good productivity, right?
If you do not start, you know, with the right approach or the right principles it’s either useless that you track even track numbers or metrics. You have such organizations. I think there are many elements that enable good to great culture. I can think of a couple that are really very important to me.
One is cooperation and collaboration in general between the various areas and departments. Because I see many teams wherein the engineering is considered like a piece of a pipeline, so things only move in one direction like you start to product requirements. Then there is design, then you have the implementation, then you release and it’s done. While in the real world, it doesn’t work like that. So, it pays off to involve engineering in conversation from literally day one. I mean, I say engineering, but the same stands for designers, PMs. People in customer support. So, you’re likely gonna build better features by moving fast and iterating with all the stakeholders involved from day one because they can inform better decisions than just moving, you know in just one day.
Kshitij Mohan: Just telling them what to do. Its just being a part of the entire decision-making process.
Luca Rossi: Absolutely. So that’s very important thing to get right, in my opinion. And another thing that is instead more about engineering itself is really focus on releasing, being able to release in production fast and often. Because I, I have to say, if we have to name just one thing to optimize that almost cures all the problems is to being able to release often in production very fast, like in a Minutes. Because I mean, software doesn’t work like other engineering. It’s not like you’re building a bridge or a building. It’s something where if you do a mistake, you can recover fast.
So in most situations it pays off better to have a snappy release process. That also means a snappy recovery process if you do some small mistake than just putting more, guide rates, and cautious parts of the process that expand the release time to how was something that really reduced the productivity of everybody.
Kshitij Mohan: Right. No, I think this totally makes sense Luca! And as you touched about moving fast is what all dev teams aim to, aspire to actually, how can we drive things fast? So, one important aspect then in this entire shipping process is code reviews. There are definitely certain teams who are moving away from this review process trying to implement a different approach to it, but most of us still follow it, right? So how do you think, what could be the right processes around acing these code review?
Luca Rossi: I think it’s one of the most controversial parts of the engineering process. I agree they’re crucial to the well-being of the team, to the quality of the code. But yeah, it’s also infuriating to me that sometimes we found ourself sweating off the details of our release pipeline to remove 10 minutes out of the deployment process.
And then we just do nothing with the code sitting idle for 18 hours before getting a review, it’s just nonsensical to me. So I get that we should work asynchronously, but it’s not like we can wait 24 hours to review some code that has been done in like 30 minutes. So I think there are various ways of approaching code reviews to try to make them a little bit snappier and more optimized.
One is for sure at the cultural level treated as a P1 activity or P0 activity that is when the review lands and you’re assigned as reviewer. You just have to do it. You have to do it as the very next item in your in your list. And you can enforce this with notifications.
You can have ChatOps integrations for this, whatever. Then you should try to have small, code reviews. Pushing very small batches of code to simplify the job of the reviewer. And, and there’s long tail of more things that you can do. You can adopt more pair programming that actually allows you to avoid code reviews because code is automatically reviewed by your pair.
There are many things you can do, but I think one of the metrics in the KPIs that most teams can start with and it’s beneficial to look into is the PR cycle time. It is often the case that you can optimize it a lot and it brings benefits across the board.
Kshitij Mohan: Perfect. These are real actionable tips Luca, that I think definitely teams could follow restricting sizes. Taking this up upon priority, limiting your review process. This really helps. I think moving on to one last thing, Luca, that we have seen you talk a lot about evolve your thought process around this. And I think this is me and we, all of us are excited to know more about, is that you say, Hey, shift focus from 10 X engineers to 10 X teams. This is a very interesting thought to hear, but we’d love to know more about what exactly that means for everyone in the ecosystem.
Luca Rossi: Yeah. I think we are engineers, so we build systems and processes with software and I think we do the same with teams. And I’m really a believer that 90% of the performance or underperformance is systemic rather than individual. I mean, is the output of a system in place. And then, of course, individuals have an impact on that. But if you don’t begin with good systems, you’re not gonna get a good outcome just because of talented individuals.
And I think sometimes as an industry, we don’t focus enough on this. We do not realize this as much especially, recently there is this kind of pushback with all the return to office hardcore culture in many big companies. There is this tendency to reward heroics, you know?
And, but the risk to me is that you know, when you reward hardcore and heroic performance, you risk rewarding, for example. The guy who puts out the fire rather than the guy who prevented the fire from spreading in the first place. And the reality is that most of the, greatest engineering work that I can think of in my experience is like boring, transparent work that isn’t easily seen.
Because that’s what good engineering is about, good engineering gets out of the way. So, I think we should focus more on building great systems and great teams. Because that, at the end of the day, enable great engineers to arise. Yeah.
Kshitij Mohan: Perfect. Lovely, lovely thought. Luca, thank you so much.
This was really fun. This was really interesting. We highly appreciate you giving us your time. Luca, thank you so much for being on the show.
Luca Rossi: Thank you again for having me for the great questions and happy to come back any time like.
Kshitij Mohan: Perfect. We’ll definitely catch you up again. Thank you, Luca.
Good day. Bye-bye.
In the recent episode of ‘Beyond the Code’, host Kovid Batra welcomes Marc Adler, Fractional CTO & Chief Architect for startups. He has previously contributed his expertise to various organizations such as XP Investimentos, ADP, MetLife, Citigroup, and many more. Their conversation revolves around the theme 'Inside the Mind of a Fractional CTO.'
The episode kicks off with Marc talking about his hobbies, followed by a fun fireside chat. Moving to the main section, Marc addresses the unique challenges encountered by fractional CTOs and outlines distinctions between fractional and full-time CTO roles. He talks in great detail about how fractional CTOs lead initiatives and teams in startups. Marc also delves into the intricacies of collaborating with development shops to set up highly efficient teams with a positive work culture.
Lastly, Marc offers valuable advice for non-technical founders to always have a senior technical person by their side.
Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special and an interesting guest. He has super experience and has super nice thoughts to share with you today. He has 20+ years of engineering and leadership experience as a CTO and a Chief Architect. He has worked with companies like ADP, MetLife, Citigroup, British Petroleum, and whatnot. He has also been working with a lot of startups these days as a fractional CTO. Welcome to the show, Marc. Great to have you here.
Marc Adler: It’s a pleasure to be here. Thank you for inviting me. And, I’ve seen some of your other podcasts with some other guests. And, so I hope that this will be as interesting as the other ones.
Kovid Batra: I’m sure about it. By the way, pleasure is ours. Let’s get started.
Marc, so, in our podcast, if you have already seen those, we have this format of talking to our guests through a fireside chat, wherein we ask you a few questions to know a little bit more of you outside of work, right? So, I hope, you’re ready for that. Let’s get started from there?
Marc Adler: Okay. So, outside of work? Is there an outside of work? I hope there is. So I have, I, I am, uh, somebody who you say is a doer of all, master of none. So, I actually have a musical background. Way back when I went to college, I actually had a double major in Computer Science and classical percussion performance. So, I played in many orchestras and wind ensembles, and my speciality was an instrument called the marimba, which is like a very large wooden keyboard instrument, and played timpani, and all that stuff. And right now, I’m teaching myself how to play classical guitar, so that is my one passion right now, it’s learning how to play classical guitar and trying to play some of the pieces that I used to play on marimba on the guitar now.
And, I’ve also been a private pilot. So, I used to fly all over the place in the New York area. And so listen to strange avant-garde music. And, yeah, I think that, yeah.
Kovid Batra: Yeah. That’s very interesting, actually. All right. I think I still have a few questions for you. I think we would have some interesting answers there. Let’s get started with my questions, okay?
All right. So, this is a hypothetical question, of course. Let’s say, if I give you a time machine, where in your life you would want to go back or go forward, maybe, I don’t know, if you have a time machine, where would you want to go?
Marc Adler: Well, of course, everybody wants to go forward. Everybody wants to be a thousand years from now to see what interesting advances have actually happened in Computer Science and AI and, and just engineering in general. I mean, I’d love to see what the iPhone of the future could do in a thousand years. I mean, there probably won’t even be iPhones. But, going back to the past, boy I think I would have maybe going back to New York to, like the 1964 World’s Fair or the 1939 World’s Fair where there was a lot of excitement and new inventions being shown. I remember, there was this Futurama exhibit, this is where the cartoon Futurama comes from, if you know that. They had an exhibit where they were showing what life would be like in the future. And so, there was, like such an excitement around there. So, yeah, I’d love to kind of go back and, and revisit some like great historical moments that happened in New York City.
Kovid Batra: That’s nice. That’s an interesting thought, by the way. All right, my next question. So, if we are talking about going to the past, do you remember your first functional code that you wrote? Like, your experience?
Marc Adler: Mm-hmm.
Kovid Batra: Describe something about it.
Marc Adler: I do. So, I mean, way back, I got my master’s, so my education is I got my Bachelors in Computer Science and Music from State University of New York at Albany. And then, I got my master’s degree from the University of Arizona, which is a really great school for software. And then, I went to New York University’s Courant Institute of Math for one year in a failed attempt to go for my PhD and did the whole story around that. But, I think the first really good code that I wrote was a music editor in a language called Y, which was a very C-like language that the professors, some professors at the University of Arizona created. So, I did a whole graphical music editor at a time when really graphical music editors didn’t exist. So, that was fun. But, my very first commercial product was I wrote one of the very first word processors for the UNIX operating system. And, I actually showed that at the very first UNIX Expo in New York City in 1984.
So, when you said I have 20 years, yeah, I have 20 years of experience as a CTO and Chief Architect, but I actually have been in the industry for a little over 30 years.
Kovid Batra: That’s nice, man. 1984, you’re writing on code there, and doing the commercial code, I think that’s really, really amazing, man.
Marc Adler: It is. And, you know what the interesting thing about those times were is that we had to optimize every little piece of memory. I mean, there was not much memory in these machines compared to today. So, I used to print out printouts of my code on an old Epson dot matrix printer and take them into work on the New York City subway and look at every line of code and try to get, try to optimize even a little end clause. One statement, if I can get that millisecond or nanosecond of improvement, it really made a big difference.
Kovid Batra: Yeah, I understand. You have seen a big transition, I’m sure about it. Cool! I think that was a very good question to ask.
Marc Adler: And, the funny thing is that you don’t see many people doing that anymore. You know, languages and environments are just so high-level, people will just code and not pay attention to how efficient the code is. And, the only place where I’ve really seen that level, you know, people paying attention to efficiency is in the high-frequency training world, which, of course, I have a lot of experience in as, you know, both in terms of CTO and Chief Architect for various financial institutions, where you have developers who are looking at aligning structures on certain kinds of boundaries and they pay attention to every single nanosecond that their code takes up. And so, that’s a discipline which is lost on most developers now.
Kovid Batra: Cool! I think that was great knowing you, your passion for music, and where you want to travel in time. You’re writing code since 1984 and I think maybe before that. So that’s, that’s amazing, Marc.
Cool! Let’s move on to something our audience is awaiting. Moving to our main section where we get to know about your experiences in your career, how many challenges you have seen, how did you overcome those. And so, let’s get started on to that. Are you ready?
Marc Adler: Yeah. Yeah. Yeah. Go ahead.
Kovid Batra: Yeah. All right. All right. So, you mentioned your role as a fractional CTO, right? Like, recently from past five to six years, as we know, you have been running this organization, part of this organization where you are working as a fractional CTO.
How is this role of a fractional CTO more challenging or less challenging, maybe I don’t, I don’t know, I would love to hear from you, as compared to a full-time CTO who is working with a company? So, just tell us about the challenges that you see and how do you overcome those, and how is it different.
Marc Adler: Okay. So, there are less challenges and more challenges with the roles. And, I’ll kind of mention some of the less challenging aspects.
When you’re involved in a large company, like Citigroup, or I just came off of a CTO role at XP Investimentos, which is a very large, I think it’s the largest brokerage in Brazil. And, when you are dealing with large companies, unfortunately, you have to deal with lots and lots of politics. It’s not easy to get things done. I always say that you know, it’s a struggle to turn the battleship five degrees because there’s just so much that you have to go through with paperwork, with politics, with people who are pushing back against you and want their own agendas. So, that is not the part that I miss with being a CTO or Chief Architect in a large organization. You don’t get that when you are dealing with startups. And, in my fractional CTO practice, I like to deal with startups. The newer the startup, the better. My sweet spot is dealing with a founder that has no technical background or very little technical background where I get to make all of the technical decisions, right? So, you get very little pushback, there’s no politics. And so, that’s the advantage of being a fractional CTO. The other great thing about being a fractional CTO is that you get exposed to so many different domains out there, even domains that you’ve just never experienced before.
So, since I’ve been a fractional CTO, doing my CTO-as-a-Service, that’s the name of my little consultancy, I’ve had clients in education technology, in real estate technology, in almost every field right now, one of my customers is a big university in the United States that is coming out with something very, very new and unique as far as material sciences go. And, I don’t know much about the domain of material sciences, but as a fractional CTO, you get to learn some of that stuff. That’s what’s really, really fascinating is the fact that you can just go to all these different domains instead of being just, staying with just financial technology or training systems all of the time.
So, that’s why every day when I wake up and I deal with my clients, it’s like a breath of fresh air because I always feel that I’m learning something new and I could always have forward progress every day. Whereas, in a large company, you have to deal with politics. But, the good thing about being with a large company is that you have an unlimited amount of resources and development and developers. So, unlike dealing with some of these startups, you don’t have to worry about costs as much as you do when you’re dealing with the startups.
Kovid Batra: So, are you trying to say that the fractional CTO role is probably more suitable in a scenario where you are dealing with a startup, or the large-scale companies or even medium-scale companies should hire fractional CTOs for certain jobs?
Marc Adler: From what my experience is, large companies are not set up to deal with fractional CTOs. I mean, if they have a gap, if their CTO leaves, they’ll usually either fill it internally, or they’ll go outside to the market. They’ll want a full-time person because with a large company, there’s a lot of processes to deal with, there’s more intellectual property to deal with; and as a consultant, as a part-time fractional consultant, you’re not going to get the buy-in from the organization that much. It’s much easier to be a fractional CTO for startups because depending on your pricing model, you could be very, very affordable to a startup. So, for instance, if you consider what a full-time CTO earns in the United States, most startups cannot afford that. They can not afford to have a full-time.
Kovid Batra: Absolutely, yeah.
Marc Adler: For my clients, they’re getting a person with 30+ years of experience, with leadership experience for a small fraction of the price that they would have to pay for a full-time CTO. And, if you’re an experienced technical leader, then you can usually have a higher bandwidth, meaning that you can make more correct decisions upfront, you know, rather than kind of you know, maybe having a few false starts.
So, I think that for my fractional clients, they like to have that level of experience at something that they consider it to be an extremely affordable price.
Kovid Batra: Makes sense. Tell us more about what kind of initiatives, responsibilities you take up as a fractional CTO with these startups and how does it work out with the teams also, like how do they take you as a leader in the team; because even if it’s a startup, I’m assuming there are 5, 10, 15, 20 folks who are working with you in the team. So, tell us about some of specific experiences that you have had and the initiatives that you have worked with.
Marc Adler: Right. So, with almost every company, with every startup founder that I deal with, the thing that I like to see and that they help them with is getting all the product specs together, right, to know exactly what you’re building and to have documentation about what the product is supposed to do, all the use cases, all the error cases, all the edge cases, because I think one of the common mistakes that a lot of startup founders do is they just will take some ideas, they’ll throw them over the wall to some remote development company, and they’ll just say, “Build this.” Most developers, they don’t have a good idea of what to build.
So, what I’d like to make sure is that my startup founders have all their product requirements and use cases there. And sometimes, it could be Figma wireframes, or it could actually be in text, but I want to make sure that the developers actually know what they are building. So, that’s the first step.
And then, once you get all the product requirements, then you have to create the technical architecture, which is something that I do for my clients as part of my job, right? So, you can’t create an architecture if you don’t know what the product is supposed to do. You can’t build an architecture if you don’t know the scaling and resiliency requirements.
So, one of the common things that I see is that non-technical founders will throw their requirements over the wall to a dev shop and get back a system that is totally complex, right? So, something that uses Kubernetes, for instance, for a very simple web app, right? And, you have to guard against what I call resume-oriented development; that is a dev shop who is using technologies that might not be totally appropriate for a system, but they just want to learn those technologies, right? So, I help my founders with that.
So, with the product requirements, you’ll do the technical architecture. Then, what I’ll do is I’ll hire the development team. So, I’ll interview a number of dev shops. And, when we have a short list of candidates of as far as dev shops go, I will get resumes from the dev shops and I will interview every single developer, right? I will make sure that I have the best possible development team for my clients. And then, I’ll work with the founder to come up with the project plan, right, the backlogs. And, I will then run the development team. I’ll do that. I’ll set up the cloud, I’ll do the cloud administration, I’ll face off with the CTOs and CEOs of third-party vendors that we have to deal with, and I’ll basically design the whole system, and I’ll give them over to the developers. And, as far as how is it to work with the developers? Well, I’m the one who hired them, right? So, I’m the one throat to choke as they say, right? I am the technical authority. So, I like to have a development company that will have some good opinions and might push back on some of my designs and for good reasons. But generally, I think that because I am a very technical person, I can still code a lot that the developers usually have some respect for me because I know what I’m doing.
Kovid Batra: Yeah, I get it. Cool. I think the setup is pretty suitable for a startup also. But, one thing that didn’t come to me right as per your opinion was that you have to have all your documentation in place. I mean, that’s the hardest thing to get when you are working with a startup. So, how do you deal with that friction? I’m sure with almost all the founders, you would have some friction there or at least some to and fros there where you would be pushing to get the right documentation and getting it done. So, how does that scenario come up?
Marc Adler: Well, even founders do not like to write documentation, right? Nobody likes to sit there in Google Docs and write lots of documentations. And fortunately, because I’ve been around for a lot of years, I actually have a lot of templates that I give to them. I say, you know, sometimes I’ll give them existing specifications, and I’ll say, “Okay, here is the format it should be in. Here’s some sample use cases. Just tailor this to your needs.” Right? So, almost every system has to have user registrations. Users have to be able to sign up, change their password, have certain permissions, et cetera. A lot of the startups have to have some sort of payments integration with things like Stripe or Plaid or Venmo or PayPal, whatever. So, they can use my pre-existing documentation to kind of tailor things. A lot of startups have to have some kind of alerting or notification system. What I’m mainly interested in is workflow, right? What should the developers be doing? How does somebody navigate through the whole product? So, sometimes the developer, the owners just do not write the documentation, but they’ll have very, very comprehensive wireframes and the workflow on something like Sketch or Figma. And then from that, I could actually take that and write the technical specifications. So, when I write the technical specifications, I’ll say, “Okay, this is the way this service should operate. Here’s the API. Here’s some suggested data models or class diagrams for this service. We’ll do a little bit of eventstorming, right? So, here’s the events that should get generated from this. Here’s the other services that these events should be communicating with.” So, given some kind of either complete workflow or documentation, I’ll be able to then go and create the technical architecture and the technical documentation and specs that I can give to the developers. The more you give to the developers, the less you leave up to chance, right? You don’t have to be worried that a dev shop is gonna come back with something totally inappropriate.
Kovid Batra: Makes sense. Let’s talk about something that is very important, and I think critical also in a way at the initial foundation-level of a startup itself which is around the culture, like engineering culture that is there. Do you involve yourself to that extent where you try to build the right culture for a startup at that early stage?
Marc Adler: All right. Well, for the startups, since I usually use remote development shops, I will always talk to the owners and the managers of those development shops to make sure that they are the ones who are promoting the correct culture, right? It’s not like when I’m CTO at a large company that has my own developers, where I do try to promote a very good engineering culture with continuous education and lunch & learns, and sending people to conferences, things like that, and getting guest speakers to come in. When I’m with a startup and I’m using a remote development team, I will make sure that the development shops are promoting a good development environment, you know, the same kind of principles, continuous learning, things like that. And so far, a lot of the dev shops that I use will do that. They have really great cultures. Some of the ones that I’ve used in the ex-Soviet Union countries, they send me videos of parties that they have and outings that they have, and they are bringing in guest speakers. And so, I’m quite confident that they’re showing love to their developers.
Kovid Batra: Yeah, that is taken care of that way. Perfect.
Marc, I am really amazed with the kind of experience you have had, working with MNCs and then working with startups. So, this is quite a diverse experience. But, do you see in last 30 years or 20 years of your experience, some patterns which make you feel that these are one of the biggest challenges of engineering teams and these should be changing how the world perceives, or I should say, the engineering world perceives few things to be done in a certain way, but those are not in the right direction? Some counter thoughts, some anti-patterns that you see could be the real patterns, actually.
Marc Adler: Yeah. So, I’ve seen moves to complexity and back, right? So, I see that there are developers who hang on the words of certain tech industry acolytes. So people who like, for instance, the whole move to microservices; and I’m a fan of microservices if done right. But, I just saw when microservices were introduced, everybody made a mad rush into microservices without realizing what the complexities are. And now, there’s this whole movement to unwind those and go back to the monoliths, right? Same thing with Kubernetes, which seemed to be the flavor of the month for a long time, but people got into a lot of problems with actually administrating Kubernetes. So, I think that one of the things that I’ve seen is just new technologies being introduced and people just rushing to them. And, as I mentioned to you before, resume-oriented development, right? So, you know, it’s funny, my wife, she was a developer from long back, she worked for some of the big New York financial institutions. She used to work in a system called CICS, which basically ran the entire world. I don’t think it’s really used anymore; maybe it’s legacy now. But, she made an interesting comment. She said, “Marc, everything that you’ve been doing for the past 20 years, CICS did back in the 1980s. And everybody’s just trying to reinvent that stuff.” And so, one of the things, one of the anti-patterns that I’ve seen, again, is just is taking something that should be simple and rushing to introduce more and more complexity. And, for the startup founders, that’s a real concern because whatever a startup founder gets back as a product from a development company should be maintainable. It shouldn’t be written in some esoteric language that it’s very hard to find development resources for. It shouldn’t be using infrastructure up on AWS that is extremely expensive.
Applying my past experience to my startups, I think one of the things I want to make sure is that stuff is built as simply as possible to do the job, right? That people should not be following the word of one tech acolyte or another and rushing into a technology that might not be appropriate for a startup.
Kovid Batra: That makes sense. I think that’s very interesting to hear. And, it’s common, like a new technology comes in and people think that this is the best way to go forward, not much of analysis is done on how the business vision looks like or what the business needs and you just go out implementing what’s trending right there. So, it makes a lot of sense what you say.
Great! I think that was an interesting topic to touch on. Now, one last thing, and then we will wrap up. When you’re working with these teams, we touched on the cultural aspect, but then, how do you as a fractional CTO, make sure that these teams are being efficient, like they’re producing what they really need to, and what are those success criteria that you put forward to the team, to the developers that, okay, this is something that you need to look forward to?
Marc Adler: Okay. So, I do things the old-fashioned way. And that is, I will have Jira boards, I will have sprints, I’ll have a Project Manager tracking velocity, things like that. And, I just get a general sense. Because I’m working with smaller teams, I kind of have in my head where the developers are at. Sometimes I will put myself on pull requests and I’ll look at the code, and I’ll get a general sense of where developers are at, if there’s developers that are giving me any trouble, if there’s developers who are billing eight hours, but it only looks like they’ve worked for one hour, right? So, I’m very good at detecting that kind of stuff, which my startup founders do appreciate. But, I would just say it’s the old-fashioned way of actually maintaining close touch with the developers and the PMs, knowing where things are, looking at code, seeing where we’re tracking against timelines. And that way, I’ll know if a team is efficient or not.
Kovid Batra: Can you just tell us those small tips and tricks that you really apply? When you say that somebody’s working eight hours, showing eight hours, but actually working one hour. So, how does that work out?
Marc Adler: I know that lines of code is usually not a great measurement, but you could see if somebody did a check-in and they changed two lines of code in an ‘if’ statement and they billed eight hours, you know that. Yeah, maybe there was some debugging time involved to find something, but, yeah, you could usually tell. It’s just a built-in sense that I’ve developed working with hundreds and hundreds of developers and being, as I said, being a coder myself, you just know when something doesn’t take that long, but it’s being, it’s being billed. And, you know, one of the interesting things that I do is, with my founders, when I’ll help them go over the monthly bills from the remote development shops and I’ll say, “Hmm, this isn’t right. Let’s get the owner or VP of the development shop on a call. And have them, you know, say, hey, why did this take eight hours when it’s a, you know, it looks like it’s a one-hour change?” So, and then, more often than not, my founders will get a little bit of a credit from the development company, which a startup always appreciates.
Kovid Batra: I’m sure all your clients are loving you for all the money saving and the right technical strategy being implemented from early on.
Marc Adler: Yeah. Well, the interesting thing is with ChatGPT and all these large language models, it’s going to be really easy to write substantial blocks of code in no time.
Kovid Batra: Yeah.
Marc Adler: And so, it’s going to be interesting to see where developers start using ChatGPT or a large language model to write entire classes or entire apps. And then, seeing them bill a lot of time for that to ChatGPT. Basically the whole thing.
Kovid Batra: But, I’m sure like after GitHub Copilot, things have changed already. Like, a lot of people are using it. Every person to whom I’m talking to, like earlier they were using ChatGPT, and now they have completely shifted to GitHub Copilot while writing code. So, do you see that adoption happening? And like, do you prefer that happening?
Marc Adler: Yeah. Well, this kind of goes back to my prior comment about developers not paying attention to efficiency anymore and not knowing if their code is taking up more nanoseconds than it should. I think you’re going to get the next generation of that with ChatGPT, that these large language models, Copilot or whatever are going to be generating large blocks of code, but no one’s going to understand the logic behind it and the architecture. And, you’re not going to know if ChatGPT or the Copilot generated blocks of code, which are not efficient, right? Because you know, it’s the nature of it, right? You have to really take a close look at that code that’s being generated.
Kovid Batra: Makes sense. All right, Marc, that brings us to the end of this show. Lovely having this conversation with you.
Before leaving, any parting advice for the technical founders, the non-technical founders? Your success mantra, maybe?
Marc Adler: Well, I would just say that a non-technical founder should always have a senior technical person by their side. Never just trust throwing stuff over the wall to a development shop.
Kovid Batra: All right, Marc, it was really nice talking to you.
Marc Adler: Thank you.
In the latest episode of ‘Beyond the Code’, Host Kovid Batra engages in a thought-provoking discussion with Alexandre Goedert, Head of Technology at Thoughtworks and a former contributor to SecondFloor and GVT. The heart of their conversation revolves around ‘Building Autonomous Dev Teams’.
The podcast starts with a fireside chat with Alexandre, providing us with a glimpse into his personal journey. As the conversation progresses, he takes a deeper dive into his team collaboration practices and defines what constitutes 'Good software' for engineering teams. Further, he also highlights the pivotal role of large-scale CI/CD, fostering the autonomous mindset and crucial aspect of ensuring a positive developer experience within teams.
Alexandre concludes by offering parting advice to the audience, emphasizing the importance of connecting to business value and fostering a collaborative team environment.
Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. And today with us, we have an interesting, amazing guest with us who is a curious, passionate technology soul. He has 20+ years of engineering and leadership experience. He’s currently serving as Head of Technology at ThoughtWorks.
Welcome to the show, Alex. Great to have you here.
Alexandre Goedert: Hi. Great to be here. Thank you for the invitation, Kovid.
Kovid Batra: Pleasure. Pleasure. So, Alex, we’ll start with a quick fireside chat where we would love to know more about you outside of work, all right? And here, you have to be, like totally honest and tell us whatever you feel, okay?
Alexandre Goedert: Sure! Let’s do it.
Kovid Batra: All right. All right. So I’ll, I’ll start with a very simple question. How do you start or kickstart your power-packed day? And how do you love to end it?
Alexandre Goedert: Yeah, sure. I’m pretty much a morning person. So I really need to wake up early and try to do some kind of routine. Otherwise, my day is not very productive, right? So, I try to wake up around six, sometimes it’s a bit tricky to not hit the snooze button, but I think I succeed most of the time. And, one thing I like to do at least during weekdays, I do at least 10 minutes of meditation and I try to exercise from 15 minutes to one hour, but depends a lot on how busy my schedule is, right? I try to alternate between yoga, running, and functional exercises. That’s pretty much it. So, I try to do it at least on weekdays.
Kovid Batra: And, let’s say it’s a, like full power-packed day for you and you’re coming back. How do you unwind? How do you love to end the day then?
Alexandre Goedert: Yeah. For me, usually at the end of the day, I’m more tired and I have a son, so I try to keep time with my family. I try to block my agenda. I think in most of the cases, I can do that. And, I think one of the things I enjoy doing nowadays is as I’m living in the Netherlands and I’m studying Dutch, I try to watch news in the local language. I think that’s a way to also do some like a lightweight study at the evening. Yeah.
Kovid Batra: Perfect. Perfect. All right. Let’s move on to something more deep probably, and you can take a minute to think about it and tell us. Those three things that define Alex, like you have three words that define you.
Alexandre Goedert: Yeah, that’s a good question. I think probably the first one I took this StrengthsFinder test some years ago and the first strength that I have is called achiever. And, I would connect that to like I’m a passionate person to try and deliver new things when I’m working. So, I think that’s probably one of the objectives I can think about. I consider myself also a curious person. I think I started on this career because I was just curious to understand how a programming language works. And, what we could do with them back in the day.
So, yeah, problem solving and curiosity, I think it’s also part of who I am. And the last one is, like, I really like to collaborate with other folks to, to achieve solutions together. So that’s, I think me in a nutshell.
Kovid Batra: Perfect. The last one that you’ve said, like you, you love to collaborate with people. I think this is a very good quality to have, right? And, if it comes innately and if you really believe in it, that’s super amazing because that way, you are able to create even more impact than you could do individually, right?
I just want to understand what do you think actually inspires you to be more collaborative? What drives that thing in you that makes you so collaborative with people?
Alexandre Goedert: Yeah. I think it’s since I started developing software. So nowadays, I cannot be in touch with code as I used to be, but I remember when I was starting to code, it was amazing to me that the things that you could do when you started working in your team structure, in your relationships and communication lines.
So for me, the journey was like from a developer, I became a tech lead and I had to balance these activities of writing code, being with clients in meetings, talking about architecture, talking about.. And also, doing some coaching and mentoring of team members. So, I think that’s, for me, a big motivation is okay, how can we develop software in a better way? And, I think part of it, it’s through communication and relationship within your team.
Kovid Batra: Makes sense. All right, moving on to something related to book reading, I’m sure you must be doing that. Just tell us about the latest book that you’re reading and share some learnings from that.
Alexandre Goedert: Sure. The book I’m reading at the moment is called, ‘Find Your Red Thread’ by Tamsen Webster. And, this book actually I gained in a conference that I presented last year. It was sitting in my shelf for quite some time and I picked up recently. So the author is, she used to work as a TEDx idea strategist. So, she was essentially responsible for selecting multiple TED talk ideas, right? And there was a lot of competencies. So, she came up with this structured way to select the best talks. And, I think why it’s relevant to me nowadays is that I’m spending a lot of time trying to build proposals for new clients, and sometimes when I join a client engagement, I have to set up the foundation of this new client account. And, I think it has a lot to do on how you communicate your story in a way that is compelling to the other person. And so, it’s a very interesting book from this angle. So yeah, I’m finding it very interesting.
Kovid Batra: Nice. I think that’s, that’s really interesting. Never thought somebody would be planning what talks to have on TEDx. So, I think that really requires a deep thinking and connecting with the audience. Yeah.
Amazing. All right. I think that was knowing you and it was pretty amazing. I would love to move to the next section, which is talking about your experiences, your success, failures, how you work with your teams. So, are you ready for the main section? Let’s get started?
Alexandre Goedert: Sure. Let’s start.
Kovid Batra: Perfect. My first question is how do you currently work with your teams? Just talk about some of the practices that you follow, and what do you think you are trying to achieve in terms of operating in the most ideal way. So, just talk about something, how you operate right now and how you would want to operate ideally with those teams.
Alexandre Goedert: Yeah. Yeah, it’s a good question. I mean as I mentioned, I like to collaborate with other people. And, also in the StrengthsFinder, I have this “relator” attribute. So I enjoy doing that, but it’s not always easy, right?
So, as a work I’m doing now, the role is called Head of Technology, but in practice, as I work in a new market within ThoughtWorks, I have to do a lot of work with demand that is related to technical sales, but it’s also related to how we implement in the region, the technical, or the technology strategy from ThoughtWorks Global. So, for me, the interesting part is that how we articulate that strategy into action with different people. So, the way I prefer to do it is like, we have a group that we call Tech Council. And, we have representatives of different specialties. And, we try to come up with agreements on what is more important. So, a lot of times what I try to do is like, drive this group to actually prioritize together. I think you need to give up some structure because otherwise it’s just, it takes a lot of time. But, I don’t try to solve everything by myself as well. So, I try to give some structure and let also the thinking flow a little bit. And of course, you need to sometimes take decisions on, okay, we should go to this side, or we should pivot. But, that’s pretty much how I like to work with my teams and of course, we have people with different seniority, so, sometimes you have to support a little bit one person or the other.
Kovid Batra: I have a question here.
Alexandre Goedert: Yeah, sure.
Kovid Batra: So, this team, first of all, I didn’t catch the name of the team. You call it the?
Alexandre Goedert: We call it the Tech Council, Technology Council.
Kovid Batra: Okay, Technology Council. What’s the purpose of having this team in place? Like, for you as a Head of Technology, translating, let’s say, the business strategy into a technical strategy and then execution is something that you want to do, but how does this team actually help you in doing that? I just wanted to understand because I’m just listening to this term for the first time. So..
Alexandre Goedert: Yeah, sure. I think for me, the main benefit is to have people that can challenge my own ideas and perceptions, right? I have a lot of experience in this market. But, I’m not a technical specialist in some areas nowadays. I think technology has changed a lot, and nowadays, it’s very hard if you’re a generalist to actually know some specific things about, let’s say, IoT, data and AI, machine learning, you know? So, I use this group as my source of information and critical thinking about different tech trends. Yeah. So, I cannot do all by myself.
Kovid Batra: Amazing. I think this is a very good thought, and this really helps in making much better decisions that you could be taking individually. So, it makes sense. Perfect.
Alexandre Goedert: Yeah.
Kovid Batra: All right. Yeah, please, please go on. Yeah.
Alexandre Goedert: No, exactly. So, I try to use this thing as much as possible. It’s a lot to do with, like creating the structure for a conversation, having the conversation, taking decisions during the sessions, and then helping to draw a conclusion at the end and next steps, right? So, for us, it’s really important to know what we are investing in terms of technology strategy and how we can meet this sweet spot because we need to sell things that the client wants, that our thoughtworkers want to work with, right? And things that we can actually have the capacity to deliver.
So, I think the work is actually finding the sweet spot and taking decisions every now and then to adjust.
Kovid Batra: Makes sense. Perfect. So while you’re working with your teams and making these decisions and then operating, do you feel that there is something that you could do better? Do you feel anything missing right now which you’re not able to do, or maybe you’re trying to do right now, but some realities, some ground realities stop you from doing that and you’re finding your ways out?
Alexandre Goedert: Yeah, yeah. I think always, right? But in my case specifically, as I work for usually new markets within ThoughtWorks, it’s always a very constant stretch between working with demand and pre-sales pursuits and looking inside ThoughtWorks from an engineering point of view. This is normal because new markets in ThoughtWorks, they’re kind of an internal startup. So, it’s part of the work, but doesn’t mean it’s easy. Right? So, I think a lot of effort is also to try to balance these things. And, it means having to drop a lot of plates sometimes. But, yeah, I think that’s something that’s, it’s always a struggle.
Kovid Batra: Yeah, absolutely. But, I think the balance is the key. Like, you always try to strive for that. Makes sense. Perfect. Perfect.
All right. I remember our last conversation, like when we were talking about having this podcast together, you told me, “Kovid, people just need good software and that’s enough to run something.” And, I was intrigued by this thought, but I could not relate to a situation where this philosophy exactly fits.
So, I just wanted to, like go back to that thought and understand more from you. Like, from what context it is coming, in which situation this philosophy applies, or it is generally applicable in every scale of company, be it like the scale of ThoughtWorks or be it a startup of 20, 30, 50 folks?
Alexandre Goedert: Yeah, sure. I think the point is, like, what good software means, right? And, if you talk to different people, they have different definitions. And usually, it’s the case that technical people, they know better. And, this reasoning doesn’t come out of the team. So, we have this classic misconception of people want to start with a new team and deliver fast into production without investing in good engineering practices and having a solid foundation, right? So, because what you want to achieve at the end, you want to have a software that is easy to evolve. So, to consider nowadays, business is changing faster than ever. So, I think after the pandemic and with all this recession.
Kovid Batra: Definitely.
Alexandre Goedert: Yeah. Together with the fact that technology basis is very accelerated. So, we can only make a good usage of the client’s money, if you build software that is adaptable. So, we need to be very conscious about what good looks like in this scenario, right?
Kovid Batra: Yeah.
Alexandre Goedert: So, for example, we cannot afford accumulating tech debt since the beginning and we need to expose that. So, what’s the shortcuts we’re taking? What is the consequence of taking some bad decisions in code? So, the problem is that you need to invest some more time initially to make able to make easy changes later in the software. And, some people take the shortcut to deliver fast initially and after some time, it just stalls, right? So, I think it’s a lot about that. So, to define that from the start and make the team with proper autonomy to fight for it, to explain what good looks like to the external stakeholders.
Kovid Batra: Yeah. I think now, I think I relate a little bit. In one of my podcasts with Serdar Mustafa, I think he mentioned, “It should not be a Minimum Viable Product, it should be a Minimum Lovable Product.” So, when you have that mindset of building a Minimum Lovable Product, you would definitely consider building the software also to a certain standard that doesn’t.. I mean, of course it has to cater to a customer’s requirement and the person should love it at the very first stage, but also, it should not be a tech burden for the coming months or the coming years when you’re operating on that. So yeah, it makes sense.
The next thing that I would love to know from you is that this topic is quite hot in the DevOps from quite some time now, but still, how important do you think for a company like ThoughtWorks or at that scale, a continuous integration and delivery, deployment is important? And, how do you think it should be done at that scale?
Alexandre Goedert: Yeah, I mean, it’s something that we like pretty much inside ThoughtWorks, right, since we started to work with the agile movement when we used cruise control that was on the first CI servers back in the day. So I think the discipline of keeping your build in a healthy state and your artifacts always ready to be shipped, I think it brings many benefits. So, if you do it right, there is no concept of works in my machine problem. So, you get consistency across environments. There is also no obscure script that you need to execute and then only some senior folks know how to do it, right? So, you deploy, your deploy is automated and it can also be audited.
There’s also a good way to recover from failure. So, or even if you use techniques like Canary Release. So, I think in a way, you can give the autonomy for the team to deliver instant value and even multiple, multiple times per day, right? So, for us, it’s really one of our core practices. And I think one very interesting way that we try to apply it is, like when we start a new team, the first iteration, we call ‘iteration zero’ and it’s really what would a ‘hello world’ for this team context would mean in production. And, we start by building the path to production from a CI perspective, right? So after that, your first story, it’s automatically deployed in production. So, I think it’s a mindset that is very important if you want to be really adaptable as a software team.
Kovid Batra: But, I think what we have usually seen is, I mean, it’s right that you have to build that frame of mind in the teams to actually move on to this process and this kind of ideology. But, there are a lot of challenges like they’re innately, people are not in for it. Why do you think is, is that there, like with developers, with teams? It exists, I’ve seen that. What do you think is the reason? How should one work on that?
Alexandre Goedert: It’s interesting, right? Because what I’ve seen also in, if you talk about DevOps as a culture or a mindset, in many companies you see nowadays that platform engineering is all the rage and the way some people implement is by having these layered teams, in the sense that you have all the expertise about DevOps inside one team. And then, you have the consumers that only know how to consume that, but they don’t have the knowledge of built themselves. So, if any clients that we work with, we try to say, okay, you know, “Platform team, you should build services that should be composable and owned by the external team.”
So, for example, if we’re building a development pipeline, I can maybe build some libraries that I can connect to build stages in my CI, but I never should build the pipeline myself for the other team. The team should own that, and they should know how to build that from scratch. I just build accelerators, right? And try to build some conventions around what’s good. So, for me, that’s something that we see in many clients. And, they see, okay, I have a platform engineering team, but I still need help with DevOps. And usually, that’s the case. So, usually, you don’t have a multidisciplinary team where actually people own the full deployment process, right?
Kovid Batra: Yeah. Perfect. All right. I think moving on to something which you just talked about, like you should allow the teams to do it themselves. You should work as an accelerator there. So, this is more around giving them autonomy. So, how do you think we can bring this autonomy mindset or how do you think we can improve this autonomy in the teams and inspire them to probably deliver more? Because when people are autonomous, I’m sure they move faster. They feel more accountable. There is more value delivered in that scenario.
Alexandre Goedert: Yup.
Kovid Batra: So, how do you do that? Or how do you recommend to do that with different teams?
Alexandre Goedert: Yeah. Yeah, sure. I think CI/CD is actually a mean to an end, right? So, when we talk about autonomy, I think what something that is very important in delivery teams is to connect the software delivery process with the business to start. And, it seems obvious, right? But in many places, you have this multiple layers of teams, people, and processes that are sitting between the software is deployed and the actual value that you have from a business perspective, right?
So, I still remember when I once back in the day, I had to develop a fancy 3D visualizer for market data used for financial instruments.
Kovid Batra: Okay.
Alexandre Goedert: And, we had a BA that tried to capture the requirement from the user. And then, it was our proxy to the business. Past it was, we took one month to develop some beautiful 3D charts. At the end, the client said, “Okay, it looks beautiful, but actually, it’s useless for us from a business perspective.” Right? So, I think that’s the first thing. So, you need to.. Many people have POs nowadays, but I mean, is the PO really a representative of the business? Do you really have autonomy of pivoting your backlog if you’re required to, right? So, I think that’s the first step.
And, I think people should start having observability for business metrics as well. So, what are the KPIs that are lagging or leading that indicate that what you’re developing is making an impact, right? So, if I talk about e-commerce, for example, you might think about a conversion rate for a sales pipeline. So, what is the conversion rate after I do every release of my product? What’s the impact of the conversion rate in the total revenue of the company? There’s a correlation or not? And, the developers should try to explain that. So, I think that’s the starting point. And then, if you have that combined with automation and a good software process.
Kovid Batra: Yeah. Got it.
Alexandre Goedert: You can achieve real, real autonomy. Yeah.
Kovid Batra: I think this is a very, very interesting point. This goes long way actually. If people have clarity on the impact that they’re gonna create, their brain starts working in a very different manner than if you just tell them, “Okay, do this piece.” Like, accountability kicks in, your curiosity starts popping up, right? You tend to think of ideas that could actually get things done, and you become more agile also because you know that you want to achieve this. If something is defined and it’s not working out, you are seeing it in real time, you are quickly adapting to something else, which could really work out according to you. So, I think that’s a very interesting point where autonomy can be built by bringing that visibility of the business metrics.
From the point of business metrics, I think, for sales teams, for support teams, there are always some KPIs defined, people are looking at it. If you go to the juniormost salesperson to the Head of Sales, everyone knows that, okay, they need to work on the revenue or they need to close this client, which would bring so many dollars, right? With engineering teams, I feel, there is a little bit of a gap. I’m not sure how you think about it. So, I would love to know your opinion on how you define success for an engineering team and how you measure it, how you find inefficiencies there and then try to improve on those right?
So, I hope I made my question clear there.
Alexandre Goedert: Yeah. Yeah. Is it clear? Yeah, it’s clear pretty much. So, I think that the problem is that developing software is expensive, right? So, it is even more so if you need to break your system every now and then to add new features and that unfortunately happens very often, right? But, that’s no wonder that many different corporate departments, they just want to know how IT is performing as a whole, right? So, there’s a lot of pressure over CTOs and these kinds of roles. So, sometimes it’s quite a difficult conversation for non-technical people when engineers, they have to constantly excuse themselves for a perceived bad performance, right? So, it’s the perception that IT is always lagging behind. So, I think the problem is that we need to explain these technical reasons in a way that people can actually relate to them.
So, before actually measuring, I prefer to start optimizing the flow and capturing the metric, what a normal metric looks like. So, we always have this problem of business coming up with estimates and people have to say, “Okay, I think it’s nice.” But, no, no one knows at the end, right? So, what we prefer to do, at least at ThoughtWorks with our clients is, let’s start the first iteration. We optimize the flow to a minimum level, and we try to see what our base is, what’s our throughput after a couple of iterations. And then, let’s start to measure those things, right? So, how many cards we have for iteration. Usually, one thing that we also try to cover is DORA’s four key metrics. So, okay, what’s our lead time from idea in the backlog until deployment? What is our time after the commitment to the deployment? What’s the change failure percentage? So these, these things we, we try to measure together with the throughput, and then we try to interpret what is happening after each iteration, right? So, sometimes you have a lot of outliers. So, maybe you have one card that it was too big and was poorly captured. And, this thing is dragging your lead time as an average, right?
So, I think what you need to create is this habit of normalizing what are the metrics for different teams, acknowledge that each team is different, and then try to use that as first signals, but then interpreting what reality looks like after each iteration, right?
Kovid Batra: Yeah.
Alexandre Goedert: So, I think it’s very dangerous sometimes when people try to come up with metrics from outside because in other departments, I mean, if you talk about sales, it’s pretty easy to have a target, like, okay, what amount of leads we have and how much leads are converting, and what’s the revenue that we have projected, right?
Kovid Batra: Yeah.
Alexandre Goedert: In software, it’s a bit harder than that. So, we need to create ways to communicate, a sense of performance, but that’s not all. We need to always interpret them and explain to the outside non-technical audience in an easier way.
Kovid Batra: I think just to add onto this, I feel we measure velocity, the quality, throughput, and then we have these DORA metrics to enable us to measure that. What I feel is that this is very critical. So, it’s like engineering is a function which is always enabling the whole business. Like, depending on the nature of the business, the percentage would vary. But, at the end of the day, if I look at a product team and an engineering team, I mean, they should not be looked at separately. I feel they should be one unit, because at the end of the day, what product is going to deliver cannot be accomplished without having that feature or a release in place, right? So, for an engineering team and for a product team, the metrics they need to actually look at to create that impact should be same, like it could be something as simple as user satisfaction, right? Like, after every release, how the satisfaction of the user is growing, let’s say, if it is aligned with that particular metric. And, let’s say, if that is not working out and you’re not seeing the impact there, then when you deep dive and try to understand what could be the reason behind it, is it the bad user research or is it the bad quality of the software that we are producing here? And then, comes the point where you say, “Okay, quality is bad.” Then you jump into those metrics and then look at it.
Alexandre Goedert: So, I think a combination of these business and technical metrics, as you mentioned, yeah. Yeah.
Kovid Batra: Yeah. I think that makes sense. It was really an interesting point there. And, lastly to conclude on a point here. I mean, I just wanted to understand it from you. When you look at the throughput of the teams or how they’re doing velocity-wise and everything, I’m sure there are certain cultural practices that you are ensuring to have a good developer experience also, where you take care of the developers, where you take care of their well-being. So, just wanted to understand, how you ensure in your teams that a good developer experience is there, and…
Alexandre Goedert: Yeah, yeah. Yeah, I think that is a very good point. I was a bit not skeptical, but I, I didn’t believe, for example, in pair programming as something to use constantly before I joined ThoughtsWorks. And, I was amazed to see that we actually use it quite a lot and so this is 1 of the things, right? So usually inside a team, I mean, staffing for technical teams is very complex, at least inside our company, right? So, you need to find this right combination of people that it’s a benefit if they can work together or not. And then, there are also people, so maybe they don’t get along with each other. There are many variables. So, what I like about pair programming is that it enables you to usually level up the team according to technical expertise, according to the one person that knows best about a particular tech stack, for example. You should do a proper rotation in pairs. It could be after one week, after one iteration, after a couple of days, depends on the team. But in my experience, it helps a lot to create this sense of support. And you know that you are not alone, that you can count with other people, right?
We also like to have these sessions we call ‘Dev Huddles’, usually on a weekly basis. And, I think it’s important for new teams. So, if you need to take an architectural decision, you’re not quite sure, you can have this huddle to actually talk with the team and maybe you capture a decision as an architectural decision record at the end. It also helps to create that sense of, okay, it’s a collective ownership of the code base, right? You should read the code base, you shouldn’t know which person wrote each part. It, it should be a collective like standard. So, I think these practices help a lot to achieve that.
Kovid Batra: A lot, yeah. I think that is a very good example actually. And regarding pair programming, I have been hearing both sides, but, if I have to, like personally, go for this opinion, it really works, I feel so.
Alexandre Goedert: No, and to be honest, I mean, I don’t think it’s something to do all the time. For example, there are certain tasks that are quite mechanical. Maybe some of them you can automate with AI nowadays, but still, if you don’t need to think a lot critically to write the code, maybe you should just do it yourself.
Kovid Batra: Yeah, yeah.
Alexandre Goedert: At the end of the day, as Martin Fowler used to say, right? “Our limits in velocity is not dictated by the speed on which we can type in the keyboard, it’s by the speed of thought.” So usually, if we have two people, they work faster.
Kovid Batra: Yeah. Makes sense. Perfect.
I think to sum up this point, I feel looking at a lot of aspects of an engineering team is very important. So, just to like, put out loud these DORA metrics are important. Developer experience, the processes that are built around having a good developer experience are very important. So, probably product and engineering can have similar goals, but when it comes to the KPIs or on daily or weekly or sprint level, you have to look at how people are doing or efficiency-wise people are doing, maybe product has different metrics and engineering teams can have different metrics.
So ultimately, it is important probably to have that measurement in place, so that things remain on track. But yeah, I think it was really, really interesting to know those aspects from you, hearing those hands-on advice that you have just shared. So, thanks a lot for this, Alex. I really loved talking to you.
Alexandre Goedert: Thank you for the opportunity.
Kovid Batra: Great! All right. So with this, I think we’ll end our episode. Any parting advice for our audience?
Alexandre Goedert: Yeah. I mean, I think one of the things is like, try to get more ownership about what you deliver from a business perspective. Don’t think it’s normal to accept tech debt, try to correlate that with business and money value right? So, as technical people, we need to be able to explain what we do, even though we have to translate it. So yeah, my main advice is like optimize your flow first. Try to connect to business value and try to create a team environment that is good for everyone.
Kovid Batra: Perfect. Thank you so much.
Alexandre Goedert: Thank you.
Kovid Batra: All right. See you. Bye-bye.
Alexandre Goedert: See you. Bye-bye.
In the recent episode of Beyond the Code, Host Kovid Batra engages in an insightful conversation with William Mendes, SRE Manager at Feedzai and mentor at IFTL. He had previously contributed his expertise to well-reputed organizations including Accelera Technologies, FARFETCH, and FCamara. The central theme of the discussion revolves around Leadership, Management, and Engineering Metrics.
The podcast begins with a fun fireside chat with William, allowing the audience to see his candid side. Later in the main section, he explores the challenges faced as an SRE manager. He discusses the balance between metrics, including DORA metrics and Cycle time, and the need for direct communication. William also emphasizes psychological safety and shares strategies to prioritize and support developer experience and well-being.
Lastly, William offers valuable advice on seeking feedback from the team for personal and collective evolution.
Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with me, I have a really amazing guest. He’s a calm, composed person, yet a very passionate leader. He believes that leadership is for people, not for projects or tests. He’s currently an engineering manager at Feedzai. He has 10+ years of experience in engineering and management. He’s also a mentor at IFTL. Welcome to the show, William. Happy to have you here.
William Mendes: Thank you so much, Kovid. It’s a pleasure, man.
Kovid Batra: Pleasure is ours. All right, William. So, I have given a quick intro about you, but our audience would love to know you more. And for that, we have a quick fireside chat where we will ask you a few questions, and that would help us know you better. Are you ready for it?
William Mendes: Okay, of course. Let’s go.
Kovid Batra: All right. My first question. So, you have to be very honest, okay? Like, you have to tell what’s there, okay? So, what are you really passionate about? And it not necessarily has to be work, it can be outside of work also. So, tell us about your passion.
William Mendes: Okay. I am really passionate about evolution and performance, and I have a love for engines and improvements. So, right now this is translated into my biggest passion being motorcycle traveling and almost everything related to cars and motorcycles. And, and that’s it.
Kovid Batra: Nice! I think we have a bike rider on the show now.
William Mendes: Yes, you do!
Kovid Batra: All right. I, I mean, that’s really interesting. Tell us something about your first motorcycle trip. When did it happen and how was the experience for you and what made you, like really stick to it going forward?
William Mendes: Okay. My first big motorcycle trip was a trip to Picos de Europa in Spain.
Kovid Batra: Okay.
William Mendes: And, it was a completely immersive, exhilarating, and fulfilling experience. It’s something that you can’t describe, that you cannot feel unless you ride a motorcycle, that is being part of the environment, feeling everything, feeling the cold, feeling the weather, feeling the wind, and listening to everything. And, on top of it, having power, having control, and being on top of the situation. It’s amazing. It’s an amazing feeling.
Kovid Batra: That’s nice. So, how old were you when your first trip, motorcycle trip happened?
William Mendes: I was, uh, I started riding motorcycles when I was 13 years old. And, my first big trip was in Europe was 26.
Kovid Batra: 26, okay.
William Mendes: So, it took me a while to take the courage to do a big trip like this, riding for a long day.
Kovid Batra: So, you ride solo or is it like a gang, you go together? What is it like?
William Mendes: I had both experiences. Right now, I have been traveling with my wife a lot. So, those pictures in here, have me and her traveling around. We went to a lot of places and I think that being in a smaller group with people you can count on is the perfect environment and the perfect set for a motorcycle trip.
Kovid Batra: Nice, nice! Amazing, man.
All right. Next thing that I would love to know about you is how you get inspired, from where do you learn? So, yeah. What are you reading these days? Just tell us about your last read and some interesting lessons from there.
William Mendes: Okay. Right now I just closed the ‘Radical Candor’ by Kim Scott.
Kovid Batra: Okay.
William Mendes: And, it’s a very impressive book on leadership and how to be candid and clear with the people who work with you.
Kovid Batra: Okay.
William Mendes: And, still show them that you care and that you are working together on the same purpose and the goal. And, this is amazing, a very nice book.
On top of it, I try to have a very disciplined routine. I am usually reading two books at the same time, one in the morning related to leadership and one technical book in the afternoon. And, consuming a lot of podcasts, consuming a lot of content to stay on top of the topics that we’ll have to do.
Kovid Batra: That’s nice. I think you’re probably into that zone where you’re trying to understand what a true leader looks like. And, maybe that is something which you are pursuing in your career also. Is this the reason why you are reading these?
William Mendes: Yes, exactly. For me, it’s very important. So, when I started my career in leadership, it was not as fulfilling as I thought it would be. Actually, my first experience was frustrating. I was not prepared for that. I did not know how to be a good lead and how to deal with the people that I had below me or that I have with me on that journey.
So, I got back. I read an article from Charity Measures. Which is called the ‘Engineering Manager Pendulum’. And, I did the pendulum. I got back to an IC role. I started working on myself and trying to improve, to understand what went wrong and how to improve to be a better lead. And, by doing so, I developed a very interesting routine of topics to learn that would allow me to be a good engineer first, and then, a good lead for that engineer that I was making of myself. And with that, I had to fulfill that role.
Kovid Batra: This situation would have been very different, right? Like, moving to a leadership or a management position, and then going back to an IC, and then again, aspiring back to be one. I think, probably there is something that you realized in that phase, right?
William Mendes: Yes. First, for me, that is the feeling of being an engineer that is always with me. I am always curious. I’m always trying to be on the top of the technology that I am working with. Even though I am not fulfilling tasks anymore alone, the vast majority of the problems that I am solving, I am solving with my team and that they are involved with more technically with that. But, being on top of this guaranteed that I understand their pain, I understand their challenges, and how to help them move forward with this. And, by doing so, I can guarantee that everything that I have to be a good lead, to be a good leader, to understand the necessity, how to talk with them, how to understand their motivations, and to engage with them will be on the right place when I need it.
Kovid Batra: That’s amazing, William. I think this journey of learning and learning specifically when you have to change yourself from the core, because in the beginning, when you realize that you are not a good leader, I’m sure that would have been very disheartening also at that point, but..
William Mendes: Yes.
Kovid Batra: It’s good, like people like you are definitely the ones who have a real growth mindset and want to do something. They don’t feel the gap where they can’t do anything. So, I think this is really nice. Appreciate it. It was really nice knowing you through this fireside chat.
Now, I think we would love to move to the main section where we would like to talk about what you are currently doing, knowing about your experiences, your success and failures. So, I hope you’re ready for the main section.
William Mendes: Okay, let’s go for it.
Kovid Batra: Perfect. Perfect. So, let’s start with a very simple question, like, tell us about your current role, your responsibilities as an SRE manager at Feedzai. How does it look like?
William Mendes: Okay. So, the SRE team at Feedzai is the responsible team for the entire infrastructure and the health of our products. So, if a new customer signs a contract with us, my team will be responsible to set the proper environment for that customer to be working with us, to have all applications that they hire, and to have everything working as soon as we can. And, as soon as we have that customer working with us, my team will be responsible to redirect and guarantee that customer is having the best services that he has hired from our company throughout our infrastructure and platform. So, we have different projects, we have different capabilities and a lot of amazing people working with us around the clock. We have an amazing team completely distributed. We have people in Australia. We have people in China. We have people in Europe. And, we are talking about having a complete functional team solving everything that is needed to have a happy customer with our company.
Kovid Batra: What are the usual challenges that you see in your day-to-day role and responsibilities? Like, the top most ones, just tell us about that.
William Mendes: Okay. This type of team has a very specific need, which is you have to understand and work with context. You have to understand everything that the customer needs and everything that was sold to a customer, how to integrate that with the operation that you have running, and how to guarantee and communicate with the customer and with the other areas in the company to guarantee that satisfaction and that delivery.
Kovid Batra: Can you give us an example? Like, I think audience would be able to relate more, like any, any specific example that could explain any of that situation. Yeah.
William Mendes: Of course, of course. So, imagine that a customer signs with us, and for the vast majority of applications that we have, this customer requires us to use, specifically for them, a different type of database.
Kovid Batra: Okay.
William Mendes: And, even though we do not support the database on our infrastructure so far, neither our products have connectivity to it, neither something to support it, this customer would represent a very important customer to the company in the future. And, we have to work with that.
So, my team will be responsible to investigate and to help the product team adopt this new database, for example. And, it could be a database or a message queue or something like it that will integrate with our infrastructure and products to implement, to define a plan to understand how to keep it reliable, and to make it work with that customer in the future. So, we have to integrate the entire company working towards that environment, to understand their necessity and to help them understand until when we’re going to be able to provide that, how we’re going to do it, and why something would be or not be possible.
Kovid Batra: Right. Now, I get the point when you were saying that when you have to do something, the team has to have full context, any new piece of tech coming into place, any stack coming into place, whether it fits, doesn’t fit, what would be the feasibility; all those things can be answered well only if you have the complete context. So, I think now I relate to the point which you were saying. So, that’s cool. I think that makes the job challenging, but I feel it’s interesting at the same time, right?
William Mendes: Yes, very interesting, mainly because we have multiple sources of income for our work. So, we have inputs coming directly from our customers. We have inputs coming from the teams that develop our products, the company that requires something to be implemented for their perspective. And, we also have inputs coming from inside the team, something that we have to improve, something that was not working as expected. Therefore, it’s just moving pieces that we’ll have to integrate and make the work per se.
Kovid Batra: Makes sense. Makes sense. Totally. All right. I think this was a very good example to understand what your role, responsibility looks like and how challenging it could be at times. I think one thing you just mentioned in the fireside chat also, and like last time when we were talking about having this podcast, I had that sense that you really want to grow into that position of leadership also. So, being a manager for the site reliability engineering, at this point, what kind of metrics do you look at in the team, and how looking at those metrics defines the leadership that you would want to take up with the current scenario? I hope my question is clear, right?
William Mendes: Yes, it is. This is a very interesting question because, you know, being a good leader means that you have to take actions on top of something that you can measure. You cannot take actions based only on your opinion. And, this is a very interesting pitfall for the vast majority of leaders. Me, myself, when I started this work as a lead, I thought that I had the clear goal and idea and everything could be taken under my special opinion. But, without collecting metrics, you cannot lead properly, you cannot guide your team properly. So, thinking about the metrics that you can have, I will go back to the context principle when you have to understand which metrics fulfill the context of your team.
So, for example, for my team, we work both on projects and service requests, which means that for projects, I have to understand the cycle time, I have to understand when a task enters the board, when a task enters, when a project is defined, refined and enters on our work, and how long it takes to be completed and to have that tool, that feature provided for our customers. I also have to understand the number of changes, the deployments, the PRs that we are doing to maintain a customer happy, as I have to understand the failure rate and the mean time to resolution for everything that we are running. And, a lot of the things that we have comes from the perspective of understanding also the MTTF, the mean time to failure. So, if we saw that something that was not a solution, it was a mitigation, how long would it take to be failing again, so we can fix it properly, and to understand that, during the day to understand that, during the working hours, and during incidents. So, when an engineer from my team is called 2 a.m. after having a time off with his wife or his companion on a Friday, he doesn’t have to rely on his opinion or on his specific oral knowledge. We’ll have to set procedures and give them metrics to take those needed actions. So, is it better to mitigate a problem or to solve it properly at 2 a.m. on a Friday? This has to be calculated by the metrics that we have already collected.
Kovid Batra: Makes sense. I have talked to a lot of EMs and engineering leaders through this podcast and outside of this also. But, what I have felt is that most of the time they have this challenge where they say that the metrics don’t tell us the reality. Ultimately, we’ll have to go back and talk to people. So, how your experience has been in that sense, like, is it just the metric or you have something more to tell?
William Mendes: I only think that when we’re working with those types of metrics who have the truth on this, have three sides. You have the metric side, you have the team side, and you have a personal side to each person that is related to that, to the composition of that metric.
So, being a people manager, you have to give and to have your one-on-ones to understand the team, to understand the situation. And, there’s something that I really like to use that is the happiness metric, which provides me the health of my team. So, I understand which problems are appearing. I can use this metric to anticipate problems, to understand if the cycle time that I am measuring is actually true, or if we are moving tasks on the board just because we have to move them, you know,? And, if people are happy, are feeling fulfilled by the project that we are investing, and if the failures that we think we are solving between the team and the product or between the team itself are actually being solved or are just being mitigated and hidden under the carpets, you know?
Kovid Batra: Makes sense, makes sense. So, this was one thing, like where the leaders and the managers had their own resistance towards not completely relying on metrics. And, very well said, like it has three sides. It has the metric itself, it has the team’s perspective, and then, your personal perspective on things. So, a combination of this would give you a realistic picture. But, again, when these metrics are being implemented, it’s not just the manager or the leader who is taking a call and adopting to this situation; it’s the team also that has to like buy in and then, they have to, like be a part of that whole procedure and process, right?
William Mendes: That’s right.
Kovid Batra: I’m sure you would have implemented it at your company or previous companies you’ve worked for. So, how was your experience there? Tell us about that experience. And, how easy or difficult it was with the teams when you brought that in?
William Mendes: Okay. Man, it’s always hard to implement a metric that the team doesn’t believe should be there. So, if your team, for example, works with different input sources, you have to want to help them understand how that metric will help them move forward. So, why would they help you measure the cycle time or the MTTR or the failure rate, if this is not helping them achieve anything else? Are those metrics related to their improvement on the company? Do you have something to help tell the story on why that metric is being implemented? I really like that book from Simon Sinek, ‘The Golden Circle’, when you start thinking about the reason why you’re doing stuff before doing it.
Kovid Batra: Yeah.
William Mendes: So, if I try to implement something on my team, the first thing that I have to understand, imagine that I join a new team. And, first I have to understand how this team is doing, what are the dynamics that we have and where this team is failing. As soon as we have that, I try to have a retrospective or a session to build trust and to have the teams telling me which metric we should implement first, where are our first pains and how that metric will help us achieve something better in the future.
Kovid Batra: Definitely. I’ll just like to add on here. What I have seen is people take it, like the team members take it in a negative way also. Like, they think that we are monitoring and measuring when we are doing that. That perspective, you can’t just change suddenly. It has to be a cultural aspect of the team, probably where people feel that they are psychologically, they’re safe, basically. Psychological safety is an aspect where people are open to such things. They know that even if a metric or DORA metrics are being implemented, we are not being put out and in front, and everything is evaluated based on that. So, that kind of psychological safety has to be brought in through the leadership from the company culture. And, I think that in combination to what you said, like giving a purpose and giving that psychological safety together to the team might really bring in an easy implementation, at least in terms of adoption from the team perspective, I can say, that it would work out well. So, yeah.
William Mendes: That’s exactly it.
Kovid Batra: Yeah. Yeah.
William Mendes: And, it goes also with the purpose of the team. If the team doesn’t understand its purpose, how they are being better, or how they are helping the company, there are no metrics that will help them.
Kovid Batra: Right. Right. Makes sense. Perfect. All right. I think this was really interesting. One more thing you just touched upon is about the happiness metrics, and there is a new wave of developer experience, developer well-being also we can see coming in. So, how exactly do you take care of the developers, how you take care of their well-being in the team? Can you just deep dive into it and just give us a few examples, so that a few people can understand from here that, okay, these are some things that we need to implement?
William Mendes: Of course. So, it’s very interesting to start by measuring and understand the impact that you have on the team or on the person that you have working with you on the team by the amount of work that that person is doing. So, the happiness of a guy or a girl working in the team, it’s completely related to the amount of work that this person is requesting. So, for example, you may not know that you have a silo on your team, unless you start seeing that all merge requests related to a specific topic doesn’t go forward without the intervention of this specific person. And, this is not healthy, neither okay for the company, neither for that person.
Kovid Batra: Right.
William Mendes: By talking with that, we can understand and explore if this is a common and same problem. And, by measuring it, you can start measuring other stuff related to that. So, the amount of merge requests that are being stopped and taking longer to be reviewed, the amount of service requests that you have going to a single person, the amount of work that a specific person is needed, and how happy is that person with those specific topics.
Kovid Batra: This is a very good example. I think, how the flow of a developer work looks like, whether it is easy or not, I think that’s where it relates to. So, perfect. Cool.
Any other example you would like to share?
William Mendes: Of course. There’s one which is the relation that I think is very hard to have on those areas where you have multiple inputs; that is the link between services, so you can understand the difference between the productivity and the impact that the person, that the people on your team have on different areas. So, sometimes we are asking for people to work with cycle time and number of changes when they are actually providing prevention of issues from happening by giving us documents and by giving us guides and by having meetings with other people. So, understanding the metrics and how they link to each specific person and each specific needs of the team would be the perfect way to go in there.
Kovid Batra: Yeah. Yeah. Totally makes sense. Cool. Cool, William. I think this was really, really interesting. Most of the things that you have said look very promising and I would say, for a lot of teams, ideal to do. But, as you are doing it right now, do you still see some scope of improvement? Like, maybe more visibility on what’s going on in the team in terms of the inefficiencies or bottlenecks that you would want to have or something like where you would want to identify those areas where you can improve by adding more metrics, maybe, or maybe some processes or tools. Just if there is any progressive thought there?
William Mendes: This, having all those different, different metrics is very hard for us because we do not have, or it’s difficult to have it on a single tool. It’s difficult to use for the vast majority of us. We are using a specific tool to manage our daily work. So, we have boards on the tool. We have tasks going on that tool. And, actually, we cannot relate everything from different projects on that specific tool, neither use it to measure how the team is behaving without having third parties.
So, what I would say is going for a tool that could help me understand the health of my team and the work that has been done by this team would be the starting point to change the lives of the people that are working with me.
Kovid Batra: Makes sense. Makes sense. Cool. I think there are multiple tools like that in the market and these solutions are also improving and one should go out and look for those, but it’s a very good thought, like bringing everything into one place and bringing that holistic visibility would be really, really helpful.
Cool. I think this was a very interesting conversation. I would love to deep dive more on a lot of aspects, but in the interest of time, I think I’ll have to just stop here and I would ask you to give us some parting advice for the audience, like any success mantra that you would like to share from your life, from your work.
William Mendes: Yes. Always seek for feedback. The hardest ones that you will hear will be the ones that will make you go further and evolve the most. So, don’t be afraid to talk with your team. Don’t be afraid to talk with your colleagues. Don’t be afraid to talk with your bosses or the boss of your bosses. And, to understand how and what they think about you and how they think you should improve to keep working with them.
Kovid Batra: That’s a very good advice, I must say. Perfect, William. I think it was really nice meeting you, talking to you. Would love to have you again on one of our shows again.
William Mendes: It’s a pleasure. Come for me if you need anything.
Kovid Batra: Sure. All right, William. Have a nice day ahead. See you.
William Mendes: You too. Bye-bye.
Kovid Batra: Bye.
In the recent episode of ‘Beyond the Code’, Host Kovid Batra welcomes Harijs Deksnis, Director of Engineering at Giraffe360, with a rich background in organizations such as Passionate People, Philips, and more. He engages in a compelling discussion focused on the theme of moving ‘From To-dos to Kanbans to Scrums'.
The podcast starts with a fireside chat with Harijs, providing us with a glimpse into his personal journey. As the conversation progresses, he takes a deeper dive into navigating the scale-up journey and effectively dealing with high-performers during the scaling process. Further, he sheds light on the importance of 1-on-1 meetings and psychological strategies to manage team members. Harijs also imparts valuable wisdom on managing technical debt during the 0 to 1 and 1 to 10 stages.
Wrapping up, Harijs explains ways to identify burnout and emphasizes key priorities in establishing team goals.
Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. I am back with another episode and a really passionate and a growth-oriented engineering leader as a guest. He has 10+ years of experience in engineering leadership and management. He’s currently serving as a Director of Engineering at Giraffe360, and you can find him next at the DEVWorld Conference on 29th of February in Amsterdam, talking about the team design.
Pleasure to have you here, Harijs. Welcome to the show.
Harijs Deksnis: Hi, Kovid! Awesome. Yeah. Thank you for having me. Pleasure to be here.
Kovid Batra: Great! So, Harijs, before we start and deep dive into your experiences, challenges that you have seen while scaling startups, I think there is something that I want to know more about you. The audience wants to know more about you.
We have this quick fireside chat where we’ll be asking you some personal questions outside of work so that we know you better. Are you ready for that?
Harijs Deksnis: Yeah, of course.
Kovid Batra: All right, let’s get started. My first question. How do you unwind your day? What are your hobbies, passion outside of tech?
Harijs Deksnis: Yeah, I try to unwind by watching or listening something of my interest, sometimes reading. I do like chess a lot. Sometimes I watch some videos, do certain type of literature, but it can change and, there was a period was very eager into learning different languages, so I used to just listen to audio books in different languages. But yeah, that’s, it goes like in phases, some, some months you have more passion in one direction, and then it changes.
Kovid Batra: So, what are you reading these days? Like, is there anything going on?
Harijs Deksnis: Well, at the moment I currently have a phase I’m actually pretty interested in Vedic literature. So, I’ve been looking into Vedas more. Actually just recently read through Rig Veda. So, that’s sort of my current interest.
Kovid Batra: That’s nice. Being an Indian, I haven’t read that yet. And, I think that’s amazing to know that you are reading it. Any specific things that you came across while reading the Vedas?
Harijs Deksnis: Well, it’s, it’s, it’s a collection, a huge collection of different hymns and it’s very poetic language. You don’t really read it as a prose, but there’s something behind the words that you just feel it, that it’s quite inspiring. So the very process of reading itself is a very uplifting experience.
Kovid Batra: That’s nice. Amazing. That’s a very, very different choice, actually.
Harijs Deksnis: Well, it serves well as unwinding after a long day of work and meetings and a lot of information handling. So, you read it not for the sake of, you know, comprehending information and perceiving every word, but you just read it for the feeling, for the switch of context and, uh, before bed, it’s, yeah, it’s very blissful.
Kovid Batra: I see. Well, that’s, that’s interesting.
Moving on to our next question. Well, we all are techies, so I just can’t skip this question. I just want to know, like, how was your first encounter with technology, with computers?
Harijs Deksnis: Yeah. Well, if we talk about desktop computer, I think my father brought one home in around ’96 from his office, so, I believe, of course, it was Windows 95, and yeah, we just spent the evening playing with Paint and Microsoft Word Clipart and Minesweeper. Uh, so that was the very first computer.
Kovid Batra: So, is that the time when you really fell in love with computers? Or it was just a thing you had at that time?
Harijs Deksnis: That was an insufficient experience to fall in love with. I was always passionate about technology, you know, playing the NES video game console, that sort of things. But I really, I gravitated towards computers when we got the first computer at home. It was like a year or two later, and then I just loved going through all the settings in the control panel and just figuring everything out. I’ll start making my first website by saving a word document as HTML files. And, you know, there were links to other pages. So, it’s super static, made in word, but yeah, that was my first attempt to make a website.
And then I thought, “Oh yeah, this is something I really enjoy doing.” Creating these experiences and links, you know, hyperlinks, jumping to one content to another.
Kovid Batra: Nice, nice. All right. That’s amazing. Moving on to the next thing. I think this is very important for all the audience to know, and I am being very curious here. I asked this to almost all the guests, what’s their success for mantra in life.
Harijs Deksnis: Yeah. Yeah. I resonate with the saying “I didn’t come this far to only come this far.” I really like that one. It’s acknowledging that there’s always a next mountain to be conquered after you’ve done something. And yeah, to never give up, stay persistent, and never settle.
Kovid Batra: Yeah, I think that that is coming from that growth mindset that you have, like, the challenges that you see. You find climbing mountains and it’s like seeing what’s on top of that. So, it’s always good to be, like exploring things and knowing things and then finding challenges to overcome them. So yeah, perfect. Perfect.
But still, there is one thing that I would want to know, what do you think that makes you go in this direction? What is that realization that pushes you to be a growth mindset person? Because it definitely takes a toll, right? It’s not like very straightforward that you say that, okay, every time I just want to do something. It has to be some inspiration from within to do this.
Harijs Deksnis: Guess curiosity plays a big role. And just yeah, letting go of the past, yeah, shackles of the past, so to say, even though, even though, yeah, it’s maybe past achievements, but you want to sort of step beyond that. You don’t want to stay on that level forever.
Kovid Batra: Nice. I think that’s a very interesting point. I think curiosity always helps you move in that direction. What I have felt is something which is related to, I should not say survival, but a peaceful survival is what pushes, at least me, even I believe, and I feel that I have that growth mindset that this peaceful survival, if you want to have in this world, you have to be growing all the time. And, it’s not just, like career in all the aspects of life. So, yeah, just sharing my thought here.
Harijs Deksnis: That’s the way of nature, right? Sometimes you have something to run, stay just where you are. It’s like the Red Queen and Alice in Wonderland. Isn’t it, right? You have to run as fast as you can, just stay where you are. That’s the evolution, pushes us all forward.
Kovid Batra: Perfect. All right. That’s some interesting talk. Well, moving to the main section now where we would love to know how you have progressed through your engineering career, what challenges you have seen. So, starting with the first thing, like, tell us something about your experience where you have seen that scale-up journey, you have seen the transition from a room to a 60-member dev team, moving from to-do lists to Kanbans, to scrums, right? And, this whole thing, what role you played as a tech team member, as a tech leader here?
Harijs Deksnis: Yeah, well, if we’re talking about experience with Giraffe360, initially I came on board, building upon my front-end developer experience in the past year. So, I joined to start basically a new front end project, a new dashboard. And, started working closely with the team. But, it became quite quickly apparent that you would need a bit of better way of organizing. So, we started scrum in one team, a bit of more structure around planning things. Also started, you know, demos. And then we quickly, got quite productive compared to the rest of the company and the team and, you know, backend became sort of a bottleneck. Then I joined that team and started the process there. Then it went to another team, which was more handling the platform side of things. So, it went a bit of like, yeah, like avalanche ball. So, just get getting momentum and pulling other teams with interest in the same process. And meanwhile, there was the Series A financing round had finished, so there were funds to really grow the team. We also embraced the outsource model with team augmentation. So, just bolstering our capacity with some outsource members in New York, which basically they basically worked as in-house employees, just joining the teams and yeah, that really forced us to grow further, create more structured organization.
That of course, was challenging, put a strain on communication. Some all-time members were struggling, of course, with the change because they get, you know, they were used to certain type of environment, culture. As often in smaller or earlier stage startups, you see ‘hero culture’ forming like a lot of things happen because of some few, but very capable key individuals who do a lot, who can do a lot. But also, as you grow further, as you need to organize better, communicate more scalably and sort of try to get rid of bottlenecks or, you know, ‘bus factors’, that people can just safely leave on vacation and things don’t stop, and delegation can happen. Yeah, those people tend to struggle because, they get used to a certain way of working that also, of course, combines with a bit of feeling of their status or achievement or importance. So yeah, that is an issue that can be challenging.
Kovid Batra: That you have faced during this journey, yeah. So, let’s say, these kind of people who are there in the team, at times these people, you know, inspire other people to, like come up, step up. But at the same time, as you said that it is a double-edged sword, these people then become an issue in the team also. So, how do you create that balance? How do you handle such people who are actually very good for the team in terms of the efficiency, or if I have to use this word ‘productivity’, but, how do you handle these people? As you said, like you face them as an issue also over a period of time and the teams are scaling. So, how do you handle that?
Harijs Deksnis: Yeah. Well, I think as you grow, it’s really vital if you haven’t been doing before, start doing regular 1-on-1s. That’s one of the best ways, best windows to actually see the state of your team apart from, yeah, you know, surface metrics, that sort of thing. And, yeah, try to guide them through this transition, explaining what, you know, the phases we’re going in, what kind of role is, and what kind of benefits there are from being able to let go, being able to delegate and being able to instead of being in the center of things, with being the one who documents things well, sets things up for automation, oversees the process that happens well, and yeah, that they can leave on safely on vacation and, and, you know, just turn, turn their phone off for two weeks or whatever.
Kovid Batra: Yeah. Cool. So, I think most of the people who are in that category, would definitely come on a 1-on-1, listen to you. I feel that maybe 10% or max 20% of those people would actually have that feeling of changing themselves after those discussions. So, these 10-20% people probably who would change after these discussions or 1-on-1s, what do you think really clicked with them that you explain, or the other leaders in the team explain that hit them hard to change their behavior from being that bossy nature to being more cooperative, more understanding and leading with the team, not just leading the team the way they are thinking. So, do you think there is any specific thing that actually click with those people?
Harijs Deksnis: Hmm. That’s a very good question. I think that ties into psychology, and the other can, can be very diverse, depending on the nature of the person. But, the underlying factors are that the company, of course, is evolving and changing and growing, and unless a catastrophe happens, it won’t, you know, go back to earlier stages. And, this is just a new sort of new status quo, and everyone just needs to come to terms with it in a as healthy manner as possible. Acknowledge that, yeah, if some expectations are not being met or somebody is still attached to older ways of working or still have that sense of urgency that used to be there in earlier days that, you know the pivots, pivoting happened more often that every client request was super urgent and important because yeah, there were only a few clients.
But yeah, realization used to come, those days are gone. So, and we are, we need to, operate a bit more at thinking more about long-term, about just having things operate sustainably and without too much upheavals and chaos, or stress that we need to think about developer burnout. That’s also, of course, a big thing.
Kovid Batra: So basically, what you’re saying is it’s a collective effect of a lot of factors that could help them change their nature, right? It’s not probably just one thing that pushes them to.. Yeah, I get it.
Harijs Deksnis: It’s not a conversation that convinces them, like you know, solid argumentation because arguments don’t always work, you know, especially in psychology. A lot of things just based are on our feelings and arguments cannot always penetrate that.
Kovid Batra: Definitely. Makes sense. Makes sense. I think let’s, let’s move on to the next thing that I would love to hear.
So, when you’re scaling, right? Initial stages, as you said, you have less clients, you have to, like move really, really, really fast, right? You really end up building, some fixes, and ultimately, two years down the line, when probably you have that Series A and you are becoming stable, you realize you have created a lot of technical debt, right? It happens. It happens to everyone, probably. How consciously were you taking those decisions in those first two years or one year of the journey? And then, how in the retrospect, you thought it could have been done even better. Just tell us about that experience of handling the technical debt when you are in the 0 to 1, and the 1 to 10 stage.
Harijs Deksnis: Yeah. Yeah. That’s, that’s an inevitable consequence. Yeah, technical debt persists throughout our industry, especially when you move fast and in early stages every client request is almost like a, you know, a push for pivot because you’re still finding that product-market fit and every client feedback is vital for you. So, you often, you know find yourself changing slightly or a bit more direction quite, quite often just to cater to that client needs to, you know, so they stay on board and often they are a good signal for other clients, what would make them to join your, you know, client base. So, that Inevitably leads to creating a tech debt.
In my philosophy, I think ideal way to handle tech debt is to, you know, acknowledge that it exists, and to factor it, factor solving it in future feature development. So, don’t just say, “Okay, we’re going to, you know, take two next sprints, just handling tech debt.” That usually doesn’t sit well with business and product because you know, they always want to see some sort of incremental progress. However, you can sort of balance those both needs by saying, okay, yeah, we’re going to work on this feature, but as we work on this feature, we’re also gonna solve the technical debt that this feature touches, so we can, be in a better state. Yeah, this feature will take more time. Maybe we’ll take, yeah, three sprints instead of one, but doing so, we will both deliver that feature for you, and we’ll have sorted out some X amount of technical debt. That I think is the best way.
However, in practice, of course, yeah, it doesn’t always go that nice. And sometimes, yeah, we have had that, we operate with set cadence. So, this quarterly cycle of our feature development and then a release event announcing it to the clients and the public, and, you know, then the sales and marketing can build upon that. And, you know, there’s another cycle of three months. So, we also had that some team was very pushing forward just to get some features out. So, you know, we could have some relief on the other parts of the company where, you know, where that feature helped a lot of, you know, automation, and reduced a lot of manual processes internally.
So, we just, you know, pushed on to get it out of the door. And, the next quarter we said, “Okay. Yeah, this team now has done a lot. They really rushed. Okay, this quarter, they will be more quiet on the new feature development. They will solve the technical debt part, so that in the future they can go faster again.” That has also ended up happening. And, I think it’s fine at the end of the day.
Kovid Batra: Makes sense. Definitely.
Harijs Deksnis: The first version of what I explained, I think it’s more wholesome, more healthier, better if it’s possible to pull off.
Kovid Batra: All right. So, I think it’s more about being conscious to not just completely, you should not just completely ignore that aspect because anyway, you’re going to carry some technical debt. You can’t just solve it and build perfect software at day one, but you can definitely be conscious about it, be considerate of the overall business scenario, situation, and then take a call that “Okay. This is the percentage of technical debt that we are going to cater to.” Of course, you cannot, like quantify it completely, but still there can be some level of focus given to catering to technical debt while building the features also, right?
Harijs Deksnis: Yeah.
Kovid Batra: Makes sense. Perfect. I think with all this going on, I think what becomes most important is that there should be alignment in the team. Like, without the team alignment, having that hyper growth in the 0 to 1 phase, or 1 to 10 phase is very difficult. So, when you lead teams, you have to have the same success criteria for them, or maybe some specific success criteria for them to align with the business goal so that the business is achieving what it wants to.
But, when it comes to engineering teams, I would like to know it from you. How do you define engineering success? How do you measure it? And, while all this is going on, I feel that a very important part which you just mentioned that we should take care of the developer burnout with the factor of taking care of the developer well-being also comes in. So defining success for engineering team, measuring it and looking after the developer experience, developer well-being, how do you do that in a startup in this stage where you need hyper growth?
Harijs Deksnis: Yeah. We actually are still finding our way with the, when it comes to, like metrics and that sort of thing, because it of course, it takes also a bit of time to collect them and to, you know, to make sure they’re consistent across time so that they can actually be based upon to, to make some decisions. So, we still operate often more of a sense or common sense when it comes down to that. But, yeah, I think I’m also converging on the opinion as I think the most of the industry, the DORA metrics at the team level are quite reliable signals of how well the team is doing. So, you know, the four metrics in there, to deal with them with stability, and deal with velocity. So velocity, I believe, is the ‘lead time for changes’, and the ‘deployment frequency’. That is how fast you’re going. So, the faster you’re going probably is better, it means you can, you can react faster.
And, another two, what was this? ‘Change failure rate’ and ‘recovery time’ is stability. So, how stable you are, how often you are introducing a change that needs to be rolled back. Or if you do that, how long it takes for you to recover. And, if those are low, it means you’re quite, quite stable. And if you’re going fast, if those all four metrics are good, it means you’re going as fast as you can and you’re still doing it in a stable and reliable manner. I mean, then you’re doing great.
Kovid Batra: Yeah.
Harijs Deksnis: And when it comes to yeah, developers, well, of course, a big red flag is if you, if you happen to have too high employee turnover, or you see burnouts happening too often. That is a big, big thing.
Kovid Batra: How do you identify a burnout? Like, if somebody is in that zone, how do you do that?
Harijs Deksnis: Yeah, I think 1-on-1s, both with your team lead and then sort of the team leads with their team members. I think that is very, very important to catch these signals early. I know when it happens first time in career, when you encounter a burnout, it’s actually a lot of people don’t notice that it sneaks up. Also when I, in the past I had my first one, yeah, it just snuck up on me and then it was too late.
Kovid Batra: Sorry to interrupt you here, but, I would love the audience who might be feeling the same, should know that it’s okay to feel that way. And, it’s okay to come up and talk to your managers or leaders to actually resolve this problem. Because I think in that situation, I personally have been in that zone. So, I would love to know, like, what does it feel like and what did you do about it when you went into that burnout zone?
Harijs Deksnis: Yeah. It’s a difficult state because once you’re in it, you cannot reason out of it. And it’s not like a weekend recovery to get out of it. It usually takes months. So it, it’s a serious state. I still see it as a long-term accumulation of stress that was not properly dealt with.
I think a long time ago, I, I saw some psychology lecture. Well, I’m gonna use, well, a glass, if you hold a glass like this, it’s, it’s pretty lightweight. You can hold it like this. But, if you hold it like this for, I don’t know, two minutes, it gets a bit heavy. Hold it for five minutes, it’s quite heavy. So, I don’t know, maybe you can make it to 10 minutes or even 25 if you’re resistant, but at some point you’ll, even though it’s super light, it’s going to hurt a lot in your arm. It’s going to be a lot of pain. And yeah, you won’t be able to do much with that arm for a long time. Well, not long, but you know, significant time enough. And, that just shows that even a small amount of load, if carried for too long time without letting go, you know, for, you know, having rest moments in between can result in a huge strain, and, basically loss of capacity for a while. So yeah, that’s the analogy there. And first time, yeah, it just sneaks up on you because, I just have been doing a lot and not letting go, often thinking about problems, you know, in evenings and weekends, maybe there’s some sort of personal trouble as well at home, family relationship, that adds to the load. And yeah, one day you realize, wow, you don’t have energy to be creative, to want something, to think something you just want to, yeah, you just want to, I don’t know, you don’t want anything. And that’s a very sad situation.
Kovid Batra: Right, exactly. I mean, there have been scenarios. I think, this is from my personal experience, where personally, everything was fine. I’m happy home, having a good time with my wife, my parents, but when it comes to particularly work, it seemed like the way it is there always, right? So, I mean, as you said, like it could be something going on personally, and then at work-wise, and then you’re overloaded. I mean, I have felt that I was happy at home, but not feeling the same when it came to work. And, of course, reasons are different for everyone. But, burnout could be just related to your work where you are not getting what you need from that environment. So yeah, I think good we touched on this point. I think the audience would be becoming more aware of this situation, scenario and probably have more courage to deal with these kinds of situations.
All right, coming back, uh, like to the engineering metrics and the success of an engineering team. So, you mentioned about the DORA metrics, right? Right now in your team, you said you don’t go by the metrics or you don’t go by these things. You just go by your gut feeling and the overall..
Harijs Deksnis: We pay attention to those, but yeah, we don’t have actually, like system set up, that, you know, that measures and tracks across time. We sort of look at it back and look up data when we need it and sort of have a good sense where we are, but we have some way to go there to have it more, you know, reliable and consistent.
Kovid Batra: That’s absolutely fine. Yeah, I think it’s not, like very common yet that everyone is using those metrics or tools around those to actually understand what’s going on in the teams, but they do have this sense of what’s going on in the team.
So, my interest is to know, like if you don’t have these proper frameworks in place, let’s say, what exactly on day-to-day basis or weekly or monthly basis you look at to ensure, “Okay, things are going fine.” Like, I would just want you to, like reflect on that one month of maybe two sprints or one sprint, however you follow it. How does it look like? How do you ensure that things are going fine?
Harijs Deksnis: Yeah, well, there are a couple of signals. I think it tells, everyone, even laymen, that things are doing well. So, your team is energetic, right? They feel they’re winning. They like the challenge they’re solving and they’re solving it in a reliable time. We are building features or product, that our clients like and they use, and of course there’s feedback. And, if there is negative feedback, we react to it fast and we don’t introduce too many bugs. That, you know, that keep us bug fixing for, you know, a disproportionate amount of time. And, there’s a lack of frequent incidents. Of course, you know, incidents can happen, that’s normal. But yeah, if you, if they end up happening weekly, depending on the system, of course, then something is wrong.
Kovid Batra: Yeah. Makes sense. I think, even if you’re not following certain framework, I think the signals that you’re looking at ultimately point towards the important things that you should be looking at. I think that really helps you going. Probably when the teams are really big, you would have to have a proper process, a framework in place when you have objectivity on what’s going on each metric. But right now, probably with a 50-60 team size also, you’re able to manage seeing what’s going on. If the bugs are increasing, is the team motivated or not? And then this is really amazing point that the first point you said, “Is the team energetic and motivated or not?” I think that covers the 80% of what is actually expected to be there, as a developer experience, as a team experience that everyone should be motivated and energetic. Taking feedback, doing less number of bugs, doing more, delivering fast, I think always happens on top of it if the core is aligned and motivated.
So yeah, I think that’s perfect, Harijs. It’s really nice, knowing that you are taking care of your team, not just work-wise, but in general, how they are feeling. So that’s, that’s really nice.
So, I think, this was my last question that I just wanted to ask in the interest of time. I’ll just ask one more question. I mean, you told about how these metrics work out for you and how do you handle that. One thing that I want to understand from you is when you set goals for your team, particularly, right? How do you exactly do that? Is it just some engineering achievements that you have to have at the end of the month or at the end of the sprint, or are you linking it to some product or business metrics also?
Harijs Deksnis: We are mostly guided by product features or quarterly goals the business and product wants to see. And then it comes in a form of a new feature, new functionality being delivered to the customers. We track it at the quarterly level. At the sprint level, we do have a lot of freedom for the team leads to decide on the pace or the priorities. They sometimes can and do decide they have to tackle a bit of technical debt, so they can move faster to the goal in the next sprint.
Yeah. The quarter and product feature delivery is just sort of our milestone cadence.
Kovid Batra: It makes sense. I think just keeping things tied to the engineering achievements would not be appropriate because at the end of the day, product and engineering works together to deliver the features, to deliver the product. So ultimately, the goal is to make the customer happy and deliver as much as possible for the customer. So, aligning that, the engineering team with that is really, really important.
Perfect. All right, Harijs. I think it was a really nice conversation. It was a pleasure having you. Thanks a lot.
Harijs Deksnis: Likewise. Yeah. Thank you for having me. It was a great conversation. Have a great day.
Kovid Batra: You too, Harijs.
In the recent episode of ‘Beyond the Code’, Host Kovid Batra welcomes Stephan Schmidt, CTO Coach at Amazing CTO. His vast experience includes valuable contributions to renowned companies such as brands4friends by eBay Inc., ImmobilienScout24, and 7Mind GmbH. The discussion centers on ‘Impact vs. Velocity’.
The podcast begins with a fun fireside chat with Stephan, allowing the audience to see his candid side. Later in the main section, He explores the challenges CTOs face in large-scale companies. He also provides insights into steering the team towards impact over velocity as well as navigating the challenges of balancing fast-paced growth with handling technical debt during hypergrowth cycles.
Stephan concludes by discussing what separates a leader from a manager, along with measuring success for engineering teams.
Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with us we have an interesting, amazing guest who is super knowledgeable, 30+ years of engineering and leadership experience. He’s an ex-CTO of an eBay company. He’s been the founder of a startup. He’s currently working as a CTO coach with Amazing CTOs. And, the most amazing thing about him is his humbleness. Welcome to the show, Stephan. Great to have you here.
Stephan Schmidt: Hello, Kovid. Thanks for having me.
Kovid Batra: Pleasure. Pleasure. All right, Stephan. So, before we jump into your experiences and knowing what all wonders you did in your career, we would love to know more about you, outside of tech maybe, so that our audience gets familiar with what kind of person you are.
Are you ready for a quick fireside chat with us?
Stephan Schmidt: Yeah, sure.
Kovid Batra: Perfect. Perfect. First question is very simple. Are you a beach person or a mountain person?
Stephan Schmidt: Oh, I enjoy both. I grew up in the mountains, but, some years ago, I moved to the sea, so I like both. But, if I needed to decide, probably the beach.
Kovid Batra: And in one word, tell me, what do you feel when you’re at the beach?
Stephan Schmidt: I’m amazed by the sea. I feel amazed. I feel..
Kovid Batra: Perfect. All right. Next question. It’s been 30 years of experience, but you have to go back, you know, memory lane down to the point where you had your first coding experience. Tell us about it.
Stephan Schmidt: My first coding experience, like for so many was as a kid. I played video games at the end of the 70s and I thought, “Well, I could do that too. I want to do that too. I want to write video games.” So, I went to a department store. There were other kids who did some programming on the computers in the department store. I watched them doing their stuff, learnt from them, imitated them, and that’s how I got into coding. And, since then, I’m a coder and what I love about coding is essentially creating something from nothing. Like, there is a blank screen and then you can do the thing, the computer, whatever you want it to do. It’s like you create something out of nothingness. And, that’s still something that I really, really find amazing.
Kovid Batra: So, for all the parents out there, video games are not that bad.
Stephan Schmidt: No!
Kovid Batra: All right. All right. Moving on to the next question. I think this is very close to me also. What would you choose? Like, what do you prefer, being a founder or being a CTO at a company of eBay? What journey was more fulfilling? I feel both of them are very good, but what’s your piece of cake?
Stephan Schmidt: I think the nice thing about eBay, and I was also working at a large company in Germany, which is called, ImmobilienScout24, which is a real estate website, the largest real estate website, I think in Europe. And, what’s nice about working in a large company is that you feel some impact. It’s large, people know the company. So you see people who use your product in everyday life. So, you can go around somewhere and say, “I work for eBay.” And then everyone says, “Yeah, I know eBay. I use them.” Or ImmobilienScout24. “Yeah, I’ve used ImmobilienScout24.” So, everyone knows it. So that’s, I think it’s a nice thing of working in a large company. And also, you have a lot of money around and you can do a lot of things because you have a large budget and all of this stuff.
Being a founder of a startup enables you then, but enables you to better, I think, follow your ideas and your vision. Because in a large company, you might be constrained by the company and by the company strategy. And so there’s limits on what you can do in technology. As a founder in a startup, there is no limit, on what you can… have legal limits, but there is essentially no limit on what you can do. So in doubt, I’d go the founder route. But I learned a lot in large companies and I enjoyed my time there.
Kovid Batra: Perfect. Thanks for answering that. All right. I think that was an amazing quick fireside chat with you. Now, we would love to move to the main section where we get to know all the wonders that you have done in your career. And I would simply start with something that you have been doing right now at amazing CTOs while coaching the CTOs.
What do you think are the biggest challenges CTOs face in companies like eBay, which are obviously at that scale? What do you think, on day-to-day in their responsibilities, in their role. What are those challenges that you see these CTOs facing?
Stephan Schmidt: I think the challenges one of the challenges that a lot of CTOs are facing and, and it gets more difficult the larger the company, I think, it’s aligning strategy with business strategy. I think that a lot of challenges arise in software engineering when the business strategy and the business vision is not aligned with the tech strategy and the tech vision. And, I think it’s paramount for the CTO in a company. And it’s more, more important to bigger the company to align the tech vision and the tech strategy towards the business and be supportive, because otherwise you move in the wrong direction. If you are not aligned, you move in the wrong direction, you make the wrong architecture choices, the wrong technology choices. And then, there is a rude awakening at some time because there is too big of a rift between you and the business. So, I think it’s very important to be aligned on business vision, business strategy, and execute on them. And where do, where CTO struggle is, first, I think is bridging the gap, thinking from the business side, bridging the gap. And, the second thing is they usually don’t think there needs to be a tech vision, a tech strategy. They are too focused inside. They think it emerges by their actions and by their decisions about technology, but it’s not. So, they don’t have a strategy. They don’t have a clear strategy. They don’t have a clear vision for technology. And that creates a lot of rift and problems.
Kovid Batra: But, why do you think, like, I’ll ask a question, follow up question on that. Why do you think the CTOs really struggle with formulating this vision in their heads and then aligning a tech vision or a tech strategy for that? It may be these events arise, these problems arise, but at the core, what exactly doesn’t make them move towards this direction of building a good strategy? Is it the lack of understanding of the business needs? Because probably CTOs come from a tech background and they have more inclination towards coding and being individual contributor a lot of part of their lives. What exactly it is? Why do they miss out on this bus?
Stephan Schmidt: I think there are several things. And the first thing is, is really what you mentioned. I’ve had a lot, so the team, not me, but I, as someone who takes ownership not of the good results, but of the problem. I’ve had a lot of hard tech problems with my teams and but usually this was not something very high on the, on the agenda of the CEO. So, I did not get a lot of thanks for solving hard tech problems, but I always got positive, very positive feedback on my understanding of business and my trying to bridge the gap, trying to understand business, support business and stuff like that. That’s something that the CEO said, “Stephan, that’s, that’s good that you’re not a techie. I can talk to you. You talk in a way I can understand it and you try to explain things.” And so, I think that’s, that’s very important. And, and CTOs don’t do that enough, I think. But that’s the role, that’s part of the role.
So yes, from that side, I think strategy is lacking. And on the other hand, I think a lot of CTOs think they don’t need a strategy or they don’t know what it would be to have a tech strategy, what it would look like. And they, they just go from decision to decision and say, okay, they have some kind of strategy, like, okay, we want to move to the cloud or want to move to the, to microservices or something. But they, it’s not embedded in a grand scheme, in a grand strategy and a grand vision, which is aligned to business. So they are, they have random kind of random strategy steps they are doing. Like, move to the cloud, move to microservices or move to mobile native apps or something. But these are kind of random strategy steps. And they think that’s enough, but I think it’s not enough. It needs to be a wholesome strategy, which gets you somewhere. And that somewhere is a vision where you want to be.
Kovid Batra: Definitely. I think that’s interesting. Thanks for highlighting that. All right. So, one more thing then last time when we were talking before this podcast, I remember you telling me that it’s not about doing more or it’s not about achieving high velocity, it’s always, always more about delivering more impact, right? So, as a CTO, when you step into that shoe, how do you exactly ensure that the impact is getting created? Because as a CTO, let’s say, you understand what would be the business impact. You at least have direct business counterparts to whom you are talking on day-to-day basis to understand what they need. But, what about the team who is not interacting, and is probably a little bit unaware or a lot unaware of what’s going on, on the business side? How do you make sure these people are more aligned towards delivering impact rather than focusing velocity?
Stephan Schmidt: I think developers, particularly developers want to work on impact instead of velocity. I think they want to do things that have impact, so it’s not about the tech team. I think it’s about two things. First, I think it’s about business, where I need to do a lot of explaining to get them into the impact mind frame, in the mindset and into an impact frame, because they often think we need to deliver more and see what sticks.
Whereas when I look at, I don’t know Tim Cook, but I imagine Tim Cook from Apple wants to have a blockbuster iPhone each year. And, he doesn’t care if the iPhone is one release, one month earlier or something, or two months earlier, that’s not the focus. The focus is to have a blockbuster release, iPhone release, sell hundreds of millions of them. And, business needs to get in that mindset and that’s a lot of effort because usually they are more in the, “We need to do a lot of things. We need to do a lot of things. Do things fast.” And stuff, instead of, “We do things that have impact.” So, that’s the point. And, their interaction with product or with someone who defines features or defines user stories, epics, or whatever you want to structure your software engineering around. I think the important thing there is they need to have impact metrics. You know, they need to, every story needs to have an impact metrics. What impact do you want to have? Like, it might be usage, minimal, might be usage, 50% of users are using this, but it might be more of an outcome, not only an output, but more of an outcome metric. And an impact metric, that’s very important, and to follow up on these. So, I see organizations who do not define impact metrics, they define revenue metrics, which is a very, very bad idea for various reasons. They, they don’t define impact metrics, but if they define them, they don’t follow up on them. So like, you do this. Okay, didn’t work. Next. And, you need to really follow up on metrics. That’s, I think it’s a challenge, like the interaction with the persons who are writing the stories or the epics. With the business side, that’s a story, about the strategy. I feel like developers really want to work on things that have impact, you know? And, they don’t want to create as many features as possible, from my perspective. They want to have work on things that have impact.
Kovid Batra: No, I believe that. I mean, I, I might be coming from a very narrow experience where I might not have encountered that. Thanks for an eye-opener there. Probably developers have that mindset that they want to create an impact. But, at the same time, I have one more doubt. And again, it could be something which is very specific to my experience with developers. I don’t see that tendency where they want to really get in touch with the customer, like getting in touch, not literally. Maybe a salesperson would be doing, or even a product or a user research person would be doing. But, taking that information from these business departments to understand what exactly the user feels like or getting into the shoes of the users, and then thinking of coding and developing, I feel that there is a resistance. Is that right or wrong?
Stephan Schmidt: Yes, I think that there is some resistance there for various reasons. One reason is essentially that developers are very fact-driven usually. And you know, the best fact wins, the truth wins. Let’s discuss this on facts. Whereas other departments are not that fact-based or not that detail-based. They are fact-based, but they are not that detail and analytics-based as developers are. So, some other departments want to talk about feelings and about emotions, about how we can do this and do that. And, and just glance over the details. They don’t want to talk about details. You know, they want to, marketing, sales, some other departments and customers. They talk about the big things perhaps, whereas the developers want to talk about the minor things and the details of things, they are interested in the small details of things, because in the end, they need to make it work, you know, and it breaks in the details. And there are some differences between cultures and between understanding. And, that sometimes makes it difficult for developers. And then this gets friction and that friction takes effort and, and is, you know, and it’s, it’s annoying. And out of that, I think, arises something that developers do not particularly want to discuss things. They say, “Tell me what I need to do.” You know, they’re often unhappy if some, if you tell them what to do, because they think it’s a bad idea or it’s not detailed enough, you know? So, on the one hand, they’re annoyed by if you tell them what to do. On the other hand, they say, “I don’t care. Tell me what to do.” So, there’s some, there’s some, “I want this, but I also want that.” kind of thing.
Kovid Batra: So, why I’m asking this question is because this is this whole loop. Like if I, as you said, like the developers would want to create an impact and they would want to develop something that creates an impact. It cannot happen if they don’t have the right information, if they are not contributing in terms of the discussions with the Product Manager, right?
Stephan Schmidt: Yes. Yes.
Kovid Batra: And, to actually first get involved there would make them innately accountable for what they are building, right? If you, again, if you just go tell them what to build, they would not be happy. They would not feel involved in the process, and ultimately, they would feel getting tied to the business metrics of the product metrics, the usage that you were particularly saying. So, I think it has to start probably from the point where the developers have to be put into a mind frame, as you said, they need to deliver a blockbuster product or a blockbuster feature. And to do that, they need to realize that they have to come out of that little bit of a shell and understand what’s there on the customer side. And then start getting involved in the development process with the product.
Stephan Schmidt: Yeah. Yeah. I sometimes, I sometimes shorten this to ‘developers need to become creators again.’ You know? My heroes in the 80s were people who wrote video games by themselves, or two people wrote a video game, city design, great video games like, Elite or Iridium, Paradroid. There are a lot of good video games written by only two people or one person. And there are also good, great software like Lotus 1-2-3, WordStar, VC card. But there, back then, developers were creators. You know, they created things. And today, a lot of developers are executioners. They execute things. They create things other people have thought of. They build for other people. And, what I want is that developers get back into the creator mindset and feel as creators, because that’s also something that brought me into development. So, this is something I try to tell developers is that they would be happier if they could get into creator mindset. And then sometimes, for example, if you send them off to a design thinking workshop and they get into design thinking and then they get involved in the product management, they are often happy then with being there and making the decisions, even if there is some resistance at first. But, a lot of them, not everyone, it’s not for everyone, but a lot of them are very happy getting back into the creator mindset and being a creator again, instead of just doing other people’s stuff.
Kovid Batra: Perfect. Yes. I think that’s, that’s what probably I was thinking. All right. I think this was interesting.
So, that was on delivering more impact, how you would actually drive. Now, there is one more thing that we feel that it has to come with alignment. When you’re leading with a strategy, then you have to, like create a balance between a fast-paced growth and also handling the technical debt. I mean, this is kind of inevitable and almost every engineering team has to go through this loop where they are under the hypergrowth cycle at some point and they create technical debt at that point. How exactly in your view should that be handled? What as an engineering leader or as an engineering manager, should you consider while taking on that call, whether to build it this way or that?
Stephan Schmidt: I have a, a simple, I don’t say I’m right. You know, I, it’s just my opinion. It’s just my experience. So, that’s my model that I have in my mind. I might be helpful, might not be helpful. But, how I see it is there are several phases and you need to act according to the phase in a startup.
And so, the first thing is for me, from a product perspective, startup product perspective is you build a prototype, you know? So, you go in, and you did a, we build a prototype where you can evaluate the idea, how it would look like in general. And, you can show around the prototype to investors, to employees, to people, to friends. That’s the prototype phase. And, you can do no code development. You can do whatever you like. You can do a click dummy. You can do PowerPoint slides. It’s not important. That’s the first phase. A prototype with a clear goal of getting people interested, evaluating the general idea, how would look like.
Then, you get into MVP and see what would the minimal product would look like that you could bring to market, you know? What’s the entry product? What’s the market entry product? You need to build the MVP. That’s the second phase for me.
Then, you have the third phase. And, the third phase is about finding product-market fit. So, you need to iterate and really work hard to find product-market fit. And, when you have product-market fit, you will feel it. Some of my coaches get into that mode and they feel it. Everything gets easier. People come to you, want to buy from you. So, this is product-market fit.
And, after product-market fit, last phase, last relevant phase, there are some others in the future, but last relevant phase is scaling, you know? So, you have prototype, MVP, PMF, and scaling. And, what I see about technical debt, what I see is, in the beginning, it’s okay to have technical debt. So, I would not care about technical debt in an MVP or until getting PMF, product-market fit. I would really, totally concentrate on these two things. And if I accrued technical debt, that would be fine with me, you know? I try to minimize it by having the right engineering culture in place, not doing stupid things, but overall, total focus, getting PMF, getting MVP, perhaps to get an investor, to get into the market and PMF to find traction. And then, I would think about tech debt and have a clear strategy to get off tech debt and remove it.
A lot of tech debt, essentially, I think is accrued because of two reasons. First reason is tech is not aligned to business. So, business moves here, tech moves here, and the ever widening gap is kind of a technical debt because it’s like, we can’t move there because we’re here and, you know? And, the other thing is that a lot of companies want tech engineers in startups, want to scale too early. And, they put things in it, and they add abstractions and they try to scale before they need to scale. And what happens is they get a lot of technical debt not in the form of bad code, but in the form of bad abstractions, you know?
Kovid Batra: Right. Makes sense.
Stephan Schmidt: And, I would, I would be cautious about, I, whenever they tell me how I need to prepare for scaling, I say, “No, why?” I mean, first, you can’t anticipate the future. So, probably we built the wrong things. So, always don’t do stupid things, like too easy stuff, have several servers and, you know, don’t do, I have some clients who have one server, don’t do that, you know? But, don’t scale too early because also on the other hand, you will find out things, at least I found out things when I was in hypergrowth startups, that things break that you did not think about, you know? The things that are breaking are things you’d not have thought about. So, I think it’s don’t do something stupid, but don’t try to scale too early.
Did that a little bit answer the question about technical debt?
Kovid Batra: Absolutely. I think it puts a lot of perspective in place. We are also going through that journey right now, and I totally understand you are trying to emphasize them. And, I think it’s a very good piece of advice because the need of the hour is to build, find that fit, not to build something perfect today, because for that we’ll have time. We just need to build something which is just good enough and serves the purpose. So..
Stephan Schmidt: It’s very, very difficult to achieve product-market fit, you know? A lot of companies fail there because they think they have it, but they haven’t. So, and I would not think about technical debt until I have traction.
Kovid Batra: Makes sense. Makes sense. Absolutely. Thank you so much for answering this.
With that, I would want to move on to something where I’m sure you would be coaching a lot of people on, where they transition from a manager to an engineering leadership position. I mean, the first transition is of course, from an IC to a manager, but then the journey from a manager to a leader, I would love to hear from you. What should be the reason behind it? When is the right point? The inspiration. Just tell me about what according to you is the right point for somebody to move from a management position to a leadership position.
Stephan Schmidt: I’m not so sure there is such a huge difference. And I also, I felt like I was always kind of a leader because of like in and I don’t want to be “Stephan knows everything and does everything right” and blah, blah. It’s not about that. But as a kid, running around in gangs, doing stupid things, 10-year-old kid, I always thought, like I was often the one telling people what to do, where to do, what to, what stupid things to do next, you know, or what intelligent things to do next. So, right from the beginning, I felt like, natural to me to standing in front and showing directions. And, I think that’s about leadership. And, the most important thing about being a leader is giving directions, you know? Like, “This is where we want to go to.” So you need to have a vision and you need to tell people we want to go there and remind people that you want to go there because a leader is someone who leads. And, you lead people by leading them somewhere. I mean, you can lead them in a circle, but you can’t lead people in a circle. So, you will lead people somewhere. So, a leader is someone who leads people somewhere. And to me, that’s having a vision and leading people towards the vision, which is kind of a goal in the future. And that’s leadership to me. Whereas manager is a lot of, about administrative stuff and taking care of people and being people manager and all of these things. The difference to being a leader is to me is having a vision and leading people, have a clear opinion where to go and lead people there because you believe that’s the right direction to go.
Kovid Batra: Makes sense. Makes sense. Perfect. I think, when we have that feeling, so what I would love to share what I feel that being a leader comes with something which is very core is being able to comprehend yourself, like explain yourself to others in the best way possible by being humble, not by being somebody who’s a hero or being alpha in the team. And most of the times we feel that. I mean, this is a quality that you have, I’m sure. I feel it. I just mentioned in the beginning also, I think this comes very obvious to you, but I think one of the things that I feel the leaders should have is the humbleness, the groundedness, and being one of those people with whom you’re working. It’s just a responsibility that you have taken up to give the direction to the team, but that doesn’t give you the power or the, the superiority in that plan, in that team. Yeah, so that’s something that people should be consciously aware of.
Stephan Schmidt: I think to me, as I said, crucial is leadership says, “This is what we’re going to do. This is where we want to go.” And that’s leadership to me. And it, it does not need to be that you’re standing on the table, shouting people, “Go there!” Or “Faster!” You know, it’s not, that’s not, you can be part of a crowd. And, that’s also something that I always had as a manager and leadership ideal, I was always part of the group. So, I was not standing on the sidelines. I tried not to stand on the sidelines and give directions. I was always trying to be part of the group. Like in this, I don’t know, like in the movie, you know, like being a leader, but being part like ‘The Glorious 7’ or something. Being part of a group, you can be a leader by being part of the group. It’s not something that you are directing the group around, you know? It’s not. That can always be a leadership. If this is your style and if it’s fine, then, but it was not mine. You know, leadership can be part of the group. I think you can be a leader without having a title, you know? There are a lot of great developers who are obviously the team leader, the team lead, but are not the team lead, you know, because they take ownership and, and if it works fine for everyone, then that would be also fine for me, you know? I don’t have to have the title to be a leader.
Kovid Batra: I think that thing would have a little bit of a problem in terms of people having that bias to follow what you’re saying and, and you need it at times. So I, I feel that you should be entitled in some way, like either it should come from the group itself that, “Okay, he is, or she is the best person to be there to take decisions for us.” Or the authority, or not exactly the authority, but the upper management or the existing leadership should define that, “Okay, this is the person whom you should be following now.”
And then, even if you become part of the clan and then work that way, it works pretty well. But yeah, I mean, everyone to its own but your thought is also correct.
Stephan Schmidt: Yeah, no, actually one, one minor thing I think is, is like, I didn’t go into the question why people should follow you, you know? You know, there can be various reasons why people should follow you and it can be because you’re the boss and you say so, but it can also be because people trust you, you know? People usually follow you, I’d say, if the vision you want to lead people towards is self-evident and great, and all the people say, “Yeah, that’s a goal in the future. I want to be there.” And people trust you that you will be the person leading them there, you know? If they don’t trust you, you can have the best vision, but if you don’t, if people don’t trust you to go get them there, you know? So, there can be very, very different reasons why people follow you, can be you, the boss or you, you know, but, or you have the title, whatever. But, it can also be because people trust you and you have to create a great vision where they want to be.
Kovid Batra: Sure. Absolutely. I think, one thing that comes to me is that when you move into that step and you want to be part of the clan and you want to be humble, it becomes difficult in one way is how you, like push people to move faster or let’s say, deliver more impact, measure their efficiency and then tell them, “Okay, this is where you’re working on.” How do you do that? How you have been doing that as a leader, defining success for an engineering team and then measuring it? And while doing all this, taking care of the team, their well-being, how do you exactly do that?
Stephan Schmidt: I think the first thing that a lot of CTOs are not doing, a lot of leaders are not doing is expressing their expectations. People have expectations of the team, of the company, of the individual, but they don’t, do not talk about them. And then, the person, the team, the organization fails because it does not succeed towards the expectations. But, the leader, manager, whoever has not spoken about those expectations. So, a big failure in organizations and in managers I see is that they do not talk about their expectations and then are unhappy because people do not follow their expectations, fulfill their expectations that they have not talked about, which is obviously, you can’t, I can’t, I can’t fulfill your expectation if you don’t talk about them. But, that’s what I see too often. So, the first thing, very, very, very first thing, if we talk about performance is talk about your performance expectations and talk about that performance is important to you and what performance means for you. How does performance look like? What is performant behavior? What is underperforming behavior? And, performance is important. So, what’s your expectations? How do you judge people? How do you judge performance? How do you evaluate things? That’s the first thing. Make it clear that performance is important or very important to you.
And again, little bit of a sideline, side quest, employees, developers hear so many things, so you need to repeat important stuff. If they have heard from you five times that performance is important, they will think, “Okay, it looks like performance is important to Stephan.” You know? But, if you tell them only once, they hear so many things, they need to judge by themselves, what’s important, what’s not. And, if you tell them only once they think, okay, that might not be the, you know? So, it needs to be clear expectation, performance is important. That’s a cornerstone of everything.
And then, add two things. The first thing is, is something like support the people, support the developers, you know? Give them what they want. Like I have this famous story. I got into trouble because everyone in my department got $300 headphones. But, it was too loud, people could not concentrate. So, everyone got a $300 or $350 headphone which got me in a lot of trouble because, like company did not understand why I was buying so many, like for 10,000s of Euros buying headphones. But, if this is what they, what you think they need, then do it. And, so I was very close of letting, I was, a lot of people were angry in top management. But, if you think that’s, that’s the thing that people need to deliver top performance, that’s what I said, you want, company wants top performance, pays a lot of money for these developers, and then I can’t give them a $350 headphone? Does not make sense, you know? So, give them what, what developers need, environment, tools. So, support them in every way you can to be performant. That would be the one way. That would be the one part.
And, the other part is hold them accountable for performance. So, if you expect performance and you have the feeling that someone is not performant enough and is underperformant, tell the person. And again, tell your expectations, describe what you see, what you think is happening and that you’re unhappy with this. And then, sometimes, more often than not, you’re wrong, you know? I was wrong when I said someone to them. So, this is someone, the person said, “Yeah, because this is because this is of this and this and this, and we hadn’t anticipated that. And, that’s why this project is underperforming.” And then I said, “Oh yeah, sure. You’re right. Hadn’t thought of that.”
Kovid Batra: Yeah.
Stephan Schmidt: You know? So, I might be wrong with my perception of underperformance, but nevertheless, I talk about it. And I hope people are accountable for performance, with all the support I can give them, you know?
Kovid Batra: When you say that you set the expectations, I tell them what performance looks like, how exactly do you do that? Just give me an example. Is it some metrics that you’re following? Is it some engineering KPIs that you would like to put up front that, “Okay, this is what we are going to look at when we are evaluating your performance.”? Is this what you’re talking about? How do you bring objectivity to this process? That’s the broader question I just wanted to understand.
Stephan Schmidt: So, the first thing is I always try to steer everyone to an impact framework instead of a velocity framework, because otherwise, performance is just more features and faster features which is not my understanding of performance. So performance is do things in a reasonably fast way. That’s engineering performance, with the right trade-offs between gold plating things, overthinking things on one hand, and creating engineering hacks on the other. So, hacks in a bad way, not in the, in a traditionally good way, but in a bad way.
Meaning so you need to make the right decisions. And if, for example, again, if, if someone takes two weeks for a development effort, and then I say, “Well, that’s too long.” I feel that’s too long, and then I let, let explain why it took two weeks. And then, I might be wrong because it really makes sense.
Kovid Batra: Yeah.
Stephan Schmidt: So I push for performance. So if, whenever I see or team lead sees performance in a way, speed in a way that does not look right, I go into it. But more, normally it’s more about making the right decision when to stop. So, how much engineering to put in and why not gold plating, having good quality code, low bug count, high testing, coverage. For me, performance is more about exercising good decision-making, good decisions as an engineer adhering to good engineering practices. And then, working on stuff that has impact instead of being the fastest, you know? It’s not..
Kovid Batra: Makes sense.
Stephan Schmidt: I said again, if I see someone who takes two weeks for something and I think it should take two days and it takes two weeks, I ask why it takes two weeks. It’s not.. It doesn’t make sense to me. And then, sometimes I’m right. The person is just not fast enough and needs to speed up and needs to get other skills or more training or sometimes a little bit being pushed a little, but sometimes I’m also wrong. There’s quite good reasons that it takes two weeks. And then if, if product comes to me, VP of Product and says, “That’s taking too long.” And I’m convinced that two weeks was totally fine. Then I say, “Oh yeah, totally fine. That’s how we fast, how fast we are.” You know? So, yeah.
Kovid Batra: Got it. All right. I think, thanks a lot for all the knowledge that you’ve shared, the insights that you shared with us. It was an amazing, amazing talk. Would love to do it one more time on different topics. Thank you so much.
It was really a pleasure having you, Stephan. Thank you so much.
Stephan Schmidt: My pleasure, Kovid. So, see you next time.
Kovid Batra: Thank you.
In the recent episode of ‘Beyond the Code’, Host Kovid Batra welcomes Limor Bergman, tech leadership coach and mentor with a rich background in organizations such as DigitalOcean, Quantum, Sun Microsystems, and more. She also hosts her podcast series ‘From a Woman to a Leader’. Their conversation revolves around ‘Empowering Women in Tech’.
The podcast begins with a fun fireside chat with Limor, allowing the audience to see her candid side. Later in the main section, She delves into the distinct journey of women in the tech industry, and strategies for overcoming them. Limor provides insights into managing fast-changing technology challenges in engineering teams and making optimal choices in tech career. She also shed light on how to define the success of your engineering teams.
Lastly, Limor shares parting advice for the audience, encouraging them to take risks and embrace failures.
Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. I am back with another episode and a new guest who is passionate and a powerful engineering leader. She has an experience of 20+ years, currently serving as an executive coach and a mentor. She’s all about supporting women in tech. She runs her own podcast, ‘From Woman to a Leader’. She’s coming up with season 2 of the podcast, which is ‘Women of Color’, where you can find her talking about different diverse cultures and women growing as a leader there. Welcome to the show, Limor. Great to have you here.
Limor Bergman: Hi, Kovid. Thank you so much for having me. It’s a pleasure being here today.
Kovid Batra: Perfect.
So, all right. I’ll quickly tell you about the format of the show, Limor. We start with a quick fireside chat, and then we jump into the experiences that you have had as an engineering leader. So this fireside chat is to know more about you outside of work a little bit, some interesting things about you.
So, are you ready for some quick questions?
Limor Bergman: Yeah, absolutely.
Kovid Batra: Perfect. So, let’s get started. I have been like reading a lot about the tech blogs, the tech bloggers who have been producing a lot of content and you being one of those. I just really wanted to understand what inspires people like you who are writers to come up with writing. I have this thing, which I really need to know and understand because I someday want to write a book, whatever I’m learning from here. So yeah, that’s the first question for you.
Limor Bergman: Absolutely. And, I want to write a book as well, to be honest with you. It’s on my plan as well. So actually, you know, when I grew up, I thought that I couldn’t write. It started with a teacher that actually told me that I’m not a good writer. I mean, I was very good in STEM, you know, math, physics, chemistry, but I got kind of a traumatic experience from writing. It was traumatic because I got negative feedback. And also, you know, although I took a tutor and that was like the only tutor I took in high school just for writing. And my teacher was always criticizing me and that left, you know, an impact for years to come. That. Yeah, I may not be able to write, but what happened, the interesting thing that happened then, I wanted to express myself. I wanted to share my thoughts. I wanted to share with others, you know, all the insights I had and I actually started writing.
Kovid Batra: Okay.
Limor Bergman: And I found out that first, I really enjoy it. And then, I also, I’m not that bad. I mean, it’s not that terrible. And the great part nowadays, because everyone can be a writer, right? Everyone can write a book. Everyone can start a blog. You don’t have to be Shakespeare. You don’t have to be like super-duper excellent. Just express yourself, be genuine, express and share what you have, and do it. Everyone can do it.
Kovid Batra: Yeah, it’s a very simple thing, actually. Like, you just have to have that feeling of expressing your thoughts. You just, you probably can perfect it over a period of time, but you don’t have to fear starting off. You just have to have that feeling that you want to share what you have in your mind.
Perfect, Limor. I think that’s quite enlightening for me at least. All right, moving on to the next question. What advice would you like to share with young joinees in tech?
Limor Bergman: Yeah, that’s another great question. So, I’ll start with a quick story. So, when I started my first software development job, I was still you know, in university and I started like a part-time job. And, the experience was terrible because for multiple reasons. First, I had a very, very unsupportive manager. She was actually a woman. My first manager was a woman, but she was very strict. She was not nice. I guess she felt like she needed to keep a very clear distance. She was not supportive. I really did not enjoy working with her. The second thing is that I was working on ancient things, like on COBOL, on Mainframe, and I hated every second. I hated every second. It was clear to me that while it was comfortable for, you know, while I was at school, you know, because it didn’t require much challenge from my side, it wasn’t going to last. As soon as I’m going to graduate, I cannot keep doing what I was doing.
What I did was that I went to the manager above my manager back then, and I had a conversation with him and I told him, “Listen, I mean, I really like the company. I would like to stay here. But, I cannot continue working with, with that, you know type of work. That’s not what I signed up for. I want to move.” I mean, back then Java was the shiny new technology, new language. And there was a team that actually wrote Java Applets. Yes, I’m that old. So, and I told him, “Listen, I mean, that’s the team I want to join right after I graduate and move to a full-time job, otherwise, I mean, I just cannot see myself staying here.” So, I wasn’t threatening per se, but I was making clear that, I mean, that’s not going to work for me. And, you know what happened? He listened. I mean, I was lucky, right? I mean, he could’ve not listened, but he listened and he moved me to that team.
And long story short, I would say that the advice I would share is that even if you’re just starting out, appreciate yourself and what you are worth, know what you want and don’t be afraid to ask what you want, even if you are just starting out.
Kovid Batra: Yeah. I think I can, I can relate to this feeling and when I had joined my first job, I was always under this impression that something should not go wrong, people should not perceive me wrong. And on top, like the most important thing was the managers, the leads should not perceive me wrong in any way. So, I used to, like not express much and I couldn’t be genuine there and it definitely affected me in a negative way rather than in a positive way. So, that’s a very good piece of advice that you have to be fearless, in a reasonable way. Like, you have to be polite and respectful, of course, for others. But, you cannot be just listening and not expressing your views, not being genuine there. So, yeah, I think that’s a good piece of advice, Limor. Thank you for sharing that experience, by the way.
Limor Bergman: My pleasure.
Kovid Batra: All right. I know you are super passionate, super powerful. I get that vibe. And, I just want to understand what’s your daily dose of energy, like what keeps you going every day when you wake up? What is it that pushes Limor to, like go up?
Limor Bergman: Yeah, absolutely. That’s another great question. So, I like going to the gym. You see, my hair is a little bit wet still because, I just I got back from the gym about an hour ago. So, my daily dose of energy is just running. I actually discovered running, you know, when I was in university. So, I was going to a gym there. But, I stopped for years, you know, when I got married and started a family, I have four children. So, you know, it was hard and I kind of was very inactive. I lived very sedentary lifestyle. In the beginning of my forties, I really wanted to change that. I couldn’t believe I will be able to run. You know, I had those limiting beliefs, it’s impossible for me to run, but I actually worked on breaking those beliefs and started running and found out that it’s a great source of energy for me. It motivates me. It gives me not just motivation, but a lot of strength, a lot of joy. So, that’s kind of my daily dose, either running or just doing weightlifting at the gym, meeting with people, you know, that I already know. That’s what keeps me going.
Kovid Batra: Cool! All right, Limor. Thank you for this fireside chat. And I think we got to know a lot more than we already did about you. So, that really helps.
Now, moving on to the main section, uh, wherein we want to talk about a lot of things. But, we’ll keep our curiosities in our pocket and try to restrict it to a few questions. Can I get started with you there?
Limor Bergman: Absolutely.
Kovid Batra: All right. First of all, it’s already out there, and I really appreciate from the bottom of my heart, the kind of push you are giving to the women in tech. Really hats off to you. We know that this journey is different for a woman in the tech industry. How do you think it is different from the male counterparts? And, what you really think should be done about it?
Limor Bergman: Multiple reasons. I mean, first of all, we are still outnumbered. So, there are fewer women in tech compared to men. When I started my career, for years, I was the only woman working surrounded by men in my team. I was the only woman. It wasn’t terrible. Don’t get me wrong. And, I worked with wonderful men, very supportive. I learned a lot from also very supportive managers, but I felt different. Felt like, “Okay, I’m not exactly the same.” And, sometimes it was harder for me to feel a sense, a sense of belonging, right? Because the men, they wanted to do different things to hook up after work and maybe not everything interested me. And so it’s, it’s about belonging and feeling like I belong, I’m worthy, I’m like the rest of them. Men tend to be very competitive, ego-driven, not a bad thing. I’m not saying that negatively, but it’s like, “Okay, I’m better than you.” Like, they have this tendency to really thrive from competition. I don’t know if you’ve seen that, but men have this tendency.
Kovid Batra: No, definitely that’s there. It’s just that I’m keeping my thoughts to myself and listening to you.
Limor Bergman: Yeah. And for women, at least for me, less so. I thrive by growing and becoming a better version of myself every single day. I don’t care much about how I am compared to others rather than to me. And that, like having those different mentalities, it’s sometimes difficult because I don’t want to compete with someone else. I don’t want to prove anyone that I’m better, I don’t need to necessarily. That can create a lot of uncomfortable feelings. Sometimes confidence issues, when people make comments, not in a mean way, but just that’s the way to communicate because they want to show how better they are. You know, so a lot of more differences, you know, women, you know, create life that comes with its own set of challenges. So, I think that the mentality and the way of communication, and the way of work is kind of very, very different. And the fact that we are outnumbered.
Kovid Batra: Yeah. But, what do you think exactly can we do about it? Actually, that’s something which is a long-term, long-held problem. What do you think today.. I think that ratio has definitely changed from the time probably when you joined as a leader or a woman in tech. Now, it has changed. But, what according to the current scenario can be done around it to solve this problem?
Limor Bergman: I think, first of all, it starts with awareness. Even if you have a team that most of the team are men and there are fewer women, just take that into awareness that how can I make the women in my team feel like they belong, feel comfortable? What can I do to support them and be sensitive to them, to what you say or don’t say? You know, I remember I was deeply, deeply demotivated and hurt by just code review comments that people wrote me because they wrote it in a way that was not sensitive enough. It was like very blunt. Again, nothing, it’s not a bad intention, but it can really hurt confidence of someone when you make a code review that is very, maybe you’re right, or maybe you’re trying to make a point, but it can really hurt the confidence of a woman or even what you share in a meeting and how you, how you talk. If you’re telling someone ‘you’re wrong’, if you use strong words, right? When a woman starts to express an opinion and you kind of contradict her, or maybe talk over her, that can really hurt her confidence. So, just awareness and being a little bit more sensitive can go a long way.
Kovid Batra: Yeah, I think so. That could be the first step, right?
Perfect. Anything else that you have felt in your journey as a woman was different and could have been done differently?
Limor Bergman: I mean, I wish I had met more mentors in my career. You know, when I started, I felt, as I said, I mean, I was always pushing myself forward, but I felt a lot of times confidence issues and whether I’m good enough. I think having more mentors could have helped me with acquiring knowledge, with learning better and faster, with feeling worthy, and probably advancing my career even faster than I did.
Kovid Batra: Do you think does the same problem exist right now for the women of this gen? Like, right now?
Limor Bergman: Yes. But luckily I think that they are, because, you know, it’s a complete different generation. There are a lot of online communities for women.
Kovid Batra: And there are influencers like you who are now helping people.
Limor Bergman: There are influencers like me, that’s true. There are communities. I think that mentorship, sponsorship, you know, all of those things that I didn’t even know existed when I started are kind of the norm. I mean, and I volunteer, by the way, I volunteer in organizations in women-related mentoring organizations. So, yes, there is still a need, but I think that there is more awareness both from the women’s side and also, you know, there are different communities and organizations that support women, both paid and unpaid, by the way, which makes a huge difference.
Kovid Batra: Absolutely. Absolutely. It is critical, it is very important to have a mentor, be it a male or a female. But, how did you find it difficult for a female to find a mentor at that time? Like, again, is this just because of the gender difference or is it in general, like, women don’t have the tendency to go up to a male mentor and talk to them? What exactly is that?
Limor Bergman: I think that, back then I didn’t even think about that in, I didn’t even think that I may need one that even the word ‘mentor’ was not something top of mind for me. So, I didn’t even think. I was occasionally asking, you know, people for help, right? For, “Oh, can you look at something?” Or, “Can you help me?” But, I always felt uncomfortable. I think, I don’t know if this is a generic women thing, but I personally have a tendency that I’m always happy to help others. I feel less comfortable asking for help. And, I think that’s like the main, maybe barrier that if women feel uncomfortable asking for help, eventually that hurts them.
I was afraid of asking, afraid or uncomfortable, and also was worried whether asking for help is going to be seen as a sign of weakness, maybe I’m not as good, you know, because I don’t know something. Is it okay to tell my men counterparts that I don’t know something? That I haven’t heard of a term? Like, if I’m new, and I was new in many teams in technologies that I didn’t know, and like, is it okay to say I have no idea what you’re talking about? You need a certain strength and confidence to be able to say that.
Kovid Batra: Makes sense. Makes sense. But I think that, that problem of insecurity even lies with the men, I think..
Limor Bergman: Absolutely.
Kovid Batra: Even more there sometimes because of the “alpha” ego and that we carry. So yeah, I totally relate to that. But yes, acknowledging it and overcoming it, and then probably finding a mentor is the right way ahead.
You just mentioned like, people have to be more sensitive when there is a woman in the team and try to be adjusting and offering help. One more thing I realized right now, like it’s a biologically also, it’s a very different journey, right? Like, we can’t give birth to babies, right? Unfortunately. But, that is a time when I know a woman has to choose between work and personal life, right? And I’m sure you have had that point of time in your journey also. How did you go through it? What’s your piece of advice as a mother and a woman leader to the aspiring woman leaders?
Limor Bergman: Wow! That’s an incredible question. So first of all, I am a mother of four children. And, my oldest is 19, and I have a 16-year-old, and my youngest are twins, they’re 13. And, I worked throughout my career. So, it is possible. I worked and I advanced my career. Children are not a barrier. It depends what you prefer and what, you know, it’s very personal. I would say that it was not easy for me, and as you said, like, choosing. It shouldn’t be that way. I shouldn’t need to choose between career and family. Because men don’t have to, right? I mean, there’s a mother and there’s a father. Why should there be a difference? I know, yes, we give birth. Yes, we stay with the babies a little bit. But, why should there be a difference? And, there were times in my life, actually, there was a time before I was planning my second child that I was very unhappy at my work and I was debating with myself and with my husband. What should I do? Whether should I leave and find another job and start someplace else? Or should I stay and expand the family? My husband was very supportive, and he told me that’s my choice to make. But, why would I need to make that choice? If I was a man, that wasn’t the question. The men would leave and find another job and extend the family. But a woman, like if I’m planning to expand, I felt uncomfortable even interviewing for a company, knowing that I may be pregnant or may be pregnant soon. And, why should it be that way? It shouldn’t. And I do see a change. The good thing, I do see a change, but not frequent enough and not enough that employers sometimes, you know, even higher women knowing that they are pregnant, talk more freely about it and say, that’s not a problem. Join here, start and then go take care of your baby and come back. So I do see some employers do that, but I, I guess what I would like to say is don’t look at it as a barrier for employer sides, for manager side, and try to be more open-minded. It’s not like a problem. It’s natural cycle of our lives, right? I mean, expanding the families and women, we are very capable. We are capable of doing so many things, taking care of our kids and our careers, and doing everything. And, we do it very well and we know how to manage our time and be very, very effective. So, trust us that we know what we’re doing and don’t treat us as like, Oh, you know, “She’s having a baby, so she cannot do that.”
Kovid Batra: Yeah. I totally feel that. I respect my parents, but I have a little more respect for my mother, because I genuinely feel the kind of like, a, it’s a naturally built thing and it is hard physically and mentally and you still fight through it. So, you are better warriors, maybe you are the gladiators. The hard reality in the industry is people seek profits and when it comes to work, people forget, like we need to be sensitive towards such things. But I hope, I wish, with this messaging, with these kind of thoughts, we are able to change a few more lives.
Limor Bergman: Absolutely.
Kovid Batra: All right. That was really intense and interesting. Let’s move on to something that I think the audience would also love to know. Like, coming to the core work thing, like how do you deal with situation of fast-changing technology in your engineering teams? So basically, what kind of challenges you face? How do you deal with those challenges? Can you just give us a few examples?
Limor Bergman: Absolutely. So, as I said, right, I started with the story that I started with COBOL and I moved to Java. I didn’t know anything about Java, nothing. And, it wasn’t like today that you have so many online trainings and courses and so easy to learn something new. And, I just had to learn it basically by myself. There are some books. Yes. But I had to learn for myself and ask a lot of help, right? I mean, be willing to ask for help. I was joining a team of super-smart people, very talented and much more experienced than I am. So, don’t be afraid to ask for help, I guess. And, be always willing to learn. And then I, I moved from, as I said, I started with Java Applets, and then moved to backend to Java enterprise edition. It was back then in infancy was the hot new thing. So, don’t be afraid. Don’t be afraid to learn. We are constant learners. Technology changes so fast. And, if you are not willing to adopt and to learn, you will stay behind. You will stay behind, I’ll tell you that. You know, I took a challenge, you know, when I moved to Sun Microsystems, not at the beginning, but, but after about a year, I joined a team that did real-time Java. So, I actually had to dig into the virtual machine itself, and handle with real-time threads.
So like, I’m not saying I’m the bravest and smartest. But, I wasn’t afraid of trying, of getting into very, very uncomfortable situations. So, just keep on evolving and learning. I mean, never be afraid of a challenge. Be willing to learn and grow, stay up to date, and don’t be afraid to ask for help.
Kovid Batra: Perfect. Now, let’s say, as an engineering leader or an engineering manager, you’re working on a project and you feel that this new technology would be more supportive to the requirements of the business, and you have to take this hard ball of maybe branching out and working on this piece. Before you do that, this can go both ways. Like, it can become a problem in the fast-paced growth of a company, right? You’re adopting a new technology, then you have to skill up and do things. When you take this call, what all considerations come into your mind? How do you lay out that structure that, okay, now we have made a conscious choice, made a conscious decision that this is the right thing or the right technology to go forward with? How do you do that?
Limor Bergman: I think you start with the first, what you’re trying to build. You know, what do you need, what technology to use I think you need to assess, you know, what is out there, maybe what other companies are doing, what is industry standard, you know, be always, you know, on top of what’s going on of the trends and choose a technology that can provide you with solutions to the problems you need in the best and fastest way. And, a lot of times engineers are married to something, right? Because they, that’s what they know. So, there are, you know, I had like, engineers that wanted to use a certain database just because that’s what they know. Is this the right choice? Maybe not always. So, ask yourself, I’m just taking a database as an example, am I choosing it just because I know it? Or I have some, some favoritism for this? Or is it really the right choice for what I need? So, make a list, those are the requirements. And, consider several options. It’s always good to consider multiple options before making a decision, not just one. Try to remove the bias. Make it more data-driven rather than opinion-driven.
Kovid Batra: Yeah. I think getting rid of that bias automatically opens your mind. And, then get down to the point where you, you know that, okay, this is beneficial for the business, this is what we need in the next six months as a product. So, then you start thinking that way. Otherwise, I think it’s, if you go by the gut, if you go by the instinct, then of course you would do something that you already know. So yeah, it’s very important to get rid of that bias and then take a decision.
Perfect. Next thing that I would like to ask you for anyone, how should one progress in the career in tech? Like, how one can make the best choices for them? And especially, I would love to hear a perspective again on the women in the tech industry, like how should one progress in the career and what, how should they make the best choices for them?
Limor Bergman: I mean, that’s a hard question to answer because it’s very generic, because I would say, at first you need to be deliberate about what you want in your career, and what interests you, what you’re passionate about, how do you see yourself in a few years. I didn’t always know that. I remember when I was promoted to a staff engineer at Sun, that was when the career kind of progression was split between management and IC track. And, you know, I was on the IC track. My manager decided that, you know, that’s the right next step for me. But, I actually started doubting whether that’s what I wanted. Do I want to become a specialist? Do I want to continue being a software developer for the entire career? And I realized that no, I didn’t, and I wanted to, to become a manager. It took me several years to do that, just because I wasn’t really thinking about that strategically. So, be strategic and then find opportunities to build the skills that you need in order to move forward towards the direction you want. Whether it’s learning new technologies like I had. I had a client who wanted to move to machine learning and artificial intelligence. So, they knew what they wanted. So now, it’s about, okay, how do I learn? How do I find opportunities to meet people? And with that knowledge, build a network, contribute to open source, whatever. I mean, just you have to be deliberate about what you want and start building a plan towards that.
Kovid Batra: Makes sense. Makes sense. So, having a clarity on what we exactly need, and what, where we want to be based on that, the choices should be made. Yeah, that makes sense.
Perfect. This is my last question to you. Now you have been coaching and mentoring multiple engineering teams and engineering leaders. How do you define the success of an engineering team, and how do you measure it? How do you make sure that while you’re thriving for success, You’re taking care of the developer well-being also, you’re taking care of their experience, so that at the end of the day, your team is happy and motivated to do whatever you want to do as a team?
Limor Bergman: Yeah. So, there are multiple things, right? It’s about culture, motivation, and all those soft things. And there are productivity, you know, effectiveness and those things that, that you want to measure. I think, about soft areas, the motivation, it’s about connecting with people. It’s about caring for them. It’s about knowing how to ask the right questions constantly being interested in them and their career aspirations, what interests them, what they want to do, what they like doing, what they’re good at and helping them thrive, and building those connections.
About the team, whether they’re productive or not, there are different areas to look at that. So, you can look at quality, you can look at reliability, you know, there are different aspects, development speed, how predictable you are as a team. And, the best way to know that is to measure and look at data. So like, bare minimum, like when you run a team, use a tool, could be JIRA, whatever, I mean. And, start estimating your work, story points, whatever you want, doesn’t matter, you know, whatever works. But, start, you know, estimating, and then compare how much time it actually took to you to deliver versus, you know what you thought. Do retros and, and constantly improve, because you want to see how good you are with estimating, how predictable you are as a team.
I also, you know always looked at what was not planned. What kind of work did we do? And, I was forcing engineers to put in JIRA, I kid you not. Tags of this was not like, I don’t remember the tag you use, but like, this is something new that came up because it was important. And I explained to them, always explain the why. I explained, “That’s not because I want to spy on you, but it’s because I want us as a team to understand what are the things we haven’t expected and how much buffer do we need to take to those unexpected things that will come up.” Right? Eventually, we cannot avoid all of them. Maybe some of them we can.
And then, you have to measure things like mean time to deliver, mean time to recover, all those, you know, measurements that you can do with different tools to know how effective you are as a team, how fast can you develop a new feature, how fast can you find a bug, how fast can you recover from an incident. So, you have to measure all those things, and constantly thrive to be better.
Kovid Batra: Makes sense. Makes sense. This really helps. And with that, I think, we have come to the end of our show today. I would have loved to talk more on a few topics that I’m really interested in, but in the interest of time, like we’ll have to close here.
Any parting advice for our audience?
Limor Bergman: I mean, parting advice I would say based on all I said here, just continuous learning and growing, it’s a journey. And then, don’t be afraid. Don’t be afraid to fail. Take challenges and ask for help. It’s part of growth.
Kovid Batra: Perfect. Thank you so much, Limor. It was really a pleasant experience having you here.
Limor Bergman: Thank you so much. Kovid. It’s been a pleasure.
In the recent episode of ‘Beyond the Code’, Host Kovid Batra, welcomes Peter Kristianto Widjaja, Co-Founder, and CTO at Hubble.Build, Singapore. The focus of their discussion revolves around ‘Leading Tech Teams from 0 to 1’.
The podcast starts with a fireside chat with Peter, providing us a glimpse into his personal background. Moving to the core discussion, he offers an overview of Hubble.Build and shares the challenges he faced in his engineering journey. The conversation then takes a deeper dive where he discusses the importance of ‘Purpose-driven values’. Further, Peter sheds light on 360 evaluations and the importance of psychological safety within teams for measuring their well-being.
Peter concludes by offering parting advice to the audience.
Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. I’m back with another episode and a new amazing guest who’s an entrepreneurial soul from Singapore. He’s the CTO and Co-founder of Hubble.Build. And also, he is one of the youngest leaders so far on the podcast. Great to have you here, Peter.
Peter Kristianto Widjaja: Hi. Hi, Kovid. Hi, everyone.
Kovid Batra: All right, Peter. Thank you for coming on the show. And, as a usual format, we have this quick fireside chat with every guest of ours. And here, we would be knowing a little more about you personally. All right?
Peter Kristianto Widjaja: Sure. Let’s go. Let’s do it.
Kovid Batra: Perfect. Perfect. So, let’s get started. All right. So, tell us about your first production blunder.
Peter Kristianto Widjaja: Oh, hmm, okay. Well, production blunder…I guess it’s when the company was still small, right? So, it’s about 2017, 2018. We were running a very small engineering team, about three people. Everybody doesn’t know what’s a good engineering practices and we really prioritize speed over other things, you know? And, some of the points, you know, there’s some bugs on productions that happened. And as a CTO, obviously I have production access, I’ve root access last time to everything, and we tried to make a very quick fix for our customer because it was a business critical issues and it made things worse. Classic, right? And yeah, the customers scold us for a good few hours, the CEO has to hear all the customers making noise to us. And yeah, yeah, that’s pretty much, you know, and then we learn our lessons and then we know, “Okay, no more”! Right?
Kovid Batra: How many calls did you get from the customers that day?
Peter Kristianto Widjaja: How many what? Oh, oh, dude, don’t, I mean. I guess it’s just… okay, the good thing, it was, we’re still small, so it was just one customer, but it affects a lot of users within that customer. But, yeah, we have to say sorry for about 2,000 times that day, I guess.
Kovid Batra: That’s the best thing you could have done.
Peter Kristianto Widjaja: Yeah, I mean, but we managed to, I mean, we have backup. Luckily, we have backup, so we managed to sort of roll back things. But it took a while because everybody was not seasoned, yet at that point, yeah.
Kovid Batra: Sure, sure. I mean, I see that there’s a lot of energy, you’re young, but still, there must be some daily kick for you, daily source of energy that gets you through work I would love to know about that.
Peter Kristianto Widjaja: I mean, obviously the first thing in the morning is a cup of coffee. So, you get your caffeine kicks. That’s the first thing, the most important thing for all engineers. Well, I’ve been doing this with this company for about, six, seven years, right? Since it started. Obviously, you know, it takes a lot of things to keep it going. And, you know, sometimes you have just no motivations to wake up and like, you know, the same things that you were building a few years back, it was still at a stage, you still need to do something. But for me, it’s the people, right? So, we have grown so much that now I have a lot of people in the company, and you know we are doing great things. Everybody’s so talented in the team that it just makes you feel like, you know, it’s fun, right? Because everybody just heads down, talk about ideas and implementing it. Obviously, there’s the not so fun part about, like deadlines and all those things, but yeah, I mean it comes together, but it’s fun.
Kovid Batra: So, it’s people for you then.
Peter Kristianto Widjaja: Yeah, it’s people.
Kovid Batra: Perfect, perfect. All right. One last thing. What’s your favorite go-to video game?
Peter Kristianto Widjaja: Well, I’m an old-school guy. So, I still play Dota pretty often, and not that often, but it’s too often for my wife’s liking.
Kovid Batra: Got it.
Peter Kristianto Widjaja: I should… You know, yeah, well, yeah.
Kovid Batra: Well, great then! Great. Perfect. So Peter, this was great knowing you. These were some fun things that we got to know now. Now, moving on to some important substance. We know what Hubble.Build does, but for our audience’s sake, first of all, I would love for you to tell them what Hubble.Build does.
Peter Kristianto Widjaja: Cool! So, Hubble.Build- we are a construction tech startup. We are based in Singapore. We are mainly providing a lot of solutions, B2B SaaS, especially for the different construction companies, here in Singapore and Southeast Asia. We’re looking into essentially digitizing, automating, and obviously at the end of the day, doing more of insights, for our customers. Yeah. So, it ranges different operation and verticals in the industries.
Kovid Batra: Thank you. Thank you, Peter, for that introduction. So, now my question is, I personally have been an entrepreneur. I have seen that journey, but unlike you, I mean, this journey of 0 to 1, my experience is a little less than you. So, I would love to hear your experience, how it has been starting from a garage, because last time when we were talking, you told about this. It was just three members and now scaling it up, having around 40 dev members. So, this is definitely a journey and it’s almost been a decade for you into this, right?
Peter Kristianto Widjaja: Yeah. Yeah.
Kovid Batra: So, how has it been? Let’s start with some of your best experiences of this journey. The most challenging experiences of this journey.
Peter Kristianto Widjaja: I mean, you know, as a Co-founder/CTO, starting with three people and now you’re leading about 40, the whole company is about 70, 80 people. It’s about that transitions of like, you gotta, I would say adapt, and your role keep changing as the team grows. You know, when, when we started with three people, essentially I’m an engineer, I have to code, right? Everybody, like me and my, one of the other engineers, we have to code and I have to go deep into the backend, the frontend, everything. Every day is about code, code, just keep developing and launching new products. When in which 10, it’s about being a team lead and a manager, right? So now, you have these 10 people and you gotta make sure they are happy and everybody is aligned with what they are doing. Now, you grow into 40, it’s a different ball game by itself. And, each transitional period needs a lot of self-reflections, and also just humility just to know that, “Okay, I’m not good at this. I gotta improve on this.” But, if you are the person that, say, likes coding, right? At, you know, 40, you’re not gonna code most of the time, right? So, you gotta be like, okay, you know, you pick your poison. Obviously, you still can code outside of your most responsibilities, but you have to understand that your main responsibility is not to code anymore, it’s to inspire and direct the vision of the team. So, I guess, I guess that is the most challenging part Yeah.
Kovid Batra: Doing that transition from being an engineer to a leader is definitely a transition.
Peter Kristianto Widjaja: It’s crazy.
Kovid Batra: And, I think it doesn’t come easy, particularly with the engineers, right? They have this habit of just coding, being with their laptops and desktops. So yeah, it definitely is. So, let’s talk more about some of those incidents where you actually had to change your daily habits or behaviors while you were working as an engineer to a leader today. Let’s talk about those, some of those challenges.
Peter Kristianto Widjaja: Yeah, yeah, again, I guess the journey from 0 to 1’s and obviously 1 to 10’s is going to be very different between, you know, one community to another. For me, um, it’s when I think we reach, let me count, 1, 2, 3, 4, 5, 6, about 6 people in the engineering team. That’s when, you know, I’m still heavily coding and then what I realize is that people are just doing their own things, right? And, there’s a lot of miscoordinations with regards to what we are building, how we are building it, and somebody got to take charge, right? Somebody has to make sure that, you know, we do have product managers at that scale. So, somebody has to lead the product, talk to the CEO, most likely the CEO leads the product, right? But, you know, but the CEO also has to do sales and all the other functions. So, somebody got to step up and make sure that there’s a lot of coordinations and we are building the right things at a point in time, you know. I guess that’s sort of the trigger and like, “Okay, I can just keep coding. I got to, like you know, do something else, and should I hire someone to make sure that I don’t need to put that much anymore?” That question start to come to mind. And, you will realize that because you feel unproductive at the start, that’s what I felt, when you know, you’re not really code anymore, you don’t write anything, you’re not developing anything, but you’re just talking to people, writing some documentations, you know, setting up infrastructures, talking to AWS guys, you know, all these different people.
Kovid Batra: Right. Right.
Peter Kristianto Widjaja: And you feel like, “Hey, I’m not producing anything.” But, you realize then, your team actually is moving faster, because you’re building the right things, everybody’s on the same page, everybody’s happier in general. And that’s, I guess, I guess that’s a trigger for me. And they’re like, “Okay, I guess that’s how my role has changed.” Yeah.
Kovid Batra: No, it makes sense. Actually, there is a point when you start leading teams, the motivation for you is to make them work without any friction. You start working as the oil for the team. So, your efforts start becoming the oil for the team and that’s what your daily motivation should be. So that’s cool. I think I can totally relate to it.
Peter Kristianto Widjaja: Yeah. Yeah.
Kovid Batra: Perfect. Perfect. All right. Apart from this, for Hubble, I’m sure that this journey of 0 to 1 involves this very important step, which we call as ‘product-market fit’, right?
Peter Kristianto Widjaja: Hmm.
Kovid Batra: So, back in that, like 10 years back actually, when you started this, what was the landscape like? Why did this idea come up and how did you figure that out that, “Okay, this is something that the market needs and this is what we need to build.” And, how as a technical Co-founder, you contributed there, because that’s a very important piece. A lot of engineers, a lot of technical Co-founders skip on this step of realizing that how they can drive the business impact. So I would love to hear that from you, how you did that in that 0-to-1 journey.
Peter Kristianto Widjaja: Yeah, Well, it’s gonna be quite a long story, but you know, I’m trying to…
Kovid Batra: No worries, we have time!
Peter Kristianto Widjaja: Yeah, I tried to make it, you know shorter for this. So, we started out actually just building different projects. The company was not building what we are building today. So, we are more of like an agency at the start, you know? So we’re building different things, right? And, one of it was for constructions, and that time was more for manpower tracking. We got this from a construction company, obviously. And that’s when, you know, as we’re building it, we’re realizing that, “Hey, the solutions in the market are not that great.” Right? There’s opportunities… I thought, you know, it was kind of, when I look at a product, I was like, “Hey, I think the market should have this kind of solutions already.” Right? It’s just natural. But again, construction is very backwards. Even until now, it’s sort of at the same level with agricultures, and like mining industries, and all those industries. So the adoption of new technologies is taking a while. So, it started with a real problem. So, we’re not inventing a problem, it’s actually a problem in the industries, and I was just making sure that the product actually solve that problems we are highlighting the values. And with that, we start entering the industry, we talk to more people and realize the bigger issues of things, like really there’s nothing that is automated, there’s nothing that is digitized, everything pen and paper. And, we can’t really do anything because there’s no data for us to do anything right? So, the first step is to collect those, create infrastructures for people to at least have a digital space and database of things. And then, we can start doing more things and enhancements on top of it, like analytics and all those productivity stuff. Yeah.
So, that’s sort of how it grows. So, it’s pretty organic at the start. Again, we didn’t take venture fundings or like institutional capital funding at the start, until about 2020, that’s when we get our Series A. Before that, we’re just really reinvesting on our profits, so, we really grow organically by talking to the users. And, what we realized is that everybody got to talk to the users at the start, right? And, this is what I preach, or not I preach. This is what I sort of try to envisage in the company as well. As an engineer, you got to know what you’re building, right?
Kovid Batra: Yeah.
Peter Kristianto Widjaja: And it, it, it’s not, you know, we, when we hired engineers we take time to sort of make them realize that it’s not just about doing the tickets that the product managers create for you, right? A lot of people, when they come in, they will just like, “Okay, I have this ticket. Let me just do it. I read it. I’m done. Push it. Somebody reviews, merge and stuff.” But, it goes beyond that because you need to know a few things, right? You need to know who you’re building it for, who’s going to use the product. And, what is it for? And, why they need it? Because the way you build it is going to be different, right? And, my point is that, yeah, you can have your product managers, product designers, and you know, they all work so hard to figure out the user experience and all these things. But, as the engineers, you need to really understand what you are building as well by talking to the PMs and the UI/UX about what they have been writing and designing. And then you build it in a code, right? In our company we call it the ‘purpose-driven values’. It’s one of our core values that we always talk about. So, essentially what I did now is, I just do some random conversations with my engineers and I’m sort of, I ask them like, “Hey, what’s up?” “How are you doing?” “Okay, what are you working on today?” And then they will, like start explaining what they’re working on and I’m like, “Oh, why are we building that?” And, if they can’t answer, I’m like, “Okay, you go and ask your manager and you get back to me.” So, there’s a bit of, you know, just random checks here and there. The one answer that I hate, that I always tell them I hate is that when they say, “Oh, because whoever says I need to build this.” Or, “PM wants me to do.” I’m like, “Dude, okay, figure it out.” Right?
Kovid Batra: Yeah.
Peter Kristianto Widjaja: Yeah.
Kovid Batra: No, I think this is really amazing. And, with all the previous conversations that we have had on this podcast, this has been highlighted multiple times. This purpose-driven building from the engineering teams has to be, like ingrained. That doesn’t come naturally in the dev team.
Peter Kristianto Widjaja: It’s not, yeah.
Kovid Batra: So, it’s a very good point that you understood and realized it as a Co-founder in the early stage and then you could actually, okay, preach actually in the teams and then make sure…
Peter Kristianto Widjaja: Yeah.
Kovid Batra: It’s, it’s kind of that only, and it’s really cool. I think this is one amazing thing which every tech Co-founder should keep in mind, and should make sure how things are proceeding ahead. Amazing. Amazing, Peter.
All right. And now, there is something which I would love to know from the current scenario. So, now you’re 40-devs teams, right?
Peter Kristianto Widjaja: About that, yeah.
Kovid Batra: One thing you already mentioned that you are trying to bring in that value of purpose-driven development, right?
Peter Kristianto Widjaja: Yeah.
Kovid Batra: But, there are more aspects when you have to handle a 40-member dev team, right?
Peter Kristianto Widjaja: Definitely.
Kovid Batra: You have to take care of their experience, you have to take care of their well-being, you have to take care of whether they are being efficient or not, because on day-to-day, even if you align them with the business goals, you give them those values. Still, you just need to like make sure how things are moving.
Peter Kristianto Widjaja: Yeah.
Kovid Batra: Are we really moving on the right track or not? Because sometimes you tend to deflect, right?
Peter Kristianto Widjaja: Yep.
Kovid Batra: So, in simple words, how do you measure the overall well-being of your teams? That’s my question 1. And then, how do you ensure that they are being efficient at the same time? So, that’s a thing that we would really need to know.
Peter Kristianto Widjaja: Yeah. Yeah. I would say that’s a million-dollar question, right? You know, I mean there’s a lot of literature on that. I mean, the infamous literature from McKinsey, you know about it. It’s tough, right? Because we’re trying to measure something that is intrinsically hard to measure into something that is chewable as a management to just see. But in, in Hubble, essentially we are looking at a few things. So, one is obviously the team structure itself, you know, how we put the different middle managers and make sure that they’re not overwhelmed with, like 30 people, for example, like one person leading 30 people. So, we always keep it about 8, a maximum. Yeah, it’s about 8. Max is 8. Some people are definitely less than that. And, make sure that everybody knows that you can talk to this guy about anything. So, that’s the first one. Second, well-being… So, we have two approaches here, right? So, one is what we call the metrics and KPIs. And, second is the qualitative, right? So for qualitative, we do this thing called the 360 evaluations. And, this is obviously something that we built with HR in terms of like, “Okay, we need to have these routine checks, 360 evaluations of all the people.” So this is actually the only time for individual kind of measurements. And, when we talk about KPIs later, everything is at squad and team levels, there’s no individual metrics. Right? So, the only individual evaluations that we get is from the 360 evaluations. And, this is where people will, okay, how can everyone improve, right? So, the idea is not to rat people out that they’re not doing their job, but it’s more of like how each one can improve, what they feel they’re doing well, what they feel they need to improve, and what they feel they need to be stopped doing. Right? And it includes me.
Kovid Batra: Can I ask you a question here?
Peter Kristianto Widjaja: Go ahead.
Kovid Batra: Sorry. It’s just that I’m too curious to know a lot of things. When you say that you’re doing this 360 at the individual-level, do these people know that when this feedback is collected, their names would be there along with that? So, let’s say, I’m one of the developers in the team.
Peter Kristianto Widjaja: Yup.
Kovid Batra: I give you my feedback around all the questions or survey questions that you ask. So, do I know that my manager would know that this is a feedback from Kovid?
Peter Kristianto Widjaja: Ah, no.
Kovid Batra: Perfect.
Peter Kristianto Widjaja: Okay. So, the way, the way it goes is this. So there is the, what we call the manager feedback. So, the manager gives feedback to the team, the individual people in the team. That is obviously transparent because the manager has to say to the team.
Kovid Batra: Ya, of course.
Peter Kristianto Widjaja: And then, there is the peer review, which is between the team members. And then, there’s the upwards review, which is team members evaluate the managers.
So, for peer review and upwards review, it’s all anonymous. The only one that knows is the HR, and then basically, HR will come up with this report, which is just the evaluations and the summary of all the different scoring and the qualitative feedback, but the names are not all there. Yeah.
Kovid Batra: Got it.
Peter Kristianto Widjaja: So, the idea is that, again, we want a very candid, very open.
Kovid Batra: Exactly, that’s what the point is that if they know that this is going to be, uh, non-anonymous, then they would hide away the real facts, they would not come up with things. So, that’s what my concern is.
Peter Kristianto Widjaja: The thing is this though, sometimes with the qualitative feedback, because you’re so close to your team, you know how they write.
Kovid Batra: Ya! That’s definitely there.
Peter Kristianto Widjaja: So, I mean, I was, I was reading my own feedback because I get my managers to feedback to me and I’m like, “Oh yeah, this is from this guy.” Like, I can really figure it out from the way he write, but again, like we established such a relationship that is okay.
Kovid Batra: Exactly!
Peter Kristianto Widjaja: Like, that culture has to be open enough that I tell my team, even like anyone can say, “Hey, you have feedback from me. Just drop me a message.” I’m okay. Obviously I can say that, but it’s still, you know, there’s so many of them, but…
Kovid Batra: Yeah, I totally second that.
Peter Kristianto Widjaja: With your direct reports, you’ve got to have that kind of relationship, because if not, there’ll be politics involved, and you know, people are not saying things that they really feel. It’s gonna trickle something. Oh wait, it’s sort of deviate from the question, but yeah.
Kovid Batra: No, I think this is very important. This detail is actually important that even if you put in systems and processes in place to measure the developer’s experience or measure their well-being, it is important to understand that the underlying psychological safety in the teams is very, very important.
Peter Kristianto Widjaja: Yeah.
Kovid Batra: Otherwise, the truth will not come up and you will not be able to identify the problem.
Peter Kristianto Widjaja: Definitely.
Kovid Batra: So, I think this is a very important point. You have to, like promote it as a founder, as a promoter of the company, you have to promote this culture also within the team, so, that totally makes sense.
Peter Kristianto Widjaja: Yeah.
Kovid Batra: Cool!
Peter Kristianto Widjaja: I mean, we have like, so I enforce the managers to have to go, have this thing the 1-on-1s with the team members, and there’s also skip levels whereby I can skip level to the seniors or, you know, there’s the different structures of skip levels. And, the thing that I enforce is that the skip levels, you are not ratting people out because, you know, when you do a skip level, somebody want to feedback about the managers, right? To you.
Kovid Batra: Right.
Peter Kristianto Widjaja: Now, you cannot say that to your managers and, “Hey, this guy says this about you.” And, you’re like, “Yeah!” That’s very confidential between, you know, the two people.
Kovid Batra: It has to be.
Peter Kristianto Widjaja: Even 1-on-1s. So, anything within the 1-on-1 stage, within 1-on-1s between you and your manager, it doesn’t go out to everyone else.
Kovid Batra: That’s cool.
Peter Kristianto Widjaja: Yeah. Well, so that’s the qualitative part, and from there, actually it’s more of the, again, the experience. Is people happy? Anything wrong with the pay or with the career progressions, with the challenges? That should be, you know, we can spot it up through the 360 evaluations and also the 1-on-1s. With regards to performance though, this is the very tricky part because people like to know, like which engineer performs better than which engineers, and then there’s like, oh, line of code written. No, not exactly! You know? And the key thing is this, when we sort of build this, we need to understand the engineering culture itself. And, with software engineering, right, it’s a very interdependent team whereby you cannot just do things alone, especially at our scale, because, okay, when you build this, it might impact another team, it might impact the frontend, the mobile end, you have to constantly talk to different people, right?
Kovid Batra: Sure.
Peter Kristianto Widjaja: And, it’s a very highly collaborative environment. If you start doing individualized metrics tracking, for example, story points completed by a person, I can get that metrics, right? I know exactly how to get that metrics. But if you start putting that as the North Star, people will not help each other. And actually, that will become worse for your company or for the team. So instead, what we are looking is actually the full team, the whole team philosophies, right? So, I’m not going to trickle down to individual guys, I’m just looking at the whole team. So, within each of y’all, doesn’t matter. So, y’all figure it out collaboratively, who is doing what, who is better at doing what. And basically, the numbers I’m looking at is the squad’s philosophy, and this is owned by the EMs, right? The engineering managers, for this particular squad, right? So that’s one, you know, we’re looking at.. Again, I’m not, then I’m not comparing between squad one, squad two, squad three, how come velocity’s slower? What I’m looking at is your progress, your trends. If suddenly there’s a dip, you’re slowing down, I want to figure out why. And the idea is not to penalize you, but let’s figure out what we can improve on. And obviously, because there’s a lot of things, like the kind of problem statements that each teams are handling is very different, the number of members are different, so you can’t really put a benchmark, “Oh, everybody got to achieve like 40 story points.” Like, it’s, it’s very, it’s, it’s nonsense. Now, what we’re looking at as well is, because one of the values again is accountability. We are looking at the number of stories promised, or like putting into the sprint versus completed, because what we want is, “Okay, we are evaluating on overestimations or underestimations.” You know? And, making sure that when the PMs, say, or engineers are not doing their work, you have a data, all right? And, how to improve on that. We are as well looking at things like ‘backs per stories’. So, backs per stories is very interesting. It’s something that we just really built the infrastructures. It’s more of like, because we want to increase velocities, but we don’t want that to hamper the quality, right? And with backs per story, it’s very interesting because you know if people are rushed. So, that’s what we are looking at. So, if you are rushed, you tend to just quickly get it out of the way, hack things out, but you have like 2,000 backs, right?
Kovid Batra: Yeah, correct. Quality gets compromised there.
Peter Kristianto Widjaja: So, Yeah. So again, and it’s for the managers to say, “Okay, I’m rushing too much.” Right? So, let’s work with the PMs or with whoever stakeholder’s involved to like, “Hey, my team needs a bit more time. We’re not going to hit it because everybody start doing things very fast. There’s a lot of bugs being churned out.” And, obviously there’s a lot of miscellaneous things like, you know, code churn rate, at the macro level. We have code review durations, which is sort of like, we don’t, like, a lot of the blockers was like, “Oh, somebody’s not reviewing the code.” You know? And stuff. And then we, “Okay, tell you what, let’s have measurement on this and how to improve the process for code reviews.” Something that is very interesting whhich is developed by my previous VP of engineering was the ‘commit push time’.
Kovid Batra: Okay.
Peter Kristianto Widjaja: So, at which time of the day the commit is being pushed. So, what we’re trying to look here, and as well as the line of code changes distributions. No, so, basically what happened with these two metrics, is that it requires a lot of context of what’s happening with the team. So, you cannot just put a blanket context, and then just, oh, if you are like, who is, like the most, the highest contributors with the lines of code? It’s not like that. So, the idea is that what we want to look at is technically just distribution of work, right? If you see that the line of change distributions is heavily skewed towards a single person, first and foremost, that person is a ‘bus factor’.
Kovid Batra: Yeah.
Peter Kristianto Widjaja: Right? And, are you relying too much on this person because maybe this person is so good, and you just dump every single thing on him? And it’s not distributing to other people. That’s one. Commit push time is the same thing. If you look at your engineering team and some people just keep pushing at 2 a.m., 3 a.m.. Are you being sustainable to that guy, you know? Are you pushing that guy too hard? What’s going on? Right? So, but again, some people like to work at that hours, you know? We can’t say, “Hey, you cannot push at 2 a.m.” That’s not gonna work. But it’s more, again, that’s why it requires context, because the managers will look at this and figure out, “Oh, wait, this guy, why is this guy constantly pushing at like 2-3 a.m.?” Then, he can engage, or that person can, the managers can engage, like, “Hey, are you okay?” “Why are you doing that?” “Is it your style?” You know? It’s more of that.
Kovid Batra: I think that’s, that’s pretty amazing actually, how with these metrics where you are trying to understand the efficiency of your team. At the same time, you are being very considerate about that they are not overworked, or they’re not, like doing things like that. So, that’s pretty amazing. And that’s a new way to look at some metrics.
Perfect. I think, one question here I have when you talk about the distribution of the work, right? How do you ensure, like once you identify, okay, like, this person is the one who is doing the maximum amount of work in the team, and, that can be done from various ways. One of them could be like how many one is doing the lines of code and for the team, what is the ratio, right? You can understand that. But, let’s say, you identify, what usually are your next steps? Like, how do you make sure that this thing gets better?
Peter Kristianto Widjaja: Well, technically it’s this. Firstly, what we need to identify, is this even an issue, right? So, once is that, if it’s just because this guy is super fast, blazing fast, then we can’t follow, “Hey, you cannot do too much changes.” Right? Now, if it’s actually an issue, this is when the managers and me, we gotta figure it out. And, what some of the steps is that we look at when we do the sprint planning, like how is the task actually being distributed, right? So, we want to know, it’s more of like, are we, as a manager side, relying too much on this guy or not, right? And obviously, then talk to the teams and the rest of the teams, and being very proactive and very intentional when we distribute a task and make sure that he’s not, like skewed in terms of the distributions, and ask him to chill sometimes, that works too.
Second is that sometimes there are things that comes ad hoc without the manager being aware of what’s going on, and because, you know, everybody’s on Slack, some people, like some designers or even myself sometimes is a culprit of this, you know, just text one of the engineers that I know is very reliable, and like have been working with me for a while, I’m like, “Hey, I spot this. Can you help me with this?” And then, he was like, “Okay, done.” Right? Aand more of those might translate to, you know, again, we only have X amount of hours a day, if you are doing too much ad hoc works, you’re not doing the actual product strategies, and, you know, pushing product forward. So, it’s more of that. And, it’s tough, right? Cause at one point you still want to make sure that guy is producing.
Kovid Batra: Ya, of course.
Peter Kristianto Widjaja: You know? But, you have to be very intentional because you don’t want at the same time, say, for example, you have a feature, call it feature A, right? And feature A has a lot of parts. So, what you don’t end up happening is that guy in charge of, if it’s a big features, everything about that big features. So, you have to be intentional about, okay, you work for us. Okay, let’s build this one for you and then give it to someone else. The idea is that you want another engineer to have context about that as well, such that when he is, say for example, sick or he’s on holiday, you are not screwed, right?
Kovid Batra: Right. Well, I think that totally makes sense and it answers the question really well.
Great! I think this conversation can take really long and we have so many areas to touch here. But, I think we will take a stop here. And, I would really like to thank you, Peter, for sharing your insights and thoughts about how to scale from 0 to 1, and then how to manage teams at this scale. This was really amazing.
Any parting advice/words for our audience?
Peter Kristianto Widjaja: Parting advice? Take care of your engineers and they will take care of your product.
Kovid Batra: Amazing! Thank you, Peter. Thank you so much.
Peter Kristianto Widjaja: Cool! Thanks so much Kovid for the invite.
In the recent episode of ‘Beyond the Code’, Host Kovid Batra welcomes Ashik Uzzaman, Director of Engineering of Treatment Platform at Twin Health, and the creator of 'Leader's Whiteboard' - a blog and an educational YouTube channel for engineering leaders. He has previously contributed his expertise in Marqeta, Adobe, and TubeMogul.Ashik engages in a compelling discussion focused on the theme of 'Enabling ICs to move into management roles'.
The podcast starts with a fun fireside chat with Ashik, offering the audience a glimpse into his unfiltered personality. Following that, he delves into the details of understanding the 'Why' and 'When' behind the decision to shift individuals from individual contributor (IC) roles to engineering management. Ashik sheds light on how to enable the team and support their development. Further, he dives deeper into effective leadership styles and provides insights into their effective implementation. He also emphasizes the ‘Trust but verify’ approach and leveraging metrics for the success of the team.
Wrapping up, Ashik shares parting advice for the audience, emphasizing the crucial role of continuous learning and networking in professional growth.
Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. I’m back with another episode and a special guest who is a curious soul, passionate about reading and writing, has 23+ years of engineering and leadership experience, currently working as a Director of Engineering at Treatment Platform Group. On top of that, he’s author of Leadership Whiteboard, which is a YouTube channel and a blogging website that talks about engineering leadership. So, a really good source of learning for our audience there. Welcome to the show, Ashik. Happy to have you here.
Ashik Uzzaman: Thank you. Thank you. I am humbled and honored to be with you here, Kovid. Thank you.
Kovid Batra: Thank you. Thank you so much. So, Ashik, we’ll start with a quick fireside chat, wherein I’ll be asking you two to three questions which would be more around your personal life. And from there, I think our audience and I would love to know more about you.
Ashik Uzzaman: Definitely.
Kovid Batra: Are you ready?
Ashik Uzzaman: Yeah, sure.
Kovid Batra: Perfect! Alright, there you go. We’ll start with some sports, okay? So, which is your favorite indoor, outdoor sport that you really love to play?
Ashik Uzzaman: Yeah. So, my indoor sport is actually chess. And, me and my son, we have been playing competitive chess. But outdoor sport, I’m, I’m a little bit lazy person. I’m more of an audience rather than actually player. I like soccer a lot. Yeah.
Kovid Batra: So, you watch soccer a lot?
Ashik Uzzaman: Yeah. I watch soccer a lot. Yeah.
Kovid Batra: Perfect, perfect. That’s nice. Okay, moving on to the next one. What do you think, as a leader, as a manager, is the best way to learn for people? Or, if I should ask, how do you learn your leadership style? So, when you were a manager, how did you come up with those thoughts that this is how you should manage it, manage your teams?
Ashik Uzzaman: Yeah. So, definitely learning management and leadership, the first thing will come is the hands-on experience. As you work, as you get into situations, there is no alternate of getting through situations to learn, how you manage team, you may be making mistakes and so on. But, it has to be their hands-on experience, I should say is the number one thing. I think the number two thing is the actually reading. You can read a lot. There are a lot of literatures, articles or even just watching videos, like I started a channel as I was talking about where I talk about these theories. Another thing, I think along with hands-on experience and reading is actually collecting feedback from your team members.
So, these three, if you can properly utilize together, I think will be the right way to move forward to learning leadership and management.
Kovid Batra: That’s nice. So, I think it’s hands-on experience, learning, reading, and then taking feedback from your peers. I think that’s really amazing. Yeah. I hope this has really helped you in general to improve in your life. And I really appreciate this thought. Usually people are not very comfortable with the feedback kind of thing when they themselves are managers. Feedback coming in from the team, they usually don’t take it the right way. But, I think this is a good message where even if you’re a manager or a leader, taking feedback from the people whom you’re working with, your team, your devs, I think could actually make you learn things because when, when you operate, that’s what I have also felt, like we think that we are doing it right. And almost everyone does the same way, but when feedback comes in, there is a reality check for sure.
Ashik Uzzaman: Yeah. Like you don’t watch yourself very well. Other people watch you well. So, if you can know from others, then you know where to adjust your style.
Kovid Batra: Absolutely. Absolutely. Great! All right. So, what’s your mantra for success?
Ashik Uzzaman: Yeah. So, one thing I follow a lot is that I stay hungry for knowledge, and remain humble in success. So, stay hungry for knowledge and remain humble in success. I actually have been trying, and this is my mantra all throughout my life. I don’t know if you can ever perfect the art or not, but if you are not hungry, if you are not curious, you know, you will not grow. After a certain point you’ll get satisfied, you will not grow any further. So, you have to be hungry. On the other hand, once you start getting some results, if you don’t show humility, you are going to slip from there. So, you’ll be downhill also. So, that’s my mantra.
Kovid Batra: You have to feel it, you have to feel it from within actually, like gratitude, being grateful and being thankful makes you humble. I think it’s a very good point. I think Steve Jobs had already been saying this. And curiosity, I still feel that comes very naturally to people and they develop also over a period of time. Humbleness is something, I feel is not a natural trait for people. Like, we want to be alphas, like we want to be like there, right? So, I think, yes, you’re right there. It’s an art of, like learning this and ever growing, because you’re killing your primitive feelings and subconscious there, and then coming up with a new thought process. So, it’s really nice. But, I think that what really helps is, like in general, if you feel that you’re really grateful and thankful to people, family, friends, your peers around you, I think that really makes you humble. So, when you achieve something, the first thought that comes to you is that, okay, I did something there, but this would not have been possible if everyone was not involved. So, I think, great. I think I really appreciate that thought. Very well said.
Ashik Uzzaman: Yeah, thank you.
Kovid Batra: Perfect. All right. So, that was cool. It was great knowing you there. Now, I think what our audience eagerly waits for is the learning from engineering leaders like you who have seen success failures, and past so many years of hands-on experience. So, in this section, we’ll talk about more from your experiences.
I have, I am also a curious soul, so I’ll have some questions there. So can we get started there?
Ashik Uzzaman: Yeah, definitely. Please go ahead.
Kovid Batra: Okay. All right. So, this is a very common question, but I think a lot of people find it difficult to make that move in life, which is moving from an IC role or from an, like a developer role, or let’s say senior software engineering role, into engineering management. That’s the first step towards leadership.
So, when do you think people should move there, and what should be the thought process behind it?
Ashik Uzzaman: Yeah. This is a very good question actually. Like, I have moved many engineers, individual contributors to engineering management in my last few jobs as part of, I mean, a manager of manager roles. I had to go through this a lot. So, I would say the first thing that should come into anyone’s mind, like if you want to move someone from IC to manager, or someone wants to go from IC to management role is, “Why?” “What’s the motive?” “Why do you want to become a manager?” So, there are many different reasons, but financial reason should not be the reason why you should be moving into management. Some good typical reasons that can be very reasonable is if you want to desire, or amplify your impact on project or organization. If you feel very good or happy when you see someone else being successful, rather than the product being consumed by a customer, and then, If you see that you are pretty good at strategic thinking, or maybe you have a tendency to drive organizational changes. These kinds of tendencies when you see in yourself, or if I see as a manager in someone else, these are good reason why you think this person may, you want to give them a try to get into management.
On the other hand, there is a “When?” So, the ‘why’ is the first thing you have to answer. The second thing is, you have to make sure that the individual contributor whom you are thinking to move into a leadership position, management position, are they willing to actually do it? Is there mentorship opportunities? Like, if they get into this new role, they will need help. If you are the direct manager, you have to continue to coach them. Are they ready, receptive of that? Do you have the capacity or bandwidth to do it? If not, then you should wait until you have that bandwidth. Or, if you want to wait until they gain a certain technical expertise or experience, after which you want to move into management. So, you have to think there and take a balance between that ‘why’ you want to move, which is to serve others, and ‘when’ you want to move. Is that person ready to take the challenge now, these two things, right?
Kovid Batra: I think that’s very well said, and that I think clarifies a lot of people’s doubt when they are stepping into that management role, that until and unless it is coming from within as a natural motivation. Like, one of my friends who is right now a senior engineering manager, he told me that he wanted to move into this direction because he thought that he wants the visibility of the back that he’s creating, like he want to see end-to-end what’s going on. So, I think what you are saying is also in line with that. There was a natural curiosity and motivation to see that impact, create that impact, and that’s, that’s a perfect ‘why’ you should actually step into that role.
Ashik Uzzaman: In fact, there is a book by a management guru called Patrick Lencioni. The name of the book is ‘The Motive’. And through a business fable, he explained why someone should consider moving into management or leadership role. There, he shows that you can move because of reward-centric reasons, like, you know, financial benefit and so on, or responsibility-centric reason, like you want to serve, you want to make impact and so on.
Kovid Batra: Yeah. Perfect. Yeah, I think that would be a good read to really understand the depth of this belief. I think that’s cool.
Perfect. Let’s move on to the next question, Ashik. So again, as a leader, it becomes important, and even as a manager, it becomes important to enable the team. So, when you’re a leader, you have to enable probably the engineering managers. And then, if you’re a manager, you need to enable the ICs skill up, right? What do you do to actually enable these people? Like, from a different perspective, from an engineering leader perspective and from, let’s say, a manager perspective, but what all you should be doing or what all you have done in the past to enable people who are working with you?
Ashik Uzzaman: Yeah. That’s a very good question. Thank you, Kovid. So, there are a couple of ways we can think of. It is one, enabling a team. So, you are a leader, you are an engineering manager, you’re responsible for the team, how you empower the team. Another is developing a particular person within that team who reports to you. So, maybe you want to grow them as a technical leader, you want to grow them into management position. So, when it comes to enabling the team, the way I consider is that management is at three level. Either you are a line-level manager, let’s say Engineering Manager or Tech Lead or Senior Engineering Manager, or you are a mid-level management, like Director or Senior Director, you are in a manager of manager roles, or you are an Executive.
So, for frontline managers, I think what’s very important is to see the team that you are managing, what’s their maturity stage, what’s their experience, what kind of people are there, the structure or composition. You want to enable them based on their experience, as much as they can take, and because you are a frontline manager, definitely you have to be involved in the day-to-day process.
On the other hand, when you are trying to enable or empower an individual, you’ll have to figure out what their, you have to identify the potential of that person. You have to have open conversations. You have to provide mentorship to that person. You have to offer training. There are so many trainings or materials. You can do personally, as well as they can get it online from resources, and so on. You have to try out that person by rotating roles. So, let’s say there is an engineer who is writing a code, but you see, they are also very good mentor. They write well, they communicate well. Maybe you move them into a Tech Lead role where they manage the team or share the responsibility of running a project with you or with the manager 50/50, so they get a playing ground and you can test them how, where are their strengths and weaknesses.
So, this is how you have to see, and then you have to clarify, “Okay, you have been doing good in this area. There are certain other areas I want you to focus on particularly soft skills.” That’s how we’ll have to try out the, uh, an individual to grow them in leadership roles.
Kovid Batra: I think that’s actually really nice. And the last part was very good. I think the best way to test someone is, like put them on the field, be there to support them. But, I think that’s a very nice way on day-to-day in your team, if you identify those gems in your team, I should say, then yes, giving them a playground and then seeing how do they do, how we can help them improve.
Perfect, Ashik. I think that was really nice advice.
Ashik Uzzaman: Thank you.
Kovid Batra: Moving on to the next bit. I’m really impressed with the thoughts that you are sharing here. You must have seen a lot of people who were leading you in your career, right? What were those best leadership styles? What did you learn? How did you implement them? Just talk about those experiences.
Ashik Uzzaman: Yeah, yeah, This is an interesting question. The leadership style, there are a lot of debate is actually how many different type of leadership styles are there. So, the way I think of some of the possible styles before I tell which one I like is let’s say transformational leadership, servant leadership, situational leadership, democratic or participative leadership, autocratic leadership, transactional leadership, charismatic leadership, coaching leadership. So, there are different types of styles.
Kovid Batra: Oh, okay. This, this was something really new. Yeah.
Ashik Uzzaman: So, yeah, depending on like which book you pick up or which personal leadership guru you’re talking to, you’ll see these words are coming out mostly. But, one thing you will see very common for particularly two, you will see very common. One is the servant leadership and another is situational leadership. So, my favorite leadership style is servant leadership actually, so much so that some management consultants think that this is the only type of valid leadership, which is servant leadership. So, maybe that’s a little bit too much extreme, but servant leadership focuses on the person, the team, the people who we want to develop. If you follow this style, what you do is you’ll identify the right people in the team and put them in the right place. For example, maybe a person is a good engineer, but you have put them as a Product Manager. So, they are in the right team, but in the wrong role. The servant leader will figure out not only the right person for the team, but they’ll find the right seat or the role for that team.
So, my style, I believe is that. Why it goes very well with why you should be a manager or leader in the first place is to actually serve others to grow others, and servant leadership really goes very well with me.
Kovid Batra: Perfect. And what about the participant leadership? Can you just throw some light there?
Ashik Uzzaman: Yeah, so participative leadership, it’s another name is democratic leadership, where the leader actually tries to lead the team based on consensus. So, they say, “Okay, what’s the majority seeing?”, and so on, versus in a servant leadership or in a situational leadership, often the leader will actually make the choices. They will still take the input, but they are not going to run the team by consensus, not by majority. Participative or democratic leadership, leaders actually go by majority most of the time instead of they making the decision often.
Kovid Batra: Makes sense. Makes sense. But then, in, in participant leadership, I have this feeling that it becomes difficult to lead, right? Like, every time getting consensus on everything, of course, critical decisions, you will take a consensus. But, maybe it’s just me, I’m feeling that, but what’s your thought on that? Like, isn’t it?
Ashik Uzzaman: Yeah, that’s the case. So, basically what happens is that the participant leader or democratic leader is so much conscious about taking consensus from others that they will often not take the right hard decision for the team. First of all, they will slow down the team because they have to take consensus.
And then, as a leader, you know, sometimes we don’t become leader to become popular, right? We become leaders so that we can make the right impact on the team. And sometimes the right impact of the team is actually a hard thing to do. It’s an unpopular thing to do. When you run the team by consensus, you are not going to get those unpopular decisions from the team, right? So, you’ll often not be taking the right steps for the team. So, that’s why this is not one of the leadership style that goes well with me. In certain type of team, in certain type of industry, this may work out. Yeah.
Kovid Batra: Understood. Okay. So, I think it’s more like these leadership styles are in general suitable for different scenarios, different kinds of teams.
Ashik Uzzaman: Right.
Kovid Batra: Got it. Got it. Got it. I think this is an interesting topic where I think we can have a podcast dedicated to this itself.
Ashik Uzzaman: Yeah. Yeah, definitely.
Kovid Batra: It’s enlightening actually, because we got to know that, okay, these things exist. It was something that you don’t know what you don’t know, kind of a thing for me.
Perfect! Let’s move on to the last question of this discussion. So, when you’re leading teams, you have your leadership style in place, you have a clear thought process whom to enable and then how to enable, but when teams are operating at this scale, how do you make sure that overall team performance or overall team well-being is in place? How do you define that success for your engineering team?
Ashik Uzzaman: Yeah. So, this is a tricky one because it actually involves a lot of things as a leader, you’ll have to do. So, maybe I can touch base on some of the items.
Kovid Batra: Sure!
Ashik Uzzaman: Like, the first thing is that you have to set clear objectives and expectations for the team. Like, this team is part of a larger organization. The organization has a mission, vision, value, strategy or objectives. And then, there are deliverables, and usually the deliverables are divided in quarter or yearly outcome and so on. So, you have to make sure that the team members know why they are working in the team, what’s the objective and what’s the expectation out of them.
Now, setting the expectation is not good enough. That’s the first step, but you have to do regular check-ins. There is a thing called ‘trust, but verify’ in our leadership. It’s like, you trust your team member, but you also verify. You make sure they are on the right track. As a manager, this is actually your responsibility to keep on check. It doesn’t mean that you don’t trust the team members. It’s just that you have to be there to help them when they’re going wrong. There has to be good feedback mechanism within the team. Like, metrics is one of the ways, or 360 degree feedback, or the trust between the team members for each other, so that they are vulnerable to each other. They hold the peer to peer accountability. You have to keep those process in place. The communication channels has to be open. Anyone should be able to, free to come to your leader. They should not be scared or they should not be hesitating or they should not be silent when they see something is not working.
And definitely, you’ll have to prioritize the professional development, not just deliver the project or product. Like, you know, particularly in startups, people are so busy, go to market, go to market. They often forget about the work-life balance, or their well-being or health, or are they growing as a professional, not just in terms of coding, what about are they growing as a communicator, for example, or as a mentor and so on.
Those are some of the things I think. You know, another thing is the reward. You’ll have to recognize and you have to appreciate when people are, the team is doing good and when they are not, you have to give feedback. These are some of the things I think you have to accommodate as a leader for the team, otherwise, they will become a dysfunctional team.
Kovid Batra: One interesting point you raised here, like with the thoughts that you have just mentioned, we can definitely establish that bed for the team from where they can jump and like fly, right? So, creating that psychological safety, creating a culture where people can be vulnerable, probably leading by example. These kind of things. And then, aligning them towards the mission, strategy, the goals, the objectives that you set for the team, right? So, that’s absolutely perfect. I think once that is in place, 80% job is done, or let’s say 60% job is done, to be very fair. But then, on day-to-day basis, things change, right? Like, as humans, if we have some long-term plans, we definitely want to achieve the goals based on those. But, when you operate on daily basis, there are so many things going around, there are so many emotions coming into play. And, to have things right on track on daily basis, not to make situations stressful, but to keep things on track, we need that objectivity. And as you mentioned, that you have to trust your team, but then you have to validate, right? So, validating comes in with some, probably engineering metrics in place, looking at certain, like developer experience points to ensure that there the people are happy, right? So, how do you do that? Or, what kind of metrics do you use to do that?
Ashik Uzzaman: Yeah, definitely very interesting question. So, you know, the, in many different companies, they track those metrics with different names. Like, some companies call those KPIs, like ‘key performance indicator’. Some other places say KIs, ‘key initiatives’, and so on. But, the idea is that there has to be data available to the leaders who’s running the team or to everyone in the team to see on a day-to-day basis, in a weekly basis, in a quarterly basis, how the team is doing. There are already some tools or frameworks available, like commercial, as well as free that you can use.
Kovid Batra: You’re talking about these DORA metrics, SPACE framework.
Ashik Uzzaman: Right. Yes, exactly.
And then in our company, the company I’m working on is a AI health tech startup. We are using different tools provided by Atlassian, like, let’s say starting with Jira. So, Jira is one.
Kovid Batra: Got it.
Ashik Uzzaman: Or all the other Atlassian product, the Bitbucket, or they are pull request, how much is going. We have developed CI/CD pipeline, as well as workflows to make sure that everything runs smooth.
Kovid Batra: Right.
Ashik Uzzaman: But, this is pretty basic level. I think you can actually use framework or tools like DORA kind of tools on top of it. That makes the life of an engineering manager or leader very easy, if you want to track it at a day-to-day level.
Kovid Batra: How critical do you feel it is for a team to operate with these frameworks or tools in place? How critical do you think it is?
Ashik Uzzaman: Right. I think this is very critical because we believe one thing is that ‘measure what matters’. If you don’t measure something, you are not going to make improvement on that area. So, we must measure. And these tools are there so that you are able to measure and verify and decide the next step, you can plan. Without these, you’ll be kind of running blind, or you’ll be running the team based on gaze or gut feeling and so on. So, that will not work.
Kovid Batra: Perfect. I think that’s really, I would say a hands-on experience advice that I, that I’m listening here. So..
Ashik Uzzaman: Thank you.
Kovid Batra: Great! I think that brings us to the end of this show. If there is any parting advice for our audience, please feel free.
Ashik Uzzaman: Yeah, definitely. Yeah. The one thing is actually study. Mix with people, network with people. It can be virtual, it can be face to face, but the more you talk to people, particularly your peers, your fellow industry peers, the more you will see. There are so much to learn. There are so many areas where you can focus yourself. So, I would say network, study.
Kovid Batra: Thank you, Ashik. Thank you so much for such insightful hands-on advices that you have shared with us. We would love to have you on the show again. I would definitely want to learn about those leadership styles and spend more time on that. Yeah.
Ashik Uzzaman: Yeah. Thank you so much. I’m so happy to be in your, this podcast. Thank you, Kovid, for inviting me and definitely we’ll stay in touch. Thank you everyone.
Kovid Batra: Pleasure. Thank you. Thank you so much.
In the recent episode of ‘Beyond the Code’, Host Kovid Batra welcomes Jeff Watkins, CPTO at xDesign. He has previously contributed his expertise to various organizations such as AND Digital, BJSS Ltd, and more. Their conversation revolves around implementing technology and processes in the age of AI.
The episode starts with a fireside chat with Jeff, providing us a glimpse into his personal background. Transitioning to the main section, Jeff imparts valuable wisdom on the concept of the ‘Iron Triangle’ and the ways to balance it. He also delves deeper into implementing the latest technologies that involve AI and security while also exploring effective methods for defining team success. Jeff also sheds light on the importance of understanding the psychology of programmers in effective organizational leadership.
Wrapping up, Jeff provides meaningful advice to the audience to approach tasks with a focus on efficiency and smarter practices.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a fascinating personality who is a technology leader, tech blogger, public speaker, and a technical architect. He has 25 years of experience in engineering and leadership, currently serving as a CPTO at xDesign, leading 250+ engineers.
He has great hunger for learning in technology. And I can surely say that because at this point of career, after 25 years, he has gone for a degree in Cyber Security, and he is going for another degree in Implementing AI. Happy to have you here, Jeff. Welcome to the show.
Jeff Watkins: Thank you very much. I’m glad to be here, Kovid. Yeah, you probably give me too much credit there, I think, I’ve really enjoyed my career in tech and it’s been hugely rewarding, and also, subjects as Cyber Security and Artificial Intelligence are so really of our time. I think it’s really important to make sure that as somebody who sits in the Exec space to really understand them as, as best as possible, really.
Kovid Batra: No, I think you deserve this. I’m sure people around you feel so. All right. So, we will get started on this. The first part is going to be a quick fireside chat where we’re going to know more about Jeff personally rather than professionally. So, are you ready for that?
Jeff Watkins: Sure. Yes. Looking forward to it.
Kovid Batra: Sure. So, the first question. So, I already know that you have a cat. Last time when we talked, she was also joining the call. I just wanted to know, why cat, not a dog?
Jeff Watkins: Oh, I think.. So, I love both cats and dogs. In fact, I’ve got a cat, sorry, a dog sat next to me here just out of camera shot at the moment.
Kovid Batra: Oh! That’s amazing.
Jeff Watkins: So the cats are definitely not here cause they’re not really good friends at the moment. I’ve grown up with both of them, but, cats certainly I think they’re quite independent. They’ve got a lot of personality. They knock everything off your desk. I think they are just very great fun to be around. I love both, but certainly, for me, I just slightly prefer cats, but I’m trying not to make the dog jealous. I’m sure she’s listening.
Kovid Batra: Amazing, amazing. So, this is the next question. What was your first encounter with technology?
Jeff Watkins: So, yeah, I remember it really well, which is bizarre because I was around 6 years old, so I was quite young. And my father had just bought a Commodore VIC-20, which is a exceedingly old computer. I had 4 Kilobytes of RAM. It had an incredibly.. It couldn’t support like things like sprites and he just had a beeper for a sound chip. It was very, very basic and rudimentary, but that was my first real technology introduction. I mean, obviously we know, we use other bits of technology in our everyday lives, but actually a bit that you could program and you do things with. And, I could put, 10 print “Hello World” and 20 GOTO 10, and be amazed that you could do that. So that was my first, and that was what got me hooked. And I started learning to code pretty soon after that.
Kovid Batra: Oh, that’s amazing. And that’s quite old. Which year are we talking about here?
Jeff Watkins: So, this would be around, maybe 1983. So, a long time ago. I mean, it’s a MOS 6502 processor running at point something of a Megahertz. I mean, we’re talking seriously primitive technology. Certainly never imagined that in my lifetime, the entire way of living would change because the internet, I think has existed since the 50s in some respects, but the actual web, you really in my lifetime, seeing it flourish and become that way of life, you know. When I grew up, we didn’t even have a telephone inside the house. We had a telephone box at the end of the street. To go from that to having always on instant communications throughout the entire world is, is, and this has all happened in my lifetime, which is absolutely crazy to me.
Kovid Batra: Yeah, of course. I mean, seeing this transition.. I was not even born then. So, you have seen technology since that time, not to make you feel old at all. I’m sure you are younger at heart than me, of course. But this transition.
Jeff Watkins: Nice save!
Kovid Batra: But this transition from that point till today, I think you have seen a lot. I’m sure you have seen a lot.
Jeff Watkins: And the thing is, looking at a little bit of a taste of what’s happened this year with artificial intelligence, I don’t think it’s the last one of these we’ll see. We’ll see another great change in our lifetimes. Now, if I could predict that, then I would be the next Bill Gates or the Steve Jobs, but I think there’ll be another one or two, the… If you look at the industrial revolutions, they’re getting shorter and closer together. So, you know, the first one happened, I can’t remember the exact date, some time ago. And then, we’ve suddenly started squeezing together and the, and when will we be seeing industry 4.0, 5.0, they’re getting close together and we will see these huge changes in how we live and how we, how we think even, you know. AI and Google have already started to change how we think. The different studies on things like neuroplasticity, and seeing how people retrieve rather than store information, you know. School used to be about learn loads of facts and cram it all in and keep it in there. And now it’s like, how do you go and get information? So, yeah, it’s very exciting. very exciting time to be alive.
Kovid Batra: All right. Amazing! Moving on to the next one. I’m sure you’re reading a lot of books. Which one’s your last one? And, share some learnings from there.
Jeff Watkins: I buy far too many books. So, I love to read, but also I buy more than I could possibly read. I think there’s more than I could read in my lifetime. The last one I read was, ‘Team Topologies’. I’d been thinking for some time about how teams are formed and also how static they can be. And I think this backs up the idea of, like, thinking about moving to more dynamic team structures, thinking about flipping Conway’s law on its head and thinking about actually designing your organization, and certainly within your digital arm around what you want to achieve rather than letting your systems end up being designed the other way around. I think breaking down silos with siloed areas of the business, you know, traditionally things like architecture was quite a siloed activity. I mean, once upon a time QA was security, still is, and that’s one of the big things I’m really with my fellow podcast host we’re trying to break down those barriers. Every time we, it’s like whack a mole, every time we break a silo down in tech, there’s another one somewhere as the tech world gets bigger and bigger. So, there’s a lot of lessons like that in there and things like around reducing cognitive load, because you want to be able to give people information and communication, but not too much because it becomes overbearing, you know. It’s good to have a big organization and the support of a big organization, but sometimes it can be a bit of a blunderbuss of information. It’s far too much.
Kovid Batra: Right. Makes sense. Cool. I think this is an amazing read for the audience as well.
Jeff Watkins: It’s quite short. It’s quite a short book. So also, don’t worry too much about the time investment. I think you’ll take a lot from it quite quickly.
Kovid Batra: Cool. All right. So, that was a nice fire chat with you. Now, we are moving to the main section where we would want to learn from your experiences, from your success and failures, the challenges that you have had. We will get onto that, I have a question from there. Last thing when we were talking, you mentioned about your philosophy of the ‘iron triangle’. So, I just wanted to know more, a deep dive on it, make the audience also learn the same aspects which you were mentioning. So, can you just throw in some light on that philosophy of yours?
Jeff Watkins: Yeah. For the listener who’s not maybe aware of the concept, it’s an agile project management concept of the ‘iron triangle’. Now, once upon a time, it used to be time, cost, and quality, but then people changed that to be time, cost, and scope. And the idea is you can choose two of them, but you can’t have all three because you can’t cross the triangle. And you’d put quality in the middle and hopefully make that invariant because really people usually don’t want poor-quality software. And the idea is, well, if it’s going to be cheap and fast, then you need to lose scope. And if it’s going to be cheap and have the scope, then maybe you’ll just need to take longer, cause you’ll need a smaller, more focused team, etcetera.
Well, how do you beat the iron triangle? And, in tech, I remember recently working on a system where we’ll use containerized Java services for this, a few years ago now. And we looked at it and went, “But, these services are really simple. Why not just use serverless tech? And they make this as light as possible.” And went, “Oh, but we haven’t done much of that before.” Well, learning’s fun. I personally did some of the first integration and went, “Oh look, that took us from zero to actually working maybe a couple of hours.” And really, if you were trying to build all that up and then put it in all those infrastructures, code, etcetera, that’d probably take days or weeks, anything. So it’s, it’s using this technology smarter. I think that in my opinion is the key to beating the iron triangle in tech, it’s using smart technology. What that does is it gets you more from your time and your money without sacrificing scope at all. There’s a set of scales here because you couldn’t just go, “Well, let’s just use a zero, a no-code platform.” And that’s kind of okay for some things. So there was some, I’d say back office applications where it’s fine, possibly. But if this is a user-facing application, it might not be fine to use a no-code app because some of them don’t necessarily have the most amazing user experiences.
An ex-colleague of mine, he came up with the term ‘lower code’. So, it’s not just a low-code platform, and ‘lower code’ is just like leveraging as much of Cloud Native as possible. And leaning into, well, what can it say something like as your DevOps, as your functions and making sure you use like these are database services, and like, what, what can you use with the minimum amount of configuration and the minimum amount of boilerplate to get you to where you need to be securely and scalably. And if you can crack that, then those kinds of services don’t really put any restrictions on how you deploy them and how you use them compared to maybe a no-code platform.
Kovid Batra: Yeah.
Jeff Watkins: So actually, this gives you all the flexibility of kind of coding it, but also that a lot of the speed of not coding it, which I think is a..
Kovid Batra: Is a big advantage.
Jeff Watkins: And we’re starting to, yeah, we’re starting to harness that appropriately. I think this is where consultancies really do help, cause they know how to do this. And, there’s loads of people still hand-rolling loads of stuff and wasting a lot of time on money, I think.
Kovid Batra: I think it totally makes sense. And I think that’s how you break the age-old iron triangle, and maybe just thinking out of the box, thinking about new technologies to be implemented, you can save a lot of time and maybe deliver fast and buy little cheap. So yeah, cool. I think that was really insightful.
I have another aspect that I wanted to know because you, you have been into leading teams and building things at such scale in organizations. So, you and your team, of course, approach implementing the latest technologies that are involving security and AI? How does that work out right now?
Jeff Watkins: I think there’s a couple of things that I think if we’re talking about security tech or AI technologies, one of the key things for, if you’re going to take something into your organization is doing a proper technology diligence process. And, that sounds awfully long and boring. But actually if you boil it down to what, what are the key things that matter to you? Well. It’d be slightly different between say an open-source project, maybe a proprietary or a SaaS product, but for say like, open-source, well.. How mature is this technology? How many people are contributing to it? When was the last major release? Is it actually, if you scale it, is it vulnerable or not? Is it still in good use of the community? And going on to Stack Overflow and looking at how many Stack Overflow questions are about it, is it a good yardstick for how popular something is. But it also could, is it too mature? You know, there’s a point where Log4j became so old and long in the tooth that the creator of Log4j said, “No, don’t use that. Use Logback instead.” So, it’s that balance of looking at maturity, the developer support as well. So, it’s no good procuring a technology if you have to train everybody to use it, really. It becomes then quite onerous task to actually upskill everybody on it. And, then you have a problem that well, how do you know best practice if nobody else knows it in the team? So, choosing technology, I think. But, when it comes to things like AI, there’s a lot of it’s around, well, what’s this going to cost? Cause AI is expensive to run quite often. And also where’s the data going? Because you probably, you know, we’re in GDPR countries. So, you probably want to be sure that your data, you’re not giving away personally identifying information, or clients or your own intellectual property, cause it’s not just the AI provider who might run away with that. They probably won’t, you know, it’s something like OpenAI would, but they themselves are subject to attack. They could be part of a supply chain attack. So, your data may or may not be safe. So now, safety is a kind of a… It’s never a 100%. There’s no such thing as a 100% security unless you turn off all your computers, seal them in 7 meters of reinforced concrete and dump them in the Mariana Trench. You know, that’s a particularly safe, you know, that I’ll be secure, but it won’t be reusable. So, it’s that trade-off of risk enabling innovation in that respect. But, things like, if you’re choosing AI tech, you know, in the case of, is, do we have a UK data center that makes things much easier? And if they’re within a GDPR country, that makes these things way, way easier.
Kovid Batra: Yeah, yeah, definitely it does. So, basically, whenever you are looking at implementing AI, there is definitely the aspect of security which you’re really emphasizing. How exactly, when you take care of the security part along with it, is there a framework? Is there any steps or guidelines that we have to, like, actually follow when we are implementing it? That would be my follow-up question there.
Jeff Watkins: Yeah. So, if you’re using an AI to build into a product, really one thing about AI is it’s really quite hard to secure the use of the AI if it’s like ChatGPT-based, because people try and put in protections around it, but what you don’t want to do is end up becoming effectively a free version of ChatGPT for people to abuse. So, really we recommend like thinking about the design of the security from the very far left as possible, and that’s for the product when you actually have a product and design space, because it’s really hard to, and it’s expensive to fix fundamental security flaws when you all get all the way to like release. So, you’re thinking about, well, actually, how do you make this? And it’s not just from a technical point of view. It’s almost all from a, well, who might abuse this service point of view? We call it, there’s something called ‘persona non grata’, and it’s the opposite of the persona. You know, when you do product persona, it’s the opposite. It’s the people you don’t want, they’re abusers.
Kovid Batra: Yeah, I got it.
Jeff Watkins: And then we put tenors into misuse cases and abuser stories, and link them to our security and our functional requirements. And when it comes to AI, it’s really hard. It’s like, well, what countermeasures do you put in place to stop people abusing it? But also there’s the, obviously the other sides to AI, you know, people could try and do a model inversion attack that might try and poison your model. They might use other adversarial AI attacks. So, it is also the protections you need to put around that model to avoid it being unduly influenced. How do you, kind of tear that model down? If you think your model has been poisoned, how do you tear down and recreate it in a safe way? So, you have to think about all of that before you really, before you build it all out. And the other thing is it’s like they could effectively attack your infrastructure by overloading that AI, that model or just blow your budget by spamming it with requests. So, there’s a lot of considerations. And the main thing is, like putting in threat modeling, to start with. And that can be product-based threat modeling through persona non grata, misuse cases, abuser stories, attack trees, and things like that. But then also, once you’ve got the basics there, move on to something like, using something like STRIDE to actually do structured threat modeling. And then, make sure you have a very robust way of managing your security threats and risks.
And the other thing is, and make sure you have, your entire development pipeline has got a really good automated security pipeline in place as well.
Kovid Batra: That sounds something like a good step-by-step advice for a lot of things while implementing AI and taking care of the security alongside. That’s great. I think that really helps our audience learning more about it.
Next question is, again, there are things apart from implementing technologies and delivering projects. We particularly look into the developer experience. When we are at this scale, we need to have a good culture in place. So, when you try to make sure that your team is efficient, what kind of metrics you look at? How do you define success for a team? And, when you identify problems in your team, how exactly you end up solving them? So, you can just give some examples here that you would have seen at your organization or your previous organization.
Jeff Watkins: So, obviously there’s old-fashioned… traditional, I think old-fashioned is too harsh, traditional metrics of things like velocity, but then you can start thinking about DORA metrics. And, a lot of it is around I think helping people understand the Lean and Agile together. And nowadays, we’re implementing SPACE metrics, which covers kind of quite a broad range of things. I think it’s really useful to look at where our pipeline stalls in the process, and where there’s waste in the process. So, if something keeps going around the loop, because it keeps failing, or you’re getting high defect injection rate. Well, why is that? It’s not about blaming people. It’s about figuring out what part of that process or culture is broken. Maybe things like staying in review for too long, maybe things are taking too long to release. And quite often for the most part, I’d say most teams do want to do a good job. It’s just their environment around them, it’s not allowing them to do so because it’s inefficient in some way.
Kovid Batra: Yeah.
Jeff Watkins: It might be poor infrastructure, it might be poor release process. It might be tedious red tape. It might be over the wall mentality because you’ve got a separate team doing QA, rather than bringing them together. So there’s a whole raft and it’s measuring the waste. Basically, for the most part, it’s measuring the time wasted because there’s a gap in the process, or because it hits the process and has to go back again. So, any measurements like that, and obviously things like actual quality measurements, stuff that’s relatively non-controversial, like SonarCloud coverage. Test coverage is a hot, you know, it was a hot topic for a long time because people would try and get towards a 100% coverage, but actually, if you just measure coverage, that’s a good hard slothing. When a measurement becomes a target, it ceases to be a good measurement, and people would just fake tests to make a 100% coverage. It’s all about the actual quality of that coverage as well. And there’s, I don’t think there’s a shortcut to quality, but we can do is try and bake it in as much as possible by measuring what you can in a sensible way. I think McKinsey drew a lot of ire from the industry by saying, “Oh, you can measure developer productivity.” And well, I think if you’re measuring productivity in a way to actually help, like remove blockers and build the ideal culture and efficient way of working, that’s fine. If it’s measuring productivity, so you can shoot the bottom 10%, that’s not fine at-all.
Kovid Batra: Yeah, of course.
Jeff Watkins: So I think there’s different ways of looking at that lens. And I think actually, if you take away the emotive aspects of what McKinsey published, and then look at some of the areas they’re looking at, like kind of the organizational maturity, and then engineering maturity, like, okay, so this is very sensible stuff to measure. And, we’ve actually started building out all these measurements. We’ve been assessing our internal projects, you find some really interesting things. You find improvements in where a CI/CD can be made, and improvements where you know, things like security champions can be, um, the program can be improved.
So, and when you start measuring and you have to understand that you will find that you’ll probably find a lot of stuff. Then, once you’ve measured, it’s then it’s actually about prioritizing what’s going to be the most impactful change.
Kovid Batra: Right.
Jeff Watkins: Things change, because you might find 50 things, and which one of those is going to give you your best return on investment? That’s where you need to start evaluating and think, “Well, actually this is costing us, we’ll say 80 developer hours a week because it’s really hitting the team. And, well, this probably needs fixing.” If this is an annoyance that’s costing us half an hour every sprint, well, we can probably live with it, but also then, there’s the impact of other things as well. You know security deficiencies may not actually have any actual productivity impact, but they sure will if you get fined because you’ve lost all your data, or your system goes down, or you, or your data is stolen.
Kovid Batra: So, this is something which would really help in identifying the inefficiencies or the bottlenecks in the whole software delivery pipeline. I would like to also emphasize on the point where you define the success for your engineering teams. Of course, these metrics are something which would give you symptoms or would tell you problems and where they exist, but ultimately… So this is again, a generic as well as a personal opinion that for engineering teams, there should be certain goals, how we define success for them. So, how do you see that success? I would be interested, and the audience would definitely be interested in knowing that.
Jeff Watkins: Yeah. So again, I don’t think it’s around the age-old thing of how many lines of code have you delivered, I think it’s more about the, for me, it’s reducing cycle times and increasing the quality of builds, reducing failures, reducing the waste. So, you should be aiming towards, well, what’s our effective, like what’s our uptime of our builds, and, incentivizing on things like that, incentivizing on quality going up. You know, the measurement should be if you’re improving quality, then you are being a good citizen. If you are leaving the campground in a better state than you come along, you are being a good citizen. That should be, you know, that should be acknowledged. It should be, people should…
Kovid Batra: Rewarded for that.
Jeff Watkins: …Celebrate that people have taken an interest in quality. And then there should be, there should also be notifications if there are problems, if the quality is dropping, if cycle time’s getting longer, because sometimes it might just be, “Well actually, we need to fix our build process because our build process is taking too long.” I’ve had that in the past where people are going, “Our productivity is awful because our build process is too long.” We found some ways of paralyzing pieces. We took the build down from half an hour or 40 minutes to about 4 minutes, so. And suddenly, and that’s not about anybody being non-productive. It’s just about, unfortunately, over time things change. And, but if you’re measuring that and you understand where’s the waste in the system, and set targets for people, if they’re not meeting the targets, not there to beat them over the head with a stick, it’s like what’s preventing you from hitting these targets?
Kovid Batra: Absolutely. So, in an organization where you have 250+ engineers, how do you measure it? How do you ensure? Is it done through processes? And then how do you ensure that the process is followed, or you use some tooling around it? So, I would like to understand that as well.
Jeff Watkins: So, there’s a mixture and because we’re a consultancy, so actually we use a number of different tech stacks. In some ways it’d be harder if we had nearly 300 engineers to measure in one giant team, but also in some ways it’s easier because the individual engineering managers can see at their smaller level. So currently, it’s a mixture of we take metrics from things like the build systems we’re using, the CI/CD we’re using on things like Jira. And also, then there’s elements of kind of manual inspection around. Basically, we have an engineering maturity framework where we come in and kind of lift the lid on each projects within that on a rotation.
I think moving towards a more holistic dashboard of, and I think this will be even more useful for product companies, even more so for like product companies where they have very large engineering teams, all working towards the same kind of goals, the same kind of metrics, is having a metrics platform where you can actually see, you know, what does your build stability look like, what does your throughput look like, what does your waste look like. We’ve come a long way in these platforms in the last few years, but there’s still, I think there’s still room for challenges and still room for new innovation in that, because I think there are ideas of metrics also evolving as well. And a lot of companies still haven’t adopted any at all, or if they do, the most rudimentary ones.
Obviously, you know, as the industry becomes more, continues to grow and become, becomes quite cost conscious. I think it will be a growth area.
Kovid Batra: Thanks a lot for this insight. And the one last thing which is definitely of your interest, which is psychology. So, you mentioned that you are into psychology and understanding the psychology of a programmer, particularly. So, how your understanding of a psychology of a programmer has helped you lead at the organizations?
Jeff Watkins: So, yeah. You know, first of all, you can’t completely a 100% put people in one box, but, there’s a good chunk of us got into software for one type of reason, some for another. But, a lot of us got into it because we enjoy solving problems and we enjoy learning, and we enjoy the challenge of all, rather than, um, just the money. And, I think when it comes to, and this is backed up by research and we’re like, “What do developers want?” And, I broke it into several key things. And, there’s enablement, like people who are very smart, like to be able to work creatively. I think there’s a misconception that developers aren’t creative. And I think, it’s just not, maybe splashing paint on the walls or making music. It’s a different kind of symphony. It’s a symphony of code. So it’s enablement, like giving them the tech and the tools, and the automate and actually build and problem solve. And there’s the kind of, there’s the excitement as well. Developers work so much better in my opinion, and from my experience, when they’ve bought into the vision of what they’re building, I think that was all. So, 20 or something years ago, it really was kind of, “Well, we’ll pay you some money, build some stuff.” And it was back, a lot of it was backend stuff, not so much web stuff. And then, but the modern graduate and the modern younger developer really do care about the ethics, and the company ethos and culture, of what they’re building and where they’re working. So really having a really, really clear set of values is really important to the modern generation of developers.
And then, there’s also the kind of engagement as well. As engineers are thinkers, they like to be engaged, they like to have their opinion heard and to also see that people act on that opinion. It’s no good asking for feedback, if you then just discard the feedback. So, it’s that kind of 3 things of enable, excite, and engage. And there’s a number of different topics under there, and almost none of them really mentioned money. And people will stay somewhere if they feel all of those 3 factors, if they feel that they’re excited and enabled and engaged, and it’s, and it goes back to some of the measurements as well, you know. If you actually start to produce the waste in the system, produce enablement, and allow people to work super-efficiently with modern tech, then actually, people will stay, even if they can see a higher salary somewhere else.
Kovid Batra: Yeah. I think this all, all brings it back to the point where you have to have a good understanding of who your audience is, and when you’re leading a dev team, the developers are your audience and you have to build an experience for them. And it totally makes sense to understand their psychology and then build around it.
Jeff Watkins: Well, there is, there’s a whole field of developer user experience. People go, “Oh, user experience?” You think about the end customer. Like actually, there is another user and that user is often the developer or the other people in the team as well. You know, the team is having an experience at the same time and you can neglect that at your peril.
Kovid Batra: Yes, absolutely. Great, Jeff. I think that was really, really insightful and great talking to you. Any parting words for our audience?
Jeff Watkins: I think, whenever you’re next looking at doing something new, think about how you could be doing it smarter because you can’t beat the iron triangle any other way, in my opinion. It’s think about doing things smarter.
Kovid Batra: Amazing. Perfect. Thank you, Jeff.
Jeff Watkins: Thank you very much for having me today. It’s been wonderful.
Kovid Batra: It’s our pleasure. All right. See you. Bye bye.
Jeff Watkins: Bye.
In the recent episode of ‘Beyond The Code’, Host Kovid Batra engages in an insightful conversation with Giorgos Ampavis, VP of engineering at Tide, who is also a renowned speaker with a strong presence at top-tier tech conferences including DevOps Enterprise Summit, SaaStr, and WeAreDevelopers. Their core discussion revolves around ‘Building tech teams from zero to one and beyond’.
The podcast starts with a fun fireside chat with Giorgos, where the audience gets to know his unfiltered personality. Following that, he shares the challenges faced in his engineering journey and strategies he used to conquer them. Giorgos sheds light into the framework for assessing new tools and technologies. Further, he imparts valuable wisdom on fostering a positive organizational culture and enhancing the developer experience.
Wrapping up, Giorgos leaves the audience with significant advice, stressing the importance of continuous improvement and a commitment to lifelong learning.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of ‘Beyond the Code’ by Typo. Today with us, we have a special guest who is a passionate, insightful thought leader. He has 18+ years of experience in software engineering and leadership. He’s currently VP Engineering at Tide, and he joined the company as early as, like, the 25th employee in the company.
He loves to discuss about technology, building and scaling teams. And post-COVID, you can find him at a lot of events talking about his thoughts. He has been to ‘DevOps Enterprise Summit’ in London. Then, he has been to ‘SaaStr’. And then, there was ‘WeAreDevelopers’ in Berlin. And now, you can find him in the upcoming events at CTO Craft on 7th and 8th of November in London, talking about culture at scale. And then, he would be at ‘LeadDev Berlin’, 4th-5th of December, talking about Native to Flutter transition. Welcome to the show. Welcome to the show, Giorgos.
Giorgos Ampavis: Hi! Hi, Kovid. Nice to see you here. How are you?
Kovid Batra: I am really well. Thanks for being on the show. We are really grateful.
Giorgos Ampavis: My pleasure.
Kovid Batra: Alright, Giorgos. So, we have this format of having a quick fireside chat with our guests, okay? And here, we are going to know a little bit about you, your personal life, and you have to be, like, honest, okay? All set?
Giorgos Ampavis: Will do. Will do. Try my best.
Kovid Batra: Perfect! So, I’m starting off the first question. I’m sure you’re reading a lot, but which is your favorite read, favorite latest read? And, what is your learning from there?
Giorgos Ampavis: So, okay. So, reading is tricky. First of all, I’ll have to say that I have a very short attention span, so I can be very easily distracted. So for me, reading is like it’s a struggle, but I try to push myself and I try to read a lot.
Kovid Batra: Okay.
Giorgos Ampavis: Having said that, I have a big pile of books here, which, you know, I haven’t read yet. My latest one, which I actually finished is ‘Never Split the Difference’, which is talking about negotiation. It’s actually a really nice book. I’ve just finished it last week. Really, really good book. I think it’s probably in everyone’s top 10 or 20 ‘must read’ books. Really good book about negotiation. And I just started. I’m not gonna advertise it. I’m not gonna because they want to advertise it. But, I’ve just started like reading ‘EMPOWERED’ by Marty Cagan, which I’m a big fan of, from the Silicon Valley Product Group.
Kovid Batra: Yeah.
Giorgos Ampavis: So, he has a series of book. I’m just reading now ‘EMPOWERED’, which is obviously talking about empowering product teams, product engineering teams.
Kovid Batra: That’s nice!
Giorgos Ampavis: Yeah. And I also like to read novels and the latest one I read, I can look at it here because I just put it down like a few weeks ago, ‘The Good Fairies of New York’, which is actually really nice. A book talking about two fairies traveling to New York, no surprise there. But it’s actually quite funny.
Kovid Batra: That’s such a diverse taste I must say. Perfect, I think it’s nice.
Giorgos Ampavis: Yeah, it’s actually quite funny. Yeah, but I have to say I’m also using Blinkist a lot.
Kovid Batra: Okay. You listen to audiobooks?
Giorgos Ampavis: Listen, yeah, or read, both, I can do both. But usually, I do like two or three books, like on every other day, while I run.
Kovid Batra: Got it. That’s nice.
Giorgos Ampavis: So, that helps me get the summary. And then, if I like the book, like it happened with ‘Never Split the Difference’, I’m going to buy it. And I’m going to read it.
Kovid Batra: Oh, that’s nice. And that’s a quick, like, really nice advice. Like, quickly have a summary of a book and then probably go back to reading it if you want.
Giorgos Ampavis: Time is precious, right? Time is precious. You need to optimize. You need to filter out the ones you don’t like.
Kovid Batra: Right. Right. Perfect. That was a nice advice. Nice books too.
Alright, next question. I would love to hear, like, what’s your favorite way to unwind?
Giorgos Ampavis: Okay. So I like, I like cinema. In my previous life, I did study cinema, like a cinematographer. So, I have a passion for cinema and movies, by extension. So naturally, you can find me, like, watching movies or TV series on I have all the possible subscriptions, like Netflix, Apple TV, like Amazon Prime, all of them. I try to limit it obviously because you know, I don’t want to binge-watch movies, like 3-4 hours a night. Again, time is precious, so we need to optimize that, but that’s my preferred option to unwind, like watching movies or music. Obviously, I listen to music all day long. And recently, I, you know, and obviously playing with my son is a big thing. How this unwinds…
Kovid Batra: Oh, is it?
Giorgos Ampavis: …or he winds me up or I unwind down. It depends on how it goes. But recently, I bought a guitar because I like to start playing the guitar together with him, who has been playing for one, one and a half year. So…
Kovid Batra: That’s really nice. That’s really sweet, man.
Giorgos Ampavis: Yeah! Electric guitar, by the way. I’m going straight to the…
Kovid Batra: That’s cool, absolutely great! I think, like, you have such diverse days; you’re reading, you’re playing electric guitar with your son. I’m already inspired. So, what’s your mantra for success in life?
Giorgos Ampavis: Okay. So, there’s two sides of it. The one mantra for success is looking outwards. And, I’m talking outwards is just like what I let people see, right? And, for the people that, like, they work with me or they live with me, my mantra is like, I try to be authentic. Whenever with my work relationships, I try to be as authentic as possible. I don’t try to pretend that I’m something that I’m not. I’m very direct, like in a polite way, though, respectful way. And I like…
Kovid Batra: Yeah, that’s very important actually, being polite when you’re there.
Giorgos Ampavis: I like treating people equally. But again, like, by being respectful is at the top. One of the red lines that I have, especially when I hire people, I keep telling them, when I interview people is, “I don’t like disrespect, like, you know, I have zero tolerance for disrespect from any direction.” Right? It can be me sometimes that I disrespect somebody else and I need to be put on my place if I do that, because sometimes you do mistakes, right? Things happen. So when you cross a line, you need to be told to actually to step back and, you know, apologize, right? That happens sometimes. But for me, this is very important, respectful and authentic, like being authentic. And, on the inwards, the way I approach my life, like my personal, which sometimes it is outwards as well, but it’s not in my mantra. But in words, is actually ‘continuously improved’. Like, that’s my mantra. When I wake up in the morning, I’m actually thinking what I’m going to improve today. And I actually am a big fan of Kaizen from the Toyota manufacturing philosophy.
Kovid Batra: So, tiny improvements, yeah?
Giorgos Ampavis: Small continuous improvements, obviously. Hence, the Blinkist. Hence, why I go running every day. Hence, why I do, like, small exercises every day. All of this is part of my mantra. Like, this is how I live my life, my philosophy.
Kovid Batra: Well, I think one good thing is, I noticed, you follow what you preach, right? Like, if sometimes…
Giorgos Ampavis: I try.
Kovid Batra: Yeah. So, sometimes if you disrespect somebody, you are okay that if somebody comes and tells you that you were wrong here and you have to be put in the right place.
Giorgos Ampavis: Oh, yeah. It’s very hard for people who report to you to actually believe you do that. Yeah. But you know, I try to walk the walk, like, and I prove it to them. Like, you know, I’m very down to earth. I don’t have any..I have ego, you know, like everybody else, but it’s not a hierarchical ego.
Kovid Batra: Yeah, got it. Perfect! It was good knowing you, Giorgos. I think the audience knows you now.
Now, the main section. We would love to know your experiences. You joined Tide at a very early stage, as the 9th engineer in the team, 25th employee in the company, and now the team is almost 500 odd developers, right? So, this experience, I’m sure, has been amazing for you. There would have been, definitely, many challenges. Just share something about those challenges. How did you overcome those?
Giorgos Ampavis: So, Tide is a constant challenge, but it’s a positive challenge. First I’ll start with something else. I like challenges. I like challenging myself. So, when I will talk about challenges, it’s not something that we suffered, right? This is always like a challenge comes with a positive outcome, always. So, but I’ll tell you about me. So, I joined Tide, yes, very early. In April 2017, I was the ninth engineer, 25th employee, very early employee, part of the original gang, actually. I’m number four now. There’s another, you know, most people left by now.
Kovid Batra: Oh, okay.
Giorgos Ampavis: And now we have 1500 people. Out of the 1500, roughly 500, they are engineers or in engineering, in general.
Kovid Batra: Yeah, got it.
Giorgos Ampavis: Obviously I played a key part in transitioning from that number to what we have now, because I was very early here. It was a constant challenge because we, you know, in the beginning, we didn’t have the resources that we have now, but we have the appetite. Then we have a small team, which we collaborate really, really well. Then the team started scaling, you know, with the, there was an overhead of communication. So, it was a constant challenge at every level because not only we scaled, we scaled really, really fast. So, if you look at the… I’m working on a presentation now and I was looking at, I created like a graph and actually the graph is exponential with the numbers.
Kovid Batra: Hockey stick.
Giorgos Ampavis: So, it is a hockey stick. Really close to hockey stick, yes, so that brings a lot of challenge and for a company that went from basically no processes, no tools, you know, going to what we are now, like, you know, you can imagine the pain…
Kovid Batra: Ya, ya, of course.
Giorgos Ampavis: …the pain of it. But, it was very rewarding because we learned a lot from the process.
Kovid Batra: Tell us one of those things which you found really challenging.
Giorgos Ampavis: So, okay, hiring. I’d say probably hiring is the biggest challenge because we scaled really fast. So, hiring and onboarding all these people.
Kovid Batra: Yeah, of course.
Giorgos Ampavis: You know, in some cases, it was actually four times in a year, like quadrupled in a year. Bringing all these people, you know, it was very challenging. And it’s very challenging, why? Because we also wanted to keep our culture, like the culture that we had when I joined Tide, and which was really people-centric and really about our members. We wanted to keep it and maintain it. And we actually want us to do that even now. Like, you know, maybe obviously it’s slightly different. It’s not, you know, obviously have different skin to it, but actually at the core, it’s the same. And that was probably the biggest challenge that I’ve seen at Tide. Like, how to keep that culture intact.
Kovid Batra: So, when you go out and you have this pressure of hiring, let’s say a hundred developers in next, let’s say 8 months or 10 months time frame. How do you ensure, how did you make sure that you get the right fit for the company? Just tell us some nitty gritty, like, how other people could learn?
Giorgos Ampavis: So first of all, let’s start with some base stuff that you need, right? You’ll have some prerequisites. You need to have an understanding between the team that is hiring, that nothing’s going to go perfect. Like, you will hire people who are not good culture fits, and you cannot avoid that, especially if you’re hiring fast. But what you need to do, is as you hire fast, then you also need to be very lean on actually identifying these people and then flushing them out.
Kovid Batra: Yeah.
Giorgos Ampavis: That’s actually an easy bit because usually, if you have a strong culture in house, like the bad elements of this, the bad apples usually are flushed out. And that’s actually what happened at Tide. Like, we never struggled to actually, you know, let somebody go, or we never had to let somebody go because usually they realize Tide is not a good fit for them, and usually they leave. We’re talking about, like, less than a handful of people…
Kovid Batra: Yes, got it.
Giorgos Ampavis: …all these years in my team. Then while hiring is really important; obviously, when the team is small, I could do it myself, right? So, it was easy. Like, you know, if I wanted to hire, like, going from two people, two engineers, which was in the beginning in-house, to five, okay, I could spend the time and actually manage to hire these people. Once we started scaling above, 50 and above a 100 though, that became tricky because we needed to have a hiring team, and that hiring team needed to be at the same time, like, hired as well with a cultural fit.
Kovid Batra: Correct.
Giorgos Ampavis: There was a time, I think there was a couple of quarters where I was interviewing like 60, 70, 80 percent of my time. Like, literally meeting everyone.
Kovid Batra: But, that’s actually very important also. I feel like bringing the right people in and just having the calls, the right calls with them is very, very critical. So, for any engineering leader, I would say, this could be a top priority. They can’t really ignore it. What do you think?
Giorgos Ampavis: So, it depends on the level. Obviously, you can’t expect the company, at a company of 1500 people, like somebody at the CTO-level or VP-level to actually interview every single one of them. But, what I’m trying to say is like, you build an extension around you, you build a team around you, which I wanted to do, like, you know, from the very early days, I hired my current Head of Mobile and Director of Web, who are now Head of Mobile and Director of Web, but then they were Lead iOS and Lead Web Engineers.
Kovid Batra: Yeah, got it.
Giorgos Ampavis: And, I hired them and together we actually managed to scale Tide. It was like extending my philosophy, my values like I managed. You know, when we talk about culture fit, I don’t try to hire people who are identical to me, but try to hire people who actually have the same values, core values, at least, right? So these people then, you know, by working together with me, they understand what we need to do. So, we did it together. And then these people, they brought other people, you know, and we expanded and this is how we managed to scale really, really fast. But there was a time where I was actually doing a lot of heavy lifting.
Kovid Batra: Yeah, I think that’s a transition time, the inflection time where you really need to figure out the process and you are doing the work. So yeah, I agree with it.
Giorgos Ampavis: Yeah, it’s a breaking point. It’s a breaking point. Like when you, then you actually, everything becomes amazing, but yeah, I think it was from January 2019 until probably I’m going to say Q3 2019, that was a struggle, like it was a lot of hiring.
Kovid Batra: Got it. Well, that’s on the hiring part. There must have been technical challenges also. I’m sure when you were a small team, you need to really build that MVP, get that product-market fit, and you’re just building, you’re not really caring about the technical there.
But when it comes to scaling after a point, which Tide of course did, did you experience any pains of the past, past mistakes?
Giorgos Ampavis: Yeah. Yeah, definitely. For the first five years, we’re trying to improve the platform, the iOS and Android Native platform, I was accountable for both of them. So, you know, had all these initiatives every quarter trying to improve, refactor. I think we had at some point in 2018, we had an initiative called ‘Architectural Refactoring’. So, we wanted to change the architecture, which we did, we went to modular architecture. So every year, there was a lot of workaround trying to improve and preparing for the next phase of scaling. So, that scaling at the company-level brought a lot of challenges within a team-level, but also the product-level, because, you know, it’s one thing having five engineers working in a code base, not having 50, which we have now working at the same code base, right? So, the challenges are very different. So it was again, a constant challenge trying to improve how we do things, trying to optimize. And then especially on mobile, it was critical because we are mobile first, we took a decision to move to Flutter, because. It was promising and it actually paid back.
So, that was another big challenge when we actually had to transition a whole mobile stack to Flutter, while at the same time, retain the people like the really, really strong iOS and Android developers we had, upskill them.
Kovid Batra: Upskill them, yeah.
Giorgos Ampavis: And then, also hire more Flutter engineers because we wanted to also scale the team. So, it was like, it’s like a train moving and then you are trying to change all the parts in it. But, we managed to do it, like really, really successfully.
Kovid Batra: During this whole time when the scale-up was happening, how much time do you think you were coding after the initial dates?
Giorgos Ampavis: Ah, coding? Okay, I have to admit I’m not coding now at Tide. I’m going outside Tide. I’m doing my own things outside Tide. But within Tide, I don’t code anymore. I don’t have the time to actually code. Or, I don’t think people want me to code anymore.
Kovid Batra: Right, that’s what I just wanted to understand. When you’re really scaling, at that moment, if you’re occupied with hiring, planning the tech strategy, making sure things are falling right, people are getting upskilled, you really don’t get the time to do it, but is it okay to not code at that time and depend on the complete team to make sure things are falling in line? Or, how do you exactly do it?
Giorgos Ampavis: So I think, you know, it depends on the person, but I’d be very skeptical if I see like somebody at the CTO-level or a company or a VP-level or even a Director-level at the size that we are now, and they’re actually coding. That’s…
Kovid Batra: Yeah, of course. At this size, I’m sure this is the perception, but, while you were…
Giorgos Ampavis: Something is not getting done. Something is not getting done, because I know, you know, by experience, I know that there’s a lot of things that you need to do that can keep you occupied, like, for a long time. And I’m actually very busy now so I can see it myself, but…
Kovid Batra: Makes sense.
Giorgos Ampavis: …it may be a case where somebody wants to code, right? It’s again, it’s good if they manage to…
Kovid Batra: Right. Makes sense.
Giorgos Ampavis: …if they manage to balance it, I don’t see a problem. I did phased out from coding in around 2020, 2019-2020 I stopped because that’s when I had to do all the hiring.
Kovid Batra: So, talking about this transition to Flutter, this was definitely a big change, but on day-to-day basis, such kind of big or small tech changes, new tools, new frameworks keep coming into picture and you need them. Do you follow a standard framework or a process while evaluating the frameworks, the tools, the new technologies that you want to implement?
Giorgos Ampavis: Yes. So, technology keeps evolving, right? So, there’s things that we can experiment and there are things that obviously are much trickier to experiment, like changing your tech stack every year. Obviously, it doesn’t make sense. So, it needs to be, like, very well-thought. So, and that’s what we did. Like, we didn’t just woke up one day and said, “Let’s move to Flutter!” Obviously, we had a lot of process, thought process behind it, evaluation process, before we end up to this decision. So, it depends on the scale of what you’re trying to do. I guess the decision is easier, right? If it’s just a tool that you want to evaluate and you can do a POC, you know, you can see if it meets your demand, like your requirements and then obviously cost is one of them, you know, everybody’s trying to cut down on costs now, everybody’s like trying to do that. So, that’s one thing. You evaluate based on the three, four, five criteria you have, and then you make a decision. I don’t want to overcomplicate it because it’s not complicated. But, reality says that it is complicated because then you have all the politics that come with it, especially when you’re talking about engineers. Because you know, everybody, like an engineer, it’s a classic phrase, like, “We can build it.” “We can build that tool. Why won’t we build that tool? We can build it.” And I’m actually facing these discussions, like even today with some of our engineers, like when they think we can build tools, which I get, right? Because we are engineers, we can build everything, obviously. But, we don’t want to build, we want to build whatever makes sense for Tide, and then everything else we need to buy.
Kovid Batra: Right.
Giorgos Ampavis: So, the decision to buy comes with research. We’re never going to go full without researching, like without doing due diligence, without actually comparing technologies, like, you know, and tools. Even with Flutter, we do compare technology before we actually chose Flutter. We did look at Kotlin Multiplatform and what’s the other one? And, Native. We decided, like whether we need to stick with Native. So, we compared these three and, you know, made a decision.
Kovid Batra: Perfect. But, what was the one of the most or one or two important criteria to decide, okay, Flutter is something that fits? Like, one is of course the scale that you want to move ahead, but, apart from that, did you look at some other critical pointers also?
Giorgos Ampavis: Yeah. So, we had three everything was framed around three objectives that we had at the time. One of them was actually ‘lead time’. We wanted to be able to optimize our lead time to market.
Kovid Batra: Makes sense.
Giorgos Ampavis: And, that’s between Native, obviously, and Kotlin will be far from Native, like obviously hypothesis, which I’m going to tell you how it turned out.
The hypothesis was that Flutter will out, you know, outperform the other two. And in fact, we have proved now that we can build much, much faster, definitely from Native, because we only need one team, we don’t need two teams. So, it’s definitely faster. But also, from Kotlin Multiplatform, like Flutter, literally you build once and deploy twice. I didn’t believe it before, but actually it is possible.
The second one was actually, economies at scale didn’t work. So, when we actually wanted to scale that much, like the whole Tide, we needed to hire like probably, I don’t know, another double the mobile engineers we have now, so it didn’t make sense to me at that point to have this big a team. So, based on the premise that build once, deploy twice, then we said, okay, even if that’s not the case, maybe you can optimize your engineering capacity by, I don’t know, 33%. Actually, we managed to optimize it by, you know, we managed to halve it. We didn’t halve people, obviously we managed the demand, we halved the demand, right? We’re still hiring people. But we managed to request half the people that we need it.
And the third one is actually having feature parity between two platforms like Android and iOS. Historically, we had features that were only deployed in Android, or vice versa in iOS. Now with Flutter, everything is in power because we built again once, deployed twice.
So, when we did the original research, we focused on these three, we gathered the data that we needed from the Google team, from other teams, and then we made the decision.
Kovid Batra: That’s really, really insightful. And, uh, like scaling always comes up with different kinds of challenges. And, apart from handling this tech debt, technology, hiring, then the challenge of building the right culture also comes in, right? When you’re scaling, of course, you did the right hire, you tried to find the right fit, but let’s say after that, there is something that you’re doing to actually nurture the team, reinforce the culture. So, how do you do that at Tide? Or how in general, your practices ensure the great culture at scale?
Giorgos Ampavis: Yeah. So culture has two sides of it. The visible parts of it, which is basically the office, the people, dress codes, you know, all that stuff, some behaviors, right? And then, there’s all the invisible stuff, which is, you know, all the rules you have, the unwritten rules, things that they’re not necessarily seen and it’s under, it’s hidden, right? So this, your job is actually to surface the good behaviors as well, that people don’t necessarily see. And you can do this with different ways, like you know, feedback is one of them, like providing feedback, celebrating like, the good behaviors, the ones you want to see, listening to the employees, right? Whatever you’re telling you because you don’t know better. You need to listen, so you can improve. This is how this creates a culture like a positive and strong culture and that has psychological safety and then they can, you know, they can be adaptive as well. And more importantly, you need to lead by example, you can’t just, I can’t ask you to behave a certain way if I don’t behave that way, right? And you know, usually when I talk about it, I close this in presentation, I close with that, because this is the most important thing. Like, leaders need to actually be at the top of the culture. They can’t promote a culture that they’re not part of it.
Kovid Batra: Absolutely. When you talk about the psychological safety and taking care of the team, building the right culture, when all this is in place, I think teams are really motivated, like, innately to work on things, be more creative and deliver better. But at the same time, I always feel that when you scale, you lose that visibility in the team to understand if Teams are really performing or not. Of course, culture is one part, but you really need to understand how efficient they are. And you, of course, have to take care of the overall developer experience also in the team, so that they can move fast. You have to create that environment. So, how do you ensure that they are efficient, they are performing right? How do you exactly do that?
Giorgos Ampavis: So, I’m not going to talk about developer productivity because actually you can’t measure it. McKinsey says they can, but I don’t think you can’t. Like, we established now from Kent Beck and, ‘The Pragmatic Engineer’ that actually we shouldn’t talk about developer productivity. But you know, we do know we do have DORA metrics, like, you know, industry-standard DORA metrics, which they’re great, they cover one part of it because you can still be great at DORA metrics and your team is burned out. You know. So, that’s not enough. So now, we looking into adding a few more things that have to do with developer experience. Obviously we also have the product metrics, like, you know, for our products, the metrics, so all of them combined, they give you like a really good idea about your product engineering teams, how agile they are, how’s the business agility, how happy they are, you know, developer experience, and also are we building the right products, like with the product manager. So I think, that’s all of them together. You can’t look at them in isolation anymore. You need to look at them like holistically, if you want to have a really good health picture.
Kovid Batra: Right. Of course. So can we just deep dive a little bit into this? Like, let’s start with developer experience. What exactly would you try to gauge when you are trying to understand the experience of a developer in your company?
Giorgos Ampavis: So I think the interpretation of what is a good metric on developer experience is different. I think SPACE, there’s a new framework called SPACE, which I think does a really good job. So I have people in the team now looking at this. But ultimately developer experience is self-explanatory, right? It’s about, you know, how happy and productive are your developers? Like, you know, how happy actually mostly, and if they are, that can translate to being productive as well, right?
Kovid Batra: Yeah.
Giorgos Ampavis: So, if you have unhappy people, they’re not going to be productive, we know that. So I don’t want to, I don’t want to, I haven’t looked at it myself. Like, I know about SPACE, but I’m looking at the outcome that I want to achieve. And for me, any metrics you have on the developer experience has to be about the actual people themselves. It’s not about the product anymore. It’s not about, definitely about your releases or deployments, it’s actually about the people. Now, what makes an engineer happy? God knows! Like, who knows what makes engineers happy? We’re a bunch of people, we are.
Kovid Batra: No, of course. But I think, with this approach or this intention of keeping them happy, you will be able to understand that and also maybe work on things that you really want to do for them. So, it totally makes sense.
Giorgos Ampavis: Maybe I’m using happy as an umbrella because happy, you know, it’s like I said, like I tried to imply basically by saying that what engineers need, right?
Kovid Batra: Yeah, yeah.
Giorgos Ampavis: Happy for whatever makes you happy is probably different than what makes me happy. So, I think it’s not just simple as saying like, you know, a simple questionnaire, like, are you happy or not? Like, how happy you are? Like, because we do that as well, right? That I like the pulse…
Kovid Batra: Right. Yeah, we do that.
Giorgos Ampavis:…every week and it gives you..It’s beyond that. It’s not just that. So, I don’t want people to take out that, “Oh, if we ask people if they’re happy, that’s DevEx metrics.” No. There’s a good framework base. They do a lot of work. I’m just simplifying things.
Kovid Batra: No, it totally makes sense. Totally makes sense. So yeah, perfect. I think that answers a lot about how you are leading teams at this time. So I am totally in line with this thought, but, coming to this DORA metrics piece, like those four metrics or maybe a few more metrics which you might want to look into to understand how teams are doing. Do you do that at your organization?
Giorgos Ampavis: Yeah, so we do. Not personally me, but we have a team looking at DORA metrics. Now, we have one of the Directors of Engineering who’s actually looking at holistically as an initiative, like how to get to the next level. Yeah, we do.
Kovid Batra: Oh, so it’s kind of critical for like large-scale organizations at this scale. You think it is important or is it like..?
Giorgos Ampavis: It’s critical if you want to improve, you know. If any company at any size needs or wants to improve, they need to know how they perform, right? As a, at least as a company, forget about developer experience, but at least as a company, they need to understand how they perform. Usually, companies have the KPIs, like the business side of the company has the KPIs, you know, growth, how many users they acquired, ARR, like Annual Recurring Revenue.
But then, you know, for product engineering, going for a tech company, I think it is important to understand how, you know…
Kovid Batra: These people are doing.
Giorgos Ampavis: How basically are you working like?
Kovid Batra: Yeah, yeah. So, I think you touched on a very good point here where success of these tech teams cannot really be defined with just the metrics. I think that there is more to it, right? You have to like, probably build some alignment with the business and help them improve. So, how do you do that at Tide?
Giorgos Ampavis: I mean, think of it this way as an example, right? They’re going to have, like a perfect engineering team, and they’re building all the wrong products that nobody uses. But then, you look at DORA metrics, all four of them, they’re great. Like, you know, great. They deploy like multiple times a day, no bugs, no defects in production, no hot fixes. You know, we respond really fast when we do find one, but we keep building the wrong products nobody uses. So, are we successful as a company? No. I was successful at engineering? I’d say no, because engineering and product doesn’t separate, like they go together, right?
Kovid Batra: They’re together, yeah.
Giorgos Ampavis: You can’t. Like, that’s why we call technical debt. We don’t call it technical debt at Tide, we call it product debt, because it’s one, it’s one product we have. We don’t have a technology, and then a product. Product is one. So, Tide works together as one team, like work together with product, together with our business stakeholders, which, you know, I’m considered one of them as well, like, because we’re part of the business. Again, business is one, right? It’s not separate. We shouldn’t… it’s not us and them. And I think we work together. We have the OKRs, company OKRs, you know, quarterly OKRs. And then these OKRs that translate to initiatives and outcomes we want to achieve. And then, you know, obviously the OKR is not missed, and then we go and deliver them.
Kovid Batra: Great! Great, Giorgos. I think that was really amazing, really interesting. Uh, thank you so much for sharing so many insights and hands-on experience. Any parting advice for our audience?
Giorgos Ampavis: Advice. I’m not really good at advice. I know actually, I’m not bad actually. I’d say, I go back to, especially for new people, right? Like, less experienced people. I don’t want to call them juniors or anything because it’s about experience, right? I’d say don’t, do not be afraid to try, like new technologies. You’ll be surprised of what you can actually see there. Don’t be dogmatic. Like, one thing that I’ve learned early in my life, and actually I paid the price for it, is like, you should not be dogmatic. I actually moved to like, so that’s a funny story, I’m gonna close with this.
I was actually a hardcore Flash and Flex developer, back in 2009. Like, I was doing a lot of Flex, a lot of ActionScript 3, and I hated Apple because obviously it didn’t allow Flash to go into the iPhone, like back then. And then in 2010, January-February 2010, Steve Jobs released this nice email letter, whatever, that killed Flash basically. I decided to drop class and start learning iOS. So, you know, don’t be dogmatic because, you know, you limit your options. So, always continuously improve and always learn new things. That’s the advice.
Kovid Batra: Perfect. Perfect. Thanks a lot.
Giorgos Ampavis: Cool. Yeah, Kovid.
Kovid Batra: Yeah. See you. See you. Thank you.
Giorgos Ampavis: Very nice. Really nice chatting with you.
Kovid Batra: Same here. Same here. Thank you.
In the recent episode of ‘Beyond the Code’, Host Kovid Batra engages in an insightful conversation with Serdar Mustafa, Tech Startup Advisor and Founder of Phoenix Software Consulting. He is also known for lending his expertise to Twilio and Wise. The central theme of the discussion revolves around leading dev teams towards product-market fit.
The episode kicks off with a fun fireside chat which serves as an entrée into his journey and experiences. Moving forward to the main section, Serdar delves into the framework for startups to discover a product-market fit. He shares insights on striking the right balance between thorough user research and the 'fail and learn' approach. He also imparts valuable wisdom on effectively managing technical debt and the right way to use engineering metrics.
Lastly, Serdar leaves audiences with essential advice to navigate this journey effectively.
Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. Today with us, we have an interesting, inspiring guest. He has moved from sales to medicine, and eventually, to product and engineering realms. He has had 8+ years of engineering and leadership experience, currently serving as a fractional advisor to multiple startups. He has been ex-Twilio, Wise, contributing to their product and development. And that’s not all. He’s an author of an interesting growing newsletter on Substack, ‘From Code to Boardroom’. Welcome to the show, Serdar. Great to have you here today.
Serdar Mustafa: Hi Kovid! It’s an absolute pleasure. It’s nice to be on here, on your show today, and speaking about topics which are really close to my heart. So, looking forward to the discussion.
Kovid Batra: Perfect. Perfect. So, we start off with a quick fireside chat where we would love to know more about you personally, outside the scope of work. So, are you ready for it?
Serdar Mustafa: I will do my best and, and try to be agile, as they say.
Kovid Batra: Great! So, let’s get started. First thing – I am fond of people who write. So, I would love to know what made you move towards writing and becoming an author of ‘From Code to Boardroom’.
Serdar Mustafa: It’s an interesting one, actually. It’s really interesting for me because going back to my youth, I was very much a reader, I love to, to pick up books and always kind of add new knowledge, but I was never much of a writer. And, I actually put that down to my ADHD, I have a neurodiversity, I struggle to focus. But then, throughout my working career, I actually turned that into a bit of an ADHD superpower. I realized that my scattered thoughts in the early days were better when condensed then and put into writing. When I started documenting the things I was doing each day, keeping logs and journals, and documenting, kind of various technical operational aspects of my roles, it made everything better, not just for me, but for the teams I worked with. And, I brought that into the product engineering roles. I’m sure we’re all familiar with the type of documentation that we get in the industry. By me starting the blog fairly recently, I was able to kind of put down my thoughts in one place where I could kind of gather them and reflect on them and keep them updated as things changed, but also share them with my peers, try and help other people with the knowledge that I’d gained over the years and help them excel at what they’re trying to do.
Kovid Batra: That’s really cool. And I really am inspired already from the kind of journey you have started with. And it’s really amazing to see you contributing back to the community. Kudos to you, man, for that.
Serdar Mustafa: Thank you. Thank you.
Kovid Batra: All right, moving on to the next one. I think now I know the answer to this, but love to hear more from you. What gives you the energy to overcome those roadblocks that come your way?
Serdar Mustafa: I guess I was always a competitive person as a youngster. I was an athlete. I was practising martial arts, gymnastics, parkour, and naturally these things had various challenges. And, I guess when I first started out both in sport and then in work life, there was always some prescribed way of doing something to get the job done. And it was only really when I came into tech businesses that I found this relationship between what I had done as a youngster with my sports, and the way software development teams work with the need to kind of pivot and change on the fly, adapt to what we’re doing. I really related it to my martial arts, my parkour in particular, when I had these obstacles or roadblocks, as you say, which didn’t always have a predefined way of challenging them. There was no script. You couldn’t always plan in advance. You could try and prepare for them as much as you could, but there was always these unknown unknowns. So, I learned to be able to stay agile, I know a bit of a cliché word in our industry. But, I learned to adapt and do things in different ways. And, this mentality that I developed, when I installed that into the teams I was working with and, and saw other people excelling and doing better in their roles, it really gave me this huge motivation. As someone that’s been coaching in sports and coaching and mentoring in business, seeing other people succeed has been that catalyst to me, that’s been the fuel to my fire. And, I love seeing that success from the people I work with. So, that’s what led to the blog and that’s what led to me going back into leadership and why I’m here today.
Kovid Batra: That’s amazing. Amazing. That, that feels really intense to me, and this is quite a journey, I definitely feel so. Let’s tone it down a little bit and let me understand from you, like how do you unwind your day? How do you end your hectic day? What’s your way out there?
Serdar Mustafa: Definitely a challenge for me. It’s one of my weaknesses, if ever there was one. Wearing the multiple hats that we do in startups, it’s hard to kind of press pause or stop and unwind. But, when I eventually do I’ve got two ways, really, if it’s something I need to do on my own and just clear my head, I’m a motorcyclist, I jump on my bike, I live near the countryside. So, I just go for a blast and pitch-up somewhere and just stare at the sky, stare at the trees, anything that’s not work-related.
But, other than that, it’s my family. I’m a father, a husband. I’ve got 3 beautiful daughters, and we love going out hiking and cycling. And, that’s enough for me to re-energize and reset before the next day.
Kovid Batra: Perfect, Serdar. I think that was great knowing you and there is more to come. That would be in the main section that we have. So, let’s get started there. Are you ready for it?
Serdar Mustafa: Yep. Let’s do it. Let’s do it.
Kovid Batra: Perfect. So, in this piece, we would love to know your experiences, your success and failures at different point of time in your career. So let’s just start with something like your journey, which has been across different departments of a business. How does your experience across different departments of a business impact your leadership style? Because you have been into sales, medicine, product ops, and then engineering, and then engineering leadership. I am really interested to know how does that make you different?
Serdar Mustafa: See, what most people see is the difference in job titles, job roles and industries, but there’s one similarity in most of the things I’ve done throughout my career that people often overlook, and that’s the people leadership.
Kovid Batra: Yeah.
Serdar Mustafa: It’s soft skills, it’s learning to collaborate and communicate with people to help boost their success and their achievement. So, I’ve never focused on being the best martial artist, being the best programmer, or being the best leader in isolation. It’s more about being an accelerant and, and lifting others up. And, by having this kind of experience in other roles and teams, I’ve looked at the different ways people do things. And then, when I look at the circumstances I’m in, any given role, I try to get the best bits from each of them and combine them to find new solutions or discover new problems that need to be solved, and look at how we can welcome them together.
Once upon a time, the manufacturing and car industry worked in a very rigid way. They were set in their, the way they did things, and then we started getting kind of lean principles and things from Japan, the way that they did these things. And, I’m sure they were laughed at initially. They were told that, no, you can’t do it. Like, there’s this way that we do things, and that’s it. But eventually, things called on and people adapted. And, we all know where we went from lean to agile and all the various methodologies. It’s been diverse and I have, I guess, a great variety of diversity across different roles and types of teams and working with different people in different countries, I’m just able to filter that down through the funnel and find a mix of things that helps the team that I’m in the best.
Kovid Batra: Makes sense. When you have been dealing with different teams, of course, the core motivation for people at work, most of the times remains the same, even when you’re in sales or in tech. So, just tell me one thing that you took from your, probably the sales experience or the medicine experience that you are able to apply here in engineering, and that has really helped you.
Serdar Mustafa: So, I mean, the sales experience, there was something that we used to do when I was a General Manager at Phones4u, a company that sadly doesn’t exist anymore. They were the largest retail mobile phone company in the UK for many years. We had this way of selling that was unique. We used to sit our customers down and establish their demands and needs. They would come in with their problem statement. They would say they need a new phone, and they would already have an idea of what phone or tariffs and things it was that they, they thought they needed. But, by sitting down with them and understanding their problems, understanding their budget and the other variables, we were often able to find them a better combination of these products that suited their needs more. When I relate that to Product Engineering, when we do user interviews and do all this user research, users often tell us what they think the problem is. But, unless you know what kind of open questions to ask and really understand what the problem is they’re trying to solve, what you can end up doing, and it’s common problem for even the largest of companies is building the wrong thing or building it in the wrong way. So, by using the kind of techniques that we developed in my previous sales background, we’ve been able to enhance the engineering teams that I’ve been working with.
And, slightly shorter story, but similarly with the medicine aspect, it was biomedical science that I studied which is a lot more research-driven than clinical medicine. But, the things I learned that really help is about hypothesis testing, statistical analysis, and understanding the context when you’re looking at raw data, we see so much data in our industry, all these developer metrics and user data, but what did it actually mean? When we look at a line graph or some pie chart or something, it’s usually presented in a positive way with certain colors and points on there to give a certain perspective to a certain audience. But, what I’m able to do with my medical knowledge is apply context to that to show are we really working towards our acquisition, activation in the way that we need, or is there something hidden in this data? Are there kind of outliers and things that we can analyze further to make better business decisions? So, that’s where that experience in those two different industries has really helped me in my roles over the last few years.
Kovid Batra: Cool, yeah. That’s, that’s really interesting. And I think very insightful. Perfect. Perfect.
Moving on to the next piece, what do you think it takes for a startup to find a product-market fit? Like, you have been working with multiple startups as an advisor, as a fractional advisor. I would like to know from you, like this initial journey of zero to one, this is really interesting. I have been into that multiple times, but I would like to know your perspective. Like, what does it take? What are those core things or maybe a framework that you have in your mind people follow?
Serdar Mustafa: I mean, at this stage, when you’re looking for product-market fit, whether you find an SLG approach or PLG approach, I think the key thing is to keep things simple. It doesn’t matter if you’ve got a complex product, the way users find it and your approach to development and things should not be complicated. They should be in the simplest form possible to help you build… instead of an MVP, I prefer to call it an MLP, a ‘Minimal Lovable Product’. Ask those questions, do the right type of research to really understand who your users are, how they’re going to use it and what problems it’s solving for them. And, a key example of this is, with our kind of empty state screens and things that we get on our loved SaaS products, one of the first things that you usually see is, “We can save you money.” “We can increase your profits.” “We can increase your brand recognition.” And all these kinds of things. But, that’s not actually the solution to the problem statement a lot of the time. They are usually commercial targets or objectives people are trying to reach. You need to really dig in your product to understand who these people are and how do they use it. Once you’ve provided and advertised that solution, word of mouth will do the rest. And there’s even businesses out there which have relied solely on word of mouth with no marketing and advertising budgets. Once you do those basics, you’ll establish product-market fit.
It’s a complex multivariable equation that requires a nuanced approach. There is no, kind of one t-shirt that fits all. There’s no point reading the latest blog on PLG or any of these strategies and try to apply it universally to what you’re trying to do. You need to really look at the intricacies of what you’re trying to achieve and, and adapt things. And you can only do that successfully by keeping things simple. If you start exploring overcomplicated technologies, overcomplicated system designs and architectures and things, just because they’re cool or that they’re the latest fad, you’ll often find yourself spending too much money in development and in hiring things before you’ve established that product-market fit.
And, bear in mind the climate changes as well. What you’ve identified now may be slightly different in six months time. So, as long as you’re not overcomplicating things, you can adapt faster. Hence, why I use the word agility a lot.
Kovid Batra: That’s, that’s totally bang on, I think. I have a question on this. Like, while being on this journey, multiple times myself too, I have always struggled to strike a balance between doing this user research, coming up with insights and then implementing something. And also at the same time, where I had my Co-founders, who believed in doing and failing and then learning from it, and then iterating. So, there has to be a balance between the two where you just go on the research journey, find out something, and then you execute, fail, and then learn from it, and then improve. Which one do you prefer, and how do you strike that balance?
Serdar Mustafa: I mean, it really depends on the nature of your business and the kind of people that you’ve got behind you in leadership or as Co-founders and things like that. One thing that’s imperative is that you’re all agreed. You should have one North Star metric that you’re focusing on at a time. Any kind of OKRs or whatever goal-setting methodology that you’re using should be aligned to that North Star, and everybody should be working towards that at the same time. As far as the approach to get there, it doesn’t matter if you’re following some kind of growth engineering type reports, some experiment-driven design or development, and you should always rely on as much data as you can get practically, and within a reasonable period of time.
It’s about changing direction. I mean, the quote from Bruce Lee, “Be like water.” Water can… I’m not quoting this verbatim, by the way. So, any Bruce Lee fans, please don’t shoot me, and… Be like water. Water can flow hard. It can flow fast. It can be soft, and so on and so forth, right? It adapts to its environment, and that’s what you should be doing. So, if you choose on day 1 to follow some kind of data-driven development and you’re looking at stats and you’re looking at all this user research focus groups and things like that, you need to know when to either adjust or mix the method with a different type. I would always advocate for using some kind of mixed methods, some quantitative and some qualitative. Just be ready to change direction as the business sees fit.
Kovid Batra: Makes sense. Great! I think that’s really interesting. And, I think it’s more about being in the situation, having that feeling what’s right in that moment, because you might not always have the data to take a decision on that, but what we can do is actually timebox things to really keep moving fast and change directions, and then experiment with that.
So, cool. I think…
Serdar Mustafa: Mm hm.
Kovid Batra: Yeah, please go ahead.
Serdar Mustafa: No, I was just going to say, you know, you’re absolutely bang on it. It doesn’t matter which kind of goal-setting methodology you use, the age-old smart goals are always relevant. You should timebox things. You should have some mechanism to evaluate and review how things have gone and then make the necessary changes moving forward.
And the other thing I would say on the topic is make sure that you’re getting as much advice as you can from the professionals. If you don’t have those people in the team as you’re starting up or as you’re growing, there’s consultants out there, advisors, and fractional people like myself. There’s all of these different resources available these days. Try some different options, take that advice in. And at the end of the day, you’ve got to make the judgment, which one you follow. So, no one knows the answers for sure. But, they can at least guide you in the way that their experience has shown previously.
Kovid Batra: Definitely. Got it. Well, this is something around the startups and for our audience who are into this journey. We have people across the world who are leading bigger teams, well into the phase or who have crossed the phase of zero to one and are into the growth and scale mode right now. For them, the day-to-day challenges would be around being more efficient, being more productive. So, when we talk of this efficiency and productivity and effectiveness in the teams, how you have been doing it with your engineering teams as a leader to measure the efficiency and finding those inefficiencies and then improving on those, how do you usually deal with that? And of course, when we talk of efficiency, productivity, we really can’t give up on the well-being of the development team or the developers. So, a combination of this. How do you take care of it as an engineering leader, the efficiency and the well-being?
Serdar Mustafa: Efficiency and well-being. I mean, again, specifics depend on the type of business. If you’re a small 5, 10, 20-person startup, it’s going to be very different to a large organization that has a thousand people in engineering. Things scale differently. For me, most of my experience has been on the smaller side of businesses, up to 50-person engineering teams, and they’ve all shared a lot of similarities. I’ve been in the business where they were initially trying to use kind of more enterprise-type approaches to standardize everything they do. They would pick some kind of agile methodology or framework, use well-known engineering metrics, things like cycle time and velocity. And to support that, they would have sprints and story points and things. But, one of the issues I have with this is they’re using essentially qualitative data, and trying to get a quantitative output. Things like measuring efficiency with cycle time and velocity, you’re relying on story points, t-shirt sizes, things like the Fibonacci sequence and that, which are all numbers, obviously. They’re all quantitative, but the source of that number or that, that data point is qualitative. You’re basing something on ‘how much time does it take to do this type of ticket’ or ‘how difficult is it’, ‘how complex’ and stuff like that, right? So, how do you convert something qualitative into quantitative and then standardize it when there’s so many other things which can impact it? There’s people taking time off, there’s people leaving the business, people joining the business, there’s national holidays, there’s unknown technical problems which may occur that divert your resources and attention. If you’re in a young startup, you may even decide to pivot everything that the team is doing or certain teams within. So it’s, it’s hard to plan and measure these things in that way. So, what I prefer to look at is more on the efficiency side of things, the outcomes. What is it that we’re trying to do? Going back to that North Star metric and those OKRs or similar system, what are you trying to achieve? Is it acquisition? Activation? Are we trying to improve customer satisfaction? Reduce the amount of bugs? Pick a thing that is your goal, establish a baseline of where you are and where you want to be, have the measures in place to be able to do that, and then measure it over a given timeframe. So, like you said earlier, you need to timebox it and look at how it’s done, and then you can dissect it, disseminate it, and analyze it afterwards to see the what’s, the why’s and, and things like that, before you improve it.
Kovid Batra: Exactly. So, I think you are completely aligned on the thought where how important the business objectives are, business outcomes are, and I totally second that thought. But the point of measuring efficiency comes in when you face problems in metrics like customer satisfaction, right? Just for example.
Serdar Mustafa: Mm hm.
Kovid Batra: And this customer satisfaction could be going down just because your app is not working right, which ultimately trickles down to the fact that why is it happening and you need to know an answer to it. So probably, what I personally feel is that these engineering metrics could really help you understand that, “Okay, this is the root cause.” So, let’s say the customer satisfaction is going down because of the bugs or the issues that are there on the app. How would you understand that? You would be able to see that in the engineering metrics. For example, if there are very less comments going on the PRs that are being merged to the main branch, just for example, you would know that the teams are probably not having a strong review process in place because of which the quality of the product which is going out is not right. And so, the point is absolutely right in a way which you said, the most important thing is to look at the business metrics, and then from there, if you identify problems, you need to deep dive onto the engineering metrics to understand where things are going wrong. So, what I feel, not to say that you are doing the wrong thing, but to basically put in line that how these things connect with each other, like product and engineering connecting together to ultimately deliver the product, right? So that’s something which I personally feel is important for engineering teams to look at time-to-time that how they’re doing on their bugs rate, how they’re doing on the code review process, how they’re doing on their comments per PR. There are a lot of such metrics that are there into the picture, but yeah, that’s what my thought is. What do you think about that?
Serdar Mustafa: So, I guess it has to work, I think. A lot of what you’ve just said is on the assumption that you’re doing traditional code reviews and pull requests, when there are a lot of ways of working, shall we say, aligned with various agile methodologies, like XP (Extreme Programming), which work in a different way where people are working more collaboratively, either paired coding, group coding, and mock coding and so on, where you’re doing things kind of more proactively, you’re shifting things to the left. And, you’re not writing the code and relying on someone to catch it in a code review after. Even if you’re having regular small commits and small PRs, there’s room for error and there’s certainly room for improvement. But, I think we need to rewind a little bit before that.
Technical debt, huge topic, but actually I think a lot broader than most people give it credit for. Technical debt can cover the product side of business, commercial sales, marketing, so on and so forth, not just engineering and the code that we write. In short, there’s, I believe, two types of technical debt. There’s the intentional technical debt and the unintentional. The intentional technical debt are decisions, business decisions, engineering decisions. Somebody who’s chosen to build something a certain way… now, for that decision to be made, we can discuss another time, the kind of steps that may be involved and peer groups and workshops and things, but let’s say that, that bit’s safe, that bit’s being done well. It’s the unintentional stuff. The unintentional is we had a goal of building something that was going to end up a certain way and it hasn’t ended up that way, whether it’s a defect, a bug, an error, whatever we want to call it, it’s not the way it was intended. Now, a certain amount of this, we have a tolerance for. Technical debt is like a financial or credit card debt. When used responsibly, you can improve cash flow and get you by until you’ve got more income coming in. In terms of the technical aspect, we can introduce a certain amount of technical debt. And, I don’t like the phrase ‘cut corners’, but we can do things intentionally in a way where risk is mitigated, but we are delivering the MVP. We are getting the next iteration out there in a condition that we are happy accepting.
Kovid Batra: Yeah.
Serdar Mustafa: It is when not managed responsibly, that this debt can spiral and accumulate, until one day it bites you in the proverbial bottom. In engineering, that’s when we make out our software and code and things too complicated, unmanageable, unscalable, and too specialist and things like that. We create silos and all these things. What we need to do is focus on making sure that we are building things that are simple and solve problems. We need to keep even the operations and systems and ways of working simple at first. There’s no point investing too much time measuring these kind of metrics in the early stages. And when we do decide to start adding things, we need to do it incrementally and review them to make sure they’re actually providing value.
Kovid Batra: Absolutely.
Serdar Mustafa: I don’t want to say get rid of things like cycle time and velocity and these traditional metrics, but instead, introduce them at the right time, the right amount of them, understand the return on investment from doing this, do it in collaboration with the people that it’s going to impact. So, discuss these things with the engineers, with the product people, QAs, and so on, to see what they think, because this affects the second part of your original question about kind of developer experience and things.
If you introduce these things, they can be misinterpreted. They can be seen as kind of performance management metrics. They can be seen in a very negative light. And ultimately, there’s no point having great developers, a great team building fantastic things of solving user problems, if you’re just going to have a high turnover of stuff, because they’re not happy about the performance management metrics and things.
So, there’s a whole load of stuff in this realm that could be discussed. And I know we don’t have the time today, but, what I’m saying is really think about the kind of metrics and the value they’re going to give your business. Why are you doing them? Is it just because engineering managers typically have these metrics? Who are you showing them to? And, what are they doing with them? I actually asked these questions in a previous role. I inherited a leadership role as I got promoted and someone else left. And, I was expected to continue filling out these dashboards and looking at these metrics, and I actually stopped after the first week and went back to senior leadership and asked, “Why do we have them?” “Who are they for?” And, I actually asked the CEO explicitly, “Is it for you?” “No.” “Was it for the CTO?” “No.” The answer was, “Because your predecessor was doing them, we just assumed that you would continue.” But, they weren’t going anywhere.
Kovid Batra: Got it. I think I totally agree. I think, to conclude on this point, what I would say is that as you scale, you just need to understand the need of the right metrics that you want to introduce, and they have to be introduced with the right culture in place where people are, the developers are feeling psychologically safe and they’re not taking it the other way around, where it is ultimately for the benefit of everyone in the team. So, I totally get that point that with scale, the need of such metrics would come in. And, we have to like, as an engineering leader, we have to figure out which metrics to look at, how they should be deployed and used for the improvement and good for everyone actually.
With this, I think we have exhausted all the things that I wanted to ask on this, on this podcast. And, it was really, really interesting talking to you. I think we can have another podcast on the last question where we left and like, discuss more on that. I really found that piece interesting where you touched on the technical debt part. Would love to talk more on that, but probably on the next show.
Serdar Mustafa: Absolutely. No, I’d be more than happy to. I hope that your viewers and your audience get some value from the discussion today. And, even if there’s one little thing that they take away from it to help them improve themselves or their business, I’d be satisfied.
Kovid Batra: Absolutely, Serdar. So, one last message for our audience that you would like to say?
Serdar Mustafa: Keep your head high and stay positive. I know it’s a, it’s a turbulent industry, but it’s extremely rewarding, if you ask me. The, the satisfaction from seeing yourself succeed, your team succeed, or your product or your business that you’re in is just second to none. So, keep it going.
Kovid Batra: Thank you so much. Thank you so much for this.
Serdar Mustafa: Thank you, everyone.
Kovid Batra: All right, Sid. See you!
Serdar Mustafa: Bye, everyone. Bye, Kovid.
In the recent episode of ‘Beyond the Code, Host Kovid Batra welcomes Marian Kamenistak, engineering leadership mentor & coach, founder of Augment Lab, and a former VP of Product Engineering at Mews. The core of their discussion revolves around boosting engineering efficiency with data and empathy.
The episode initiated with a fun, fireside chat, allowing audiences a glimpse into Marian's personality beyond the professional realm. Moving forward to the main section, Marian delves into the obstacles he faced in his engineering journey and details the strategies for overcoming them. He highlights the significance of maintaining a data-driven mindset as well as underscoring his three core principles: transparency, trust, and prevention. He also elaborates on two distinctive terms - 'Roadmap contribution' and 'Epic Cycle Time’.Wrapping up, Marian imparts valuable insights for engineering leaders, emphasizing key considerations to drive efficiency within their teams.
Kovid Batra: Hi everyone! This is Kovid, Kovid with a K, your host at ‘Beyond the Code’ podcast series by Typo. Today with us, we have an interesting, amazing guest from a really amazing place called Prague. He has 15 years of engineering leadership experience. He has been a former Vice President at Mews. We would love to learn and hear your thoughts today, Marian. Welcome to the show.
Marian Kamenistak: Thank you, Kovid. Thank you for having me. I’m looking forward to run this show.
Kovid Batra: All right, Marian. So, before we get started with the main section of how to use engineering metrics and how to have a data-driven mindset, I have a quick fireside chat to know you more, okay?
Marian Kamenistak: Okay.
Kovid Batra: And you have to be, like very comfortable. Share your real thing, okay? We would love to know, our audience would love to know you. Are you ready for that?
Marian Kamenistak: I hope I’m ready!
Kovid Batra: Oh, no, it’s going to be light.
All right. So, we’ll start with the fireside chat. The first question, which is your best memory from childhood about coding?
Marian Kamenistak: Oh, coding! Yeah. The thing is, like I started coding at age 11 approximately, and it was not really like, it was the oldest PCs, if you know what I mean? So, by that time, if I wanted to play games, I had to, you know, uh, basically run it from the audio cassette. That’s the first thing.
Kovid Batra: Yeah, yeah.
Marian Kamenistak: And the second thing of course is that, you know the graphics was not really exceptional, but I was lucky to have some sort of coding book where I went through the tutorial step-by-step. That was the first like, you know, enlightening of saying like, you, this might be the right thing to do and to play with around. Yeah.
Kovid Batra: Great, great. I think starting to code that early would have been amazing, man! I think nobody at that point of time probably would have known much about it. So, that’s really interesting.
Marian Kamenistak: Yeah. And the thing is, like the computer was not really ours in my family. It was, you know, my father’s gift. He’s somewhat moved it from his office… To home sometimes from time to time. And, I was benefiting from that experience, right? And then I was, like really asking him hard way to bring the computer every single time after he’s back from work, right? So, which was really comfortable in the end.
Kovid Batra: So, now you know how legends are born, right?
Marian Kamenistak: Yeah!
Kovid Batra: Great! Moving on to the next fun question. Now, this is my favorite. Which one’s your favorite Netflix series and why?
Marian Kamenistak: Oh! There’s a couple of them. To be open, I’m not really watching Netflix or, you know, Disney anymore cause I’m really strict when it comes to my schedule. Nevertheless, if I do have some time, I, last time I remember I was watching, I think it’s called ‘The Sandman’. The Sandman is really like, you know, something that I was really astonished to see cause, you know, the story is amazing. Plus, you know, the graphics, that’s something which really caught my eye. But nevertheless, like, you know, the story about, you know, the dreams and the way how to think of some, you know, parallel universe, that’s something what was really mind-blowing in my case.
Kovid Batra: Thanks for sharing that. I think we have got a few more to watch on Netflix now.
Marian Kamenistak: But, I’m sure there’s so many better series than this, but, you know, I’m already out of the current time. Yeah.
Kovid Batra: Perfect. Last question. How do you unwind your day?
Marian Kamenistak: Oh! You know, when I’m usually finishing my day, I’m getting pretty tired, to be open and honest, because most of the time it’s mostly advisory to specific companies or mentoring. And, there is, by the way, one thing I found out, which is I can’t handle more than, I would say 3 to maximum 4 mentoring sessions a day, because it’s as intense as handling interviews and, openly speaking, I’m just moving to my men’s cage, if you know what I mean? And, cry on my shoulders to preserve my energy. But openly speaking, you know, uh, I’m living in a cottage house, so, what I love doing is really to go and walk, you know, around my garden. Plus, I’m a family person. So, you know what it means, you know, having the family and taking care of the kids, and so on and so forth. Nevertheless, as I was saying, I desperately need all the time and each and every day to preserve some of my just private time in my cave for myself with no internet, nothing, just, just, you know, taking a rest and taking a deep breath, right. Yeah.
Kovid Batra: Yeah. Thanks for sharing all this. It was really, really nice knowing you more.
Great! I think now it’s time that we move on to the main section where we talk about how to maintain engineering efficiency with a data-driven and empathetic mindset. So, this is, I think very close to home to you also because you have been a leadership coach and you have been posting a lot about such topics. So today, I have a very, I would say interesting, as well as deep questioning here from you to actually see how you lead engineering teams while you work with them. How do you teach them that data-driven mindset and empathetic mindset to actually improve the efficiency? Yeah, right. I think we’re all set.
Marian Kamenistak: Yeah! We are good. And we’re looking for the topic cause I’m a data-driven person, to be open. So, looking forward for the topics we have ahead of us.
Kovid Batra: Sure, yeah. So, I think I’ll start with your experiences first. You have 15+ years of coaching, being VP, I mean, diverse experience as an engineering leader. You would have seen a lot of challenges, and you would have overcome them. So, let’s talk about something from your experience at Mews probably. Anything that you would love to share with us? Any specific challenge? How did you overcome it?
Marian Kamenistak: Oh, okay. So, putting a little bit more perspective into my last full-time gig, it was the story of Mews where I was working as a VP of Product Engineering. And, now I can say the story was pretty funny and interesting. Nevertheless, when I started at Mews, it was not that funny anymore because it was the COVID time with the C, not with the K, of course. So, there was plenty of the layoffs and you know, the let’s say the atmosphere was not that great, I have to say. By the time I was running around 8 to 10 teams, different product engineering teams, and after almost 3 years, I ended up with more than 30 teams in total, right? So, the experience was that after a couple of years from, you know, running basically, resurrecting, that’s, I would say, the right word, the teams from sort of a poor efficiency into something meaningful, into something that the teams are really considered as an ammunition that can overcome and run over the competitors basically. And, that was what we were after. And, in the end we ended up being successful in Series C investment, which was around 200K, right? Pardon me. 200 million, right? A bit different number here. So, that was really the story of Mews. Of course it was not only my job. It was the job of, you know, other stakeholders, participants, other peers. I wouldn’t be able to basically resurrect and grow the team just on my own. That being said, the important portion of that goes to, for example, product management, and to other departments in the company.
Plus, we had to change the culture and prepare the teams for the goals, right? So, that was one of the things. So, you know, roughly speaking, when it comes to the challenges, it was really, you know, making sure that all the teams are aligned, cause, there was so many different initiatives that we were running. Plus, you know, the focus was not there. I would dare saying that the teams were not really efficient in the end, right? Although we were busy, you know how it goes.
Kovid Batra: Right.
Marian Kamenistak: The productivity was not really there. And I was told that, you know, when I entered the company, I was told by the Chief Product Officer that “engineering is a black box.” Basically, that was the message. And, so turning that into something that works, into something that’s predictable, that’s transparent, and, I would say the keyword here is ‘trust’ to turn the teams to something that is trusted.
That was really, you know, one of the stories that we were after and successfully, we made it work this way. Yeah.
Kovid Batra: Okay. Did you do anything about solving the “black box” particularly? Like, when it was told to you that it’s going to be a black box. And, then of course, when you are leading a team, you just don’t want it to be a black box. You want to know a little in-and-out. Of course, things run on trust. That’s totally there. And I totally believe that’s the core of every good team or a successful team. But still, were you comfortable with that thought or did you do anything about it?
Marian Kamenistak: Well, of course there were some sort of initiatives that, you know, I made live. Openly speaking, I started my first 3 months doing some sort of an internal audit, meaning like, you know, making sure that I understand, you know, the foundation, I understand the product, I understand, you know, when it comes to the teams, to their productivity and, you know, all the different aspects of that, including leadership, of course. And, the second thing is, you know, after the audit, it was pretty clear to me what are the main, you know, most valuable items or initiatives that I should be focused on.
To be more specific, I started observing the teams, the way that I attended their different ceremonies. I was working closely with the product engineering site. One of the issues was, you know, again, openly speaking, the cooperation between engineering and the product as such. And the second issue we were facing was transparency, meaning we wanted to make sure that, engineering, product are both transparent enough in terms of knowing where we are when it comes to sort to, to ongoing initiatives, where we are when it comes to the backlog, and what awaits us. So basically, the purpose of that was to lower down the communication gap. And, once again, the transparency was, is one of my principles that I’m sticking to quite well. That being said, I moved from, you know, spreading the gossips and the hypothesis about the gut feelings to the system that really worked through data. And seeing how things work for us, by, inspecting certain things in reports, basically. I know it doesn’t sound very attractive. But, leading more than a dozen of different engineering teams, you don’t have a much of a choice, because that would go to micromanaging the teams, which is not the right path to go, especially in case you want to scale the teams, right? And give them the ownership. Yeah.
So basically, coming back to your question, I would say ‘transparency’ is the keyword we are looking for. Yeah.
Kovid Batra: Hmm. That totally makes sense.
Great! Thanks for sharing this. Moving on to my next question, which is kind of related to this, when you talk about transparency and not micromanaging right? I have seen different teams, different type of leaders, like ones who are purely data-driven, right? Then, there are teams where leaders are purely, like intuition-based. There are 40 developers working, but they are working on purely the intuition. What’s the productivity? What’s the output? How things are moving? So, people are very intuition-driven. And, I’m not saying that it’s wrong or right, but every situation demands a different balance of both. That’s what I believe. What’s your take on that? Like, you must have seen teams in the similar manner as I have seen. Some are data-driven, some are purely intuition-driven, some have a balance of both, right? So, what’s your take on that? I just wanted to hear it from you.
Marian Kamenistak: Yeah. Well, of course, it all depends. It depends on, you know, what’s the current stage of the company, whether that’s an early startup, the scale-up, or I would say, up to a corporate, you know. The second thing is whether, you know, the company as such is working on projects or products, if you know what I mean, right? That’s a, that’s a huge difference. The other differentiator might be whether the company is a stage of, you know, sales-led vs product-led growth…
Kovid Batra: Yeah.
Marian Kamenistak: And, you know, strategy; that’s by the way, really important because when you are sales-led, then you need some sort of a lead who’s, you know, giving you the direction and who’s sort of almost micromanaging things, which might be the right thing to do at the given time. Nevertheless, if you want to scale, then you should be slightly starting to move towards the product-led organization, right? What I was going to say, there are different aspects that, that might influence our decision process, how much I’m going to lean towards, you know, the gut feeling and empathy vs data. Nevertheless, my message would be, if you are running more than 8 different teams, or I would say 6-8 different teams, then it might be the right time to verify your hypothesis and help the teams with the productivity through the data-driven approach, right? And that was really my path. And, again, I stick firmly with my principles, transparency, and providing this sort of, you know, transparent reports with valid indicators, of course, is, in my case, the right way to go. And it always, sorry to use this word, it, it always saved my ass, right? So, that’s, that’s how I see it, right?
On the other hand, when we have, you know, gut-feeling teams, if we may put it this way, what I see often, there is a big proportion of inertia and a big proportion of complaints and sort of inability to make the right decisions. To be very specific, what I mean is that, for example, if an agile coach tells me, you know, “We have an issue with a specific, let’s say, with velocity, with estimate or with, uh, the quality of the product or with the deployment frequency, or with the confidence when it comes to the sprints completion.”, then, it’s not only to have this gut feeling, but also to look into the data, because since the moment I’m showing some sort of trends based on the figures, then people start to listen to my arguments, as opposed to say, “Okay, that’s yet another hypothesis, and we heard already hundreds of similar hypothesis. So, thank you for sharing your opinion and let’s move on to the next topic.” Right? So, that’s not something that is really helpful. And, the way, for example, how I’m treating data is that, for example, I’m very specific when it comes to fixing or improving the teams. What I mean to say, for example, I want to, I’m really tying improvements to specific measures and here I may say, for example, when it comes to the sprint completion to me, the healthy consideration of the team is I want to see that the teams deliver, minimum 80% of the sprints, right? When it comes to the roadmap contribution, I expect that the teams deliver or spend minimum 60%, for example, generally speaking on the product roadmap, right? So there are different, let’s say thresholds or metrics that I’m using just for the sake of making sure that the team is considered highly-performing and healthy.
And here I want to make some, some sort of a side note, which is often I see that, you know, each and every manager or, you know, owner of the company wants to have highly-performing teams. You can have these sort of teams, but when you are throwing junk into the teams, then you get the junk out of the team, right? So, it’s not only about having the highly-performing teams, it’s also really important to know what I’m asking these teams to accomplish, what’s under their plate, what are the main initiatives and whether these initiatives are the most valuable things that these teams can do as opposed to doing something that goes to the shelf and not being touched by the customer, right? So, that’s something that I see being neglected sometimes, yeah, a bit often than I would wish.
Kovid Batra: I think I personally have felt this that this seems very right with scaling. You have to have this kind of a mindset. You have to bring in that transparency. You have to be little data-driven, in fact, not little, little more data-driven than you think you should be. But, even though it seems right, and most of the engineering leaders I feel are very intelligent, they are well-aware of the situation and they know that this is probably the right thing to do. But why do you think there is a restriction or there is an apprehension towards not adopting such frameworks? I might be wrong here. This might be an assumption, but I talked to a lot of them, but there is some level of apprehension I feel in the engineering leaders usually that they don’t move towards this. What do you think could be the reason here?
Marian Kamenistak: Well, you know, I had a luxury to implement or to help with, with the advisory, implementing, you know, this sort of data-driven approach checks when it comes to the teams in a couple of different companies. Most of the time, this sort of, you know, pushback or rejections comes from the fact that you know, we don’t want to treat our people as numbers, if you know what I mean? So usually that’s the number one thing that I’m hearing. And the second thing is that, you know, data is just part of the song, you know, part of the story, which is absolutely right. And, here the important distinction is, we were talking previously, you know about extremes, which is, you know, either you have the gut feeling based teams or the data-driven teams, of course, the combination of both is the, you know, that’s the biggest “wow factor” that you can obtain. Speaking very openly, you know, I treat these numbers not as goals, but rather as aspirations or indicators. That’s the right word in my opinion, because you know, to be very specific, you might be having a person with the high amount of pull requests or opposites to that. And you might be saying like, you know, “This is the right developer.” Opposite to that, you might be a person, you might have a person with the very low to zero number of pull requests. But, it doesn’t mean that that person is low-performing because instead of you know, individually contributing to the code, he, he might be doing mentoring and code-pairing and doing some more programming, which has a much higher aspect…
Kovid Batra: Absolutely.
Marian Kamenistak: …you know, impact compared to the metrics that we are using. So, there has to be always some reasoning why and some connotation. So, yeah, the thing is that, you know, we shouldn’t be using these numbers, some definitive metrics whether the team is highly-performing or not. There is always some sort of context into that that has to be added there. Yeah.
Kovid Batra: Right, right. Perfect! I think well-answered there. I get your point.
Cool. Let’s move on to something more interesting here.
Marian Kamenistak: Okay.
Kovid Batra: There are different, different metrics, which each team has to look at different scenarios, right? Like when, when you talk about, like cycle time, how many lines of code somebody has written or how many commits somebody has done. There are different metrics that you can look at. I mean, there are 20s of them.
Marian Kamenistak: Yeah.
Kovid Batra: Prominent framework is around DORA and SPACE, but let’s say if we are choosing to work on something in a team, there are a few metrics that one should look at, right? So, how do you choose those metrics? How do you choose which ones to really look at?
Marian Kamenistak: Okay. Okay. Yeah. Exactly as you are saying, Kovid, the basket from which we can choose is pretty broad.
Kovid Batra: Yeah.
Marian Kamenistak: Here, we speak about dozens to almost a 100 of different indicators that we might find useful. You know, before I start diving into specifics, let’s uncover some of the principles that I’m trying to stick to before, before advising specific indicators to which to lean to, right? So, to me, the number one thing is that, you know, as I was saying, these numbers are just indicators. So, it shouldn’t be tied to some sort of any performance reviews or efficiency of the teams and these sort of things, because it’s dangerous. The people will game it anyway, right? If you put it like this, right? So, it shouldn’t be tied to any bonuses or compensation metrics or whatever, that’s a way to help basically.
The second thing that, and I’m pretty radical here, is that I don’t want to see the data being used for the purpose of measuring the efficiency of an individual as a developer, right? So, you know to me, the lowest granularity that I’m looking at is the team itself, right? You know, since the moment you are starting to look into individuals, it’s a dangerous game. Of course, we might be having some underperformer in the team. That usually, that’s what I’m hearing as an excuse why to have it. But in that case, I would rather see the team to deal with that situation on their own, as opposed to teaching them to wait until a manager comes and makes the resolution. So, to me the notion of, you know, self-healing teams is something that is really important. Of course, I might be having a look into specific data about some individual, but I would still be very strict in making sure that it is the team itself that makes that ultimate decision, without using the data, right? Because to be honest, people already in the team know who’s sort of performing, not performing very well and so on and so forth, right? So, that’s the second thing.
So, again, looking at the efficiency or productivity metrics from the perspective of the whole department, the divisions, tribes, chapters, however we call it, up to specific teams, that’s absolutely fine. But, I would be strictly against using it for individuals, on the individual-level, right? The one thing that I learned is that we shouldn’t be diving too deep into, you know, how the sprints work, what’s on the plate, what’s the velocity of the teams, and so on and so forth, because usually it’s, you know, either it’s counter- intuitive, but it’s not as important as, for example, how big of a focus the teams can have and handle, or how much of importance the initiatives that we are throwing to the teams are, right? So, basically it’s more about making sure that the discovery process works right, first and foremost, and only then we can have a look into, you know, the efficiency of the teams. So usually the story is like, you know, a company’s inviting me to do some internal audit, and saying openly, “My teams are not working very well. I don’t have trust in my teams. Please have a look.” Usually, you know, doing the deep dive in the teams, the teams themselves, usually they work pretty well. And of course, we can fine-tune some of the things and increase their efficiency by, I would say 10-15%, right? Might be to 30%, which is quite ambitious already. But, the gem lies somewhere else. And it’s about the discovery, what we are throwing into the teams, what’s on their plate.
And the second thing which I learned is to create synergies. Being more specific, it’s more about synergies between the, for example, an Engineering Manager of a team and their Product Manager. If you create a synergy and the fit and the chemistry between the two, then all of a sudden, your productivity might get increased by 300%. So, that’s yet another message, not looking too much into the data and creating the synergy between and the chemistry. That’s what’s really, like boosting the efficiency like hell. Yeah.
So, being more specific, usually what I would advise is first and foremost, making sure that we are working on the right things, meaning, seeing what’s the, for example, the adoption rate. That’s how I call it. That being said, I want to see that most of the releases and the features that we offer are well-accepted by the final customer, right? So, what’s their satisfaction? And I want to see that, for example, we are working that I would say about 65% adoption rate. That being said, of course, we can’t ask for a 100% because that means we don’t allow any mistakes and no psychological safety. And basically we end up copying the work of the competitors, which is a nightmare to do, right?
Kovid Batra: Right.
Marian Kamenistak: So, that is one thing. The second thing is, I want to make sure that my teams are working or have enough capacity to work on the things that matter the most, meaning the roadmap. So, I call it a ‘roadmap contribution’. If we have, for example, product engineering teams working on the product, then I expect to have this number around 60-80%, right? That being said, most of the time I want to see my teams working on the product roadmap, right? We might have some technical roadmap, or usually people are forgetting about the off-roadmap items, which is business as usual. And usually you would be surprised if you start measuring the roadmap contribution, you might find out that some of your teams are spending 55% off-roadmap, right? Which is sort of alarming, right? So, you know where your focus should be. And that’s already a pretty good indicator to start with, right?
Kovid Batra: Right.
Marian Kamenistak: So, the ‘roadmap contribution’ is number one thing. The second thing is, usually what I see is that if you’re on sprints, then we want to fix, for example, the trust towards the teams. That being said, you know, if you’re on sprints, as I was saying, I want to see that we deliver at least 80%, of the sprint, as I was saying before. That’d be, you know, with the number of the tickets in the sprint itself, right? So that’s basically, you know, the amount of the planned tickets vs the amount of the tickets being delivered in the very same sprint with no, move over to the next sprint and again and again, the carryovers, right? So, that’s yet another thing. And, basically this way, the teams are getting trust, and build the trust on their own. And, moving this number from, let’s say 50% to 80% is already a big achievement, right? Again, we don’t want to have a 100% because it’s estimates, it’s not like some sort of commitments, right?
The other thing that I might be saying is sort of exceptional that I’m measuring is, I call it ‘Epic Cycle Time’. So, what I mean here is that usually, you know, Jira and all the tools, they are great at measuring the cycle time on the level of the tasks and these sort of minor things, which are not really important. I want to see that, the epics, the, the milestones and the increments as they are being deployed to the product are deployed on a regular basis, and the deployment frequency is roughly around a month. In my definition or in my view, in my book, the definition of the epic is that the epic should deliver a tangible value to the customer, right? So, it shouldn’t be some sort of some simple user story. It should be something really tangible as an increment. And, I really want to see the teams sticking to deliver on average one epic per month, right? So, we are talking basically about the art of vertical slicing here, to be honest, right? And the reason why it’s important is that usually you don’t want to see the teams that go dark for 3-4 months, then they move to, you know, they go back from, from the dark ages, after a couple of months and they want, they want to, you know, get celebrated because they achieved something very big, but the product manager says it was not what they meant. The stakeholder is sort of angry at seeing, what they produced. Then, there’s a bunch of, uh, endless bunch of bugs for another 3 weeks. We all experienced, you know, this situation and that’s something we want to avoid. We don’t speak about anything unique here. It’s nothing more than the feedback loop and the frequency or, you know, the… the rapidity of the feedback loop. So, we are in the principle of agility. Agility is nothing more than, you know, the speed of the feedback loop, basically. You can forget these hundreds of thousands of books about agility. It’s nothing more than that, right? And this allows the teams to steer and to adjust, you know, stick back to the roadmap basically, right?
So, you know, and of course, we can speak about the DORA metrics, the deployment frequency, change failure rate, and so on and so forth, the usual or the SPACE metrics, that’s already fine. I know I’m speaking for too long. Nevertheless, there is one tiny metric or indicator that I want to add here.
Kovid Batra: Sure.
Marian Kamenistak: And, I was really surprised how greatly it helps. And that’s the, you know, satisfaction, or employee NPS score. Basically, where you are looking at the productivity and, you know, there’s quite a lot of tools that offer you this sort of functionality, where you can measure, you know, what’s the satisfaction of the teams, what’s their cooperation, what’s the mood, what’s the wellness score, what’s the relationship score, relationship when it comes to their peers, to their team or to their manager. And the reason why I’m talking about it is that I was literally surprised how much it has helped me to save some of the teams, as opposed to see the teams rotting and not handling certain situations well.
If I may put a specific story here, is that I might see that in one specific team or specific department, the communication goes down quite rapidly or the relationship score goes down quite rapidly. So, that gives me a hint that, you know, I’m coming to an Engineering Manager and ask him, you know, “If you run the next 1-on-1s, then please ask your teams about this specific thing, and come back to me with, what’s going on.” And most of the time people say how things are, if the culture is good enough and with no intrigues and they are open to share their views. So, you already have certain hints what’s happening in the team and what your action might be, as opposed to not knowing anything about it, people being silent, your team being disassembled while not being aware of that, and you end up by in a situation that you cannot basically save the team, if you know what I mean?
Kovid Batra: Yeah.
Marian Kamenistak: And you need to rebuild, which ends up, you know, running yet another investment for half a year for usually rebuilding that team, right? A couple of months. And you can, when we speak about the budget, we all know that the biggest cost in software companies are developers, right? So, speaking of the cost, that’s a that’s a huge impact here. So basically what I was going to say or point to is that again, that’s the principle of ‘prevention’ here that helps me quite significantly to make sure that we are still on the same spot and, keeping the tendency high when it comes to the performance of the teams.
Yeah, so hopefully that was a pretty deep list of what we can talk about.
Kovid Batra: No, I think that that is much needed. I mean, I can’t say even for a single point that you mentioned that I, I differ in the opinion. In fact, I’m more now concerned and I want to go back to the same question that it seems so important, it looks very important to follow these things, be it your investment distribution, be it tracking your Epic Cycle Time, which was a very interesting piece by the way. Like, people track the PR cycle time or small things. Tracking the time to delivery of the value is something that one should track. Of course, you can break it and then track individual pieces to optimize different pieces. But yeah, it is very important to track that. So, each and every point seems so interesting and so important for an Engineering Leader, or an Engineering Manager, like imbibe in the team from the very beginning itself. I still find that adoption of such things is very hard right now. Like, people struggle to adopt these things. Any, any piece of advice on that? Because right now, when you are talking to teams, you would have also felt that. What exactly do you think you do that people start looking at it as an important thing to do, as a responsibility, or as one important thing one in engineering leadership should be doing?
Marian Kamenistak: Yeah, that’s a really good topic to uncover cause if we don’t run the adoption of these, you know, engineering efficiency metrics, right? Then, then, you know, we are not in a, in a pretty situation. Usually what I’m saying, what I’m advising, you know, the companies, how to adopt these sort of things is that, you know, the numbers is just a third of the story.
Kovid Batra: Yeah.
Marian Kamenistak: Two-thirds are how we treat these numbers and to create the ecosystem around these numbers, right? If you just, you know, throw the reports on the teams and the numbers, it doesn’t provide much of a value, right? So speaking of the adoption here, Kovid, is you know, again, we can start from the way how, you know, to motivate people and, explaining them the reasoning behind it, right? So, what’s our motivation? Why we want to introduce this sort of efficiency indicators and so on and so forth. And basically to articulate and over communicate the message, what’s the reason why? That being said, you know, I’m always, I’m constantly talking about the principle, we don’t want to, you know look at you as a number. That is one number one thing, and the, and the number one worry we have.
Kovid Batra: Yeah.
Marian Kamenistak: And the principles are we want to be transparent and we want to be preventive, right? So, these are the two utmost principles that I’m looking for, and I’m telling them and explaining that to the teams and to people via using stories. What happened to me when I had no luxury of looking into specific data, right?
Kovid Batra: Right.
Marian Kamenistak: So, that is number one thing. The second thing is that, of course, these things shouldn’t be just run top-down. It should be run, from the very beginning with some sort of a tighter team around and making sure that you choose the right people and you invite them to run these conversations bottom-up, right? So, you can start with specific Engineering Managers, Engineering Directors, Tribe Leaders, Chapter Leaders, whatever you have. And there are people who are actually interested in being better leaders and they are usually the people who raise their hands up and sign up for that, right? So, having these people on board from early-on stage, that’s really vital because if you just throw it to them top-down, it doesn’t help very well, right? So, these are the two, I would say most important things and of course, there has to be some, I would say, activation and adoption period. The activation is, you know, how you start running it. And the second thing, the adoption itself is, it’s not just about, you know, “Here are the reports, and uh, please deal with it.” It’s mostly about, “Let’s run some sort of a continuous workshop about what these numbers mean, what are the situations where they can help you actually identify certain, you know, inefficiency, potential factors, right?
And, also giving them, the ability to provide some sort of a feedback. And say, for example, “This specific indicator doesn’t make sense.” or, “We don’t measure it well.” Because, for example, being very specific, the deployment frequency might be measured in, you know, different ways, or the cycle time might be defined in a different way depending on what stages in the cycle we are considering or not.
So, these are all the different things that we might be able to consider, you know. A good example of that is, again, talking about the cycle time, I wouldn’t punish the teams in the B2B sector, for example, of course, because their cycle time might be too long and up to the deployment. So, there is always a question whether, you know, to include the deployment phase into the cycle time or not, because if you are deploying just to, you know, in the B2B world, once per half a year, then obviously, you know, this sort of metric doesn’t make sense for you, right? So that’s, that’s one, just one of the examples, right?
And, talking about the adoption itself, I would say the most important thing that I found out also was to make sure that you provide some guidelines in a written way into your knowledge base about what specific numbersmean, why we are measuring those, including some How-to guidelines, meaning like, “What are the thresholds?” And if you are in red numbers, what might be the right things to start in to look at, you know. Your focus might be totally broken or you are running too many initiatives in parallel at the same time, or you are having too many ad-hocs, you know, disturbing your sprint. So, let’s start measuring these, or you know, these sort of How-to manuals. They’re really great because from that moment on people can point their finger on to what’s the definition of that measure, without again, trying to be smart and, every person has a different, you know, explanation of how these things are measured.
So again, having specific formulas, the motivation, what’s next or what’s right for us and some sort of How-to manuals, that’s really helpful, right? And the last thing to say, part of these manuals or these guidelines, there should be some sort of the, as I was saying, the ecosystem around. That being said, for example, I want to make sure that an Engineering Manager as a first-level manager-person is responsible for these specific metrics and should be looking on these metrics, let’s say on bi-weekly basis. The Director or the VP-person should be looking on another metrics on department-level, I would say once per month or something similar to that. And, making these sort of measures part of your daily routine, that’s really important. And, ensuring that we are talking about these numbers on our dailies, on our 1-on-1s, just checking whether the health check is fine or not. And eventually trying to, basically distill some situation and you know, moving the teams back on track when some of the indicators might be not showing the best performance ever in the team. Right.
So, these are just a couple of things that, I’m really paying attention to when it comes to the adoption itself and, as opposed just to throwing the numbers on the teams and, “Please deal with that”, it never works. It never works. Yeah.
Kovid Batra: Yeah.
Marian Kamenistak: So I hope that makes sense.
Kovid Batra: Perfect! I think I couldn’t have asked for more. One of the most interesting sessions for me personally. To learn from you and see how things being done. Ggreat, man! I think I would love to have you one more time on the show talking about specific use cases where we can spread more knowledge around these topics to our audience. I think that would be really interesting.
Marian Kamenistak: Yeah, yeah. Thank you. Thank you, Kovid. And, it was a pleasure to have you. So, enjoy. Bye!
In the latest episode of ‘Beyond the Code’, Host Kovid Batra engages in a thought-provoking discussion with Eric Bowman, Chief Technology Officer at TomTom. He is also an advisory Board Member at reputed companies such as Banxware, momox GmbH, and Tradler. The heart of their conversation revolves around leading the way as a CTO.
The podcast begins with a fun fireside chat with Eric, allowing the audience to see his candid side. Later in the main section, he delves into the obstacles faced in his engineering journey and shares strategies for overcoming them. Eric also delves into the 'Team Topologies' approach, a valuable framework for improving team interactions.
Lastly, Eric sheds light on crucial aspects such as developer productivity, well-being, and the holistic optimization of software delivery.
Kovid Batra: Hi everyone! This is Kovid, back with another episode of ‘Beyond the Code’ by Typo. And today, we have an amazing guest. He has 25 years of experience in engineering. He started as a software engineer, moved to a CTO. Right now, he’s serving as a CTO for TomTom, which is providing geolocation services to big companies like Google, Uber, everyone. The journey has been long and exciting, and today, we are honored to have you here. Welcome to the show, Eric.
Eric Bowman: Thank you, Kovid! It’s great to be here. Thanks for having me.
Kovid Batra: Great, great. So, Eric, on the show, whosoever comes, there is a quick fireside chat that we have here to know you more personally, okay? Nothing related to work, but to know you more personally. So, there will be 3-4 questions. Are you ready for that?
Eric Bowman: Yeah!
Kovid Batra: Great, Eric. So I’ll start with my first question. So, that’s related to book reading. Which one is the last book you read and how do you like it?
Eric Bowman: Yeah, that’s a great question! I do, uh, I read a lot actually. The last book I read is called ‘Right Kind of Wrong’ by Amy Edmondson who teaches Leadership at Harvard. She’s quite famous for pushing the ideas around psychological safety. And, ‘Right Kind of Wrong’ is really about how to fail in a productive way. And so, you know, obviously there are certain kinds of failures that are not good, but also, it’s well understood that you have to try things and see them fail and learn from the failure in order to keep making progress. And, it’s actually a superb book. She’s an amazing thinker and writer, and I very much enjoyed that. I don’t read a lot of fiction. I kind of go in and out of reading fiction, but I recently read a book called ‘Afterlives’, by a guy named Gurnah. He won the Nobel Prize in literature in 2021. And, it’s a wonderful book and actually, you know, it reminded me that it’s important to also read enough fiction. Fiction really helps you build empathy for people. And, those are the kind of the two most recent things I’ve read.
Kovid Batra: I think that’s perfect. And from both the books, what I feel, your motivation seems to be more being empathetic and compassionate towards people. Like, that’s what you’re learning from the psychological safety that you need to build an organization. And from fiction also, you highlighted, like, to build more empathy. I think that’s really great. Thanks for both of the suggestions.
Let’s move on to the next question. So, talking about failures and then rising from there, doing good failures, where do you get this motivation? Like, it’s been 25 years into this career and I see that energy, you’re still reading books like those. So, like, from where do you get the motivation to go off to work every day?
Eric Bowman: Yeah. yeah, so motivation is an interesting topic and motivation is often compared to discipline. And some people will say that, you know, “Motivation comes and goes, and so you really need the discipline.” And other people will say, “Discipline is hard to maintain, and so you really need the motivation.” And I find myself going back and forth a little bit between the two. I think, you know, having a certain amount of discipline is absolutely essential, both personally and also professionally, but discipline is not enough. Finding the motivation is where the real drive comes from. And, you know, I think for me… and also for the people that I try to look for to work with, an underlying curiosity is one of the key things that really drives the motivation side. So, curious to understand, you know, “What are like, what are our customers problems really?” And you know, sometimes they tell you one thing and you have to dig through and find out that it’s something else. But being like naturally curious about technology problems, about people problems and organizational challenges. For me, I think that’s a big part of where that motivation comes from. And then ultimately, as I transitioned from being a software engineer into an engineering manager, really, and also getting more involved in the product side, you know, I’m seeing both myself and the team confront challenge, and the struggle of that, and then overcoming that. And, you know, especially as a group, like the idea of having shared goals and supporting each other. I get a lot of, I get more motivation from that than when I was younger, I thought that I would. Like it is, you know, it’s not necessarily about having it’s not fun every day. But, it can be meaningful every day. And that “finding the meaningful” part really comes from having innate curiosity, and then the discipline to really execute and just consistently make progress, constant progress.
Kovid Batra: Totally makes sense. You’ve already started inspiring me already.
Great! Moving to the next question. So, this is related to, like unwinding.
Eric Bowman: Yeah.
Kovid Batra: I hope you like music? I think everyone…
Eric Bowman: Love music!
Kovid Batra: So, which one’s your favorite band? What type of music you like? Something around that.
Eric Bowman: Yeah, that’s a tough one. I listen to a lot of different music. And when I was younger, I was kind of a superfan of certain bands. I listen to a range. I actually love jazz. I love kind of 50s and 60s bebop and I actually like some 70s kind of fusion jazz. I actually listen to quite a bit of classical as well. My wife is Irish and I’ve really gained an appreciation for 80s and 90s kind of Irish and British pop. I go in and out with a band called the ‘Grateful Dead’, which started in the 1960s. Actually, I love reggae. I love dubstep as well. You know, some music is useful for unwinding and some music is useful for focus. And I have a, yeah, quite a deep relationship with music.
Kovid Batra: Perfect. Perfect. That was really nice. And it was good to know you!
Moving on to the main section now. I think the audience is really, really looking forward to this. And, ‘how to lead as a CTO’ is something we are here to learn from you. So, I’ll ask a few questions. And to start with, like I want to start with something that is really, really interesting, which would be closer to you.
Any of the experience where you faced a real challenge in your engineering career? And, how did that challenge come up? How you tackled it? How did you overcome it? Just an open thought, open discussion around that. So, yeah, I think we’ll start with that first.
Eric Bowman: Sure! Yeah, there’ve been a few. If I reflect on kind of recent experience, I think one of the big challenges that I faced over the last couple of years is really around, in an environment where there are significant customer commitments and momentum against kind of a legacy technology solution, and a clear commercial desire to kind of shift into a more product-led approach in an environment where the customers are not necessarily open to that has been quite a remarkable challenge that I’ve faced recently. And it really was kind of a holistic change problem that also very much depended on external forces. What that kind of looks like is, you know, in an environment where you end up making multiple parallel customer commitments, there is a need for quite intense planning and execution. And, there’s not appetite on the customer side for much uncertainty.
But on the other hand, you know, and kind of going back to the work of Amy Edmondson and modern product management, you need a way to be able to perform experiments, to have hypotheses, to try things, to ship value and then understand at least your, what you think is value and then understand you. Your customers really like that. And, for me, it was, it’s been a remarkably satisfying and challenging exercise to figure out how to navigate that with a fairly large team, several 100 engineers, a large legacy code base and quite a modern view of what we would like the software to be and what it has to be for, in some cases for commitments that were made some years before. And, you know, one of the nice things is that a lot of the basic ideas of, say modern product management really work, you know, but it does require both the discipline and the motivation to make them happen. And, I think one of the things that’s been most satisfying for me is seeing how very high-functioning, high-performing team when they kind of understand the goal and there’s a shared North Star, and a kind of a clear vision that we’re working toward, how much that can bring out the creativity of that team to find real solutions to some of the very pragmatic problems that we faced.
And, you know, I have one moment in particular where an engineer kind of found a way to thread a certain needle where we could satisfy a customer, and make a significant pivot to a much more modern product that would be much more appropriate for multiple markets. When I was a software engineer, I loved having those moments. I liked to be that person. But, actually creating the environment where others could do that, and seeing them do that, very, very satisfying. And I’m really looking forward to this product coming out later this year.
Kovid Batra: I think I would want to know more on this. Like, broadly you told us, like there are multiple challenges and you have to do it, and then you get satisfied. Getting the team onboarded on the shared goals and getting them to deliver, being creative, everything. But, can you share one incident, one particular piece, so that our audience actually relates to what they are also doing in their organizations, maybe?
Eric Bowman: Yeah, let’s see. Well, yeah, maybe we can look at some more approachable examples. It’s a bit of a large-scale example. I think one of the challenges that I also faced not too long ago was coming into a situation where a bunch of online services were really not set up for high availability.
Kovid Batra: Okay.
Eric Bowman: And again, there was a fair amount of legacy involved, but there was a missing mindset around, I think you would call it ‘learning through failure’. And you know, the change that I introduced there was to say, “Hey, you know, there’s it has to be absolutely clear that the highest priority for everyone, if there is a some kind of customer incident, has to be not only obviously restoring service as quickly as possible, but also going through the work after that to really understand, “How did this happen?”, “What do we need to change to avoid this happening again?”, and then, doing that work. And, you know, with a fairly large team, that’s kind of a big change effort. But, what I found is that there were certain people throughout the organization who were really open to that, and they could immediately understand the importance of it. Not everyone at the same moment, but enough that we were able to get kind of a critical mass of people supporting and carrying this idea forward, and the change in mindset, because you know, like people are pretty rational in certain ways at the end of the day, but they also have a lot of constraints in their whole life, not just at work. You know, people have things happening at home and personal life, and they’re balancing their energy between these and, and it is a balancing act. And very often, especially if things are if there’s pressure at work, you know, people just want to go faster, get through it. But that’s not how people do their best work. So, really helping people understand the importance of ‘it’s not just about what we are doing today, we have to always be working toward the future’, and that means constantly working to understand, “How will this system behave?” “What don’t we know?” And, “What do we need to know?” And then really creating the incentives and the framework to say, “Hey, when something goes wrong, we really do need to know. And, sometimes you don’t know how long that’s going to take. And it may take a while, but we’re kind of in this for the long haul, and we have to make this investment now.” For me, kind of seeing the difference between that really were sort of two kinds of engineers in that case – some people who totally got it, welcomed it, loved the critical thinking and the clear exposition, and others who really felt that like, “Ah, you know, It’s all okay. It’ll be fine.” You know? And finding that first group and then really kind of empowering them and helping them.
Kovid Batra: Yeah.
Eric Bowman: And you know, I think…
Kovid Batra: Putting them as a benchmark maybe…
Eric Bowman: Yeah, exactly!
Kovid Batra: ..for the other people to look at, yeah?
Eric Bowman: And, sort of changing the mindset of people to understand that actually, you know, making the system more resilient, making sure that governance is covered and making sure that, you know, our ways of working, that how the software is built and deployed and monitored, and how’s the feedback, all of that. That’s actually very often what the most senior people should be working on.
Kovid Batra: Yeah.
Eric Bowman: Particularly, if that’s not under control in the sense that, you know, there’s always some variation, but it needs to be kind of bounded. If it’s not understood what those bounds are, and it’s not well-automated, well-understood, that has to be the priority. Otherwise, you cannot create value on top of it. And so, I think my advice, you know, for more junior software engineers is, always make sure that you understand that that is a huge part of the job. It’s not only about, ‘Oh, I’m working on kind of business logic or just trying to work through features or always trying to build things.’ The deeper problem of understanding the system and improving the system for the benefit of everyone is one of the most high-value things that a software engineer can do, and not all performance models, say, recognize that sufficiently.
Kovid Batra: Makes sense. Makes sense. I think putting the right incentives and the framework, and of course, hiring also helps. But yeah, that’s a great piece of advice, and thanks for sharing your thoughts, Eric.
Eric Bowman: My pleasure.
Kovid Batra: I think while we’re touching the topic of solving these problems at scale, I think ‘Team Topology’ is another topic which I’m really interested to hear from you.
Eric Bowman: Yeah!
Kovid Batra: Like, how do they play an important role in achieving your goals, right?
Eric Bowman: Yeah.
Kovid Batra: So, please share some examples.
Eric Bowman: Yeah, so, you know, ‘Team Topologies’ is a book that came out a couple of years ago and it’s really an excellent piece of work. And, very applicable, and you know, there’s a thing called ‘Conway’s Law’, which has been around for probably around 50 years, which is sort of the observation that organizations that build software, very often the architecture of that software models the communication networks within companies. And you know, when people say, “You end up building the org structure”, that’s kind of what they mean. And it is a real consequence of the system dynamics of development. And it reminds me a little bit, like there’s a thing in physics where if you go into a clock shop and there’s a bunch of clocks on the wall, it turns out all the pendula are perfectly synchronized, and you know, it’s a surprising thing to witness, and that happens through very subtle interactions in the way energy moves through the wall. Like, it is achieving a low energy state and you can mess them all up, and over the course of a couple of days, they will return to perfect synchronization.
Kovid Batra: Synchronization, yes.
Eric Bowman: And Conway’s law is a little bit the same, that even though, I mean, you can fight it for a while, but ultimately those system dynamics will win. And ‘Team Topologies’ is kind of a set of heuristics that leverages Conway’s law, as well as, you know, kind of what has been shown to work, that gives an organizational designer a set of design patterns to apply. And, it’s not necessarily a universal toolkit, but for the kind of companies that many of the people probably listening, it very likely does make some sense. And, it is essentially taking advantage. This is my view of it. The authors might disagree a little bit, but you know, taking advantage of Conway’s law and the importance in the modern age and what is enabled through technology to deliver value to customers sooner. And, it gives you kind of a toolkit for how to set up organizations that can do that. And, we applied that quite successfully, I think at TomTom, where we had kind of two large organizations, one working on SDK & services and one working on map. And, they were somewhat separated for quite a long time as the map company was an acquisition. And, we took our first steps into creating a single org by setting up the value streams, from map data all the way through the online services, to the SDK. We have a new, significant new map product coming out very soon. And, understanding how well that map was working with our services and SDKs was incredibly important to, essentially ensuring that the product is great. And the way the business had worked in the past, that was not a natural organizational pattern that was in place. And, so we implemented that. And I think, you know, one of the key takeaways from the book, and then my experience with those ideas is that the need for collaboration is a tricky thing because it’s very common in companies I’ve worked out in the past at least, that the idea that ‘we got to collaborate’ is sort of a universal good. And, it is true that when collaboration is needed, it has to go well. But, collaboration also comes at a cost. The need to collaborate requires energy, you know, which software engineers are balancing across a number of things. And, the whole point of many organizational structures is to combine people who are working on related things, so that they can create “synergy” between them. And, if you have to collaborate to do anything, it’s hard to go fast.
And so, one of the things that I very much like about the ‘Team Topologies’ approach is that it provides some heuristics for how to identify where is collaboration between teams important and worth it, and where, you know, is it better. Maybe a team, you know, has automation and kind of, what acts as a service. So, the direct collaboration between is not necessary. So, an infrastructure team providing cloud infrastructure, for example, if they have to directly collaborate with several 100 teams in the company for those teams to take advantage of the service they’re supplying, it’s incredibly expensive. It might be sort of fun and some good things about it, but it’s not worth it. Whereas, closer to the customer, and where you really want to kind of innovate and where you are really working to solve customer problems, you want to be able to rapidly work end-to-end, there that collaboration is almost certainly worth it. But again, it is expensive. And so, you need to be deliberate about where you expect teams to work that way and where that innovation is most needed. And I think it’s quite a refreshing view prior to that work. You know we all had, I think a much more simplified and less effective view of how to organize, really to deliver value sooner with as much automation as you can, kind of maximizing innovation. So it’s a very, very nice work.
Kovid Batra: Perfect! I think that was a great summary of what we can learn from the book. I think that’s a good recommendation too.
All right. I think I have one more question in my mind. When we are talking about the advice to the software developers, to the aspiring engineering managers, engineering leaders, one important thing is bringing a data-driven, plus an empathetic mindset to the way they are trying to improve their software delivery, trying to improve their teams, right?
Eric Bowman: Yeah.
Kovid Batra: And there has been a recent article by McKinsey which is trending right now about developer productivity. So, I just wanted to know your thoughts on that. How you have implemented such KPIs and metrics, like DORA in your team? And how to actually implement it at scale? How you’re looking at developer well-being? All this combined. It’s a big, big question, but yeah, I just want to know how you have done it at your organization, and what’s your thought on developer productivity, well-being and overall optimization of software delivery, yeah.
Eric Bowman: Yeah, the McKinsey piece created quite a bit of noise and some of the responses to it are quite excellent. And so I, I don’t think I can improve too much on that, but it is a fascinating, I think symptom of very often what is the challenge between a CTO and a tech team, and the more commercial side of the business. And you know, the McKinsey article is definitely, I think the target audience is more on the CEO side. And I think the criticism of that article reflects how industry-wide it is a challenge for CTOs and CEOs to really find a good way to work together, because ultimately in a modern tech company, the technology part needs to be everywhere and CEOs need to be pretty CTO-like in many of these companies. But, the bigger, the bigger question is very interesting and something that’s, that’s occupied a lot of my professional life in different forms, you know. The DORA KPIs became kind of widely-known with the publishing of the book ‘Accelerate’, I think in 2018. And, for a lot of people who had been working more or less in that way, whether we called it DevOps or not, found some version of that that made intuitive sense. And it was like a bomb going off in a positive way to have that research published and made accessible. And, it reaffirmed some kind of beliefs with a bit of science.
For those of you who don’t know, the DORA KPIs emerged from the research of Nicole Forsgren and others. And it’s basically four KPIs around a team’s productivity, which is essentially how frequently they commit code and how long it takes that code to get into production, how long it takes to restore service in the case of an outage, and how frequently code that gets deployed has to be rolled back or rapidly rolled forward. And, you know, the research demonstrated essentially, I guess it’s fair to say, a weak form of causality or a strong, very strong form of correlation between, kind of excellent DORA KPIs and business success, business health, cultural health. And it’s a very compelling research. It’s like, if you can actually move these KPIs, there is a causal connection, it appears, between the success of your company. Now, how you move them though is left a little bit as an exercise for the reader. And, you know, for people building online services, it’s kind of easy. When you’re building software for automotive, for example, where there is no way to deliver value, it’s a significantly harder, challenge. But of course, one can invent ways around that. And now a few years later, there’s a lot of tooling to help and there’s emerging best practices. There are, you know, common patterns that tools like typo, I think help with.
So the way, you know, you can think about productivity, kind of at a company-level, at a team-level, and at an individual-level. And, DORA is sort of focused on the team-level and then, Dr. Forsgren and others have now worked with the SPACE methodology to really look at individual productivity. And then, there’s still this open question of organizational productivity. But what all of these things have to a certain degree in common is this idea that flow is pretty hard to achieve. And, you know, you’ll find me frequently saying sooner “We want to deliver value sooner, and not faster.” And there’s a few reasons for that. When people are asked to go fast, they frequently make mistakes. But also by focusing on “sooner”, that’s where we find, you know, if like one team does some work and then they hand off to another team, which DevOps, you know, tried to remove that gap, but in a larger organization, there’s always handoffs. You can’t “everything” ops. And it’s those handoffs that end up eating most of the time. And so kind of with SPACE and DevEx, you know, this idea of fast feedback and flow and reducing cognitive load. And that helps people keep moving in the very small. And that like, once you get on a, sort of an intellectual path as a developer, you want to continue, you stay engaged and that allows you to kind of go farther through the sequence of small steps. And similarly with DORA, it’s a similar case, you know. It’s all about, “What is the delay?” If you’re releasing code in sort of small increments and then very quickly going to production, when something goes wrong, you very quickly consolidate it, reducing those delays. Those delays add up over time. And there, time is the only resource which is completely irreplaceable. Once it’s gone, it’s gone. And going faster then is like about, you know, you end up shortening the work times, but the wait times stay the same. This is all about closing the wait times.
Organizationally, then, you know, above DORA, there’s still an unexplored area. Although there, I mean, there are tools and there’s thinking around this, and Lean looks a lot at this, but the tooling is not great. And, the mindset is not there very often for people to really understand, “Where are those delays happening?” And honestly, things, you know, methodologies like scrum really exacerbate the problem. The idea of a backlog introduces delay, it builds it in. And, you know, one of the reasons why, I believe we see kind of a move away from scrum is it’s just not Agile enough. Sometimes, we need to be able to interrupt a team and say, “Hey, there’s a bigger thing going on, kind of in, in the business and we have to do this.” And that’s why Kanban, I think makes more sense, that it doesn’t build in delay. It’s more flexible around delay. And also, the nature of Kanban is on a much stronger, analytical foundation, that you’re able to apply Little’s law, and really understand bigger system behavior.
So, these three things combined, I think, you know, for anybody who’s trying to improve the value creation, which is, I guess, you know, ultimately why we want people to be productive, should really be looking at the individual-level, the team-level and the organizational-level, and always focusing on, “How can we identify where those delays are happening, and where value doesn’t keep flowing?”. And of course, there’s a lot to learn from the Toyota system. And you know, there’s a lot of thinking in the world around this, but it’s still maturing in software engineering. But very interesting moment, and a lot of opportunity, I think, for good toolings.
Kovid Batra: Perfect! Eric, that was really, really amazing. I think this is one of the best podcasts I have personally ever had. I would love to discuss even more topics that I get to hear from my customers, and in day-to-day, I’m meeting so many engineering leaders. So, I would definitely want you to come back to the show sometime.
Eric Bowman: Hey! My pleasure, Kovid.
Kovid Batra: All right, Eric. That’s all for today. Thanks for your time. It was a pleasure.
Eric Bowman: Thank you.
In the recent episode of ‘Beyond the Code’, host Kovid Batra welcomes Anton Zaides, who is currently a development team lead at Taranis and has previously contributed his expertise to Mamram and Golden Zebra Software Inc. Their core discussion primarily revolves around effective strategies for leading development teams.
The podcast starts with a fun fireside chat with Anton, where the audience gets to know his unfiltered personality. Moving forward, he delves into the obstacles faced as a Dev team lead and details the strategies for overcoming them. Further, Anton shares insights into the approaches and methods for delivering high-quality commits on schedule.
Wrapping up, Anton sheds light on transitioning from an individual contributor (IC) to a team lead, a phase that proves to be a significant challenge for many individuals in the field.
Kovid Batra: Hi everyone. This is Kovid, Kovid with a K, your host at Beyond the Code by Typo. Today on this episode, we have an amazing, cool guest from Tel Aviv, Anton. He’s the development team lead at Taranis. He’s the author of newsletter ‘Leading Developers’, which is about to cross 2000 subscribers within six weeks. Amazing, Anton! And on top of that, he has 12+ years of amazing engineering experience. Let’s just hear it from the expert. Welcome to the show, Anton.
Anton Zaides: Thank you, Kovid. Glad to be here finally! Yeah.
Kovid Batra: Great! So as for the format, we have a quick fireside chat, wherein we will be asking you some questions that would help us understand more of the personal side of Anton.
So, we are going to start with that. Are you ready?
Anton Zaides: Sounds good. Yeah.
Kovid Batra: Alright, Anton. So, the first question. Let’s say, a friend visits you in Tel Aviv. Let’s say I visit you in Tel Aviv, okay? Which would be those places where you would take me to, to show around the culture, the people, and the natural beauty? What should be those places?
Anton Zaides: I think my favorite one would be the Tel Aviv beach. It’s one of the most beautiful around the world. Tel Aviv itself, it’s like, I’d say it’s the most expensive, but also the best city that exists. So, I really love it. So, it starts with the beach and see how we enjoy it, and then continue.
Kovid Batra: Alright. So, basically you are a beach person then, right?
Anton Zaides: Yeah, definitely. Yeah, I’m playing beach volleyball, I like running on the beach, swimming, all of it, yeah.
Kovid Batra: Perfect, perfect. Alright then, moving on to the next question. You have this 12 years of experience, you’re writing, leading developers. I want to understand, what’s your source of learning? Like, what exactly helps you learn the most? Is it your mentors? Books? What is the main source?
Anton Zaides: So personally, it’s 100% books. I know a lot of people love mentoring, but I really love the format where someone spends months or even years putting a lot of knowledge in one page and hundreds of pages. So, I read like, I don’t know, two or three books every week for the last decade. I know it’s not everything might be useful, but I really love it. So, definitely a bookworm.
Kovid Batra: No, I think that’s one best way to learn actually and most successful people whom I have talked to, they are fond of reading. So yeah, I think that’s a great habit. But for audience, which one would be one or two books that you would recommend, like for the engineering leaders and the engineering managers? Which books you would recommend to them?
Anton Zaides: I think the top one that really changed how I manage is ‘Radical Candor’ by Kim Scott. That was a big, big one. And, a more general one is about Netflix, the ‘No Rules Rules’, like about how they built the culture over there. So those two are, I think, my favorite ones.
Kovid Batra: Alright. Last question from the fireside chat. Can you tell us one funny production outage that you encountered?
Anton Zaides: I caused a few funny ones, I think. I just sent a newsletter before the talk about one of them. And, I wrote an SQL query, where it was “update (some) table set is_deleted = true”. And then I had a line break. And then the ‘where’ condition. And then when I ran it, the ‘where’ condition was ignored, and I basically deleted all of our orders in the database, real orders.
Kovid Batra: Oh my god!
Anton Zaides: Yeah, yeah. It was on a weekend and it took me an hour to recover. I was the most nervous I ever was. But yeah, that was it.
Kovid Batra: I think almost everyone who has been into coding has done that some time.
Anton Zaides: Yeah. Yeah, definitely. But you do it once. I never did the same mistake again. So…
Kovid Batra: These mistakes should not be repeated.
Anton Zaides: Yeah, definitely.
Kovid Batra: Alright. I think that was cool. Now, Anton, we’ll move to the main section wherein we would be learning some practical tips from you on how to lead the dev teams. That’s what the theme of our today’s episode is. So, I’ll start off with a few questions, but, I think the first thing that I want to know from you is, you have come across a lot of challenges for sure in your engineering career, right? So, I would want to know which of those one or two challenges were really, really hard for you. And how did you overcome those? If you could share some of your experience.
Anton Zaides: I think the main challenge, and it’s a bit of tough to say it, but I’m a micromanager by heart. The easiest way for me is to be very into the details, and know everyone, and ask questions every time and be very, very annoying. Like, I’m a control freak. That’s my nature. And it took me a lot of time to understand how toxic can it be and what’s the effect on other people. And I still fight with it. For example, we are working hybrid, and on the remote days, I like to know what everyone is doing. I like to send them messages and understand what everyone has problem with. So now, I’m in the stage where can I just, you know, let go for a day or two, but it’s a constant struggle, right? Because the people tell me they need the freedom and they don’t need me to be so controlling. But, it comes from the good place. Usually people, you know, bash the micromanager saying, you know, “That’s the most awful managers.” But usually, it’s because you care about the people, you want them to succeed, you want to help them. So, when it’s from a good place, it’s hard to fight yourself, you know, and just let go. But definitely, it’s something I’m improving on and I know I should. Yeah.
Kovid Batra: Yeah, I think this comes very naturally to human beings, like having control. It’s a very primal instinct of a human to have that control, right? So, even if it is coming from a good place or from a bad place, people perceive it mostly in the negative sense, like the people who are getting managed. So, it’s hard to change. Of course, when you have right intentions, you’re not able to motivate or incentivize your brain to not do it because you’re already doing it for the positive. So, yeah, it’s difficult, but how do you exactly deal with it? I think that would be really, really interesting to know, like what goes on in your mind? “Okay. In this situation, Anton, don’t call that person.” You have to stop yourself. So, what exactly do you do to recall that and be doing that when you are in the day-to-day?
Anton Zaides: I think that for me, it’s mainly about asking questions, right? Someone works from home and I think they might have a problem or need me. So, I have like this habit that before I send a slack message or before I go to someone’s place to talk to him, I think to myself, “Okay, they probably know that I’m available if they need me, right? So, is this so critical that I need to stop them from doing work?” So, I’m thinking about the negative effect of it. If they need to respond to me they might be right in the middle of coding something or thinking about it. So, when I try to think about the negative effects, it usually helps me stop, you know, bothering people. And the main thing is hearing from them. Like, that’s the main thing that changed my behavior. When people tell me, “Okay. You can trust me. I can handle it. I don’t need you to, you know, babysit me or see how it goes.” And when people tell me that, it makes me feel like more, you know, ashamed. It’s not that I don’t trust them. I want to help them. I want to make sure I’m available. So when they tell me it’s bothering them, that’s why I know, “Okay, I crossed a line. I need to take control of myself.” So that’s the two things.
Kovid Batra: I think if they’re gonna listen to this podcast, they might have a different perception about you now, because you are mentioning that you’re doing it from a positive, positive intention. So, yeah, I think that’s cool. It’s a very good advice. We should be considerate of other people, might have to context-switch or they might have to pause in between, which is very critical right now. So, putting that thought before asking a question or doing something which is related to your management, probably can take a backseat for a while if you are considerate and you’re doing that consciously. So, that makes sense. That makes a lot of sense.
Anton Zaides: I thought that saying, “How is it going?” is micromanaging, but saying, “Is there something I can help you with?” is fine, right? So, usually the messages I send, “Is there something I can help you with?” But, it’s still micromanaging, and this took me time to understand. Even if you only offer help and you’re not pressuring someone. So, that’s the kind of thought. Yeah.
Kovid Batra: Cool! Got it. Alright, moving to our next question. So, as we know, in your career you have led the software engineering team. You have also led the DevOps team. How is it different leading both the teams? Of course, altogether they help each other, definitely. But, how is it different leading both the teams?
Anton Zaides: Yeah, as you said, many differences. Different professions, right? DevOps is what was considered Ops and IT. Now, it’s a completely different profession, DevOps engineer. But I would say the biggest difference is the people you develop for. So, when your clients are developers, internal teams, they know what you’re doing, they have technical knowledge, so they give their input. They are pushy. They’re never satisfied with what you do. They think you can do better. So, if you improve performance by 50%, they want 80%. So, you know, customers don’t always know and don’t always demand things. And this one was hard for me to understand. Like, I’m doing my best. What do you want from me as a DevOps team leader? And as a software team leader, you know, you work with the PM and you manage the expectation and you are the authority. When you say something will take X time, that’s usually what it takes. So, that’s one major difference.
And the other one, I think it’s the priorities. I’m used to having a big project, let’s say 4-6 weeks or something like that, and just working on it, with minimal distractions in a regular software team. In a DevOps team, it’s like, you know, fires all over the place. You know, everything is more urgent, you have the SOC review, and then you have some new features someone needs, and then the database needs to be restored, whatever. There is like, so many distractions. And that was very difficult for me. Because I tried to do like, sprints, and you know, 2-week sprints and everything, it was not a good success. Yeah.
Kovid Batra: Just a follow-up question on that. which one do you think you like more? What aligns more with you?
Anton Zaides: I think software teams, not DevOps team for me, mainly because I like less distractions. I like the ordered work and mainly I love the communication with our customers, right? I feel like as a DevOps team, one of the toughest part is you don’t directly affect the business. You might not even know what the business is about, you’re focusing on the development process. And, I love to know like everything, from what the customers are using, how the sales are going, helping the sales people. So, that’s the major difference that I now, feel that’s the main reason.
Kovid Batra: Perfect. Thanks for being so honest. Alright, moving on to the next question. Setting expectations, and then delivering on them with the product teams & the business, is something that every engineering manager or a lead developer or a team lead wants to do, right? We have had a chat around it. So, I really wanted to know, like, what approaches or methods do you take to actually build things in time, fulfill the commitments? Because that’s the expectation of the business side of the product side and me coming from that background, I feel that is what usually we have to fight over and discuss in the team. So, I really want the audience to know what approach or method they could take to actually deliver on time.
Anton Zaides: Yeah, that’s, that’s your toughest question, I think, and would require the longest answer. It is something that I’m heavily focused on and I can say it’s improved a lot in the last two years.
My first mistake is committing to something I was not comfortable with. So, saying, okay, I was pressured to commit. “You need to release this project in three months.” And, even before the scope was clear, I said, “Okay, I will, I will do it.” without completely understanding the picture, right? Asking the questions, going down to the details. So, if you start developing when you’re not comfortable with the time, you already start on the left foot, right? You need to be comfortable and give pushback to your stakeholders. So, if they say, “Commit to this in three months.” you need to understand exactly what you’re committing to. Ask why shouldn’t we do something simpler in one month. Right? Why should we do such a long project? Because you know it probably. The longer the project, the less likely you’ll finish on time, right? A three-year project never will finish on time, and five year will never finish. That’s how it works. So, the smaller the project, the more chance it will finish. So, that’s the first thing that I had to overcome because as a young team leader, it’s very hard to give pushback to your manager or the PM (the Product Manager). They say something, they have experience and you trust them to estimate it correctly, but you will be the one held responsible for delivering on time. So, you have to be comfortable with that.
Kovid Batra: Yeah, I think that’s a very good point. Anything that you usually practice, or you use as a tool to actually overlook what’s going on? So, as a team lead or as a manager of a team, how do you ensure things are moving on time? Let’s say, you have signed up for a sprint and during this sprint, five, six days have passed and you want to keep a check on what’s going on in the team. So, how do you usually do that? And how do you proactively take measures to actually reduce the bottlenecks, and making things smoother and move faster? So, how do you do that?
Anton Zaides: Yeah, that’s something I actually haven’t solved yet. So, have a clear understanding of what are the pain points, who is stuck where. So currently, because the team is pretty small, right? Five developers, four now, we had some re-org, so it’s basically based on dailies, and talking to people. So, there is no, like, understanding. I tried to use the burndown chart, you know, that says ‘how many things you completed’, but it’s a bit of a lie because you almost always complete everything in the last 2-3 days of the sprint. So, even if you feel pressured, it’s not necessarily a bad thing. So…
Kovid Batra: It makes sense, but I think, here, a few tools could be a real good help. Just a suggestion from my end. Like, you can have certain tools which give you a clearer picture on things that are happening on day-to-day basis in your sprints as well. I think there would be, something that you would want to improve on here where you have a clarity on what’s going on on day-to-day basis to proactively take measures.
Anton Zaides: Yeah, I definitely agree. I think there is a need for it. But it’s more of the change, the habits of people, right? You need to educate people about the need, and I think that’s what you and Typo are doing with the podcast and with the tech itself, to share the need and I agree, I feel the pain.
I have many more, like, thoughts on how to deliver on the expectations. I think we covered the first one, right? Never being comfortable with what will you commit to. And, we touched a bit on the second one, never commit to tremendous, long, long projects. Even six months is long. And even three months is too long. I recently read a book about ‘Basecamp’. I don’t know if you hear about it. Those guys are amazing. So, different perspective, they do a bootstrap without VC and they have different culture. And they say they don’t have a roadmap, they have 6-weeks projects. They don’t know what they’ll do in more than six weeks. That’s how the whole company runs. There is no 1-year plan, no quarterly plan. 6-weeks projects. And I think that’s actually a good recommendation. Not having your roadmap, right? You cannot control that as a development team lead, it comes from the management. But, having projects no longer than six weeks and making sure you release something, right? Because even the most complex projects, you can have an MVP in six weeks and get feedback and it’s, it’s obvious, right? Everyone talks about lean startup and everyone knows it, but it’s very hard to do because you want to deliver something beautiful, right? You want to deliver something super useful from the day one and you don’t want to deliver like small part. So, that’s a fight I’m constantly having with myself saying, “Okay, it’s fine to deliver a small piece in two weeks, in four weeks.” And that’s the obvious one.
And the last one, I think, which was the biggest learning for me is, you know, the triangle of time, cost and quality, right? if you commit to the same scope for the same time, something will suffer, right? So, the things that we are currently optimizing for is the scope, right? So, you deliver the same time, you deliver high quality, but you can change the scope after it starts. You can remove things that you think are not necessary. You can play with it, because if you fix the scope and the time, it will be lower quality. And I felt it. You can release on time, but the code will not be reviewed, right? Because you don’t have time. No QA. You don’t have time. Lots of bugs. You do not have time. So, if you want high-quality code on time, you have to be very, very flexible about the scope. Yeah. And that’s something that our organization improved on. I feel the improvement and I think it’s a great way to work when everyone is aligned that the scope can change. That’s a good way. Yeah.
Kovid Batra: Yeah. I think what I get, an essence from the two points that you have mentioned about how to deliver on time. One is, of course, being comfortable and confident in what you want to do and what you can commit to. That is one very, very fundamental thing which one should have. And the second point is breaking down into small projects and then being flexible with the scope, would really help. But, at the same time, I also feel that there are times when you have to stretch, when you are in a startup mode, when there are things to be delivered, and there is less time for planning, actually. That’s where the problem comes in, right? If you will have the time for planning, then you will be able to estimate it better. But, when you don’t have time for planning, what exactly works for you? Is it like, just keep the scope flexible? On the run we will decide what is something that we see getting completed or we don’t see, is that how it works?
Anton Zaides: Yes. I think the main benefit and it’s still hard, but especially if you don’t plan to release as fast as possible as you can, under a feature flag, easily reversible, but to get a real feedback from your customer as soon as you can. So, let’s say, there is an idea. We had a good example of it, of something that our U.S. team, our customers in the U.S. We are an agritech startup flying drones over field and our whole team is in the U.S. like sales and customer success. And, they flew here and we had a meeting, you know, with a whiteboard and they had an idea to do, but there was no time to plan. We are an agricultural startup and now is the money time, right? People are in the fields harvesting. So, there is not much time to plan. And we had some idea and we just went with it. And after a single sprint, up 2-3 weeks, we did something that was not perfect. It was different than what they thought, but it let us have a conversation, right? I remember a lot of creators saying that code wins arguments, right? That you can do something. So, that’s my solution for when you can’t really plan and it’s not perfect. Definitely in this case, you don’t commit to anything because you don’t know what you do. You’re saying, “Okay, I work as fast as I can and we’ll see what happens.” And sometimes in startups, as you say, that’s the way to go. You don’t even need to plan. You just need to move as fast as you can.
Kovid Batra: Makes sense. I really like your thought process on this. Is there more that you want to talk about? Anything else you want to add to the already-defined approaches that you’re taking?
Anton Zaides: No, I think to summarize it, like as a team leader, it takes, and it leads us to the next question. it takes a lot of time to have the, I would say the strong base to say no, to give your own estimates, to have pushback to the other people. So, as you learn it, it gets easier. That’s what I want to say to new team leaders that it’s hard. It will be hard, but it gets easier to both estimate and push on what you believe.
Kovid Batra: Perfect. Perfect, Anton. I think that’s a great piece of advice. I hope this helps a lot of our audience, the aspiring leaders, aspiring managers. I think we already touched this topic and that is, what exactly is this experience of transitioning from an IC to a team lead role? I feel it requires a lot of change in your behavior. And some people are natural leaders, so they easily move into that, but there are sometimes biases, there are sometimes already built habits that actually, are not healthy when you are leading a team. So, you have to change that. So, that phase really is difficult for a lot of people. What’s your experience, what’s your thought on that, and anything that you would like to share?
Anton Zaides: Yeah. With every team leader I talked to, this transition was hard. There was no single one, even the most, you know, leadership-prone ones, like the best leaders. It was hard for everyone. I think this is the toughest transition in tech. If you go like higher, everything is tough. But this one, from being an individual contributor to manager is crazy. And mainly because you’re doing so many things, it’s like you knew how to juggle 3 balls and now you need to juggle 27, right? It’s like, “Okay, how can I do that?” And that’s really, really overwhelming. And the biggest part, I think, is as we talked about micromanaging and the downside. It’s really trusting your team. And, the one thing that is hard is requesting help from them. So especially, when you start, you want to reject an image of a strong leader that knows what they’re doing, you know, lead the team to a new place, especially if it’s your own team. If you’re promoted in your own team, suddenly you try to behave in a different way to be the manager, right? And it’s not your teammates anymore. And this is what makes the job hard when you don’t depend on your people. You try to do everything on your own. You don’t trust and also try to code a lot. So, the combination of you feeling everything is on you, is really hard. And the one thing that helped me to start delegating is really ask for help saying, “Okay this project I know I will not be able to do it the best I can.” Talk to a developer and say, “What do you think we should do here? How would you tackle that? Do you think you can lead this?” So, it comes from a place, not delegating like, “Okay, you do this, and you do this.” Right? You decide with your team, play on the strengths of each person. That was the main game-changer for me.
Kovid Batra: That comes from a very core feeling of, again, humans. Like, when you see someone sitting on top of you, who has been an equal, let’s say previously, you definitely would have that insecurity developed. You would already be defensive towards a lot of things and not accepting a lot of things. So, in that situation for a person who is moving into that role, I think the best thing one could do is have a clear mind of treating everyone equally, because if you’re doing everything with that intention, as you just mentioned, would really, really help. Like, be inclusive, take the team along, make decisions with them. Just don’t put work onto them, or simply delegating things, it should be more of a discussion. So, yes, I think that’s where you have to actually think through and be very particular and conscious of your actions and words that you take when you are in a meeting or when you’re discussing it with the team. So it makes a lot of sense, I think, Anton. Yeah.
Anton Zaides: And, also just admit it’s difficult for you and admit your problems. So, for example, when you transition, you have your first 1-on-1 with someone who was your teammate, right? And it’s always awkward. It’s like, “Okay, it should be different. We never had one.” And even admitting this really simplify the conversation saying, “Okay, this would be awkward for a few weeks, I know it. We’ll find the balance. I want to hear from you. You are knowledgeable. I trust you to help me to do this transition. We are together in this.” Like, “I want to hear feedback from you as soon as possible. Let me know what I don’t do right or where can I improve.” So, when they feel part of your transition to leadership, they will be more receptive. That’s my experience.
Kovid Batra: Right. This is one great advice, Anton. Thanks a lot.
So, I think that brings us to the end of today’s episode, it was really, really nice talking to you. I would love to have more such conversations with you as you transition into even higher positions in your company and really feeling great and happy about your newsletter growing so well.
So, all the best. I think you’re doing great.
Anton Zaides: Thank you. Appreciate your time and great questions. I didn’t know I like to talk so much, but yeah, you have great questions and it was a pleasure being here.
Kovid Batra: Thank you so much. Thank you.
In the recent episode of ‘Beyond the Code’, host Kovid Batra welcomes Tobias Mende, founder of Unblocked Engineering and author of ‘DevEx Nuggets’ newsletter. He has previously contributed his expertise to PayOne and Drager. The central theme of the discussion revolves around elevating developer experience and driving continuous performance
The episode kickstarts with a fun fireside chat with Tobias, providing a delightful glimpse into his genuine and unfiltered personality. Moving forward, he shares the obstacles faced in his engineering journey and how he successfully overcame them.
Tobias delves deeper into proven strategies for identifying and eliminating bottlenecks in the development process to enhance the developer experience, while effectively communicating their impact in terms of business value.
Wrapping up, Tobias imparts a valuable perspective on fostering a team culture that places continuous improvement and the pursuit of excellence at its core.
Kovid Batra: Hi everyone. This is Kovid, your host at ‘Beyond the Code’ by Typo. Today on our show, we have a special guest who is really adventurous and interesting, Tobias. He’s a founder of a DevEx consultation firm, ‘Unblocked Engineering’. He’s the author of ‘DevEx Nuggets’, which is a very famous newsletter, which I personally like. He has 10 years of experience in software development and leading dev teams. And on top of that, he loves to travel, he’s humorous and loves to drink whiskey. And, so do I. Welcome to the show.
Tobias Mende: Hi, Kovid. Pleasure to be here.
Kovid Batra: Alright, Tobias. So, you’re aware of the format, I hope. We’ll have a quick fireside chat with you wherein we’ll get to know about you personally apart from work, and then we’ll have another section where we’ll be discussing about how to elevate developer experience and drive performance in engineering teams. We know that you have experience in driving developer experience because you had created a platform in your previous organization to improve developer productivity by impacting the developer experience. So, we’ll be talking more around that in the main section. And, before that, I would just move on to a fireside chat if you’re ready.
Can we go?
Tobias Mende: Yes, sure.
Kovid Batra: Great. Alright. So the first question is, where do you get your daily dose of learning?
Tobias Mende: I’m mostly on LinkedIn at the moment. I’m following a couple of really great content creators. I have subscribed to some newsletters there. So, I get a lot of articles every morning. And in general, I do a lot of reading.
Kovid Batra: Great. I think LinkedIn has become a learning source for a lot of people. Most of my learning also these days is happening on LinkedIn itself.
Great. Next question. What is your preferred mode of learning? So, people do it with experiments. People do it with an online course. What’s your preference?
Tobias Mende: Usually a lot of trial and error. I’m definitely a hands-on person. I like to experiment. And, that’s usually how I understand things the best. I might, like, join a small online course before I skim through some tutorials briefly, but then I need to try things out.
Kovid Batra: Cool. I think hands-on experience is something that really gives that dent in your head, where you learn something. Just doing an online course won’t really help. So yeah, it makes sense. Doing some theoretical learning is great. But then, some experimentation is definitely needed to learn something in a better manner.
Okay, the next question. Can you describe your feeling in one word when your code really works?
Tobias Mende: Yeah, I would say when the code finally works, that I’m definitely, I’m satisfied.
Kovid Batra: Cool. And, this is something I wanted to know, which one’s your favorite brand when it comes to whiskey?
Tobias Mende: Oh, I like Mackmyra, which is a Swedish scotch actually, which is quite interesting and really has nice flavors. And they have one that’s called Vinterglod, which is tasting a little bit like mulled wine from the Christmas market, which I, coming from Germany, definitely like.
Kovid Batra: I think I got to learn a lot more things from you than just engineering and leadership.
Alright. Alright. So, moving on to the main section where we talk about developer experience, leading high-performance teams. This is your area of expertise, but before jumping onto that, you have been into the engineering space from last almost 10+ years. You have been a software developer, senior software developer, tech lead, a DevEx expert, and a founder of a consultation firm now. So, this is quite a journey. And, you have seen a lot of different working styles, different teams. What I want to understand from you is, there have been multiple challenges that you have seen in different teams; give me a few of those experiences where you were into a situation, you faced the challenge and then you actually overcame it.
Tobias Mende: Great question! So, there are a lot of different challenges, of course, as you can imagine. So, for example, one time I was working with a team of tech leads who were collecting technical risks and, technical debt inside of the system, but had challenges to communicate those to other stakeholders in the business. And therefore, it was always a challenge for them to get time and people to work on those technical risks and adapt and removing those. So, what we did there was, first collecting everything that the tech leads had in their head of risks and opportunities, and weighing them according to how much impact would it have and how much effort is needed, on kind of a diagram to visualize that, and then we prioritized that based on that diagram. And then, I coached tech leads and we worked actually together on making clear what is the business impact behind that and communicating those technical initiatives in a way that business people or non-technical people could really understand why is it so important, because sometimes tech leads and engineers in general are really great at finding the risks and the technical things that need to be done, but they are sometimes not that great at communicating those in terms of money and business value. So, once we got that done, it got much easier to plan them alongside all the feature ideas and initiatives that we had from product management. That was one challenge. Also, maybe a bit more related to developer experience, in the last company, when I joined the company, they did not have continuous deployments, even though it was a quite modern company. And what was even worse was that there was a handover in the deployment process from developers to QA engineers, who then did the manual testing, the automated testing, and ultimately, the deployment. So, that caused a lot of pressure on that QA team. And also of course, a very long feedback loop for the engineers. And, in order to shift that to a more continuous approach, people first need to understand why this is a problem, and they need to feel the problem. And at that point, the engineers were okay with not having that direct feedback because they didn’t need to deal with deployments. But once we changed that, they realized how messy the process was. And, that helped us, first of all, to get the pain to the people who should experience the deployments, how that is, the engineers. But also, the benefit was that the engineers contributed too, with their ideas, how to improve the process. And they asked a lot of questions on the process, “Why are we doing this step?” “Why are we doing that step?” And through that, we were able to automate and improve the process, remove some parts completely, and then arrive at continuous deployments, eventually with like 15 teams and 60 people, who then also understood what the benefit of that is. And, even though people were skeptical in the beginning, in the end, they were very happy that we arrived at that part, because it was better than they could have imagined in the first place.
So, that was something really cool.
Kovid Batra: That sounds interesting. On the first experience that you shared, I think having a clarity on what is the outcome of any work that you’re doing as an engineer is very important. And there is no denial, a lot of teams face this challenge. Even the tech leads are sometimes not that well subconsciously aligned with what the outcomes are. And, that is what is much needed when you are working on something. So, it is very important. I want to ask a follow-up question on that. How exactly you communicated it? Was this through standups, meetings? What is the channel you use? Because, I want to communicate real actionables. I want people who are hearing this podcast to know, like how to do it.
Tobias Mende: Yeah. So, with the tech leads, we were meeting once a week to get that clarity. And, we worked on a moral board, in a remote setting where we were discussing in a zoom call, basically these topics and refining those. But then, in order to communicate it to the business, we wrote Notion documents where we wrote down, “This is the initiative.” “These are the reasons.” “This is the risk of not doing it.” “This is the risk of doing it.” “This is what we think it will take us.” And then of course, there was some commenting on those documents asynchronously on, “Okay. Could you please clarify what the business value is?” “Could you clarify if that’s really something that needs to be done now, or if you can push it another quarter?” And then, we had quarterly OKR plannings in that context, in that company. And, we brought those into the OKR plannings. Like the product management would do with their objectives, we brought that in from the technical side as well. Also, to highlight that it doesn’t really matter where the initiatives come from or the objectives, as long as they are aligned with the business goals. Those can be technical objectives, but it could also be, of course, product objectives. And, in the end, we want a stable system, a stable product that will make customers happy in the future.
Kovid Batra: Absolutely. I think this is one very important point that I have been also discussing with other folks around setting goals for the engineering teams. Even I feel that these goals which are being set up, these objectives which are being set up, of course there are a lot of technical objectives that have to be met, but ultimately whatever they are delivering it’s something that goes out to the customer, they’re using it. So, just like product teams, engineering teams should have common objectives, like NPS, customer satisfaction, retention. All these things are something that even the engineering team should look at when they are delivering something. So yeah, it makes sense. Till the time everything is in line with the business goals, where the objectives, where the initiatives are coming from, it should make sense for the business.
Alright, moving on to the next question here. While enhancing the developer experience, what’s usually your go-to strategy for identifying, first the bottlenecks, and then eliminating those pain points and the bottlenecks in the development process? You can take one example, and then explain it, so that we have more clarity on how it should be done.
Tobias Mende: Yeah, okay. So in general, how I do this is by talking with engineers, because developer experience is all about the experience that people have. It can be subjective at times and measurements that we get from metrics like DORA metrics will not give us enough insights on the developer experience. They might show us that we have a problem, but not where exactly the problem is. So, asking people. And, how I usually do this is through surveys because 1-on-1s are great to talk with people and dive deep into some challenges, but it requires that there is a lot of psychological safety and trust in that communication. And, what I recommend to leaders usually is to be careful with that, because as a leader, I might feel very safe and confident in that interaction, but my employee might not feel as safe to tell me what really is a problem, because they might think, “Oh, maybe my leader thinks I’m not capable enough and that’s why I have the problem. So, I rather not tell anything.” But, if you do anonymous surveys, we can ask all kinds of questions around developer experience, for example. Like, “How satisfied are you with the deployment process?” And then, we can have a scale from 1 to 10. 1 is “I’m very unhappy with it.” And, 10 is “I’m absolutely happy with it.” And then, when they click something that is more on the unhappy side, we could add a free text question, “Please tell us a bit more about what bothers you about the deployment process.” And then, people can give also some subjective and qualitative data to that. So, that helps also to get a lot of engineers interviewed, not only the ones that are close to me, because when I’m the leader in an organization, doesn’t matter which role I am in the organization. I have some people who are closer to me and other people I don’t have that much contact. And, we are usually biased towards what the people close to us tell us, or what our own assumptions are. And in 1-on-1s, it’s quite likely that we fall into a confirmation bias, that we just get confirmation for what we already think to know about the developer experience in the organization.
Kovid Batra: Great. I think that’s a good start for anyone who’s looking at knowing the challenges the developers are going through. But, just to like, bring forth the most common problems; what do you think is the most common pattern, or which are those most common areas that you have seen, the developers are blocked, their experience is dented, and that really requires an improvement? Any, any specific things, any specific patterns that you have seen in the people you have talked to?
Tobias Mende: Yeah, something that’s quite common usually are problems or blockers in the software development process. This can be that they need to wait too long for code reviews. It can mean that there are flaky tests, flaky automated tests, end-to-end tests, for example. It can also mean that tests take too long or that there are parts that are manually processed, or it can mean that the deployment is done by another team than the team who actually works on the software, so that they have a hand over anything that blocks the software deployment process, between “I commit some code.” to “It runs in production.” That usually is an issue that is quite close to engineers. And, that’s also what engineers are very likely to complain about the first, because they see it on the daily interactions. Some of the things that have usually a much higher impact even, but, a bit more sensitive are things like company culture. “Do I feel safe in the organization?” “Can I collaborate with my peers and communicate freely what I think?” “Can I raise my concerns?” “Do I know how I can influence my environment when I think something isn’t right?” All those things are also important for developer experience and productivity. But usually, less an issue raised first by engineers because many engineers tend to accept the organizational environment as they see it and as they are in that organization, and don’t question how that could be changed. But for leaders, I know that there’s a lot of potential in changing the organization and the culture and the organization to allow for a better developer experience.
Kovid Batra: Great. I think that was really insightful, and with such kind of services coming into the market, I think it’s already a need. I see a lot of blockers, a lot of things happening. By the way, you mentioned about code review times being high and you might identify that as an issue and then go deep down to understand what exactly lies there. Have you come across any efficient method to identify such problems or is it mostly like, these assessments have to be done or you have to go and talk to them 1-on-1, or you understand these problems first-hand while you’re doing standups and sprint reviews with the team? Have you come across anything of that sort which is more efficient?
Tobias Mende: I mean there are of course a lot of tools who measure parts of the deployment process from the moment somebody picks a ticket, to the moment it moves to done, and all the stages in between, the ‘merge requests’. “How long are they open?” “How big are they?” There are a lot of tools. The problem is that we can get a lot of data, but without knowing where we suspect a problem, it’s difficult to find that out, because maybe the long code review times aren’t actually an issue for the way how engineers work in the organization for whatever reason. Maybe they don’t care about this, but something else is much more frustrating and we only get that by really asking engineers, “What’s frustrating for you?” And they will tell us. And, the good thing is when we work on what frustrates the engineers, that will improve their experience because they see, “Okay, something that frustrated me before is gone now, and we might get other ideas from metrics.” For example, in the last company, we measured all the big jobs and how long they took with data doc and also had some alerts on certain. It’s increased their build time for an unreasonable amount, just to check, “Okay. Why does this not take twice as long?” “What happened there?” And that helped us of course, to improve things even before somebody noticed, and over time, people were like, “Oh well, this used to take an hour. Now it just takes 10 minutes.” Cool that we have this developer experience team. But, for finding problems in the first case, I find that talking with people or getting kind of surveys out, maybe also automated through tooling, are the most effective ways.
Kovid Batra: Great. Thank you. I think this really helps bring forth another important point, which I would want to discuss on this podcast. In pursuit of this high performance, teams are sometimes like, there, there is a resistance to change, like they don’t want to go out and change outright, right? So, how do you overcome those resistances, and drive a team culture that is always on a continuous improvement and towards excellence? So, how do you tackle that?
Tobias Mende: So in general, I think it’s a myth that people are resistant to change in general, because people change things in their life all the time. The difference is that when they do changes in their life, such as getting a child or getting married or any other thing, moving houses, traveling to a place. Those are changes, but why are they not a problem? They are not a problem because people understand why they are doing those changes. So, when we feel resistance in the workplace, then the question is often, “What are people not seeing (why this change is good)?” Maybe they think that the risk of this change is higher than the benefits for them. Maybe they got tired by too many cultural change initiatives in the past that always led to just another culture that has the same problems under different names. All these things are important to understand first.
And then, one thing that I see happens often is when people, leaders normally, see a certain change that they want to see in the company. They communicate that, and why it is a great change and all the numbers and facts and everything to rationalize why this is a great change, but what often completely is missing is the emotional part. We need to connect that to emotions. “How does it feel to work in that new environment after the change?” And, “How does that benefit?” “How would the life look for engineers in that new environment?” And once people can feel that, they are much more likely to support that change because they believe this is actually great for them. I can give a small example. When we introduced the continuous deployments, I already explained a bit about that as an answer to the other question. I showed a slide where I showed them, “Okay, this is the time it takes today from a commit to deployment. And, we have this and this stages and they take this long time.” And I showed them below that, a graph that was only, I think it was roughly a third or a sixth of the usual time. And I told them, “Okay, look, imagine how it would feel if you can get your changes live to production within 20 minutes?” “What would that mean for your database migrations?” “What would that mean for your experiments that you are running with your users?” And so on. And people were like, “Oh, this would be actually quite cool. We don’t need then days anymore to get that life, but we can do it within half a day.” And that was how people got excited, I think.
Kovid Batra: Right. I think you gave a very good analogy here. Like, when we change in our personal lives, whether it is having a baby, moving places, getting married, whatever, things fall naturally to us that, “Okay, this is going to be good for me.” “This is why I’m doing this.” Right? So here, in the personal space, it’s the culture, it’s the society, your personal happiness, your experience, seeing other people, other couples enjoying their lives; you already have that mindset and believe that, “Okay, all this is very positively rewarded.” Whereas in companies, in workplaces, usually, I think resistance to change comes in those companies where the culture doesn’t appreciate the change. They do not embrace failures and ask people to improve on them. Like every time, there should be something that is imbibed positively within the company culture around these changes. So, I think that also can bring a lot of ease when you introduce something new to the system and people take it, and then do it and deliver what is needed. So, this is my thought. I was just thinking on what you just said, so.
Tobias Mende: Yeah. Thank you. Exactly. I mean, the thing is when we focus on developer experience by definition, this is we are caring for the experience of developers and we try to make that better. We are not focusing on performance or making them productive just so that the business can make more money. That is a side effect. A very nice side effect, a very important side effect, but when people truly believe that we care about them and about their experience, their work experience, and that we make it better, then people are far less resistant to the change, because they know, “Okay, the last time the team changed something or the leader changed something for the purpose of improving developer experience. That was awesome. So, give us more of that change. We want more of that.”
Kovid Batra: Right. Great. I think it was a really, really nice talk. We had a good discussion around developer experience, your experiences, your challenges. So, it’s great. Thank you for sharing the experience and the knowledge here. I would love to have you for another episode, talk more around developer experience because I think that is a topic which would be a complete episode to discuss on. So, all the best for your ventures and all the best for your journey in life.
Tobias Mende: Thank you, Kovid. I really enjoyed the conversation with you. And, yeah, whenever it’s the right time, I’m happy to join again.
In the recent episode of ‘Beyond the Code’, host Kovid Batra engages in a thought-provoking conversation with Miroslaw Stanek, who serves as the PL Engineering Site Lead at Papaya Global and author of the newsletter ‘Practical Engineering Management’. He has previously lent his expertise to Azimo. The focus of their discussion revolves around achieving technical excellence while effectively managing tech debt.
The episode starts with a fun fireside chat with Miroslaw, allowing the audience to see his more genuine and unfiltered side. Moving forward, he shares the challenges he has encountered in his role as an engineering director and how he overcame them. Further, he delves deeper into maintaining a harmonious collaboration between CTOs and VPs in order to tackle existing tech debt while concurrently delivering new projects.
Lastly, Miroslaw sheds light on instilling a sense of ownership and collaboration within engineering teams for continuous growth and improvement.
Kovid Batra: Hi everyone. This is Kovid, Kovid with a K, your host on ‘Beyond the Code’ by Typo. And today with us, we have an amazing guest, Mirek, who is an engineering director at Papaya Global. And he’s an engineering leader, he’s very unique in his own ways. He not only loves engineering sprints, but he also loves marathons. He has recently completed his OCR.
Welcome, Mirek. Welcome to the show.
Miroslaw Stanek: Hello, Kovid. Hello everyone. And thank you for having me. Just, you know, small update. I’m not a marathon runner, I’m a trail runner. It’s still, you know, running, but actually I prefer running, you know, uphill and downhill rather than running through city. But, you know, it’s more or less the same.
Kovid Batra: Great. Thanks. I didn’t know about that. The learning has already started. So today, on ‘Beyond the Code’, we have Mirek with us and he is running a newsletter, which I personally love,’ The Practical Management’. I want to give you a kudos for that, Mirek. It’s really nice. I’ve been following it for some time now.
So, keep writing and I really see that passion of writing in you. So please, we need more people like you in the community.
Miroslaw Stanek: Thank you. Yeah. So, if everyone would like to check, just go to www.practicalengineering.management, where I put all of the things for fresh engineering leaders, tech leaders, engineering managers, and others.
I was there. I know what kind of struggles I need to face. So, I hope I can share some of my experiences to make your professional life better.
Kovid Batra: Sure. Alright. So, the format of this podcast is, we have a fireside chat with you where we get to know the real Mirek and then we’ll jump onto the main section which talks about your experiences, engineering, how you handle those challenges, and how you improved on those.
So we’ll move on to that, but a quick fireside before that. Are you ready?
Miroslaw Stanek: Yeah! I am.
Kovid Batra: Alright. Alright, Mirek. So, the first question, it’s something related to reading and books. So, if there is one book that you would want to recommend to all the engineering leaders, what it would be and why?
Miroslaw Stanek: This is actually quite hard question. If I have to pick only one book, I would say it’s ‘Empowered’. It’s written for product managers and product people, but actually it states that engineers, engineering teams are also part of product teams. And, I think that this book explains very clearly what’s your role as an engineer or engineering leader in the product organization. When working with engineers, I trust with the picks for their technical books because they know what are the challenges for them. But, this is the book, which I recommend every single engineer who would like to make great job building, not just the code, but the working product. So yeah, short answer, ‘Empowered’.
Kovid Batra: Great! Alright, moving on to the next one. Do you prefer to jot down your thoughts old-school style with paper and pen, or you embrace the digital era?
Miroslaw Stanek: You know, I think that we can have like another episode only on the notes taking because I don’t have the clear answer here. I like writing in both ways, either with pen and paper, and digitally. It all depends on the context. So, for example, I use note-taking apps. The one I use most often is Obsidian. It’s a note-taking app, which you can, you know, write and mark down. You can have tagging, you can somehow connect the notes. It’s great syncing across different devices. So, basically Obsidian is a place where I put like everything, my daily notes, my notes from work, my ideas, drafts of the blog posts, and tons of others. I love it. I love doing notes in this way because basically, you can use search, for example. If you work on something which actually you touched half a year ago, you just go to search and you can find your note. So, this is why I like using the digital notes.
But, it doesn’t always work perfectly. For example, if I have meetings with people, I prefer not having my laptop during the meeting, if I don’t have to have it. I prefer to make notes on paper, because I don’t want to have this wall between, you know, me and the person I’m talking to. I don’t want to have distractors. I don’t want to have even the screen shining on me or the notifications or anything. Also, I read some interesting scientific papers and actually when you write your notes with pen and paper, it actually puts the thoughts your memory and it roots there. So it’s easier to remember what you were talking about. Also, for me, it’s faster to write, you know, handwritten notes than write something on the keyboard. So, yeah, like I said, no simple answer for the simple question.
Kovid Batra: No, no, it definitely makes sense. I am one of the users of the tool. We are using it for our platform, for typo help docs. We use that. And in general, I really feel the benefit of having something published over multiple devices. Wherever you are, you can update it for yourself. You can share it with them. So yeah, that way is very very productive and helpful. And of course, sometimes you just don’t want to have that barrier of a digital thing in between human and then, paper and pen works best for us. So, totally I think it’s a balanced approach for most of the people.
Miroslaw Stanek: Yeah, definitely.
Kovid Batra: Moving on to the next one. So again, coming to one of your interests, tech and run, right? This is a match which is unique and made in heaven, I think so. So, what is your motivation? Like, what is your mantra of life that fuels you?
Miroslaw Stanek: Yeah. So, there are a few aspects of that. First of all, it’s like very, very practical, because what I’m publishing on social media, for example, you know, photos from my latest trail runs or obstacle races. It’s kind of the end of the story. And this story begins with me having quite big issues with my health. Basically, two or three years ago, I could barely walk because of the problems with my spine. Why? Different reasons. I had the injury, but also I’m the engineer. So, I spend most of my time sitting. So, the practical thing here is that you need to stay healthy physically. You need to do something. It can be running, swimming, or just moving. Currently, when we are talking, actually I’m using the standing desk. Yeah. so, we need to find the ways to keep you moving, yeah? But apart from that, because you know, there are like tens or hundreds of different sports which you can pick. For me, obstacle race is something which there’s always the next level like I can reach, you know. I remember watching races, a year or two years ago and was like, “Oh my God, what are those people?” “How they can do this?”, and today I’m one of those people. What motivates me to that is, mantra, I would say, is, you know, just dream big. Everyone says dream big, but the next thing is make a plan. So, to make your dreams happen, you need to find ways how to make the small steps to accomplish that. And if you have a plan, don’t think about the motivation, but rather about being disciplined, because motivation is when you’re watching those people running and you would like to be like them. Yeah, so this is the motivation. But, when I wake up at 5 a.m. in the morning, I don’t care about that. I’m not motivated at all, to be completely honest. But, I’m kind of disciplined to go to this training like three times a week. It’s not pleasant at the very beginning, that’s why you need to enable your discipline, and motivation comes later. So, this is my kind of mantra for how to make this thing happen.
Kovid Batra: One great investor here from India. He runs a very big fund. He mentioned one very great thing recently I came across related to discipline. So, he said, “Anyone who lives life successfully has to be disciplined.” So, living life successfully means you have to be healthy. You have to be mentally healthy, physically healthy, and achieve a lot of professional goals, personal goals. And, I also have started feeling it very recently that discipline is at the core of everything. When you’re young, when you’re a kid, school teaches you all that. But, I think at that time, people really don’t perceive it so strongly as we do when we reach this point in life. So, it is very important to keep yourself involved in some physical activities, some sports to be healthy and keep going.
Miroslaw Stanek: Definitely. Yeah.
Kovid Batra: I think let’s move to the main section wherein we’ll be talking about the technical excellence while managing architectural debt. So, this is something that is very cool to you. But before we move on to this topic, I specifically wanted to talk about very basic things, core to your journey. Wherein, I want to understand, there have been a lot of challenges that you might have come across during your engineering journey, right? You’re an engineering director at the company, but whatever challenges you have faced as a leader throughout your journey, can you just put a light on some of the key events which you came across and how did you overcome them?
Miroslaw Stanek: So, you’re asking about the key challenges which I faced during my journey? The one that I’ve been facing all the time is connecting the world of product and the world of the technology. From the technical perspective, there is always something you can do. There is another library that you can do some refactoring. You can increase, I don’t know, the testing coverage, whatever. You can hire a big number of people and you won’t accomplish that. So, the important thing is to be sure that no matter if you are the engineer, I mean, the individual contributor or the leader or director, you need to be sure that you do things in order to satisfy your customers. You build features, not just the code, and it touches many areas. Technical debt is one of them. So, I think we’ll go into details into that. Saying no to some particular activities. So, for example, you would like to migrate from one container solution to another one, only because you heard that today everyone is using Kubernetes, and you would like to use it. Yeah, of course you can do this. It’ll take you, you know, a few weeks, few months, depending on where you are with the company. But in the end, you need to understand, “Okay, what’s the real value for the product you built?” Maybe it will be better scalability, better maintainability, or maybe it will bring you some other challenges which will keep you from providing the real value. So, this is the challenge I’ve been facing on every stage of my career. Either when I was, you know, writing the code or leading the team. It was always easy to find something fun to do, but it was harder to find something which is both fun and useful.
Kovid Batra: By talking to other engineering leaders during the podcast and otherwise outside of the series, I think this has been popping up again and again, like the connect between the product and the engineering that the engineers do. So, the purpose of doing something is something that should always be instilled while you are working as an engineer. So, it makes a lot of sense what you are saying. But, any specific advice on how we can instill it in the engineers? Because when everyone is talking about it, I feel it doesn’t come naturally to the engineers, at least for a lot of them. So, what do you think worked out well for you when you faced this challenge and you tried to solve it? Any practical advice there?
Miroslaw Stanek: So, I would say having clarity on the outcomes of your work. I think this is the extremely important thing. So let’s say, you have a project and the deadline is, I don’t know, December 1st, yeah? So, you have two, three months to finish that. And, this is the only message you give to the team. Team is like super focused on delivering feature to production. Period. Yeah? So, you know, November 30th, you launched production. December 1st, your goal is achieved. End of story. And actually, it’s not the end of story for the product. Maybe it’s the end of story for the, you know, very first launch production, but not for the product, because actually, on the December 1st, it’s the very first time when your product reaches your customers. So, this is the moment when you need to understand what’s the stability of it, what’s the adoption, what’s the feedback of customers, what are the biggest struggles and everything. So, you know, if you focus people only on delivering on the deadline, they will put all of the energy and attention into making it happen. And on December 1st, they will be exhausted. While actually you need to be sure that on the December 1st, they are in shape because they should wait for the feedback. They should, you know, continue working. They should continue improving the product. So, months later they can celebrate success. First customers, first paid customers, first conversion, new market open, increased conversion of something. And, if you tell people, “Okay, deadline is important because marketing team is waiting for this deadline.”, “Few other things are waiting for this deadline.” But, the most important thing is, “What’s the value you generate for customers?”, and this is what you should focus on. And how I do that in practice? I try to bring as much data as possible. So, for example, if your work is to enable new market, for example, I’m asking to create a simple chart, which shows me how many new customers signed up in a given country, for example. Another project, if you would like to increase the conversion of your login flow. I’m asking for another dashboard to show you, “Okay, what’s the current conversion?” “How many people open the app or open the website?”, and “How many of them land on the main page after logging in?” And, we can see the percentage. And then I say to people, “Okay, your goal is to increase this conversion by this or that percent, and this will be our success. I don’t care if you release that, you know, this week, next week, this is just first step. I do care what we’ll achieve as the outcome of your work.”
Kovid Batra: Yeah, this is really, really helpful, Mirek, because accompanying product and engineering goals together would really bring a big change in the mindset how engineers operate. As a product manager, my goal for a particular release is to have that conversion or that retention, right? Whereas for engineers, that doesn’t come directly. But, if the same goals are set up, same key results are set up, then of course, we can see that change, and engineers can also start thinking in the direction of an outcome-based deliverable, not just delivering something. So, it makes a lot of sense. And thank you for this. This really is a practical advice which resonates with your newsletter name also.
Perfect. Moving on to the next question in your area of expertise, which is bringing the technical excellence while managing the architectural debt. So, how do you collaborate the CTOs and VPs to address the existing architectural debt while ensuring that you’re delivering new projects also, right? So, at that time, this is the hardest call to take, I feel, that what to do right now. Whether you’re a startup, or let’s say, a mid-sized company, somewhere or the other, you have this question and how to take a call on that. I would love to hear your thoughts, your experience on this.
Miroslaw Stanek: Yeah. So, when it comes to addressing tech debt, I think that we need to make, you know, a few steps back, and tell very clearly what the tech debt is, yeah? Because let’s say we have monolithic systems. Is that the tech debt? Sometimes it is, because it blocks the multiple teams working on a single product. Sometimes it is not, because if you are a startup and you have only one engineering team, like let’s say three engineers in the company, actually it’s beneficial for them to have a monolithic system, because they can go live very quickly, they have like a single monitoring system and everything, yeah?
So, first of all, what’s a tech debt, yeah? I would say that tech debt is, it’s something what stops you from reaching your product or business goals. And obviously, some companies are more major than others. In some companies, you have, you know, KPIs or OKRs, like very clear information, what you would like to achieve. In others, you know, fresh startups, you’re still, finding this product-market fit, pivoting a lot.
So, when thinking about what’s the high-level goal here is that there are four essential things all of the businesses or product companies to succeed. One is growth. Another one is expansion. The third one is customer satisfaction. And the fourth one is profitability. If you understand what’s your current goal. For example, if you do optimization of the login funnel, it’s probably something about growth. If you fix some of the most common problems of your customers, it’s probably customer satisfaction. If you are, I don’t know, migrating from one database to another because of the optimization, probably it is about profitability. If you open your app to another market, another continent, probably it’s about expansion. And if you have this in mind, you can identify, “Okay, what are the biggest obstacles in order to, for example, launch our product?” Let’s say, you are a European company, “What’s the biggest obstacle to launch your product in Asia, to launch your product in the U.S.?” And if you know that, it’s easier to identify what are the moving parts, in terms of, you know, software architecture, for example. Which of the things should be generalized enough so you can start launching to other countries? For example, let’s say you have the sign-up flow, yeah? And, in one country, you just take the name, and first name and last name. In another country, you need to take, I don’t know, the postal code because of compliance rules. Which means, that your sign-up flow needs to be more generic, which gives you some idea that, “Okay, this part probably needs to be quite dynamic.” You need to bring dynamic configuration, whatever. While other parts, a particular screen, like, showing you something. This can be static for all of the countries. So, maybe it’s not the right time to generalize this kind of domain. So, if you have clarity here, you can tell your management, “Okay, if we would like to launch to another country, maybe we can use our current infrastructure, but if we are planning to launch to another 10 countries, those are the moving parts we need to optimize, the technical debt we need to fix, the domain we need to extract, whatever, in order to reach our business goals.” If we want to increase customer satisfaction, we need to invest more in one, bug fixing, but another one may be better SDLC. So, we reintroduce less bug fixes. If we would like to increase the growth of the company, maybe we need to optimize some things. And, what means optimizing? Probably it means launching to production like every day, every week, whatever, yeah? So, you can do quick experimentation. If your SDLC doesn’t help you with launching like every day, this is tech debt, because your company cannot, you know, iterate quickly over the product.
Kovid Batra: What I understood is that there could be different situations where you have to like, evaluate multiple moving parts and then take a call on how you should move forward, so that you don’t end up creating more technical debt or whether you should handle technical debt right now or just focus on time to market first. One thing that I felt is that it is always, or it should always be driven from the business goals. Like, technical debt, first thing when you’re thinking, “What is your business goal?” And then move on to the next step of thinking what you need to move in your system. So like, maybe clear the technical debt, or maybe at that point you should not care about it much. Just focus on launching for that particular country and that would be sufficient for now. Like, move fast there. Yeah. That’s great insight.
Perfect. A follow-up question on this. So, this is something when you are in a position where you have to like take a call, like whether to handle it or not. But, when you’re building something, at that point, engineers are writing code, which could be optimized or highly optimized or not at all optimized. What things should be taken care while building things in general, to not have a lot of technical debt for the future?
Miroslaw Stanek: Well, you know, it would be good to know what’s the kind of long-term roadmap for the company, because it will give you at least some clarity. “What are the important technical things, which not addressed now will block us in the future?” But it’s not easy, yeah? Especially early, the startup. They simply don’t know. They don’t know what they will do in next three years. They can have vision, mission and all of the values, but market will check it anyway. I think that another good thing to keep in mind is that one of the book I mentioned is ‘Accelerate’, it’s a set of good practices, mostly in software delivery processes. And, you know, it is with us for quite a long time. And simply there are good practices which we should follow rather than reinventing the wheel. Just see what are the recommendations for the biggest, most successful companies and those recommendations are, how fast you can deploy to production. Because it will tell you how fast we can iterate over product. If you cannot deploy to production every day, I think this can be the sign of the technical debt. And I’m not telling you that this has to be your goal. Your goal should come from product, and being able to deliver like every day is just kind of tool for reaching your goals.
So, rather than telling, “This is our goal to release every day and let’s say in a half a year from now, I would like to see you guys launching every day”, I prefer checking if we can release every day, if our SDLC process is capable of doing that. So, I don’t care if you release like 50 times this month. I do care if this is possible to release when it’s needed, yeah? So, there you have weeks in which you will release like 20 times a week and you will have weeks when you release just one thing, because this is how it is. And I would focus on this, yeah? Releasing very quickly. Automate as much as possible. So, don’t do manual work at all or very little, including testing, for example. Obviously, you need to also try your, you know, core metrics, the usage, the cost of your infrastructure, so you can see how it goes up or down. And yeah, I think it should give you some early indicators in order to learn where is the technical debt of yours.
Kovid Batra: This is a suggestion. This is an interesting topic actually and it can take a few more questions for me to understand and for audience to understand what calls to take when. Can you write something in your newsletter about this, like particularly this topic? In startups, “What to do?”, “What are the best practices to not let any technical debt accumulate over a period of time and simultaneously managing to deliver fast?” That’s just a recommendation because I find it very interesting.
Miroslaw Stanek: Oh, yeah, I really love feedback. So, thank you for that. For sure. I will. I will try to write something about it.
Kovid Batra: Great. Thank you. And, moving on to the last question of this episode. As an engineering leader, you face a lot of challenges, but one thing that remains common in a lot of teams, which I would definitely want to understand from your experiences that how do you instill a sense of ownership and collaboration within your engineering teams so that they’re always growing and they’re doing that continuous improvement? How do you build that culture?
Miroslaw Stanek: It’s a good question. If you want people, teams to own something, you need to be very, very clear about what does it mean. So, I put a lot of effort, especially now when I’m the director of engineering and I’m not doing the day-to-day code, I try to bring as much clarity and transparency as possible. So, one of the things is obviously being transparent about how we are doing as a business, what are the core things discussed by management, and so on. Those are like less technical things, but I also try to bring as much data as possible, either from the product, which I mentioned earlier. So, conversions, number of customers, maybe number of issues, but also, technicalities. Because, let’s say I tell people, “You own the quality of your product.” What does it really mean, the quality of the product? Some people will care only about the quality of the code, the performance of the code. Others will care about the full picture and number of bugs, especially the ones faced by customers. So, I try to bring those numbers to light. And I try to discuss them as often as possible. So, if I talk to the team responsible for, let’s say, the website. I try to discuss, “Okay, what’s the crash rate?”, for example. “What are the errors in console?” “What are the issues with the performance?” And by discussing that, I’m also presenting, “Okay, what are the practical aspects of the ownership which I expect from you?” So, this is one side of the ownership. Another one, it also touches the transparency and the clarity. It’s celebrating small accomplishments, because very often, especially if you are like super busy in delivering feature after feature, you don’t have time to stop. So, you have no idea if you did a great job. So, depending on the situation, I do a few different things. So, for example, I write monthly newsletters to the entire company or the entire product organization, which highlights, “Okay, in this month, we achieved this and that. We achieved those product goals, but we also built this part of architecture.” “We implemented this technical thing”, and so on. I try to approach as many people as possible and tell them clearly, “Okay, you did great presentation on performance testing. Thank you for that, because thanks to you, others will know or will have some kind of inspiration how they can do this.” And by that, by simply saying “thank you” and “great job”, you’re showing people, “Okay, this is a very important thing.” And, I think that you need to do this quite often, either publicly or on one-on-ones, you need to keep reminding people what’s important. You know, when you have CEO or CTO, they often focus on the mission and the vision of the company. It is important because this is something which gathers all of us, the employees of the company, under one goal, but sometimes it’s hard to capture that, especially if you are individual contributor. if you, for example, write the pieces of the infrastructure or you do the database optimization, it’s quite blurry to understand how your work commits to the 5, 10 years vision from CEO.
So, my job or job for every single engineering leader is to ensure that every single person knows how his or her work connects to this high-level vision, and you need to do this as often as possible, to keep reminding people why their work is important.
Kovid Batra: Totally. I totally feel that and bringing transparency, bringing clarity on what they are doing and how things are moving around that, setting up the right goals, celebrating the outcomes. I think all of this makes a lot of sense when you connect it. And, one thing that I feel is that it should be done very often.
Miroslaw Stanek: Exactly.
Kovid Batra: You’re doing your work. You actually tend to lose the bigger goal, the vision, and you really don’t connect to what you’re exactly doing. As you mentioned, if you’re doing some infrastructure change, then you don’t know how it is contributing to the mission which was mentioned by the CEO in the last meeting. So, it is the job of the engineering leaders and the engineering managers to come in and communicate that and celebrate every small achievement that contributes to the journey.
Miroslaw Stanek: I would say like one thing for every single engineering leader, if it feels weird to tell your people, “Great job, thank you.”, you need to do much, much more often, until it feels natural for you. And people don’t look at you like, okay, we’ve some kind of, you know, suspicious, okay, what this guy wants from me.
Kovid Batra: I read one of your newsletter issues, which mentioned about having frequent one-on-ones and I couldn’t get a sense of this, that this is in the DNA of the engineers, probably, or the engineering leaders, that they’re kind of introvert, right? They really don’t open up easily. It might not be true for a lot of them, but I feel that comes in the DNA of an engineer. We’re sitting in front of a laptop, 10 years of coding and then suddenly you’re meeting people. It seems a little weird. It becomes difficult. It’s, it’s a barrier. Right?
Miroslaw Stanek: Exactly.
Kovid Batra: And I think, the engineering community will embrace this and they’ll learn and probably have better teams and better culture of continuous improvement.
Great, Mirek. I think that was a great session. A lot to learn. Looking forward to more newsletter issues from you. Thank you so much. Have a great day.
Miroslaw Stanek: Thank you, Kovid. Thanks for having me and yeah, have a great day to everyone who is listening to this.
In the recent episode of ‘Beyond the Code’, Host Kshitij Mohan, founder of Typo, welcomes Anemari Fiser, a Tech lead trainer. Her vast experience also includes valuable contributions to renowned companies such as CodeOp, Thoughtworks, and Waterford. The focus of the discussion is on navigating tech success with an emphasis on Career Goals along with Team Relations.
The episode initiated with Anemari sharing her inspiring journey - transitioning from a software engineer to a tech lead trainer, followed by an engaging fireside chat. Afterward, Anemari dives deeper into creating a growth plan setup for team members. She also underscored the significance of conducting one-on-one meetings to gain a deeper understanding of team members and to provide them with constructive feedback.
Lastly, Anemari highlighted the core principles that every leader should be well-versed in: self-awareness, reflection, and embracing vulnerability.
Kshitij Mohan: Hello everyone! I’m Mohan, your host, back with another exciting episode of ‘Beyond the Code’ by Typo. Today’s guest brings a very unique perspective on navigating tech success. From being a software developer herself, today, she helps software developers build a successful career in engineering. She has completed the entire loop. Today, she acts as a career coach where she helps engineers get what they need to reach to the next level. Please welcome, Ane to the show.
Hey Ane, thank you for your time today.
Anemari Fiser: Nice to be here and to meet you, Mohan. It’s a pleasure.
Kshitij Mohan: Thank you so much, Ane. I think before we start with anything, we are already amazed by the kind of career progression, the evolution that you have had. And I think to begin with, we all would love to understand about these career choices that you’ve made that helped you reach where you are. And now, you are helping the entire community with it. Would love to understand your experiences, Ane.
Anemari Fiser: Sure. Well, a quick overview over my trajectory, let’s say. So, I started as a software engineer. I had what you would call a straightforward path to software engineering. I’d done my four years of university, got my degree in computer science, and then I started playing different roles as a software engineer in different companies, different industries. And, I loved that for a while until at some point, early in my career, I got really curious on all the other problems, like the product side “Why are we doing the things we’re doing?” “How do we make sure we’re more productive together as a team?” And, that’s how I got into leadership. And once I switched to that part of focusing on people and focusing on what exactly we’re trying to build, it became clear to me that that’s the type of impact that I want to have. So, I started my role as a tech lead. I’ve been a product director. And, at some point, some years ago, I burned out in the tech lead role that I loved. So I had to change the trajectory a little bit. So, I started working with people individually, in tech leadership positions in different roles, helping them identify when they are close to burnout, but also identify how to move forward in their career. And this is what I’ve been doing for the past three years. I’m also running trainings, like with tech leads into helping them building high performing teams, and individually supporting their individual struggles. So, yeah, I think that sums it up.
Kshitij Mohan: You know, I think that’s such a great initiative, Ane, that you’re working on. And as you mentioned, burnout and how do we help build teams sustainably. If you would be okay, would love to understand this entire ecosystem of burnout, When do you start feeling? How do you start experiencing? How did you realize “Hey, this is something that we need to address and then move on to the next journey?” I think that would really be valuable for all of us.
Anemari Fiser: So, I think for me, it was pretty obvious given the fact that I couldn’t be productive anymore in the day-to-day. So, I was feeling overwhelmed all the time. I reached like the final step in which I wasn’t able to function day-to-day at the level that I was expecting from myself at that point.
So, I do believe there are signs earlier. And, if you’ve been through it, you start to identify them sooner. And also for people that didn’t get to that point, I think there are some signs that you can identify before getting to that point and you can address it. So, that means you can address this with a way better approach than me, which is quitting your job. I think the signs are clear, but we just ignore it. Tiredness, it’s demotivation, it’s exhaustion, it’s not being able to sleep. You know, like just kind of feeling unable to show up every day to the level that you expect from yourself. So, I think those are the small signs.
Kshitij Mohan: Right. And just talking about a bit more, Ane. So, these sometimes are phases also, right? Sometimes there is a phase where you experience this and then after the phase, you are back on with the same energy. So, is it like a cycle that you constantly are on, or any specific things to consider about?
Anemari Fiser: So, definitely can be cycles. I think it’s depending on how intense the cycles are and how often do they repeat, in order to get to that burnout phase. I definitely think if you identify the signs earlier, you can address them earlier and then you can be in this period, like you say, “Okay, they are temporary.” “I know how to address them.” “I know how to get back on track.” but, I think it depends from individual to individual, and from the level of exposure to stress they have.
Kshitij Mohan: Right. This is really great. Before I jump on, I just read your LinkedIn profile and there was one thing that I was really curious to talk about. So, you mentioned that you help quit your job without guilt and leave a door open. This is a very interesting statement that you have written. I think we’d love to understand what’s the perspective behind this.
Anemari Fiser: Yeah. So, I mean, quitting your job is a normal thing to do, mostly in the world today. And it doesn’t have to be like a door closing. It’s not like I’m not going to talk with these people again. It’s not like I’m not gonna maybe even come back at some point. So, I think it’s important to normalize quitting, just as normal as it’s become now firing people. Unfortunately, it’s just the world we’re living in. And so, normalizing quitting and just understanding that it’s about moving to something else, looking for different opportunities. It’s okay. At the same time, while understanding that you never know, and trust me, i’ve seen it. You never know where life takes you. You never know when you’re gonna start or meet those people again or that company or their product. So, it’s always important to just act as people and to treat it as an adult. All of this, it’s like separation, situations and just approach it like that and, leaving that door open, so you can come back, so you can work with those people in the past.
For me, definitely that happened and I’ve seen it firsthand. The world is very small, even if we think it’s really big and you never know when they will need you or you will need them. So, there’s this level of professional friendship that I think needs to just be there as a base. But for that, it’s important to have a clear understanding on why you’re quitting your job, and to not basically get to that point of full frustration, when you’re just slamming the door. I think it’s just a more healthy approach for your development, but also for the industry’s development.
Kshitij Mohan: I think it definitely takes a mature set of conversations to end things on a good note, other than just making it anything on the personal front. Perfect, Ane. So, before we begin with anything, we would love to have this quick fireside chat with you, where we would love to ask some questions to know more and then just go about it. So, if you’re ready, I’ll just shoot those three questions for you.
Anemari Fiser: Go for it.
Kshitij Mohan: Perfect! Question one. After a demanding day of work, which I’m pretty sure most of your days are, how do you unwind yourself?
Anemari Fiser: With a good thriller book. That’s my escape from the work, brain.
Kshitij Mohan: Oh wow! So now coming to who’s your favorite thriller writer? And any specific book that you would like to mention?
Anemari Fiser: Yes, so I don’t remember the writer, but the book is called ‘The Silent Patient’. That’s my favorite thriller book.
Kshitij Mohan: ‘The Silent Patient’. So guys, ‘The Silent Patient’ has to be on our next reading list.
Perfect. Question 2. What does it take to bring a smile on your face even in the toughest of the times?
Anemari Fiser: I would say reggaeton music. There’s nothing that puts me in a good mood more than a reggaeton. Very, you know, classic reggaeton song that completely shuts down my working brain.
Kshitij Mohan: Whoa! Nice. Gets you in your zone.
Last thing, your most triumphant moment as a leader?
Anemari Fiser: My most triumphant? Well, there are a couple to choose from. I think the most triumphant, the moment that I’m most proud of as a leader, was actually the moment when I failed miserably, and I let my team down. But I think the comeback from that experience was something that I’m really proud of as a leader.
Kshitij Mohan: Totally! Any specific situation that you would like to talk about there?
Anemari Fiser: Yeah, I mean, it’s pretty simple. I basically made a decision that wasn’t in line with what the team was going for. And I had to stand behind that and work together with the team to build back that trust that I lost in that moment.
So, it was early in my starting days as a tech lead. And I learned my lesson definitely. I would not like to be in this situation again.
Kshitij Mohan: So, thank you so much firstly for this. This was really fun and exciting. Now, getting to the real stuff, the expertise that you have seen and evolved over time. Navigating into this entire dev ecosystem, dev journey. And, when we talk about growth and scaling and all other aspects in your career. The first important aspect that comes in that, how do you identify who needs what set of things to grow on. That need gap analysis. How do you identify which set of members need what set of support to grow, and all this has to be balanced while you are doing what you are doing in your daily flow of work?
So, how do you do that? Any specific ways that you have done in your career that could help us?
Anemari Fiser: So, I think every person, every individual in the team needs some sort of growth plan set up. And I think that’s part of the responsibilities of a tech lead, of a leader in the team to make sure that they have that. That means helping them develop it. Personal growth plan, and identify areas for improvement by asking for feedback. Maybe just taking an assessment on their skills and seeing where they are, based on the expectations of the company and seeing what they have to work on. So, I think it’s a key expectation of a leader in the team to make sure everyone has some sort of roadmap for growth in the area that they need to develop, which is aligned. And that’s where again, the role of the leader comes, to make sure that’s aligned with the needs of the team or the needs of the company.
So, I think that those are the main things. It’s about working together with the individual to identify areas of growth, and then helping them find opportunities, and in the day-to-day work, so they can develop those skills.
Kshitij Mohan: Right. And what I’ve realized is that the folks, for example, the developers are also not aware of what they need to be, or how do they fit in the bigger picture of the growth journey and roadmap.
So, how do you actually make them also buy in and realize, “Hey, this is something you should also be focusing on”, because most of the times it looks like just a one-way conversation, right? You, as a leader say something, developer thinks, not thinks, ignores and then you just keep on going about it. How do you ensure that these folks also buy?
Anemari Fiser: I think everything comes from the culture that you set up in the team. So, how do you develop that culture? If it’s a culture of growth, then definitely it’s gonna set in. For example, I’ve never been in a situation like the one that you’re describing, where I actually had to push someone at that level to do something and feeling like I’m not being heard. And so, at least in the companies that I’ve been there was a default expectation of constant growth. Not even that, but people were very aware of the value that personal growth brings. They all wanted to grow. So, coming back to your question, I think what’s important and what tools you have as a leader is to identify people’s motivation.
So, it might not be growth in certain tech skills, but it might be going to the next level in their career and for that, it’s your role to point out, “Okay, in order to get there, you need to develop these skills.” or “You need to get better in this specific area”. And that’s basically you connecting the needs of growth with their personal motivations. I think that’s where the key is.
It’s not about making people do something, but it’s about working with them, understanding where to find that middle ground, in order to align. Like, the needs of the company or growth with their personal motivations. I think that’s definitely something that can happen. And, I’ve seen it happen by using different tools.
Kshitij Mohan: Sure. I think you mentioned a very critical aspect, identifying their motivations. And, this is where I think most of the managers or leaders fail. Especially, while being a new manager or a leader. We are all in that black box and we don’t know how to actually proceed with this process.
Any specific thoughts around how do you actually achieve them in a practical sense?
Anemari Fiser: So, how do you get to actually understand people’s motivation, is that the question?
Kshitij Mohan: Exactly.
Anemari Fiser: I think first, you have to show real interest and curiosity about their day-to-day, the things that they care about, like, “Okay, tell me what motivates you?” that’s a fair question, right? And it can get you something, but it’s definitely not going to give you the information that you need in order to move them forward. And so, I think it’s one of those situations that takes a little bit of time and the main part that it requires is for you to build trust with those people.
So, I think the best way to build trust in my opinion, is to have those 1-on-1s where you build rapport and you build a relationship with that person. So, before you get into the motivation, it’s a matter of getting to a point with that person where they can trust you enough to share with you. There are struggles, what they care about, where do they want to go, and also understand that you can help them, right?
So, I think that the key part is when you show them that you can find opportunities that you can delegate things to them, that can help them go in the direction they want to go. That all only makes it easier for them to come to you, instead of you kind of trying to drag the information out of it. So, once you have that trust, you don’t have to do that much work, because people will come to you.
Kshitij Mohan: I think it makes sense. So, basically again, everything comes down to the right setting of trust, the culture that you are setting out in these conversations, right?
Anemari Fiser: Exactly.
Kshitij Mohan: And, talking about these conversations, It’s easier said than done, right? When you talk about these 1-on-1s, these conversations, the critical aspect of this entire growth is this constructive feedback that you just talked about. Let’s talk about what I need, what I don’t, what do you think I need to grow on?
And, this has to be on some levels of trust, as you mentioned. And still, in general, we are also skeptical to give feedback, receive feedback, while we know how critical it is. How do you cater to this in this entire coaching process that you do? How do you ensure that the right practices and processes are being set around this?
Anemari Fiser: I do agree with you that if you set up a culture where feedback naturally develops, then you have a base for all of this. And so, how do you ensure that? Well, first it comes back to that trust, to that psychological safety that I was mentioning before. I think once you have the trust in the team, a correct culture, or the culture that you want is gonna naturally develop. Now, in order to do that, I think there are simple tricks. Like, you can just make it part of the expectations that feedback happens. So, that means creating the opportunities for that to happen.
There was this thing that we used to do in one of my previous teams, they were called ‘speedbacks’. So, basically you would put people together, the whole team. Each pair would have like five minutes where they would have to say three things that you are doing well and three things that you have to improve. There wasn’t any follow up conversation. At that point, it was just a quick thing. Now, the idea of that was to trigger conversations after. So, there was no value in it in just throwing some things at people, but it was about triggering them to go after and talk between themselves on examples and how to take it further from that point. So, that’s one thing.
Second, it’s about showing the value that it takes to do that. So, one thing that I used to do before these speedbacks was to block half an hour in everyone’s calendar to make sure everybody has time to prepare for that. So again, it’s not something that you do in-between or in breaks or whatever. It’s something that you actually have to put effort on. So, giving people the opportunity to do that and actually saving time shows them how valuable it is.
And last, but not the least, the best tool any leader has in order to create the culture, in this case, the feedback culture that they want, it’s them, by acting as an example. If you provide people useful feedback, if you put effort in it, if you react to it when they give it to you in the correct way, then I believe and I’ve seen it, that is going to have the biggest effect. So, it’s about you acting in the way that you expect them to act and them seeing the value of that. I mean, you’re the one that has the tool, that you have the most control over. So, I think change happens one person at a time. So, that’s how you basically start to move things around.
Kshitij Mohan: Sure, great point. And, just to add onto this, while doing all these sessions with engineers, leaders, what’s that common mistakes that you feel, “Hey, we generally tend to make, where we are able to go beyond these blockers in order to unlock”, right? As you mentioned, your biggest tool is, us.
Where do we lack on in understanding this aspect?
Anemari Fiser: So, first thing and one of the main mistakes I’ve seen, it’s not even having the 1-on-1s. I’ve seen a lot of leaders that don’t see any value in the 1-on-1s. The reason for that is because they don’t do it right. The problem is not with the 1-on-1s, it’s how they do it. So, I think they expect people to kind of just see that as an opportunity and take it. That doesn’t happen. You have to show people what is the value in them. You have to show them consistently and explaining to them, and helping them understand that that’s for them and how it can move them forward.
And so, I think one main thing coming back to your question is not even having 1-on-1s, deprioritizing them, which I think is worse than not having them in the first place. When you have that call with your tech lead, scheduled every week, and it keeps getting moved around. For me, that’s the clear sign that whatever you’re doing, it’s more important than talking to me, right? That’s definitely a message you don’t want to give people. So, that’s one mistake.
Second, it’s about prioritizing results over people. So, it’s more keeping your eyes on “What is it that we have to deliver?” “When do we have to deliver?” “What’s happening?”, instead of trying to actually understand, ‘Why are people struggling with this?” “Why are we taking so long?” like, kind of doing that switch between “Why is the system not working?” to “Why us as a team, allow the system to keep working like this in this not desired state?”. So, this is the second mistake that I’ve seen.
Kshitij Mohan: I think keeping results above people. I think that’s a great point that you mentioned, Ane. I think, totally aligns to what I think every leader or manager should be thinking about. In the end, it’s the team that drives those results and not the other way around, right?
Anemari Fiser: If you have a happy team, results just happen.
Kshitij Mohan: Definitely. Now, so just coming to the last part, which you have personally experienced, and you talk a lot about is this entire burnout and well-being part. As a leader, as a manager, as a coach, you must have had so many experiences around identification, firstly, of, “Hey, this is the wrong stage here where you are at.”, and then helping them to overcome that part in some way or the other. Any specific instances or any specific experiences that you can share with us around this piece?
Anemari Fiser: I guess it’s about you as a leader, identifying when someone in your team is struggling and helping them deal with that.
Kshitij Mohan: And the other way around as well, right? Some key advice, insights for every developer should also be a part of it, right? I also need to be aware of what’s happening with me as an individual and then kind of driving those conversations most of the time. So, would love to understand these spectrums.
Anemari Fiser: Yes. Okay, thank you for clarifying that. So I think, first it’s about self-awareness. Identifying whatever individual that is struggling, it’s about identifying that in that point, you are struggling. Now, that self-awareness can come from different sides. It can come from you, like feeling like you’re getting close to burnout, feeling like you’re not well.
Second, it can come from the outside. And, this is where the leader can play a good role. If you’re noticing that someone is struggling, tell them, “Hey, I’ve seen you’ve been working over hours.” ” Is there something?” “What’s happening?” “How are you managing all of this overwork?” “How does it affect you, the fact that we have this big deadline?”.
So, it comes from both sides. You can be self-aware or people can make you aware that you’re struggling. Sometimes, we don’t see it. It’s just that. Third, even if people are not telling you, you can actually ask for feedback. For example, for me, a good awareness when someone in my team goes, “Hey, I feel like you’re not doing well.” they just told me that, right? Like, I feel, “Are you okay?”. Someone just asking you, “Are you okay?”, it’s a sign that something is not right. So, I think it’s about whoever comes to you and asks you, “Are you okay?”, I think that’s a sign for you to start asking, “Why are you asking me this?” “Is there something that is showing you that I’m not okay?” so, I think it’s about just paying attention to what people are telling you and what’s happening with you and with people around you to understand if you’re in a good state or not, and taking action, right?
And the best way to do that, it’s reflection. So, if you want to develop self-awareness, or if you want to understand where you are, or how people feel around you, it’s reflection. That means just taking a moment out of your very busy life and week and understanding, “Hey, what have I been doing?” “How am I feeling?”. Getting some feedback of people around you to see if it’s aligned with the signs you’re giving out. I think that’s the best indicative to understand where we are and then taking action. I think that’s a different point because once you get aware, you can take action. The simplest thing is just making people aware around you that you’re struggling. Even as a leader, I did this. I went to my team and I said, “Look, I just need help.” it’s as simple as that. So it’s kind of working from that point. One word, and being vulnerable. So, one thing that I’ve noticed is that it’s magic.
When you show vulnerability, something happens. Even the people, their first instinct is like, “Oh, what’s happening?” “Why is she telling us this?” but then over time, they start sharing also. So, I don’t know, I feel this for me, has been a magic tool. The more you share, the more people share. I think that’s the place where you want to be as an individual, as a leader. And that’s where the solutions are.
Kshitij Mohan: Definitely, this was so insightful. I think you touched on very core principles – self-awareness, reflection, and being vulnerable. And, this is what I think most of the leaders we have heard talk about, and it’s just about how you start reinforcing them in your everyday of work and talking more and more about it.
And that’s how you guys are trying to build a community around it as well. So, thank you so much, Ane. I think this was really wonderful. We were really impressed by the kind of experience and wisdom that you’ve shared with us, with our all viewers.
Thank you for being on the show, Ane. This was really great, thank you.
Anemari Fiser: Thank you for the invite, it was a pleasure. Nice meeting you both. Have a great day!
And, thank you again for the invite. It was a pleasure being here.
In the recent episode of ‘Beyond the Code’, our new host Kovid Batra welcomes Mihai Valentin who thrives in various roles i.e. mentor, tech lead, principal engineer, and author of the newsletter “How Did I Get Here?”. He has previously contributed to reputed organizations such as Meta, Datadog, Adobe, and more. Their conversation revolves around building your own tech vs. leveraging third-party solutions.
The episode begins with a fun fireside chat during which Mihai shares his personal favorites and the guiding principles that shape his life. Afterward, he delves into the challenges he encountered while leading teams and provides insights into how he tackled them. He then takes a deeper dive into the scenarios where the choice between building own tech or leveraging third party solutions becomes pivotal as well as maintaining a balance between addressing technical debt and keeping pace with the fast-paced tech world.
Wrapping up, Mihai provides an intriguing glimpse into the inspiration behind naming his newsletter, "How Did I Get Here?".
Kovid Batra: Hi everyone. This is Kovid, Kovid with a K, your host for another show of Beyond the Code by Typo. And I'm today really excited to have Mihai on our show, who is a very humble, very renowned newsletter writer and author of the book, and really loves to give back to the community. He has had 15 years of software experience in leadership, leading tech teams. And he has worked with organizations like Facebook, Datadog, and whatnot. And right now, he's a mentor, he's a contractor with an MNC. Over to you, Mihai. Really happy and excited to have you on the show.
Mihai Valentin: Hi, Kovid. Thanks for the introduction.
Thanks for hosting me on this podcast. I'm really happy to be here. And a big hello to all your viewers.
Kovid Batra: Thanks a lot, Mihai. Thanks for taking out time for us. So, you have come to the show for the first time. I'll quickly tell you about the format. So we are going to have a quick fireside chat. wherein we love to know about Mihai personally and other aspects other than work. So there will be quick two to three questions that we're going to ask here, and then we will move to the main section where we will be understanding how to lead tech teams better, and then we'll have that section for around four or five questions.
Is that cool?
Mihai Valentin: Yeah, absolutely. Let's get going.
Kovid Batra: Great. Great. So Mihai the first question from the fireside? Which is your first tech gadget that you ever owned?
Mihai Valentin: Oh, that's a good question. So let's go a bit back down the memory lane in my childhood. I got my first ZX 80 computer. It was one of those computers that didn't have a screen So you'd need to connect it to your TV set and you would connect it to a cassette player as well because you would use audio cassettes to load and save programs or games. And whenever you would load stuff or save stuff, it would make this noise like kind of the dial up noises from the 2000s, but like 10 years earlier. So that was an amazing gadget because that's how I learned to program at first. So the ZX80 had BASIC as a programming language. It was a very simple language comparing to what we had today, but nonetheless amazing for being able to learn as a first programming language.
Kovid Batra: Perfect. Perfect. That was unique actually. I haven't spoken to someone who has had that gadget ever. Great. So your love for tech has been like from your childhood itself then, right?
Mihai Valentin: Exactly. Like when I got this computer, I was spending most of my day in front of this computer. But I think it definitely paid off because that helped me learn programming and then that basically started my tech career.
Kovid Batra: Great. Okay. All right. Moving on to the next one. What kind of a person you are, like, are you an early adopter of things? Or you really love to wait and see if things are proven and then you try your hands on that. What kind of mindset do you have?
Mihai Valentin: So I'm always aware of what's new. So in our industry, all the time there's going to be a new technology, a new version of technology and so on. I'm trying to keep up as much as I can with what's happening. However, when it comes to actual implementation, I'm a wait and see person. However, the way I think about technology Is I don't look that much into the hype, right? Because if you look at every technology at their marketing page, you will see a lot of hype. And sometimes a lot of technologies are marketed as if they solve all the problems in the world. That's not actually the case, right? Because in the end, they're just here for solving a specific business problem. So this is more like a rule of thumb of how to judge a technology is what is possible now using this technology, but it was not possible before. So I'm trying to understand the reason behind this technology existing. And if this reason is clear enough, or if this reason gives me a definitive reason for adopting it right now, I will adopt it. But in most of the cases, I don't adopt it right away. I wait and see and I go with something that's fairly known. And this might also be the case because I've been working in large and very large companies. So, adopting new technology right off the bat can also pose a risk for stability, for governance, for security and for other things. But being aware, I think it's super important because if you are aware, then you can, you can adopt, but if you are not aware, then you won't be able to, to adopt it.
Kovid Batra: Correct, correct! So I think it's, it's more like that you analyze and research at your own level. And if the problem, which the technology solves is pressing enough for you, you give it a early try. And if it is not, of course you are a late adopter for things.
Mihai Valentin: Yeah. Yeah. Of course. Yeah.
Kovid Batra: Love that mindset. Great, Mihai.
I'll move on to the next question. This is a funny one. Which is your most used keyboard shortcut?
Mihai Valentin: Hmm, okay. I would make a joke like maybe 10 or 15 years ago, it would be control+C, control+V for copying and paste code. But that is no longer the case. The most used key that I have today is command+shift+F. I find and search a lot. And the reason for that is in any tech organizations I work with, I don't work on a specific project. I work across the whole business, so this requires me to have an end-to-end understanding of all the moving parts of all the services of how data flows and so on. So most of the times I find myself going from repository to repository from understanding how data gets from here to there, where is something used, how many times is it used, where is it used from, so that requires an extensive search. So I'm searching and reading a lot of code on a daily basis to understand how things are going.
Kovid Batra: Great. I thought when you said earlier, 15 years back, it was controls+C, control+V and now it's not there. I thought you were going to say chat GPT or something like now I don't code. I asked chat GPT. What's the code?
Mihai Valentin: No, chat GPT is super, super useful, but you need to give it a lot of context if you want for the answers to be really helpful, because if you don't know what you're asking, then yeah.
Kovid Batra: Great. And I think we'll move to the last question of our fireside chat. Which is your favorite mantra that you live by?
Mihai Valentin: Okay. So, my favorite mantra that I live by is a combination between life and career. And I would call it something like live your best life so you can do your best work. And the reason I live by this mantra and it's always on the back of my mind is because I met so many people who unfortunately postpone living their best life until they get to retirement. And they are hoping for one day they say, like one day I'm going to live in that beautiful place. One day I'm going to do what I want to do. And the truth is that you can actually enjoy life while working eight or nine hours per day if you live in a place you love and if you have a role that you love and for some people, sometimes this seems hard to grasp because it seems complex, but all you need is a remote role. You need a Airbnb in a place you love, and then you just work during the day and then enjoy your evenings, enjoy your weekends. And if you do this for a couple of weeks in places you've always wanted to visit, this should be extremely beneficial for you. And you'll see that the quality of life will increase and then also how you see work and how you see the future will definitely change.
So, yeah, live your best life so you can do your best work.
Kovid Batra: No, I totally relate to this and it takes years for people to actually to arrive at this position. So, like Einstein used to say people know things, people understand things, but believing in them and living by them is something that really takes time. So, I'm really happy to hear that, that you believe in this, and I'm sure you're living your life like this. Would love to give this thought to everyone in the world and not just dev teams but everyone because this is the crux of life according to me also. Great. Mihai. I think we'll move on to the main section and main section is all about leading dev teams and today we'll be specifically talking about your area of expertise, your area of interest, which is more around whether you should build or you should like buy, making a decision there so that you can reduce cost, improve the time to market, do all those things. And a lot of engineering leads, engineering managers, find it tough to make that call. But before we jump onto that area of expertise, I just wanted to understand a few things from you. You have been working with companies like Meta, Datadog, and you are currently working as a mentor and contractor with MNCs. There have been a lot of challenges which you would've faced while leading these teams, right? Can you just bring up certain experiences of yours, like one or two, which would be really helpful for other people to learn from you because every time you come across a challenge, you solve it. And when you look at it in retrospect, you have a good perspective on how actually that problem could have been solved. And in fact, in that situation, you would have done extraordinarily well. So any of those examples would really, really help our audience to understand how to actually lead teams like pros.
Mihai Valentin: Yeah, definitely. So one thing I've seen how it works and how it fails. Because if you want to understand, how to do something, you need to see it working, and you also need to see it failing. So only after you see both sides, you know, what would be the best way to do it. So one such thing is consistency. So for example, if you as a small company, let's say of 20 to 50 engineers, if you build your tech organization in a consistent way, then you would be able to ship faster. You will not have to waste so much budget on operational tasks and so on. And what I say by consistency is using a single stack, for example. Unfortunately, there are so many companies that use, let's say, react and javaScript for the front end, then they do some Python and maybe some go on the back end and then they make a microservice in rust and then they use some other language for some other microservice. And the truth is it can be exciting. Like it is exciting for engineers to build all these new services in all these technologies. But then when they need to manage when they need to be fast in them, they will not be able to do it because first, it's very hard to move one engineer from a team to another to be able to help because they know different languages and different tech stacks. Second, there's always going to be some corner cases or very weird bugs in each of the tech stacks. So if you have three or four tech stacks, you're going to have three times more, weird bugs or situations that require debugging and lose time. And down the road, like immediately you won't notice it. But down the road, it's going to be so slow because you're not working as a single team. You're working as three or four or five different teams that are trying to solve a problem. So what I've seen works incredibly well is using a single tech stack, meaning here javascript or typescript depends of how you prefer. I personally prefer typescript and then use it for the back end. Use it for the front end and then also if you're a company has a mobile app, use it for your mobile apps, and then you'd be able to build in an Android and build in an iOS. So it's one technology that you need to know, one build system, one test system, one knowledge of corner cases, like understanding what are the subtleties of the language. Um, and once you do that, you can move your whole company with the same speed. Otherwise, you would every time need to go from one thing to another. And the speed at which you develop will not be the same. And one other thing that I love about this approach is that you can do a lot of code sharing. So if you have code that's in multiple languages, it's going to be very hard to reuse a part of functionality from the back end to the front end and vice versa. So for example, validation, right, you do validation on the front end, but you also need to do it on the back end for security, of course. So in case you don't use the same language, you'd need to write the code once in JavaScript, and then once in Go or Python or Rust or whatever. But then if you have a single language, you write it once, And then you import it in front end and you import it in back end. And validation is not the only thing. It can be any sort of business logic that can help you.
Kovid Batra: Great. this is interesting. Just a quick follow-up question on this. Most of the times, when you are in a situation, you have to take a call, you choose a stack and you start working on that, right? You're saying that we should have a consistency here to have speed to not waste time on fixing bugs or catching corner cases for each of those stacks. So what do you think motivates the people to take the wrong step at the very initial stage itself? Like, can we inhibit that itself? Any thoughts on that?
Mihai Valentin: Yeah. So I believe it all starts from the engineering maturity. So the more mature an engineer is, the more their focus will be towards solving problems and less towards a given technology. So it this is kind of normal, because at the early phases of their careers, engineers are super excited to learn, to grow, to see how various languages work, like to see, oh, how is Go working, how is rust going? And it's totally fine. Like all these languages have their use cases, but unless you're using them for their strength, for their specific use cases, like for example, for high concurrency, which could be Go or like for high performance, which could be rust, for example, or for Python, which is fast development and also a bit into this whole data science, machine learning and so on, unless you're using them for the strength, then it might be better to actually use something like TypeScript, which is more like a general language that you can do a lot of things, even though you can do something like very specific, like I said earlier. And one way to prevent developers from going down this route of adding technology after technology in the team is to make sure you hire mature engineers and that you always talk to engineers about the fact that it's the results that we ship that pays our salaries and the customers don't care so much about whether you're using this technology or the other one, but they care about results. And the fastest we can go to get to those results, the better for us, the better for the team and for our iteration speed.
Kovid Batra: Perfect. I think that really helps in understanding how we can actually avoid this problem. They should be mature engineers. mature leadership who is taking call on that stack at least. And of course, learning is one good aspect, which engineers should be enthusiastic about, but it should be put right. Not at the cost of company's velocity.
Mihai Valentin: Exactly, exactly! Yeah.
Kovid Batra: Coming to this point of velocity getting impacted. This is a very important metric for every engineering team. How fast teams are moving, where are the blockers? So from your experience, as you said, that having a consistent tool stack solves this problem and of course impacts the velocity of the team positively. How in the initial phase itself, you are able to identify that, okay, teams are moving slow and this is the root cause. I just want to understand, like if this problem exists in a big team, how would you realize, let's say you come from outside the system. And now you see teams are moving slow or what is that indicator that tells you, okay, this is the problem.
Mihai Valentin: Okay, that's a very good question and I've been doing this many many times. So first I try to talk with engineers on the team. I try to grab them, have a coffee with them maybe, a very informal chat and trying to understand how they work, what they have achieved so far. And what they feel is currently blocking them. So this is the first thing to get the perception because sometimes perception is different than reality. But in order to make these two converge, I need to understand both point of views. So after talking to engineers and figuring out what's slowing them down or how their process looks like, I spend a bit of time seeing how the normal development workflow takes place. And one place I clearly look at is a PRs and code review because in some companies, code review takes so much time to complete. And for example, for a very small PR, there is a lot of back and forth comments. And, while this is extremely useful for the code quality, if that company is growing and it's very likely to rewrite that code in three months or so. Then it wouldn't matter so much if people are going above and beyond to make a perfect code review for that PR. As I said, I'm trying to look at metrics, like how much does it take a PR to get landed? How many comments usually take, like how detailed are these comments? Do people want to solve all the existing problems or people are just looking for things that would, I don't know, break or cause an issue in production if landed? then I also look at the pragmatism and the focus of engineers, like are the engineers talking about what to build? Or are they more talking about how they build it? Do they know the requirements? Do they know how their company makes money? Do they know what's the biggest cost of their company? So this again comes into the maturity of engineers, because the more mature an engineer is, the more they understand that It's the results that we ship that pays our salaries at the end of the month and not that the technology, the 100 comments on PRs and, and other things that really matter in this picture.
Kovid Batra: Great, Mihai. Thanks for this. We'll move on to the next question, which is interesting to you, to me and I think for our audience also. It is about building versus leveraging existing technologies. And it's a very hard call to take when you are on the go, you need to deliver fast, you need to take care of the technical debt and long term shots also. So how do you take that call in which situation it is good to build in which situation it is good to leverage an existing technology. Throw some light on that and give us some great examples like the previous one. I think people would be able to relate it better.
Mihai Valentin: Yeah. Yeah. Okay. So whenever I have to take these decision and I've had to take the decision many, many times, I always look at two things.I look at the cost and the time to market, like these are the only variables that matter in this equation. Nothing else like things like feelings, things like emotions over a given technology. Okay, they might bring up some discussions, but they are not actually, real data. And, for this costs and time to market, there's also another dimension, which a lot of the people don't look into is the first order costs. And the second order cost. So, for example, the first order cost is I decide to build from scratch, and I know it's going to take me three months, and I'm okay, this is the time. But if then it takes me two people, two engineers to maintain the solution every month, this can quickly add up to the cost. And this usually is a second order cost that people don't see it. So it's very rare that you can just build something, keep it in place, And require no maintenance, no bug fixes, no further developments and so on. So, that's something I really look into. Then, I usually go for a building or using a third party integration in case, the available SAAS's are extremely expensive or if they pose a vendor lock-in risk and there are no alternatives that would be easy to replace down the line. So for example, if there are two SAASs and they have similar APIs or similar ways of functioning, then I don't see this as a vendor lock-in risk because you can go from one to another fairly easy. But if they're not, then it's a bit risky to have the whole business rely on a single SAAS.
And on top of that here, coming more from the development point of view, every SAAS I integrated with, I don't integrate with it directly. I make an intermediary service, which is like a proxy, so to say, so that, the application communicates with that service using a very clearly defined protocol. And that service communicates to the SAAS through an API so that when I change the SAAS I don't need to change my application. I just change the service in the middle to know how to work with a different SAAS. So in this way, if my SAAS is being used from, let's say, 10 places throughout my code base and, requires some changes, then I just change in one place instead of changing in many other places.
So this is a very useful tip for development. Now I do also look into building or third party whenever what needs to be done is a strategic decision for the company. So for example, if a service is of strategic importance and we know that we're going to use it for the next, I don't know, 10 years or so, because it's like Core business functionality, then it might make more sense to build it because then you can build exactly the features that you want to have rather than try to adapt a SAAS, which is not going to have all the features you might want. And it's also going to be difficult to negotiate with a SAAS company to add various features that you might need because they need to serve hundreds or thousands of clients and not just you.
Kovid Batra: That makes a lot of sense. Great. I think, moving on to the next question, which is about moving fast. So moving fast is very crucial in this tech world and it also sometimes lead to technical debt, right? So what's your approach towards maintaining this momentum and managing the technical debt alongside that? How do you usually take a call on that?
Mihai Valentin: Oh, that's a good question. So technical debt, all these things are always correlated with the maturity of engineers. So I see technical debt as good technical debt and bad technical debt.
So it's like in finance, you can get a mortgage to buy a house, which is a responsible thing to do. But if you get the mortgage for consumer, which is of a higher rate, that's not ideal to do. And by splitting this technical debt into two things, like good technical debt and bad technical debt. I see the good technical debt as a way to move faster for shorter amounts of time. And for example, If you're applying this rule for a small company and, you need to release things very fast, then that code will definitely be refactor or rewritten completely in a few weeks or in a few months as you grow. So then you need to move there as fast as you can. Even if you add a bit of technical debt because at the end you just delete the code and rewrite it again for the next phase of growth, because usually as you grow in terms of scale, let's say 10 X to 1000 X, it's not going to be the same code. Because it's not going to be the same scale because things change and it's natural to change. So if you spend so much time crafting this code in a perfect way, then you spend a lot of time and then you just deleted that entirely. The debt will simply disappear when you rewrite the code. And then I keep mentioning this, but the more senior the engineers, the less technical debt will produce because what is the technical debt is a way to cut corners to achieve something fast and good, but if you are a senior engineer, you will not do a horrible hack. You will just do something that helps you move forward with a little expense. And if you understand what can break there? What are the limitations of what you did? Then that's absolutely fine. So it's okay to create technical debt, as long as you know what you are doing. You know how things are fail, you are okay with them failing at some point and you have a process in place to mitigate or to fix it. I noticed that also a lot of technical depth gets created when Teams and engineers aren't able to take decisions. So, for example, let's say an engineer works at a feature and the communication in the team is not perfect. And then the one engineer needs to take a decision. And if that decision is not the right one, that can create technical debt. However, if the whole team works together and is able to take very quick decisions on a certain topic, then technical debt is less likely to happen. Why? Because, think about it, you need to implement a given feature, and if you are able to let's say, write on Slack, make a poll, say, here's our context, here's our problem, here are the three solutions I propose for fixing this. Hey folks, please vote until, let's say 3 PM. So you give people time to choose and if they haven't choose, you go with whatever choice you prefer. And then if the culture in your team is to tackle these things immediately, to vote, to express opinions and so on, it's very less likely to end up in a situation where you create technical debt. So taking quick decisions together as a team reduce technical debt.
Kovid Batra: Makes sense. I'll not take much time on this, but just because I found it very interesting. Let's say I'm a junior developer and I'm working on a problem. I am sure to make certain mistakes, which could be from the scale of horrible to be okay with them. With every junior developer in the team, how will you ensure that whether they're writing the code piece right or not? Of course, code reviews are one good way of going about it. But when you say that teams should be looking at it together, and these are the solutions which would propose to avoid such technical debt. What should be done for the junior developers who are working, how their code should be reviewed, how they should be looked into so that they don't create that problem.
Mihai Valentin: Okay, that's a very good question. So I think, you need to treat juniors, not as juniors, but as people who will at some point be mid level developers, senior engineers, and even higher. And why I'm saying this is that instead of just giving a task with very brief specification, you would need to give a bit of context. Why are we doing something? How did we solve this in the past? So help juniors to make the right choice. Don't leave juniors isolated. Don't leave juniors without, let's say a mentor or without a buddy. Keep juniors in the loop with the whole team. Of course, as you said, code review is a very important step because when the juniors will put up a PR, everyone will come to review. And also here's a very important thing, not to do critical review. So don't say this is bad, this is wrong. Because you will demotivate the person. And, if you do this, you're lacking self-awareness that you've been in their shoes at some point, not long ago, most of the time. Exactly. But then help them and try to feel them welcome to ask questions because if they are not feeling welcome to ask questions, they will not ask questions and they will be afraid of doing this, and maybe they will take some decisions which can hurt the team. So, the most important thing here is to acknowledge that juniors are juniors. Juniors need help for development, for learning. And it's your responsibility as a team or as a senior engineer to make sure that they are growing a bit. Because the seniors today will be the senior software engineers of tomorrow. So, there no other way it's going to happen anyway, but at least make it happen in a way that everyone benefits from it. The junior engineer, the company, the team, everyone.
Kovid Batra: Yeah. I think this is a good way to go about it.
We should just always keep the junior developers also in the loop in terms of the context, in terms of taking decisions. And of course, reviewing is one good way of going about it, but assigning a buddy or a mentor would really, really help. Great. Mihai great thoughts. I know you are leading the best team. And people in your team would be happy. So I think, the last thing that I just want to know, the name of your newsletter- "How did I get here?" So what's the reason for putting out this name? It's a very interesting one. I have recently subscribed to it and I'm loving reading it. So what do you have to say about it?
Mihai Valentin: Thank you. Thank you. I started writing on LinkedIn for the past one year and a half, I guess. And initially I started writing like once per week and then I ramped up to write many times per week. And as I wrote, as my audience grew, people came to me, messaged me and told me, Wow, Mihai, you have such a, such an impressive profile and CV. And I'm like, No I mean, everyone that puts in the work, everyone that takes the right steps, everyone that's open-minded and wants to get things done, will be able to, to get in these companies to get this experience. And so on. It just takes the work. So then I thought, what if I instead of just talking about what I know, I'm talking about, how did I come to know the things that I know and how my mindset go to be the mindset that I have today? So then I thought, it doesn't make much sense if I just throw things like out from a position of someone who has a lot of years of experience, but then show what were the steps, like what were some key moments of my career in which I learned something that has made me challenge my assumptions and drove me further up the growth slope. So I called it, how did I get here? Because I'm interested in sharing not only what I know now, but also what were the steps that I took to, to get here and not only the steps, right? Because the steps are fairly easy, right? Like you interview, you get into Facebook, then you interview, get into another company, and so on. But no, What was the toughest thing when interviewing? How did I view interviewing before or after? What was my biggest fear? How did I overcome it? Who did I learn from? What did I read? So all these things that create a context around what happened rather than just saying it happened. Right?
Kovid Batra: Makes sense. Interesting. That brings us to the end of the show. It was a really nice talk and would love to have you again.
Mihai Valentin: Likewise. Kovid. I really enjoyed talking to you and looking forward to talk to you again.
In the recent episode of ‘Beyond the Code’, Host Kshitij Mohan, founder of Typo, engages in a thought-provoking discussion with Jordan Cutler, Senior frontend engineer at Qualified. He has also contributed his expertise to reputed companies such as Twitter, Dolomite, and Gusto. The heart of their conversation revolves around Metrics, strategies, and burnout prevention for tech teams.
The episode kicks off with Jordan recounting his inspiring journey, followed by a fun fireside chat. Following that, he imparts valuable wisdom on achieving a balance between team dynamics and leadership roles as a senior engineer. He delves into the effective utilization of metrics and new tech tools along with addressing the critical issue of developer burnout.
Wrapping up, Jordan leaves the viewers with valuable advice on continuous learning and nurturing personal growth.
Kshitij Mohan: Hello everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by Typo. Today’s guest is a young gun of the engineering ecosystem. Within a short span of eight plus years, he has evolved from being a software developer to an engineering coach, to an author of a newsletter. He has worked with teams at Twitter, dolomite, Gusto, and so on.
Please welcome Jordan to the show. Hey, Jordan.
Jordan Cutler: Hey, how’s it going? Super happy to be here.
Kshitij Mohan: Thank you so much for sharing your time with us. Means a lot.
Jordan Cutler: Yeah, thanks. I’m super excited to chat more and get this going.
Kshitij Mohan: Definitely Jordan. I think before we start with anything, right? First, we would love to understand your amazing journey, right? And the kind of mission that you are on today to help fellow engineers achieve their career goals faster. I think this is really interesting. So to begin with, please share some light on the journey that you have been on, Jordan.
Jordan Cutler: Yeah, totally. So I started off interning at Twitter. At the same time, I was actually working at Dolomite, which is like a crypto startup by a couple alumni at the same university that I went to. So I was kind of working two jobs. That’s kind of what helped me like catapult a little bit, to be honest. But I wouldn’t recommend anyone to do it. It definitely like got me to the point of burnout. But it definitely also helped me get a really good start to my career. Know a lot. I got kind of the mixed bag of experiences between working at a well-established company Twitter.
And then having no code at all and going from no code to 80,000 lines of code and mentoring the other engineers on the team. And when I started at Gusto, it was a really awesome experience because it was kind of in the middle ground. So I kind of have like this very wide, you know, range of like small, middle, large, and Gusto was super awesome too. It was like a startup within a startup was the team that I was on. It was like a financial products team that essentially helped people, get access to their paycheck before their normal payday, their biweekly payday so they could get their paycheck a week in advance.
And it helps people in like, you have a car breakdown, get in a hospital situation and a lot of people live paycheck to paycheck. So, it was like an entirely new product we were working on. So it was almost like a startup with the security of a bigger company behind you.
Kshitij Mohan: Yeah
Jordan Cutler: So it was really awesome, man. And I loved the experience there. That’s how I ended up getting to the senior level pretty quickly. I got back-to-back promotions up to senior and then now I’m working at Qualified and I’m here doing mostly like front end development, infrastructure, platform platform-related work. And it’s just been awesome. So that’s kind of the journey.
Kshitij Mohan: Awesome. And how did you land on to this thought of running your own newsletter, supporting other folks in the career journey? This is a really interesting part that we’d love to know about.
Jordan Cutler: Yeah, a hundred percent man. I think what happened was at Gusto, I did this thing where I gave a lot of the advice that I give on LinkedIn, but in Slack, and it kind of blew up into like this channel that was just kind of typing notes out to myself, like writing my learnings and it got to the point where I think there was like 60 people in the channel and I wasn’t really like advertising it that much or anything. And I was like, oh my gosh, people actually really enjoy some of this stuff. And so I think eventually I thought, wait, what if I like put this out there into the world? And I just started with like one LinkedIn post. It did pretty well, and I was like, wait, let me just keep this going. And so kept on going and then eventually turned it into a newsletter. And now, yeah, we’re up to 7,500 subscribers. I think like 25 paid subscribers, which is more than I could ever imagine having got, it’s so awesome. I’m so thankful. And, the LinkedIn growth has been really awesome too.
Kshitij Mohan: Yeah. It looks like your content is read, shared. I think you must be doing something amazing that the community is loving you, Jordan.
Jordan Cutler: Yeah, I appreciate it, man.
Kshitij Mohan: Perfect. So, I think before we get started with anything, I think we would all love to have some quick fun fireside questions with you to know Jordan as a person more. So if you’re ready, let’s get started.
Jordan Cutler: Let’s do it, man.
Kshitij Mohan: Perfect. So question one, Jordan, if you were not a coder, which alternative career path you think you would’ve chosen?
Jordan Cutler: Yeah, this is a good question. I think like a while ago I, it probably would’ve been like accountant or you know, finance or something like that. But I know that’s like a classic answer for engineers to think if I were to go like the more creative, like fun route though, it would probably be like photographer.
I’m definitely like, I love photography. I love getting into taking pictures and taking cool stuff.
Kshitij Mohan: Great. So is it like more of a, a nature photography or some abstract?
Jordan Cutler: I think like just in general. I like taking pictures of animals for sure especially cats. I got like a couple closeups of my outdoor cat the other day, so that was really, really nice.
Kshitij Mohan: Perfect. Question two for you, Jordan. What’s the favorite tech gadget that you use daily?
Jordan Cutler: Okay, so I think for this one I’m gonna give you like, the most unique answer you’re probably ever gonna hear is my blinds. You know the window blinds. I got these automatic blinds where it’s like the smart blinds and they go up and down at sunrise every single day automatically. And I think it’s like the best thing ever. It’s like just totally automated. You don’t need to worry about it. The light is kind of the same every single day.
Kshitij Mohan: Definitely, this is one of the craziest answers, Jordan, that we’ve ever heard. So kudos to you for doing this. Perfect. So last question, right, so about this high growth engineering newsletter that you write, So what’s that one piece of advice that you think every engineer should know in their career progression?
Jordan Cutler: Yeah, definitely. I would say there’s a lot of focus on code. But as you get higher and grow to the more senior levels, you’re gonna see that focusing on code can only get you so far. And it’s really like the relationships and building that strong bond between your teammates and your manager, that is gonna get you further and further. And it’s good to focus on that.
Kshitij Mohan: This totally makes sense. I think it’s always the people skills that take you longer than any other aspect of your work. Perfect. Perfect Jordan. This was cool. So, now getting to the real stuff, right? So just to give you a quick context. So we have been having these, interesting, insightful conversations with a lot of engineer leaders, senior engineers of the ecosystem, but we thought, Hey, how would a perspective of a senior engineer would look like, right? How do they fit in because they are always stacked between the senior leadership and the team that they’re supporting with, and that’s how they’re kind of building the entire ecosystem. So we believe this is the toughest phase of any journey, right? Where you have to balance work, relationships, teams. And I think this is what we would love to more talk about with you today. And I think to begin with, the first aspect comes in how do you build this balance, right? You manage teams as well as you manage the expectations of your leaders as well. So, would love to start with these thoughts, Jordan.
Jordan Cutler: Yeah, definitely. I’m trying to think. One thing that typically comes to mind that a lot of ICs want to get done compared to management is like cleaning up tech debt, right? Management is typically like, Hey, we need this new feature. We need this quickly and all that. And I think a lot of times it can be up to the more senior ICs or tech leads to try to help bridge that communication to help management understand better. You know like, hey, we need to focus on the stability aspect here and one good way to do that is to literally show examples of where the stability has failed and say, like this last feature rollout, it went bad because we didn’t have our stuff together in this area of the code and we had to take shortcuts or, we didn’t do proper testing all that and help them understand a little bit better that like some of these things are gonna take a little bit more time.
Kshitij Mohan: This totally makes sense. I think a very good thought, Jordan, that there is always discussions around tech debt. You would want to, but again, you are pulled back, no, hey, this is what you wanna focus on. And I think talking about this itself, so as you mentioned, right? You would want to show some things to the engineering leadership to believe, Hey, this is where we are at today, right? For example, a feature failure that you mentioned, right? So, in your experience, have you seen using any metrics or any sort of visualization that kind of helps everyone understand- hey, this is where we are at, this is what we need to focus on, any other things that you have used maybe in your experiences so far?
Jordan Cutler: Yeah, yeah, definitely. A couple things that come to mind are one thing we’ve done is track issues in bug snag. So, it’s like a kind of like your standard error reporting tool where you could see how many errors are occurring. And you could point specifically to that. There was one point where I think we were able to show that there was like 5,000 user errors occurring like every month. And you know, show exactly like, hey, these are all the different areas. It’s normally like, you know, because. This stuff is not in TypeScript or we don’t have our proper error-handling patterns in this area. And from that you could say, Hey, we need to focus on this a little bit more. The other thing I like doing too is you could track specific metrics at CI time. So one thing like we’ve done before is track how much of a percentage of the code is in like the new system versus the old system and we could say like, Hey, you could see like this part of the code here is just not entirely this. And for some reason when you put it on a dashboard versus just saying it, it makes it that much more like impactful.
Kshitij Mohan: Exactly. Things does go serious as soon as you put it out on a dashboard.
Jordan Cutler: Exactly. Yeah. So I’d say in short, if you can get it on a dashboard, that’s the ideal situation.
Kshitij Mohan: That’s the idea. Perfect, perfect Jordan! This is great. And while you talk about all this, right, we talked about managing teams. In this aspect, there is a very critical aspect that every devs get kind of very excited about introducing new tech in the team part, right? There is always something or the other evolving, and then there is learning curve also. And then there are expectations of your teams also that, hey, we need to balance this stuff out, right? So any specific thoughts around how do you manage those introduction of new tech in the teams, and how do you generally go about it?
Jordan Cutler: I feel like I’ve had a lot of experience with this ’cause there’s so many different tools. Like, I’m always trying to find that next best thing to try to bring to the team. And that honestly, just taking a side, I would say, Something to be careful of. But also one of the best ways that you could like try to enhance your growth like earlier on, is if you can find ways to take the initiative and level up the team in ways that they didn’t even know that they could, then that that’s gonna be awesome. One thing that I’ve brought to the team at both Gusto and Qualified is like storybook as an example. Storybook is like a tool where you could document like all the existing components, that exist in the front-end app and it helps people see like, oh, this is how you use it. It shows code examples and you could just copy and paste into the code and it just works. And then you can also use it as a prototyping tool. So one thing that I would say whenever you introduce a new thing, try to make it as easy as possible because people don’t like change and try to show the value right away as well. So if you could like, do like a small little prototype, like what I did was I put together a little storybook mini app showed a couple of the code examples that we have existing and showed just like how you can copy and paste and be like, oh, you know, boom, it’s done. And the code, the new component is there and everything is like visible on the left side. And so having that like prototype and easy one command that you just run either to turn it on or run it, is I think like one of the best ways to make things easy. The last thing I would say is just making sure that it’s being communicated in multiple channels. Because if you just do it in one, people are gonna miss it. And even if you do it in multiple, people are still gonna miss it. But at the very least, you tried. Yeah. So not just Slack, but like Slack plus a team meeting, plus your all engineering meeting or documentation and like Confluence or notion or something like that, right?
Kshitij Mohan: I think this is how people evolve also, right? You need to keep on identifying the new ways in order to optimize the entire team structure, and this is what gives you that extra set of learning as well that keeps you ahead of the curve. So I think this totally aligns with it and while talking about this new tech, right? And I’m pretty sure you are right in the midst of everything that’s happening with AI around, the dev productivity, and all right, there are so many tools. I think every day a new tool is being launched today, powered by something or the other to ensure that teams, especially dev teams are being more productive, right? So, Your thoughts on these? Have you been using some? How do you feel what exactly is happening in this ecosystem for the devs?
Jordan Cutler: Yeah. It’s a great question. I am big on AI for sure. At the same time though, I am cautious about introducing so many new tools. I feel like there’s kind of a balance that you need to find between introduction of new tools and the value you’re getting out of it. Because if you have like 20 tools to manage and you’re introducing a new one every day, no way you’re gonna be able to keep up and balance everything. I personally use a co-pilot and Chat GPT the most and I think eventually I’ll probably integrate with maybe Chat GPT plugins or maybe some wrapper around Chat GPT. But I know, like exactly kind of what’s happening under the hood and, I think like copilot is, honestly, it’s been a huge productivity boost for me, for sure.
Kshitij Mohan: What do you like most about the copilot? Right? So what really helps a dev in a GitHub copilot setup?
Jordan Cutler: Copilot is so much fun for testing for sure. Because like what I do is like I’ll name the test. And then I’ll just hit enter and then tab. And then hit enter and then tab and it just keeps on filling in exactly what I would’ve wrote pretty much. So that is pretty fantastic. It just saves me so much time typing and all that. And it just makes us be able to get so much better test coverage because you’re incentivised to just add more. It’s so much easier to do. I think that’s probably one of the biggest things. I think it’ll be interesting how copilot, changes the dynamic for more junior engineers because I do suggest people, like junior engineers use it because it’ll help them understand more of the language features and like what is possible at the same time. Sometimes it does give bad suggestions. So, I think there’s nothing still that like can trade having like that hands-on, like in-person mentor that has like been through it and very experienced type thing.
Kshitij Mohan: Right. So there is always this debate going on, right? And specifically for folks who are just starting off, especially in the dev ecosystem. There is so much on auto mode right now that they might even miss on learning an important aspect of the entire engineering part. Right?
Jordan Cutler: Yeah.
Kshitij Mohan: So I think how will you even ensure that there’s a balance that’s been maintained?
Jordan Cutler: Yeah. One thing is to try to like, from, especially like managers, should try to do like matching as much as possible to ensure that a junior engineer has a mentor that is more senior that they could go to. And then similarly it’s just as important for the senior engineer to find someone to mentor because that’s how they can grow as well. You know, get into the next position, whether it’s, you know, staff or go into management or something like that. And so making sure that they have that support on projects that they’re working on or just in general, having some that, that they can talk to and help learn how to grow and create a growth plan with I think is hugely important.
Kshitij Mohan: Yep. No, no this is really good, Jordan. Now, I think coming to the most important aspect, right, where everything just culminates together is ensuring that as a developer, as a senior engineer, that you feel you are not burning out, right? You are kind of able to balance. Your work, your life, your success goals, everything that comes along. So what’s your take on this here? You must have, you already mentioned that you would have been in that state at some point in time and then you kind of reflect back, Hey, no, no, this is not the state that we should be in. So what’s the developer’s perspective over here?
Jordan Cutler: Yeah. It’s a really good question. I think that you definitely can work a lot and still not burnout. But you have to be very self-aware and you have to understand if the work that you’re doing is draining your energy consistently or if it’s helping you get your energy back because I’m sure you’re aware you’ve been in the industry like there’s certain tasks, right? Nobody wants to do.
Kshitij Mohan: Exactly.
Jordan Cutler: It drains your energy.
Kshitij Mohan: We hate test cases, we hate documentation. We hate the review budget.
Jordan Cutler: Exactly. Yeah. And if you spend, you know, like you’re 60 to 80 hours and you’re overworking yourself doing those types of tasks well yeah! You’re gonna burn out but if you essentially let’s say you do a portion of it and it’s those types of tasks that do drain your energy, but then you do something that you’re super excited about and you have been looking forward to, and your manager allows that space for you to do some of that.
Then that allows you to keep your head up and not burn out and, you know, maintain your energy. So I think it’s kind of about managing your energy more than anything else.
Kshitij Mohan: Oh, got it. I think you have to ensure that your creativity juices also keep flowing along with every other thing that you’re working on.
Jordan Cutler: Exactly. Yeah. And you know, I can also give like some advice like for Managers, and I think like tech leads as well, you know, try and watch out for their ICs burning out. I think one thing is they should make sure that there’s like weekly one-on-ones, or biweekly, probably weekly with your manager and then maybe biweekly with like teammates or something like that. And use that like as a time to catch up, you know, the person that you’re talking to is genuinely being honest with how they’re feeling or what’s going on. Then they’ll tell you like, things are not that great. And you can always start too from like the manager side, you could start with like, Hey, gimme like a score. Red, yellow, green. Where are we at? What do we need to do? Because I think if you start that way, it really shows that you’re caring about what score they give and that’s what the whole meeting is about. The meeting is about making sure that we get you to a green. What do we gotta do to get there? And hopefully, they’ll, you can have a conversation.
Kshitij Mohan: Right? But I believe here, Jordan, it’s very important that the leaders should ensure that basically, they have to show that they are vulnerable as well. And that’s how kind of your developers start opening up, right? Unless and until they don’t see you taking a step forward saying, Hey, I might miss out on few things. Hey, I know things are going hard these days, but okay, let’s just talk about it. I think that’s a very critical aspect that every leader, manager should be first taking out, right?
Jordan Cutler: Yeah, definitely. Some of the times that I’ve opened up the most have been like, after my manager says that they’re not feeling that great. Because it’s hard because sometimes you need to always act as things are good because at the end of the day, your manager is the person that does rate you on a performance scale. And so, if you do come to a every single meeting and you’re saying, well, things aren’t that great, I wouldn’t recommend that to an IC to be a hundred percent honest, you should try and like maybe use your mentor for a little bit more of that and try to figure out how you can not do that with your manager a hundred percent of the time. Definitely should, sometimes for sure. But at the same time, yeah, if your mentor is more vulnerable, then it does open you up to feeling more comfortable doing the same thing.
Kshitij Mohan: Perfect, Jordan. This was great. Any parting thoughts, Jordan? Any key advice that you would like to give our viewers who are watching you, learning from you? Any specific thoughts on anything that you would like to share Jordan?,
Jordan Cutler: Yeah, it definitely sounds kind of cheesy for sure. But, I will say that as we grow, it sometimes we stop focusing on learning, and I think there’s always room to improve no matter what level you’re at. And so just keep that drive going. You know, focus on growth always. There’s always room to improve and if you’re not getting feedback from your manager or your mentor, when you say like, Hey, are, are things going, okay, push harder because like there’s always something that you can like be working toward.
Kshitij Mohan: Beautiful. Keep that hunger alive.
Jordan Cutler: Definitely. Yeah.
Kshitij Mohan: Perfect, Jordan. Thank you so much. This was such a great conversation. Thank you so much for your time today. We’ll definitely see you sometime around again. Thank you.
Jordan Cutler: Yeah, for sure. Thank you so much, Mohan.
In the recent episode of ‘Beyond the Code’, Host Kshitij Mohan engages in an insightful conversation with Richard Donovan, director at RD Coached. The central theme of the discussion revolves around helping leaders and developers balance well-being and success.
The episode starts with Richard recounting his inspirational journey, followed by an engaging fireside chat. Afterward, Richard imparts valuable wisdom on managing the 'Not knowing everything' mindset as a leader and effectively delegating tasks. He takes a deeper plunge into developer mental and physical well-being and the challenges associated with it.Lastly, Richard leaves developers and engineering managers with essential advice to navigate this journey effectively.
Kshitij Mohan: Hello everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by Typo. Today’s guest has had an amazing journey of evolution while being in the software engineering space for more than 22 plus years. Right from being a software developer to a leader, to a mindset coach today.
He has a very unique perspective on helping leaders and developers balance well-being and success. And this is what we would be talking to him today about. Please welcome Richard. Hey, Richard, Welcome to the show.
Richard Donovan: Thanks for having me, guys. Looking forward to it.
Kshitij Mohan: Thank you so much, Richard. This is really great. We are so happy that you could find time for this. So thank you so much for being here. Perfect. I think before we start on anything, Richard, and as I mentioned, we saw a lot of content about you, what you write, what you post. I think we are just so amazed by the kind of journey that you have had. Right? And you talk a lot about mental well-being, emotional well-being, physical health, and while combining all these aspects with the engineering piece as well. So I think. Before we talk about anything, I think we would love to understand and just get a quick glimpse of how your journey has been.
Richard Donovan: Well, it’s been a long journey as you’ve already pointed out, and it’s been an interesting one. So for those that don’t know, I’m a self-taught developer, so I don’t have a degree. I didn’t go to university. In the first job that I had, I was pointed at a stack of books on the shelf and a few people kind of said, “Look, read this one, read this one”. And I took them all in the evenings. I read them. I start to build things and six months later, that company took a chance on me as a junior developer. I did that for a little while, and that company decided to rewrite their entire software suite in the .NET framework, and that was in .NET 1.0 so…
Kshitij Mohan: The beginning of time!
Richard Donovan: I’ve basically been working with .NET since 1.0 and I still work with it now. So it’s been the biggest part of my career. After that I’ve worked in all different levels, I’ve been a junior, I’ve been a mid, I’ve been a senior, I’ve been a manager. I’ve been a software architect. I’ve been a contractor. So I’ve really kind of explored so many perspectives and I suppose one of the things that led me to move into mindset coaching is when I actually reflected on my career. I remember particularly early on being extremely introverted. I hated speaking up in meetings. I hated meeting new people. I used to just get so embarrassed and hot and bothered and all of those things. I didn’t like sharing my ideas in meetings or when we’re estimating. I didn’t really contribute to the conversation. And also, even though that stuff was going on and that was really holding me back, one thing I did always do was fitness. So that’s carried me through when other things were maybe holding me back. So I’ve historically got a lot of confidence from going to the gym and, and my fitness journey.
And then later I started to work on my mindset. I started to realize that it was actually holding me back. And when I started to work on that, I realized that the value that I was bringing to businesses and my role was actually a lot more about me and how I communicated with other people and how I shared my ideas, all these things that I wasn’t doing before, and it was a lot less about the code that I was writing and you can probably imagine that that leads quite nicely into leadership roles when you kind of get that realization that actually it’s you as a person that is the value and not the code. So that’s a kind of a fairly brief summary of a very long journey, shall we say.
Kshitij Mohan: Oh, amazing. Richard. I think that’s definitely inspiring to a lot of us and most of the things I think we all can relate to and so glad that you found your way to keep going, and I think that’s what kind of made you what you are today. So glad to hear this, Richard. Perfect. I think before we get, and I think this is what we are gonna talk about a lot more today evolution in this journey, growing from the starting aspect of NIC to all the way around.
But I think before we do that, Richard, we would love to ask a few quick fireside chat questions that we have for you. Just to add some fun element to your already amazing journey that you’re on, and while on this, what you learned is what you would love to hear. So if you are all set, I’ll just get started with that.
Richard Donovan: Go for it.
Kshitij Mohan: Perfect, Richard. So first question, what’s your most favorite podcast that you listen to these days?
Richard Donovan: I would say the Huberman Lab podcast.
Kshitij Mohan: May we know what was that about, Richard?
Richard Donovan: It’s a guy called Andrew Huberman and he goes into neuroscience of all kinds of topics including sleep, focus, motivation, you name it. He goes into massive detail and into the neuroscience of how the brain works. And it’s quite detailed and, and they’re often quite long episodes, but it’s really, really interesting.
Kshitij Mohan: Perfect. And I think we have found something to share it with everyone after the podcast. So this is something I think then we all should just get hooked to. Perfect. Question two Richard, the best non-tech book that has unexpectedly impacted your coding mindset as well?
Richard Donovan: I would say “Atomic habits”
Kshitij Mohan: Oh, Atomic habits.
Richard Donovan: And it’s not only impacted my coding mindset, but it completely impacted my mindset for life as well. Yeah.
Kshitij Mohan: Oh definitely that’s a great book on building habits, breaking things down and helping you move ahead. Oh, lovely book by the way. Yeah. Perfect. One last thing, Richard, what’s the motto of your life or your entire thought process that you have been working on, and what resonates you today?
Richard Donovan: I think it’s actually, it’s a bit self-indulgent, but it’s one of my own now, and it’s, there’s nothing more important than your own self, and your own well-being.
Kshitij Mohan: Definitely. And I think you are speaking from your practical experiences to say the least.
Richard Donovan: Absolutely.
Kshitij Mohan: Perfect. Perfect. Richard, this was really nice. Thank you for being so candid and sharing your honest and lovely opinions about the things that you have been doing in your personal space. I think moving forward, just picking up from where we started, right? Talking about your journey and how you kind of evolved and how fitness kind of helped you during this entire process. One quick question here, right? So, while being on this journey, you never realize at that instant in time, right, what’s happening with you, and it’s generally the hindsight reflections of what’s happening and what’s not. Right? And while being on this journey this is I think, the most challenging aspect. And when you put this into the dev ecosystem, this really becomes a lot of things to balance and work out. Right? Any specific thoughts on how you were able to figure this out while on the go, or any specific thoughts around that?
Richard Donovan: Actually for a long time, not really, so much of it was actually navigating the struggle and I think at a certain point in time, I don’t know where it came from, but I had a little bit of a realization. Maybe some of that comes with age. At the time I was getting closer to 40, so we might call it a midlife crisis. I don’t know, but I had a moment. I was sitting at work and I just had a thought and it’s a little bit morbid, but it was about time and I thought if for whatever reason, I was laid on my deathbed and I was looking back at the time that I’d spent here and how I’d spent it, and I thought if I continue to spend it how I was, which was sitting in front of a computer and tapping a keyboard. I just asked myself, would I actually be happy with that? If that was all the time I had. Perhaps it is, perhaps it isn’t. But if it was, would I be happy with it? And the answer was no. And in that moment, kind of just decided to myself that actually what I want to do, if I look back, I want to be able to have had an impact on other people around me. And, that was because I just felt like I could do that. And I spent a lot of time not doing that.
Kshitij Mohan: Hmm. No, I think that’s definitely the ultimate realization of changing the way you work and changing the way you live. So this is great, Richard. Now bringing these things to the dev ecosystem part of it, right. Working and how the things evolve in this entire dev chain. So, there are a lot of pressures while you are going ahead, building, leading, right? And one of very critical pressure that we have all felt is a pressure to know everything, right? And in this kind of competitive world this just surpasses everything. Your thoughts on how to balance this stuff, how, how the managers, leaders, and because that’s where, as soon as you keep on growing up the ladder, I feel this is what keeps on growing, along with you as well, that hey, expertise and, and you should be knowing it all thoughts, right? So your take on this Richard.
Richard Donovan: Yeah. I think the ultimate take on it is to stop thinking that because it’s not necessary. But you know that being said, I’ve been in a couple of leadership roles where that is exactly what I thought, and to be honest with you, I didn’t deal with it very well. I dealt with it badly, and those jobs didn’t work out very well for me and for the team. We might have got some software out the door, but we probably didn’t feel very good doing it. These days I don’t carry that with me. I don’t believe that you need to know everything to be able to lead. And I try and share that with my teams as well. And I openly share that, you know, I don’t have all the answers, and software development is a team game and, you know, contributions come from all sides.
Kshitij Mohan: Right! And I think this is really important, right? How do you keep on telling yourself, Hey, this is fine, right? You just need to pass on better. Maybe you just need to delegate better in order to drive the ultimate outcome that you as a team are trying to achieve. This is where I feel we lack a lot of, as leaders and managers, the right art of delegating things well, right, because. Other than that, this is a great way of myself also relieving a certain pressure of knowing everything to actually making people, push up the ladder and say, Hey, now let’s just start distributing more, driving more. But I think this is definitely an art to learn and go by it. So your take on this, Richard, you must have had certain experiences to live by this.
Richard Donovan: Yeah. I’ll probably repeat myself a little bit during this, but again, in a few of my earlier roles, I just didn’t do this very well at all, and I tried to take responsibility for everything and I tried to do everything right and I tried to go to all of the meetings and I tried to do so much of the work and eventually, I got to a point and I realized I can’t do all of this, and I wasn’t sure whether some of the developers that I was managing could step up and do a bit more than just the code. But it got so much that I had to try and trust someone with that. And I did that in this instance, I handed over a project to one of my developers. I didn’t know if he could do it. But he stepped up, he delivered technically, he communicated really well with the business, which was really important because at the time I was failing to communicate with the business ’cause I had so much on and they couldn’t see progress on this project. And when I handed it off, actually this person communicated really well. The business started to see the progress. And actually, it was quite a, quite a lot of stress off my shoulders, to be honest. And you know, that was a bit of a defining moment for me to realize actually I can’t just do it all. I can’t keep hold of everything I’ve got to let go. And, also to trust and as a leader, that’s a really important message to give to your team as well, that you trust them and that you’ll just back them and help them. And you know, that for me it’s a really important message and again, something that I didn’t do in my probably first couple of roles really.
Kshitij Mohan: No, definitely. And I think what we have seen over time and again is that in such circumstances people do shine. You just need to give them the right information, the right platform, and they can just make everyone’s life better. Definitely.
Richard Donovan: Yeah. Absolutely.
Kshitij Mohan: And while doing so, right? Talking about all this a circle of pressure, keeping things to yourself, right? Not delegating and thinking, Hey, it’s me who just has to solve it all. This is what eventually leads to burnout and maybe not the right state of this mental and physical well-being, right? And. luckily over the past few years, we have started seeing this wave of leaders, engineering ecosystem talk about developer well-being, burnout, developer experience, right? Would love to hear your thoughts on these aspects, right? Because we definitely have seen along with your journey, this is what, the closest thing that’s close to your heart when this is what even you are trying to achieve in what you are doing today. So we’d love to hear your experiences on this aspect, Richard.
Richard Donovan: Yeah, so well-being in software development, I think it’s so big and it’s something that over my career, I think it’s been massively neglected. I didn’t ever feel like I was supported with my wellbeing at any time and there are a couple of reasons for that. So, one, I didn’t really feel like I could talk about it. So when I had imposter syndrome, when I suffered with burnout, I didn’t really talk to anyone. And I didn’t think anyone would understand. And so it becomes difficult for people to then help you if you don’t ever tell them. So, you know, that’s on me. And, but as an industry, I think we find it hard to talk about these things, so we need to make that more acceptable and we need to understand more that people are dealing with these things. So I think that’s really important. What I also found is that how we think plays such a massive role in how we feel. And ultimately our well-being and the perspectives that we take, and recognizing that we choose how we think and realizing that we have the power to change even our belief system if we believe a certain thing, we have the power to change that and believe something different if it’s not helping us. And that for me has been a huge realization and it’s obviously a really big part of my mindset coaching. And those areas really feed into things like imposter syndrome and burnout in particular, and achieving, you know, work-life balance. We kind of touched on it earlier, but as I say physical well-being as well. We sometimes talk about them in isolation, but they’re so intertwined. Physical activity, whether it’s workouts or walking, yes, there are obvious physical benefits of doing those things and health benefits from doing those things, but it also has such a massive impact on your mental well-being as well. And not just your mental well-being, but we can take it further into the realms of performance. It has massive impacts on your focus, your motivation, probably your morale, and it’s absolutely huge. So I am actually as well as a mindset coach, I’m also a personal trainer, so I really do kind of bring them all together in, in under that well-being banner, so……
Kshitij Mohan: Oh, perfect. Richard, and but Richard, in these entire experiences, do you feel there is any specific practical processes or something that managers/ leaders need to keep on working towards, need of implementing so that everyone feels that, hey, at a very first step, you can just open out and say what you’re feeling. I think that’s what the first biggest challenge is and as even you mentioned, right? People just don’t speak up and most of the people don’t even realize that it’s happening with them. So how do you ensure that you are able to create that ecosystem around it?
Richard Donovan: Yeah, I think it comes from the people at the top, it comes from the leaders, and, you know, if our leaders never show vulnerability and they never talk about the times that they maybe failed or they got something wrong, then without seeing it, everyone who works for them can almost read between the lines and think that they can’t talk about that either, because if they show it, then they’re not as good. So I think it really does come from the top when the leaders can share their own vulnerability, share their own feelings, and ensure that’s okay. And especially in my experience when I have done that my teams seem to feel more comfortable doing it as well, and, and it leads to a lot of things, but it tends to lead to a lot more trust with within the teams and also general morale seems to be better when that is the case.
Kshitij Mohan: Yeah, I think that that’s totally the case. We all need to ensure that we are working together, break those silos, and then I just talk about the stuff that’s going on. This is great, Richard. One last thing, you have seen it all, learned it all, definitely reflected so many times on your past journeys. What’s that one piece of advice that you would like to give today to your all the viewers, listeners, EMs, developers? How do you build the right balance between success and well-being?
Richard Donovan: It starts with self-leadership and you don’t have to be a leader to practice self-leadership. You can be at any level whatsoever, but you want to reflect and work out what it is that on a daily basis, What do you want in your day? How do you want to feel? How don’t you want to feel? What are you prepared to put up with? What are you not prepared to put up with? On top of that, you probably want some goals to work towards, and bringing all that together, it’s a really powerful concept is to work out and get clear on what your own core values are. Because your core values are the things that are gonna strike up whatever it is that you’re doing, you are gonna kind of move towards them. And what happens a lot of the time when people haven’t reflected on them, they don’t really know what they are. They kind of know, but they’re not totally sure. And what can happen there is they might find themselves in a job or in a situation and they kind of feel like it’s not quite right but they can’t put their finger on it. And what’s happened, as a coach, when I’ve gone through this process of helping someone define their core values, when they realize what their core values are, suddenly they go back to this situation and they realize, I know why this isn’t right now. It conflicts with what I’ve got here. It doesn’t sit well with me and this is why. And suddenly things just seem so much clearer and it just makes. I think it makes it a lot simpler to navigate life. Nevermind work.
Kshitij Mohan: Definitely. Perfect. Thank you so much, Richard. All I can say is this has been such a mind-blowing conversation and we are glad too, that you could talk about openly about challenges, the learning, the journey, and we just can’t be more happier about.
Thank you so much, Richard, for your time today. It was really nice having you. Thank you so much. Have a good day.
Richard Donovan: Cheers. It’s been a pleasure.
In our recent episode of Beyond the Code, host Kshitij Mohan, founder of Typo welcomes Isabel Nyo, Head of Engineering, Atlassian Australia. The focus of their discussion is on growing development teams in a sustainable way.
The podcast begins with a fireside chat with Isabel Nyo, providing us a glimpse into her personal journey. She places valuable insights into building engineering teams that foster a culture of transparency and excellence. Isabel also shares specific metrics she utilizes to gauge her team's velocity and satisfaction. Further, she delves deeper into the framework - C.A.R.E. explaining how it plays a pivotal role in instilling a product-driven mindset among engineers.
Lastly, Isabel addresses the challenges faced by women in the tech industry and how individuals and the industry as a whole can work collaboratively to break down these barriers and create a more inclusive, equitable, and diverse tech ecosystem.
Kshitij Mohan: Hello everyone. I'm Mohan your host back with another exciting episode of Beyond the Code by Typo. Today's guest needs no introduction in the engineering community. She is the head of engineering at Atlassian Australia. She has been a part of the engineering ecosystem for more than 20 plus years, and believe it or not, she has authored six books.
She actively speaks about winning a positive change for women in tech. Actually, she has done it all. She's her. She is Isabel. Hello Isabel. Welcome to the show.
Isabel Nyo: Hi. Thanks for having me, and thanks for the really nice introduction about me.
Kshitij Mohan: Thank you so much, Isabelle. It's an honor to actually host you here, so thank you for sharing your time with us.
Isabel Nyo: No worries.
Kshitij Mohan: Perfect. So before, before we start, I think this is one question that has kept me intrigued since the time we started doing this podcast with you. How have you been able to author six books, Isabel? How have you been able to find this time of doing everything while you have been doing a lot?
Would love to hear your experiences around that.
Isabel Nyo: Yeah. This is the question that I get asked often, and the thing is that it's not like I was writing all the six book at once. So my first book was written. In 2018, and the last one was written in 2022, so just last year. So it's more about the incremental improvement and incremental delivery, so to speak. In software development, you know how we have got like the HR and incremental development, so if you look at things after a while, you think that people are doing a lot of things at once, but that's not really the reality. It's more about taking time, taking step by steps, and after a while you feel like you have reached the top of the mountain and that's what it's, in this case.
Kshitij Mohan: Well definitely, but Isabel still four years and six books.
I think a commendable job. Definitely. So kudos to you! Perfect. So, in your entire career span, you have seen it all. You have built teams, scale teams, and I think while doing all this, the biggest challenge is how do you do it in a sustainable way? So I think today we would love to talk about, growing dev teams in a more sustainable way. But I think before we do that, we would love to have this fun fireside chat with you where I'd ask this quick series of questions. And we would love Isabel to answer this for us and so that we get to know you better and feel free to be as candid as possible Isabel. So if you're ready, we can get started.
Isabel Nyo: Yeah, let's go for it.
Kshitij Mohan: Perfect. Let's go for it. So question one, what do you like more Isabel coding or leading teams?
Isabel Nyo: So when I was a developer, and this was about 15 years ago, I really liked coding and I couldn't imagine being a manager and I didn't become a manager for a while because I really enjoy building things from nothing or solving complex problem. However, throughout those time, I found myself mentoring other developer and teaching them on how to solve problem and stuff like that. And I found that I was quite good at it and slowly I took into the management career part. And now I can honestly say that I enjoy management as well. I like that I am able to make positive impact on the professional and personal development of people through being their manager. I find that I am able to have more impact, and this is my personal opinion. It doesn't mean that if you are a software engineer, you don't have as much impact. It's just for me, I find it really rewarding to be able to steer the ship in the right direction and help them grow.
So I like both, but right now I'm very happy in my role as a Manager.
Kshitij Mohan: Question two, What's your source of energy that gets you through the tough days?
Isabel Nyo: I like to go for long walks, so I usually have like a 10,000 or 15,000 steps a day. And when I'm going for a walk, I like to listen to music or podcast. So I will definitely be listening to this one as well, actually helped me clear my mind and it helped me to be more productive.
So that's where I get my source of energy. Perfect. So that's!
Kshitij Mohan: That's how you find your zone basically.
Isabel Nyo: Yeah. Yeah, that's right.
Kshitij Mohan: Perfect, perfect. Next question. You have written six books now, so which one's the one that you feel has shaped you most as an author?
Isabel Nyo: So I actually thought about this question a little bit, and I have to say, honestly, there's no one single book that has shaped me to be who I am as a writer, because as I said earlier, every time I write a book, I learn a lot from it.
And I'm feeling that I'm improving it incrementally improving the craft of writing. And one of the central theme and the central reason for me to write is to share my knowledge and insight with other people. So, I feel that I'm getting that from writing, and it doesn't matter how many books that I have written, I still feel this sense of satisfaction and responsibility, and purpose with what I'm sharing.
Kshitij Mohan: Definitely. So every book holds a special value in your heart. Definitely. Right? Perfect. Next question, Isabel, what's that one tech myth you wish people would stop believing?
Isabel Nyo: This is a good one. So I wish people were believing that innovation has to be big and disruptive. There's a lot of time where you can innovate based on incremental improvement or making things better or easier. It doesn't have to be groundbreaking or something new and disruptive all the time. And this is a myth that we have in the tech industry, and we believe that innovation is only one. You create something that nobody has thought about. That's not true.
Kshitij Mohan: Oh this is sweet Isabel! So even small changes can lead to bigger impact, so definitely. Perfect. One last thing. What's that one most memorable eureka moment you feel in your career?
Isabel Nyo: So I think it was when I was a developer, so I was working for this company and we were doing a very challenging and complex project, and I was only with the company for about a few months. So I wasn't the most senior person or most tenure person in the company, but I found a lot of people who are not developer were coming up to me with their questions or giving me their feedback, and I found that my approach to collaboration has really helped bring people together. And when there were problem, I was able to be the voice for them. So this has really helped me understand having a diversity of voice, really bring people together and make the outcome of the collective better.
Kshitij Mohan: Perfect. So that's where the leadership journey of Isabel started, I guess.
Isabel Nyo: Yeah. You can say that. Yes. So that's my approach to how I collaborate and how I work as well.
Kshitij Mohan: Perfect. Thank you so much, Isabel. This was, this was really fun, and thank you for being so candid. Now let's get into the real stuff. Right? So, given the kind of vast, amazing experience you have had, you have held multiple positions, right? From CTOs engineering leaders, I think today what we would love to start with is your experience as a CTO, right? So, what do you think is that interesting reality about building dev teams as a CTO that's kind of counterintuitive for others. What do you think has been that key insight for you while building your engineering teams?
Isabel Nyo: So earlier in our conversation you were talking about how to build sustainable teams, right? Yes, right. So I think one of the counterintuitive fact for engineering leader is that we need to understand that less can sometime be more so in a world where we always think about having a lot of PR or lots of codeship or lots of code written. As technology leader, we need to understand that sometimes small things can actually lead to big results. And let me explain what I mean by that. So for technology leaders, we should focus on quality. Rather than quantity. So rather than pushing for a large volume of code or a large number of feature, we should encourage team members and engineer to take the time to write clean and maintainable code, make sure that there's enough trust in it, and think about reliability and scalability as part of the development and this will lead to actually sustainable process. And this is just one part of it. And second part of it is around how we work and our way of working. So often CTOs or tech leader are the people who are very smart and they are problem solver. So when they become manager, it takes them a while to really understand what leadership is all about and they need to take a step back and actually, speak less and listen more. So this is where speaking more is actually detrimental to their success as a leader. And less is actually more so when it comes to way of walking. They also need to take a step back and give room and space for people or engineers on the ground to grow to really help them achieve success in their team and to to have great result as a team, not just from one individual, but a collective. So these are the counterintuitive belief that I have around less is actually more and more is sometime less.
Kshitij Mohan: No, definitely and while you talked about, although this is very close to building the right and fostering the right set of culture as well in the, in the dev teams, right? So this culture of transparency, culture of excellence, and I'm pretty sure you must have faced certain set of challenges while building that culture because its not easy to set the right foundation for everyone to grow and evolve from there. Right? So any thoughts on that? How have you been able to do that?
Isabel Nyo: So when it comes to creating a culture of engineering excellence or culture of continuous improvement, I have found that setting this culture or instilling this culture, take a while. And it might.. It's often very hard to reverse the culture. So let me give you an example. A while ago I inherited a team that was looking after a large code base, and this team was under a lot of pressure all the time because they have a huge tech debt. They were always busy firefighting, and they had no time to do like innovative project or feature development. And this actually impacted their velocity as well as their satisfaction. And this is the result of not having a continuous improvement culture. And they were too focused on shipping things quickly and not taking into consideration the impact that it has on the technical infrastructure and the platform. So, In this case, what I did was, and what I would advise all the senior engineering leader to think about in terms of fostering a continuous improvement and continuous engineering excellent, is to have an understanding of the current state. How is the infrastructure like what are the bottlenecks that the system has got? And once you understand the current state, you might need to make decision around what are the things that you need to fix immediately and make room for it. In product development, we often have roadmap, right? Like you have roadmap with things that you need to ship, and we need to have the same from the technology perspective as well.
You need to have a technology roadmap and it needs to have a plan and the vision and strategy so that we can have this continuous improvement culture in the technology as well.
Kshitij Mohan: Right. Perfect. And while talking about this, so you mentioned two critical aspects, right, that every leader talks about, about this velocity, the satisfaction part, right? Any specific metrics or any specific way that you have been using to understand, Hey, how my current team's velocity is, , or how my team satisfaction levels look like? Any specific thoughts on that? Have you been able to kind of objectify this entire approach?
Isabel Nyo: So, in terms of how do we gauge the satisfaction level as well as the stability of the platform, so to speak, or the engineering excellence I recommend two kind of metrics. The first metric is the Quantitative metrics and you can use Dora metrics for that. So how like number of incident, what is the change failure rate and things like that are really good way to gauge the number around how things are going. And you can see the trend as well. So for example, if you see the trend of number of outages increasing over a few months, then you can see it clearly that something needs to be done. So that is the quantitative. The other side of it is qualitative metrics, and this is where you need to have conversation with engineers and speak to their engineers to find out how things are going for them, because sometime things may look rosy on the outside, but engineers may be feeling like they are not being productive or they don't understand what they're doing. They don't understand the big picture. So this kind of information can be gained by having survey or speaking to engineers on the ground.
So I would recommend not looking at just the quantitative metrics.
Kshitij Mohan: Quantitative level. Yeah. We're bringing things together. Yeah, totally. Totally. This makes sense and by talking about culture, it would be so not good without talking about the Atlassian culture. I think you have been in that culture for too long. So any specific things that you really love about being a part of the Atlassian culture?
Isabel Nyo: So we, Atlassian, one of the reasons why I joined Atlassian about five year ago was because of the value. So we have a few value for Atlassian and one of the values that really resonate with me is be the change that you seek. So Atlassian really encourages people to take ownership of whatever area that they are passionate about, regardless of who they are or what kind of role they play. So for example, I'm a head of engineer, but if I feel that there's some process improvement that need to be done, even though I'm not a program manager, I am more than welcome or encouraged to bring this, bring about change in that area as well.
Kshitij Mohan: Whoa. This is so cool. Perfect. And so just moving forward to it, right? Recently there has been a lot of talk about product-driven mindset, right? Experimenting, innovating. Everyone continuously talks about, Hey, how do we actually are more focus on this so in order to evolve more, right? But I think the biggest challenge that would be is how do you translate this thought from the leadership team till the actual engineering level, like every engineer feeling and aligning with the same mindset, but what's your thought on this entire process and approach?
Isabel Nyo: So I actually have a framework that I use in, in terms of bringing about product-driven mindset to engineer, and you are absolutely right in this world where we are always creating something, whether it's a platform product or the product that consumer use, we need to understand how to bring about this change and how to instill into the engineers.
So the framework that I use, I tell you an acronym, so it's called C.A.R.E. And each acronym or each letter stand for something. So C, stand for clarity. Clarity means everyone in the organization or every engineer, every product manager, they understand, what is the success that they are working towards. Oftentimes, I see a disconnect between what the business is trying to achieve and what the engineer are asked to. And this is very important to provide this clarity because once people understand the big picture, they can actually make changes or they can actually ready for things to be done. So clarity is very important and my job as a leader is to provide this clarity to people that I work with. The second letter is A, A is autonomy. And earlier I was talking about one of the value that really resonate with me is be the change that you seek. So giving autonomy to people means that you give them what is the success criteria, or you tell them what are the guide rate that you have. They can decide on the how or they can even decide on the initiative that they are gonna work on to meet the details or to achieve the goal. So autonomy is really important. And autonomy also bring about engagement when people feel like they are allowed to make decision that impact things that they are doing. Whether it's the technology choices or how they would solve a particular problem, it really motivate them and provide them with the sense of ownership. The next one is, so we talked a little bit about the product driven mindset. When it comes to product driven mindset, we need to understand who we are solving the problem for, and we are solving the problem for customer, but we might not know how to solve these problems. So it is important to take calculated risk and measure as you go. So this is where experimentation come in handy. You might need to do small incremental improvement, and you might need to learn from it regularly. And this require everyone to be comfortable in taking risks and the way my role come in as a leader is to make space for people to feel comfortable, to take risks, and also not only to celebrate successes, but also failure as long as we learn from the mistake that we made. So R is risk-taking. And the last one, the last letter is E, and E stands, for example. So leading by example, and this is the fundamental trait of any great leader. They need to lead by example. So it is not enough to tell people what to do. You need to show them the way and you need to demonstrate the principle and value that you want people to embody. So when it comes to the product thinking mindset and product development, this mean as a tech leader, I'm engaging closely and collaboratively with my product managers and product conduct because this is what I would like to see from my engineer as well. And this also mean me being curious about. What are the pain points for customer, how they are feeling, what they're using, and what problem they have, and also understanding what are the business metrics that we need to meet in order to be successful as a company. So these are the things that I really try to do and I do in order to foster a continuous improvement and product thinking mindset in engineers. So I think gones were the day where engineers do engineering work, do their own craft and designer do design. This day everyone needs to be aware of each other craft and has empathy for each other expertise and knowledge.
Kshitij Mohan: Wow, Isabel. So you kind of transformed this entire approach into C.A.R.E. So C is for Clarity, A for Autonomy, R for Risk taking, and E for Example, leading by example. Wow. This is mind-blowing, Isabel. Perfect. Thank you for sharing this, actually. So I think this definitely is highly insightful for each and every engineering manager trying to foster this culture. Perfect. I think lastly, we'd love to talk about a topic that's really close to your heart, right? You have been actively writing, speaking a lot about women in tech trying to bring a positive change, right? So we would love to understand your experience and what do you think could be done to change the entire narrative around it?
Isabel Nyo: So I've been in the tech industry for about 20, 21 years, or more than 20 years, and in this journey I've had both good and bad experiences, but good experiences are where I have worked with people who are very inclusive, who celebrate diversity of voices and who would make room for me or who would make time for me to hear my point of view. However, on the other hand, I've also faced situation where people would dismiss me because of who I am or how I look, or the way that I think. And sometime I had to prove myself twice or three time as much in order to get the same respect or in order to get the same level of treatment as my male counterpart in the tech industry.
Regardless of all this, I think we are improving in terms of being more open, being more accepting, and being more appreciative of different kind of people and their thought process and the perspective that they bring to the group. So personally, I have a daughter and she is 11 year old and she is in her last year of primary school. And in about maybe a decade, in 10 years time, she will enter the work phase, and what I will hope is that she is treated equally as her male counterpart, regardless of whether she wants to take a job in technology or science or not, or medicine or whatever. And in order to do that, you ask a question about what we can do to change the narrative. I think there are a few things that we can do right now. Firstly, we need to educate other, we need to educate everyone and we need everyone to be aware of the problem that we are having or challenges that…
Kshitij Mohan: So the folks don't even know that they're doing it. No, exactly.
Isabel Nyo: That's right. So sometime there's this subconscious bias and people like people who look like them. So if you have a room full of male developer, they might think whatever they are doing is okay, but it could exclude certain people who are not like them. So education and awareness is really important. So there are a lot of trainings around unconscious bias. You can read books about what are the different.. How different gender thinks, different perspective, not just gender, by the way, it's also cultural as well. So people try and educate themselves and have awareness around these differences. Then there should be sponsorship and advocacy. I say this because sometime we tend to promote or celebrate people again who are like us. So unless you have some conscious effort to try and celebrate, People or different voices, then there will not be enough representation in this industry.
So representation matter and sponsorship in order to have enough representation, sponsorship and mentorship matter. And lastly, I would say we need to come together as a group. It is not about us versus them. I'm doing this podcast with you and it's not... We're like, we are trying to make a change together.
So it's important for everyone to come together and make a change as a collective rather than saying, okay, you, the problem is with female. So the female representative group should be doing something and male don't need to be involved, or female shouldn't feel like they should be the one pushing for change. It should be on everyone responsibility to bring about change because we can be better together.
Kshitij Mohan: Well, definitely I think that this is, thank you so much, Isabel. So this is a really important lesson for I think each and every one of us. How do we come together and build this inclusive culture?
Because that's how we can all grow and evolve together. And definitely we all hope Isabel, that pretty soon as you mentioned, right? I would say not even a decade, let's just do it as fast as possible and to just make this world a better place for everyone to work. So definitely thank you. Thank you so much Isabel, this was a really nice conversation. We're kind of humbled to have you here and thank you for being so candid and opening your heart out with us and for all of viewers. So thank you so much, Isabel. Have a good day.
Isabel Nyo: Thank you. Thanks for having me. It has been fun. Bye.
Kshitij Mohan: Thank you.
In our recent episode of Beyond the Code, Host Kshitij Mohan, founder of Typo, engages in an insightful conversation with Mateus Viegas, Engineering Manager at Luxclusif. The central theme of the discussion revolves around fostering innovation and well-being in dev teams.
The podcast starts with a fireside chat with Mateus, providing us a glimpse into his personal background. The conversation then takes a deeper dive into dealing with challenges when transitioning from developer to managerial role. Further, he sheds light on the ways to get a bird's eye view of the team’s dynamics and operations. Mateus also imparts a valuable perspective on enhancing the experience and well-being of developers.
Wrapping up, Mateus provides thoughtful advice to fellow engineering managers in the field.
Kshitij Mohan: Hello, everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by typo. Today’s guest comes from the football Frenzy Nation of Portugal. He is a renowned engineering leader, a published author, an ex-CTO, and what not. He brings a unique mix of creativity, engineering, and leadership. Please meet Mateus. Hello Mateus. Welcome to the show.
Mateus Viegas: Hi Mohan! Thank you so much for the nice compliments. Just a curiosity, I, I have actual dual citizenship. I was born in Brazil and live in Portugal nowadays.
Kshitij Mohan: Basically you belong to both the Ronaldos? I think so lucky
Mateus Viegas: Yeah, exactly.
I wish I had their abilities, but that’s okay.
Kshitij Mohan: Perfect. Thank you so much Mateus for sharing your time with us. This really means a lot. Perfect. I think before I get started with anything mateus, this is one question that I can’t just stop myself asking from. How did you get time to publish a book while doing everything else that you have been doing?
Mateus Viegas: I mean, it was in the pandemics. We were locked in the house and the opportunity came by. So I can’t deny that it was like quite a big challenge because, I mean, it took a long time and a lot of back and forth. But yeah, basically the pandemic have to be inside the house, so nothing else to do, yeah!
Kshitij Mohan: Perfect, I think you grabbed the opportunity with both hands definately. so man, Congrat to you Mateus!. By the way, how does it feel to be a published author? Like, anything changes or is it all the same and all?
Mateus Viegas: I mean, I did it most for personal experience, you know because I always struggle as a person to commit myself to long-term projects. And I knew that the book was going to be like a really long-term project, like two two-year project.
So it’s really like an exercise for me, for discipline. And that was the thing that I was searching the most, like really to commit to long-term things. And for me, it was played really, really nice in the sense, in that sense, I didn’t think about money, about reach, about nothing like that was more like a personal experience.
So yeah, that’s it.
Kshitij Mohan: Perfect. I definitely, that’s, that’s great Mateus. So Mateus, given the kind of experience that you bring in, I think today we would love to talk about how to drive innovation and well-being in dev teams. But again, before we do that, there is always a fun fireside section that we do with our guests.
I would ask a quick series of questions and we would love to know the personal Mateus to go about, and then that’s all how it goes. So if you’re all set, I would love to get started.
Mateus Viegas: Yeah, sure. Let’s go.
Kshitij Mohan: Perfect. So let’s get started. We know from your profile that you visit a lot, you like love to drive in nature, take photographs.
So I think the first question would be that what’s that one most breath-taking place that you have visited? That you just loved and you just can’t stop yourself taking pictures from?
Mateus Viegas: Well, I mean, that’s a tough question. Being born and raised like in an ocean country, in a coastal country like Brazil, I’m from Rio originally, I was always amazed by mountains and by how huge they are in this kind of thing, right?
So every place that, every place where there are like these big mountains are pretty places that mesmerize me. But there, there’s one place that, I mean, it’s my dream place because it looks really like another planet, which is Iceland. I went there like almost 10 years ago and it just can’t get off my head since then. But there are a lot of places and mountains in general.
Kshitij Mohan: No, definitely. I think Iceland is definitely one of the most naturally gifted countries to be with. Like definitely. Perfect. Question 2, This is for the developer Mateus, What’s your favorite Algorithm or data structure?
Mateus Viegas: I am thinking of this right now and I think that, I would call it the merge sort. Because it really forces me into like thinking of breaking down a problem, like to that divide and conquer approach. You know, it’s like really breaking down bigger problems in chunks of smaller ones. So I think, and it’s quite fast actually as well, so definitely. But mainly because of the reasoning of like breaking things down and I really like this, this kind of approach.
Kshitij Mohan: So question three, what’s that one favorite tech gadget that you can’t live without?
Mateus Viegas: I have to see my camera. I mean I have a tiny camera. The Fuji Film three. It’s not a new one, but it’s the one that I carry around all the time, so that’s my tech gadget.
Kshitij Mohan: Yeah. Perfect. Question four, What’s that most inspiring quote that you live by? What inspires Mateus?
Mateus Viegas: I like to say that I’m a pretty sentimental guy and there was this cult, from an American out of college that I heard like years ago that says, “Nobody has ever measured, not even poets how much the heart can hold.” And it’s something that really inspires me in living with my family and living with the people that I love and doing the things that I love.
So I think that is my motto, I would say.
Kshitij Mohan: Thanks, Mateus. This was real fun. Thank you for being such a sport. I think now getting to the real stuff, getting to pull out some insights from your experience. Right? So you have seen this entire journey from a developer to a manager, to a leader. You have seen it all. And I’m pretty sure this must not have been easy, right? You must have faced certain set of challenges that you, you must have felt, Hey, this is something that I need to deal with. I think we would love to understand those set of challenges that you think, Hey, this is what made me to the next level of where I am today. And, how did you kind of overcome those situations?
Mateus Viegas: Yeah, I think that coming from a software engineering background of being a developer, I think that one of the biggest challenges that I personally faced, it was like the feedback loop is different. So when you’re a developer, you’re like writing code and you have test suites and you can iterate and fail and try again the red-green refactor kind of thing. But when you’re like leading teams, It is like a change of mentality because it’s not so much the output that matter, but more the outcomes. And the outcomes usually take a little bit more time to compound. So one thing that I’ve tried to do is like, well, I’m a manager. I’m not seeing any result, I have to be totally hands-on again. So I started being hands-on, but that just got things worse because I took enough space from the team, I took autonomy from the team. I was actually being more of a blocker than a blocker removal. So I mean, really to making this switch was something that was a huge mistake that I did. And my team surely had paid the price at that time. And thank you folks for understanding and for making me improve as well publicly to them, because I mean, was my biggest challenge at all. It was like to change the motto, you know, to change like this perspective. Okay. Now I’m not more like the guy who codes, but I have to try to make the guys who who are actually coding do their best, so empower them. So really make them shine and understand how can I help more as a support than as an another operational team, another operational folk. So I think that was one of the biggest challenge that I have faced.
Kshitij Mohan: Right. So basically moving from this mindset of doing it yourself to enabling teams, how to do that is really what the biggest mindset shift is. Definitely!
Mateus Viegas: Yeah. Yeah, exactly. And that, that was something that one really nice manager that I had told me, he said to me, because I said to him I have too much, I can’t do this leading thing anymore. And he said to me, of course, you’re having too much. You’re coding! Why you’re coding? And that, and that just triggered me because, I mean, I can surely help the teams with my technical background in architectural review with things, these kind of things. But I was like taking too much time trying to do both things, wear both hats, and it just doesn’t work. So also a big thing to my manager at the time who shined the light on me because was it really helpful
Kshitij Mohan: Right. No, definitely. And any specific practices that you followed to change your mindset? So basically before jumping on to saying, Hey, let me, let me finish this up. You were in a mindset, Hey, how do I actually define things for others? Right? So how did you balance this out and like gradually shifted to where you are?
Mateus Viegas: Yeah. I think that for me one thing that really motivated me I didn’t like to see my team struggling. So I think that by coding I will remove the struggle from them, but I was also removing the learning from them.
So it was really like a mind treat for me to say that they have to go through it as well. They have to struggle sometimes. They have to face this challenge in order to know how to overcome them. So, it was really like. Really making a switch in my mind to say, okay, let me step back. Let me see a little bit of chaos. And if needed, I can step in.I can step in somehow. But sometimes it is good to have a little bit of chaos. Sometimes it’s good for the teams to good character and to learn.
Kshitij Mohan: No, I think definitely this totally is the right way but one thing in doing that Mateus is, right. So while doing this, how do you balance this act that, hey, till this time, let the team figure out on its own and, and from a time, Hey, no, no, this, this is not happening. I have to step in and kind of figure those things out. So how do you do that?
Mateus Viegas: Yeah, I think that is really like, about something about defining expectations.
You know, when building teams, one thing that I always had in my mind in I have to, to hire the best guys that I can afford this role. If I hire them, it’s because they are more than good enough. They are really like pros in what they do. They know what they’re doing. So it was really like, okay guys, you know what you’re doing, we have to reach there. So my goal was really to provide alignment and give them autonomy, because autonomy without alignment, I mean, it just doesn’t make sense, right? But it’s really like, okay, we are aligned that we need to get there. I don’t know how you guys tell me how, how do we get there? What do you think that is the best way? What do you think that are the challenges that we might face? What do you think that are the risks that we might have to take together? But that is the place, or it’s really that the place do you see? So it’s really about like fostering them, this sense of autonomy so that they can really be accountable for how they get there. And my role is really to provide direction, provide alignment, and try to remove any noise that might be in between. And was mostly is really like making a step up, step out, and doing more like a bird eyes view of the thing, the perspective, like really elevating the perspective and empowering the teams. I think that was mostly really a changing of mindset.
Kshitij Mohan: No. Perfect.. And I think as you mentioned, right, getting this Bird eye’s view, so any specific tools or any specific kind of dashboards that you were using maybe to get this entire picture? Or was it more of a conversational-driven way where you were setting up meetings and trying to understand what’s happening?
Mateus Viegas: I really like a dashboard too called the Google Sheets. Just kidding.
Kshitij Mohan: That’s the master of all.
Mateus Viegas: Yeah, exactly. But basically one thing, that I really like to do with my team is like, one process that I really enjoy do is the goal setting. You know, so we have, for instance, the goal setting as a company, one desire outcome and we discuss as a team, what are the team set, the team’s objectives, the things that we need to reach as a team, the deliverables that we can contribute with. So it is really like to compounding goals, right? So we have this team goals that we have to compound and individually with each, each team’s member. What are your goals that you think that you can set for yourself that might help us to compound into this one. So one thing that I really like to do is to track with them these goals. Like they have their own spreadsheets with their goals. We have a template as of now where they do the tracking and we do kind of bimonthly check-ins and we see the things compounding in a way. And if all these goals are compounded, we are like, It’s not certain that we get there on the main goal, but we are closer. So it’s something that really like to use to track this.
Kshitij Mohan: Definitely, Mateus. So, this is great now coming to this team-building part, right? So I think as you also mentioned, autonomy and alignment. It’s also important that how do the teams communicate, collaborate, right? And in order to ensure that the entire development process is smooth and efficient. I think that’s the foundation of every, high-performing dev team, I would say, right? So how did you foster that? Any specific things that you worked on to ensure that’s in the right place?
Mateus Viegas: Yeah, first thing I think that is important for everyone to know their roles and their responsibilities within a team. So regarding the responsibilities, one thing that I really like, to have clear for everyone, and I really like to have a document, is what I call the engineering playbook, where basically we say what is our way of planning. Where is like the software development life cycle that we had. Where is the approach to code reviews? Where is our approach to monitoring? What is our approach like to considering something done? So really defining this playbook of like more like a basic common ground and starting from there. So we know how to work. I don’t think that is also set in stones in different teams. Like you have kind of different playbooks, but having this engineering playbook of like standardizing the basics of the software development lifecycle for that team, it starting there, this is our process. So mostly within this process, letting everyone compound. One thing that we started to wait like more one year or so with, with the teams that I really started to see in the results was for instance, like their RFCs and the proposals of implementations and where basically we had a lot of times different people, different backgrounds, different experience, different opinions, different personal tastes. So one thing that I really like to drive consensus within the team, within the planning process, are RFCs, because someone proposes something, everyone’s puts their comment in and we get to have like, More rational trade-offs of the pros and cons of each alternative. And at the end of the day, try to remove the emotion a little bit, even though I’m emotional guy. Try to remove the emotion of the decision process by really facing, we have these on our hands, these object pros and cons. So which one’s the best? And when we are not able to decide, we vote and move on. So it’s really like having a standard ground of rules and basically driving consensus. Try to remove emotions and be as rational as possible with the decision-making.
Kshitij Mohan: Right, So basically setting the right processes and then ensuring everything is aligned to that is what it takes to set the right processes. Makes perfect sense Mateus, I think, the last topic is very close to my heart, and I would really love to know your thoughts around that. Right. So developer experience and wellbeing. I think this is the next buzzword, I would say, in the entire tech industry. And I’m pretty sure you must be aware of it. Right? And this has specifically, the entire scenario has changed. We all know after the Covid scene, and that’s when a lot of, more and more people have started talking and writing and printing stuff around it. So I think first, to begin with that, I’d love to understand your perspective on this entire developer experience aspect, which in the end, everyone talks about translating into productivity, right? Your thoughts on that Mateus?
Mateus Viegas: Yeah, I think the developer experience is a quite broad term, you know? I mean, we can extract a lot of things from it, but the way I see it, I see it from two perspectives I see from a qualitative and from a quantitative perspective. I see the quantitative one as metrics that we can capture through surveys or softwares that express something like how long does the team take to ship something? How long does this team take to fix something? May provide some signals of let’s say, the technical health of the team. Right? But for me, those quantitative things are more like signals. And what about the qualitative things? How can we extract them? I’m not a DevX expert, so I really don’t know about everything about it, but I think that One thing at least the developers that I work with, really, really enjoy is really like having feeling that they have a say in what they are doing. Feeling that they have a say in what they are deciding. So really like providing them with the big picture, providing that the reasoning why we are doing this. So first questions. First question is why are we doing this? Do folks understand? Why? Do folks understand? Also, what are trying to solve the main goal, right? And basically empowering them. So I think that empowerment will be the one word that I will use, to give like, not to give, but to translate, not a better developer experience, but to try to give the developers a better experience. So, I mean, really empowering them with enough context, empowering them with the decision making, empower them with the abilities that they, they bring to the table, you know? So, and that comes from the truth. That is more this, let’s say the qualitative thing, the subjective thing, and comes to being close to them. So like tightening the feedback loop, having one-on-ones. In the one-on-ones, we would talk eventually about work, but the first question shouldn’t be about work, but how you’re doing. How are things going for you? How are you feeling? So it’s really about understanding the people that you have with you. Understand their wishes, understand where they want to be, and giving them enough power to do the best job that they can do. So, That’s why I say that my perspective’s a bit subjective.
Kshitij Mohan: No, no, definitely, I think everyone is trying to figure out the right developer experience, what it means, how do you create it. So I think that that definitely helps. Mateus, and I think just before we close our discussion, one piece of advice that Mateus would like to give to all the EMs out there, right? One critical piece that they should be very much focused out while driving everything, while managing all the chaos that’s around there.
Mateus Viegas: Yeah, but that’s a hard one because I don’t see myself in position to give advice to so many brilliant people out there. I think that one thing really important is that I just said, like, I mean, being close to your team. Know that they are before developer human beings and try to develop a relationship with them. I think at least for me, it changes that lot in the way that we can approach things, that we can really conquer things. So stay close to your teams, know how they’re doing, know their challenges, and yeah, just stay present.
Kshitij Mohan: Perfect. This was great, Mateus. Thank you for sharing all your insights and experiences with us.It had been such a fun, fun conversation. And again, all I can say is you are so lucky to have both Ronaldos working with you. So I think that’s all wanted is, that’s how we can summarize this for you.
Mateus Viegas: Yeah. I can’t say my personal preference of the ones. Because I play.
Kshitij Mohan: I can’t even go there and ask you about it. That won’t be a fair question. Thank you for your time today. It was such a great conversation. Thank you. Have a good day, Mateus. Take care.
Mateus Viegas: Thank you, folks. You too bye-bye.
On our recent episode with ‘Beyond the Code’, Host Kshitij Mohan, founder of Typo engages in an enlightening conversation with Andrey Adamovich, CTO at VLAVI Group that focuses on the impact of collaborative dev practices on software delivery.
The episode begins with a candid chat with Andrey where he talks about his love for Copenhagen, Italian cuisines, and coding.
Further, he delves deep into building the right team topologies and how collaborative programming practices can increase the speed and quality of the overall development process.
Lastly, Andrey emphasized the ‘specific’ metric that is best suited for all the development teams.
Kshitij Mohan: Hello everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by Typo. Today’s guest brings a very unique perspective on software delivery, automation, and excellence. He has been a part of the engineering ecosystem for more than 24+ years. His masterclass on DevOps has been delivered more than 150 times across the globe.
He is none other than Andrey. Hello Andrey. Welcome to the show.
Andrey Adamovich: Hello Mohan! Thanks. Thank you very much.
Kshitij Mohan: Thank you so much for sharing your time today with us Andrey, really means a lot.
Andrey Adamovich: Thank you.
Kshitij Mohan: Perfect. So we all know the kind of experience, the expertise, Andrey, that you have on software delivery, excellence, automation, tooling, GitOps a lot more.
But, we would love to today talk about the impact of the collaborative dev practices in the software delivery. But before we jump onto that, we would love to have this fun fireside section with you where I would ask a quick series of questions. Would love to hear your answers in quick so that me, the audience, you all get to know the real Andrey.
So if you’re ready, we can get started. Andrey?
Andrey Adamovich: Yeah, I’m ready. Of course, I’m ready.
Kshitij Mohan: Perfect. So here goes my first question. Andrey, we all know you have been to so many places in the world. Which one’s your favorite and why?
Andrey Adamovich: Yeah, good question. I think I like Denmark. I mean, of course, I like my own country because I live in Latvia, but, if we think about, you know, the way things are organized and the things are neat and nice, I think I like Copenhagen a lot.
Kshitij Mohan: Ah, Copenhagen makes sense. Perfect. Second question, Andrey. Europe is full of delightful cuisines, right? So which ones your comfort food?
Andrey Adamovich: I think Italian.
Kshitij Mohan: Italian. And, and what exactly? In Italian. It covers from pizzas, pastas, lasagnas. Which ones your fav?
Andrey Adamovich: Well, everything actually, everything because Italian is not just pizzas.
It’s a lot of other things. But when you experience the full Italian dinner, that’s awesome. That’s cool.
Kshitij Mohan: Perfect. And I’m sure, uh, that goes along with the Italian wine, right?
Andrey Adamovich: Absolutely, absolutely.
Kshitij Mohan: Perfect. Next question. You are so much into teaching, delivering experiences, right? So what, apart from teaching, what else brings you joy Andrey?
Andrey Adamovich: Yeah, of course. I like coding.
Obviously, I’m a developer in my heart, so.
Kshitij Mohan: So you’re still coding, Andrey, you still love to code sometimes?
Andrey Adamovich: Yeah. I mean it really brings joy when I can be alone and, code for like, maybe, a day that’s awesome. Of course. I like traveling apart on that. I like spending time with my family. but yeah.
Kshitij Mohan: Yeah. Perfect Andrey! Next question so what do you think people love about your teaching, your coaching style?
Andrey Adamovich: I dunno. But I think it’s honesty because I’m always honest about the technology, about the facts that, about my experience and that’s I think what buys attention. And then, loyalty after that as well because people come back to my coaching
Kshitij Mohan: No, definitely works. And one last thing, and this is definitely just for fun. So when do you plan to retire and what do you plan to do then?
Andrey Adamovich: Good question. I dunno, I guess I’ll still be coding. I’ll still be coding. It’ll never stop.
Kshitij Mohan: Oh, perfect. So basically your love for coding surpasses everything, so,
Andrey Adamovich: Yeah.
Kshitij Mohan: Perfect. Thank you so much, Andrey. This was, this was fun, and thanks for being candid and on bringing honesty in this discussion as well. So this really helps. So now getting to the real stuff, Andrey. So, we have seen you, hear, talk a lot about building right dev teams. How do you set the right processes, excellence, everything around it, right? I think, while doing this, the foundational part comes in that how do you define the right team topologies? What topology works in what scenarios, and what could be the right fit for them? And I think given your last experience, would love to hear any specific practical use cases that you must have seen and thought, Hey, that’s the right way to go about it.
Andrey Adamovich: First of all, I think the size of the team really matters because you cannot really be successful with a team of 100 developers working on the under one manager. It has to be like a team of smaller teams, smaller team leads, and it’s the only way to deliver value. Because the more people you have, the more communication channels you have, and the harder it is to deliver anything, and then these kind of chaos. Of course the size matters, but in this case, maybe a team of five to maybe eight people is an ideal team. And then of course, you as a manager, as a delivery lead or some other profession, you should set up the communication channels very well between the first of all, communication channels and second, also the boundaries. Define the responsibilities for each team and define how they communicate. What is the, basically the human API sort of between the teams. So that they work effectively. Maybe you’ve heard this book called team Topologies, and it defines different types of teams that exist. It’s super important to understand whether your team is value stream delivering team, or your team is like enabling team. They are the one that is supporting the other teams. And sometimes, especially in the big companies and big organizations, you have to have one or two enabling teams that will make sure that other teams are working smoothly. So if we go into the direction of DevOps, there’s really a trend now that people are talking about platform teams. The teams that are delivering platform for developers do their job. And well, it’s working. I’ve seen it’s working, first of all, and, it’s a really nice way of organizing, especially the big company that you have somebody who is working on a product- let’s say an application and somebody who is actually helping them to deliver infrastructure, deliver, monitoring and stuff like that. And, it’s important that this enabling team, they also should work as a product team. But it’s like the customers are not external customers, but internal customers. And, that’s super important to have.
Kshitij Mohan: Okay, perfect. So basically size and how do you define the right roles and responsibilities as what it leads to the right balance in setting topologies. Makes sense. Makes sense. Andrey, okay. And then coming to the another aspect, right? So while building all this, you and I think every other leader talks about doing this collaborative programming practices, right? Pair programming, mob programming. What’s your take on it? Right. So how do you think of their impact is on the actual velocity, quality of the overall process?
Andrey Adamovich: Actually I think there’s a lot of resistance despite of the practices of pair programming. They exist for like 20, 30, 40 years. Still there’s a lot of resistance in the industry because many people don’t really get that, you know, the pair programming in one programming is actually a learning tool. It’s a tool for spreading knowledge. The usual argument against pair programming is that two programmers doing job of one programmer at the same time. And of course, it’s not true. ’cause the other thing that happens is like you, you’re actually sharing knowledge, you’re sharing understanding, you’re sharing some ideas you’re brainstorming at the same time. And that’s very valuable. And of course, you probably shouldn’t do pair programming all the time because there are some of the tasks, actually the super simple. You don’t need another person. But quite often, a development process is a discovery process, and having another person nearby is actually quite a nice thing to have because you discover something and at the same time they discover the same thing and you have feedback and you actually are becoming more efficient in the long term because you get that knowledge at the same second you discover that knowledge and that knowledge stays with you forever. If you don’t use pair programming then you may discover something when you’re alone, but then in order to share that, you need to probably spend another hour or maybe a lot of energy explaining that thing to other person. And that’s not as efficient as pair programming as such. So many people don’t see pair programming as knowledge-sharing tool, and that’s why they oppose it. But I really like it. Of course I don’t do it all the time, but I really like sometimes to do pair programming sessions or mob programming sessions with people. And after that everybody knows everything. There’s no need to document anything basically. And you just, because everything is already there. Yeah.
Kshitij Mohan: Oh, totally makes sense. But does this also somehow brings a fear of judgment in depth? Is that the case also, do you feel so?
Andrey Adamovich: Of course. Yeah. It’s hard. It’s yeah, actually, I met people who were really nervous during pair programming. They didn’t really like it at first because and I’m personally, I’m also I’m an introvert. I also, I don’t like talking to people too much. But when you realize the value, when you realize that it’s the person nearby is just another professional and they have the perspective, that makes things much easier. But of course, some people can start it like without problem, but, some people it could be a problem to sit with another person and do something. But at least try to do that, it’s really rewarding after that.
Kshitij Mohan: No, definitely. And I think if you take the approach, as you mentioned about more of the knowledge sharing other than actually trying to find something that would add more value to it definitely. Perfect. Andrey, this helps. Now coming to one important thing that we have seen you talk about a lot and we have seen being followed is also a test-driven development practice, right? This is something that a lot of leaders today are also talking about. How do you think that TDD impacts the real code review process and I think to begin with would to understand how do you see TDD in whole and what are thoughts on this practice going about it?
Andrey Adamovich: First of all, TDD really works. That’s another misconception that some of the leaders, some of the engineers actually still have. I would say it’s not easy to start with that it’s, of course, the framework itself is very simple. It’s red, green, refactor, it’s no brainer. But, The actual depth in that idea is so cool. Not many people realize that and until they really start doing that, of course I’m not doing TDD all the time, but when I’m starting a new product or when I’m actually doing some refactoring of legacy code, then TDD is probably the default method. I’m going to look into because that allows me to go with small steps and allows me to discover the problem as I go. And at the same time, I write tests at the discovering the problem and that’s really nice journey. Of course, many engineers, all are smart people and, they make this mistake because they’re smart, they can understand the whole problem at once, and then they basically become drown and they’re drowning in all the details and they spend a lot of time, like days, sometimes weeks, analyzing the problem. But if you use the real TDD with red green refractor approach, when you define a small subset, a very small subset of the functionality you want to understand and write code for, you first write the test. That sort of defines your idea of what, how the code should work. Then you write this small piece of code and then you implement the test, or actually the other way, write the test and write the code. And then you do refactoring and this small staff, small bits approach, that’s what makes a lot of a difference for even large problem. And I’m teaching to do this myself and I usually give this, task, the bowling game. I’m asking developers to write a simple algorithm to calculate the score for the bowling game. And I mean, everybody who is familiar with bowling more or less, and they think they know how to code this problem like in 30 minutes and everybody fails. Nobody can code bowling-coded bowling scoring rules in 30 minutes is impossible. And after 30 minutes without using TDD, folks cannot tell me whether, how much time is left for them to be done, how much time is left to implement the problem. But if they use TDD and if they split the problem into smaller bits and it’s possible, then they at least can have this feeling of progress because we didn’t finish in 30 minutes. That’s obvious, but at least we have like five or six test cases that actually pass. And that’s another thing that’s good about TDD it gives you the sense of progress much faster than any other deep-level analysis that you can do with the problem. And that’s amazing.
Kshitij Mohan: No, definitely. And what do you think why people just have this first level of resistance in doing this TDD?
Andrey Adamovich: Because they quite often confuse it with unit testing and if you have lots of code yes. And, then you have to write unit tests after that, then of course it’s hard to enter and reanalyze the problem to understand what is the acceptance criteria for the problem? And actually, write the tasks. The entry criteria is much higher than it is with TDD because with TDD you write the task first. Very small one then small code, then small test, then small code, and so on. But many people think that TDD is just about unit tests and one they are forced to write unit tests for the code already exists. Of course, they think, oh, TDD sucks. Of course, they do, but it’s not TDD that’s unit testing.
Kshitij Mohan: No, Perfect. This is really great, Andrey, and, coming to bringing everything, all these pieces together, right? We talked about this collaborative programming and TDD and you totally believe that these are the right practices that helps in impacting and increasing the overall efficiency. But I think, one piece of resistance also comes in because people are usually not able to see the value it delivers. Right? They’re not able to measure the value and the overall impact on their efficiency levels. So is there any ways that, that you can suggest, so that you have seen implementing where these practices, the impact can actually be measured? Any thoughts on that front?
Andrey Adamovich: The best way to measure that is the happiness of the team.
Because when they realize that these techniques, they actually work and they give them the sense of progress. They give them the sense of actually delivering value you see happy faces. That’s probably the best way to measure the performance of that. Yeah.
Kshitij Mohan: That’s the heart. That’s the heart of a European that’s speaking now. In the end, it all matters too. The real happiness of the people.
Andrey Adamovich: Yeah, exactly. Exactly.
Kshitij Mohan: Perfect. And any specific metrics that people can track and look at while doing so, or any major impact that could be seen around that?
Andrey Adamovich: Yeah, it’s a good question because I mean it, I think it really depends on the team, what kind of metrics you use. And also personally I prefer not using metrics because especially when you start using metrics and I’m the team realize is that you’re using metrics on them. Then they, psychologically they start sitting on those metrics. They may not do it like on purpose, but psychologically they become like, aware of the being measured and then they start doing things slightly differently. So I think the success should be measured by the value we deliver to the customers. So if we deliver nice features to the customers, and customers are happy, like with those features, Then we’re a good team, then we actually have a good velocity and we are delivering value. And the way you can measure that is probably, by understanding, first of all, How many nice things you released into production. And maybe also, try to measure how these things actually being used by your customers. And then compare the numbers, right? And if you have growth there, then it’s good If you don’t have growth there, any other metric doesn’t matter.
Kshitij Mohan: Oh, no, definitely. This all makes sense. Andrey, I think this almost sums up our conversation, so this has been really insightful. Just one last thing before we sign off, we recently saw that you do a 10k run as well. You are a runner who has been competing. So would love to hear about that experience.
Andrey Adamovich: Just starting. I’m just starting.
Kshitij Mohan: No, no. Perfect. Perfect. Andrey. So this was really great. Thank you so much for sharing your time and wisdom today with us. We definitely would be seeing you sometime again in near future, talking about some more experiences and insights
Andrey Adamovich: Yeah. Thank you. Thank you very much for having me.
.png)
In the recent episode of ‘Beyond the Code’, Host Kshitij Mohan welcomes Leonardo Andreucci, an esteemed Tech Advisor and Fractional CTO. The central theme of the discussion revolves around - How does the culture & dynamics of high-performing dev teams look like?
The episode kicks off with a fun fireside chat which serves as an entrée into his personal journey and experiences. Moving forward, the discussion takes a deeper plunge into shifting to the customer approach and solving the right problem.
Further, Leonardo delves into the leadership dimension, highlighting the significance of offering autonomy to team members and cultivating trust in their abilities.
Wrapping up, Leonardo imparts a valuable perspective on what constitutes the right team culture within the developers' realm.
Kshitij Mohan: Hello everyone. I'm Mohan your host back with another exciting episode of Beyond the Code by Typo. Today's guest is special and unique in his own ways, right from being a VP of people to VP of Engineering, he has seen it all. He has been in the engineering ecosystem for more than 20 plus years and currently acts as a technical advisor and fractional CTO to organizations.
Please meet Leonardo. Hey Leo, welcome to the show.
Leonardo: Hey, Mohan. Great to be here. It's a pleasure. Thank you for the invite and yeah, I hope we can speak about interesting stuff for the audience.
Kshitij Mohan: Definitely, Leo, your experience speaks the volume, so Definitely. And thank you for sharing your time today with us really means a lot.
Leonardo: Great, great pleasure. My pleasure.
Kshitij Mohan: Perfect. So, given the kind of this unique experience of people, culture, and engineering that you bring, Leo. So today we would love to talk about how to build the right dev dynamics and culture in the right teams. But I think before we get started, we have to go through our fun fireside chat with you. That's when us and the viewers would love to know the real Leo, and that's what it aims to be. So if you're ready, let's get started.
Leonardo: Sure. Let's go.
Kshitij Mohan: Perfect. So let's go. So question one for you, Leo. Since you come from this beautiful Brazilian country, which has its own unique cultural heritage, how do you celebrate this heritage in general? What's the fun way to do that?
Leonardo: Yeah, there are lots of traditional, parties celebrations, holidays, and everything. ,I think the most famous one is Carnival. It's four days holiday in February or March. And each region, celebrates it in a different kind. The one you probably know you'll see on TV is from Rio de Janeiro . So it's a huge avenue and they're actually groups that they compete against themselves. Right. So it's a competition for the best samba school, the best parade, so to speak. And this is huge and people prepare all year for that. I actually prefer smaller environments, so I have some friends that do it, and, it's very popular in Rio and Sao Paulo nowadays too. So you have people going through the streets, a group of, I don't know, 20, 30 people playing instruments and people just moving around in streets, singing, dancing, having fun, having a few beers.
Kshitij Mohan: Haven't you been doing samba, Leo?
Leonardo: I actually played when I university for a year or so, but I prefer the listening and drinking part.
Kshitij Mohan: Drinking part, obviously. No, perfect. I think this leads to the second question that how do you unwind yourself? What's your favorite way of yours to do that?
Leonardo: For the last two or three years I've been playing a sport called Footvolley which is very interesting. I'm addicted to it. It's like beach volley, like two people in each side of a court in the sand. But you cannot use your hands. So it's feet, shoulder, chest, and head. And it's the same as beach volley. Like you have three passes in one side. Then you attack on the other side. And it's super interesting. I've been doing it for a while and. I wanna play it every day. It's great.
Kshitij Mohan: Whoa. That's fun, isn't it? Tough not to use your hands and like, do all the other stuff.
Leonardo: It's, but it's why it's so fun.
Kshitij Mohan: Oh, perfect. I think now coming to the third part of gadgets, right? Android or iPhone, which one are you?
Leonardo: This is gonna surprise you, but actually none. I'm not a huge fan. You know, I have an iPhone, but I use a Windows on a Dell notebook. So for me, it's just a tool and whatever gets a job done.
Kshitij Mohan: Whatever suits you better.
Leonardo: Yeah, I used to be bullied by my software engineer colleagues. Because everybody had a Mac and I was on my windows, and they would make fun of me. But yeah, whatever.
Kshitij Mohan: Perfect. Now coming to the fourth question, Leo, what's your favorite Portuguese saying that you live by?
Leonardo: Yeah. it is not actually in Portuguese. I've heard in the Manager Tools podcast. This is a great podcast. I highly recommend it, and it's something that I've tried to live by my whole life, and then they summarized it. It's "you must not lie or cheat or steal, nor tolerate others who do it" and it's so funny because it's so difficult to not tell little lies in our day-to-day lives. So even to our kids and everything. So I'm really trying to speak the truth at all times.
Kshitij Mohan: Ah, beautiful. Beautiful, Leo. Perfect. I think then one last thing coming to these advice is that what's that one piece of advice that this calm experienced Leo of today would love to give his younger version of selves. So what was that one piece of advice that you'd like to share?
Leonardo: Yeah, I don't think I'm gonna stop at one, but please stop me if I go too far. But the first thing that really changed me a lot is having scheduled weekly one-on-ones with each member of my team, this increases trust and you'll get to know people on a personal level, and for me, it's the basic stuff when you lead people. The second would be not to go into desperation modes like things will go wrong. You will have tough days, you will have tough weeks. You'll have tough challenges and everything, but man, it is part of the job and it's part of life actually. So just take it easy, keep working, and know that it'll pass, you know, you'll overcome the challenge that sometimes we'll overcome you. Things might go wrong. You might lose your job, or, I don't know but then there's a lot of learning opportunities when things go wrong. So even if they do go wrong, there's a still learning to have. And especially when you feel stressed about work, I don't know, one year from now, will you remember why you were so stressed about it? Probably, probably not. So just try to take things easy. And the other thing I've seen people in companies that sometimes they're really restless and I think I am one of these people that I always trying to improve things and move things forward and this not good, this not good. Not exactly perfection, but moving in the right direction, right? And I've seen people say, oh, maybe I shouldn't be doing this and I always say, yes, you should, because these are the people that move the company forward. So if you're a restless person, keep trying to improve things and never be satisfied with the status quo, like things can all go, or, things can always improve. And actually, if they're not improving, they are getting worse. It's hard to keep flat, yeah. So you either improve or you worsen.
Kshitij Mohan: No. Perfect. I think this truly is insightful and I think this totally resonates to what I personally believe that this too shall pass. So what you mentioned, right? So it's good or bad. If it's good, it'll pass. If it's not good, it'll pass. You have to just keep moving. So, perfect. This kind of really helps Leo, thank you for being so candid and being true to us. So thank you so much. Now I think getting to the real stuff, right? So you have scaled, seen the entire growth journeys of startups, right? And while building these dev teams, I think the first biggest question that everyone has is how to do more with less, right? You are always short on resources, but you would always want to do so much. I think your given experience, your thoughts on that Leo?
Leonardo: Yeah. So I think this is not the answer you want to hear, but I wouldn't worry about doing more with less. I'm worried about doing less, like how do we do less?
But we do the right thing it's having laser focus on what you really want to achieve, what you really need to do right now. And for me, this goes through talking to customers all the time. It's something you've heard before, but go out of the building and talk to customers. Understand what you're really trying to build and sometimes in a software product, it's better to have fewer features, but features everybody really uses than have feature creep and other things that nobody uses. And then it gets so complicated, then you don't know where to start. And also to do things that don't scale. Because when you're doing things that don't scale, you are learning a lot and you're doing things manually. So if you're doing things manually, it's much easier to change things right, it's easier to learn and easier to change. If you want to start with an Excel spreadsheet. Go ahead. If you want to start to type form or the low code or no code or just a lead form, and then you call your customer and try to solve their problem offline, that's fine because then you are learning and you're actually working on the thing that really matters, and okay. When you get to the point that you cannot, you have so much demand that you really cannot do things manually, then you have a very good problem you start thinking, you start to focus on engineering and scaling and everything. So that's my point. And I think not that many companies and products are at this stage that, oh, we need to scale to millions of users. So let's focus on solving the right problems.
Kshitij Mohan: Oh no. Perfect. Rather than doing more with less, think of doing less, but with the right set of attitude and things coming together,. Great perspective view. I think this totally aligns, right? So while doing all this, while being in that mode of building and doing everything together, there are two values that I think everyone talks about is autonomy and agility. Because this is what when the right combination fit in is what leads to high-velocity teams. But your take on that, because that's what the biggest challenge is, how do you balance this stuff together?
Leonardo: Yeah. So I've been studying a lot about self-directed and self-managed teams. One important thing to clarify is like a self-directed team is a team that the team defines where to go and this is not the reality of many people, right? When I talk about self-managed teams, what you usually have is somebody defines a direction, probably the CEO or the board or the stakeholders or whomever and then the team organizes themselves towards that goal. So these are self-managed teams and what I think really works is like having boundaries for action. So let's agree as a team or as a company, what can the team do by itself? What does he need to ask for permission? What are the things, like, what are the values? What are the things that we should be working in which way should we be working? And this needs to be aligned, right? So I always say to have alignment between the team and leadership and what should the team do by themselves or not. And another thing that really strikes me is that I've heard it recently, and it's treating adults as adults. So you are hiring a very knowledgeable people. You are hiring knowledge workers. You're hiring people that have studied a lot to be where they are. So you don't know that much. If you have these people, why not trust them to do the right thing? So I really believe in autonomy and having people decide on how they work. How do they approach problems and how do they get stuff done? Because after all, they're the experts here, so this is important for me. Yeah.
Kshitij Mohan: But I think, as you mentioned while doing all this, there is always this difference of opinion, right? People coming with different perspective, different thoughts. And then I think that the biggest challenge becomes in that how do you make people agree to disagree or commit to one cause? And then just moving and going about it? How do you think is the right way to go about it?
Leonardo: To have people agree or to decide the way to move forward?
Kshitij Mohan: Exactly. Because everyone comes with their own set of thought processes. They think, oh no, this could be the right way, or this could be the right way to build, the right way to move. How do you bring those thought processes in line?
Leonardo: Yeah, I think the first perspective that not everybody really thinks about is how much time do we have to make this decision? What's the deadline? If the deadline is five minutes, I would decide right now and we'll not talk to anybody because there's no time. So, it's not common, but it might happen. Okay, so assuming it's not a five-minute decision, how much time do we have? And then, I need to decide which people are gonna be involved in this decision, right? So it's my direct reports or is the whole team, or is the whole company? And this, depending on the decision could be more people or less people, right? If you have more people, you have more, buy-in from everybody. But probably the decision takes longer to be made. So I have to balance this. And then another part is, Okay. If we know the people and we know the timeline, how are we gonna reach a decision? Is it majority through voting? Is it consensus? Is it give information? But I decide or give information but that person decides. So there's actually two decisions should be made. How are we gonna risk the decision? And then the decision itself. And I like consent-based. So somebody would bring up a proposal and say, okay, here's the decision I wanna make. Is anybody strongly opposed to this? I'm not asking would you do it differently? Maybe you would do it differently. But are you strongly opposed as the way I'm proposing or anybody's proposing? 'cause that's the way we move forward a little faster, right? It is not, I wanna have it my way, but it's this way is fine with me. I like the good enough for now, safe enough to try approach. So this is good. And I also like to stress the solution with questions. And to think if it can evolve, because we probably won't get it right this time, right now. But can it evolve? Or if we uncover new perspective or new things or new challenges and the environment's gonna change, right? Things are gonna change, technology is gonna change, our customers are gonna change, but can this definitely decision architecture or whatever, can it evolve? And if we have a path forward, great. The problem is making a decision, if we uncover it was the wrong decision, then we need to throw it away and start all over again. So these a bad one. But if you can evolve, that's fine.
Kshitij Mohan: Sure. I think, but you must have been, in a situation where, hey, you thinking X, but the consensus comes on y then any specific experiences that you had on this? So was it my way or highway then?
Leonardo: Yeah, but I've been proved wrong many times by my teams. So I usually trust the teams and if I have some people that I really trust that I know are very confident and, and they're telling me the other way to go is the way to go. And if I cannot have a strong argument against it, I'll go with the team. And also depends who's gonna be accountable for the outcome of this decision, right? If the team is responsible, is accountable for it, okay, let's do it. It's trusting their people. Treating adults as adults
Kshitij Mohan: Exactly. Coming to the autonomy. So that definitely has to be, has to be felt in. Perfect. I think one last question, Leo. So we've been talking about people in engineering and everything together. So what's the Leo thought of that Utopian or the right culture for dev teams and every role that a stakeholder has to play in building that piece up? So your thoughts on that, Leo?
Leonardo: Yeah. So the first thing I like to think is what's a good software engineering teams, right? In terms of skills so I like to have, I don't know, five people in teams. They should all be great software engineers, great in writing code and everything. But, I like when they are great software engineers and they have an additional skill. So imagine a team of five that one person has good product skills and the other has good cloud skills. And the other is very keen on agile processes. And the other one's very good on metrics. And the other one's very good on quality. Man, this is a dream team for me, right? So
Kshitij Mohan: Yeah, that's a dream team!
Leonardo: Everybody will, everybody will write great software, but they'll get this adjacent skills, would be very helpful to the team. And then when I think about leadership and managers and everything. I really believe in servant leadership. I think the manager is more of a facilitator, right? So I don't think the manager is any better than the rest of the team. He or she just has a different role and this is very important. Like, I'm not superior. I might have more experience sometimes not I might have a broader view of some things, sometimes not. But I have a different role, so I'm not any better than anybody on my team or on my company just because I'm a manager, a director, or a C-level or whatever, right? My role, my position does not define me. So this is important, and I like the manager or the leader also managing the system, not the people, and then reducing the information asymmetry and reducing the power distance, because sometimes you're a manager, but you have more information than your team and then you wonder why is your team not making the same decisions as you would,? Man, because they don't have the same information as you have. So maybe if you give them all the information, they'll get you to the same decision or to the same thinking. So always try to give us all the information I can, I really am super transparent, and I believe this is a core value in any company- to be super transparent and also listen to the team, right? Most of the time, if you ask your team what are the problems they have, they know the problems. And they can tell you what the problems are. They need help solving the problems, but it's not rocket science. You know, like talk to people and they probably know 10 things they need to get to improve. So yeah, let's discuss about it and see how myself as in a leadership position can help the team overcome these problems.
And I think this helps solve the basic stuff. If you do resolve all the problems in the team, you get to a very good position. And then the second part is, okay, let's raise the bar and team. We're in a very good position right now, but it's very different in a retrospective meeting, you ask "Hey, do you think we work together?" And people say, yeah, we work together. Well, our team's good. We get along fine. We achieve great results. The product's going, this one kind of question. But then you ask, "Are we the best software engineering team in the world?" Probably not. So how could we be the best team in the world, right? And then people will start to think like, how to go further along and how to be much better than they are right now. So yeah, it's all about how to frame the question to invite or incite people to be better than they are right now. So,
Kshitij Mohan: Right. So let's pass the right information, push boundaries, I think that's what collectively builds the right ecosystem.
Leonardo: Yeah, exactly.
Kshitij Mohan: Perfect. Perfect. Thank you so much, Leo. Thank you for your time today. This was great, insightful. Thank you for summarizing all your 20+ years of experience in these fine bits of conversations. So thank you so much for your time today, Leo.
Have a good day. Thank you.
Leonardo: Yeah, no, you're welcome. It was my pleasure. I hope it's been useful. Super, super happy to contribute.
Kshitij Mohan: Thanks, Leo.
On our third episode of ‘Beyond the Code’, Host Kshitij Mohan, founder of Typo engages in a thought-provoking conversation with Denis Čahuk, a Tech leadership coach that centers around implementing a human-centered approach for building efficient dev teams.
Denis imparts valuable wisdom on fostering psychological safety within teams and achieving faster delivery of the products. He also delves deeper into event modeling and the role of visualizing the entire impact and leading dev teams.Lastly, Denis sheds light on why software engineers should prioritize developing soft skills; beyond their technical proficiency.
Kshitij Mohan: Hello everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by Typo. Today we have a very special and unique guest with us. Although being a part of the startup ecosystem for more than 15 plus years, Denis brings a different set of expertise into this entire ecosystem. He has evolved his abilities and now helps mentors, engineering leaders to develop this growth mindset. He has a very unique approach, which he calls as a human-centered approach that he brings into the ecosystem and helps build efficient dev teams.
I think we are all fascinated by this concept and would like to hear from the man himself. Hey Denis, welcome to the show. Thank you for your time today.
Denis: Hey, Mohan. Hello to our listeners, to our viewers.
Kshitij Mohan: Oh, yes.
Denis: Thank you. Thank you for inviting me.
Kshitij Mohan: Perfect. I think, firstly, Dennis, we are all fascinated by the concept that you are trying to bring in, and we love, by the way, your detailed insights that you share in crafting tech teams, so that’s really helpful.
And secondly, we have seen that happen. We just love this style of yours, the beads that come in, and I think a few words, we would all love to understand the significance of this and how it adds to your persona.
Denis: Well, I’ve always been a recovering left brainer. You know, I’ve always been very analytical and there came a time in my life where I can no longer solve problems by analyzing them. So I had to experience something outside of my comfort zone and on my way of personal growth and personal development. I sought out yoga and yogic and Ayahuasca retreat, here in Italy, Europe. And that was possibly one of the hardest and, and not just hardest in the sense that it was hard.
There was something challenging, but prior to going it seemed that I am signing up for something that is impossible. That’s gonna be impossible, that’s gonna be for whatever reason, challenging and very difficult. And I just had a lot of irrational fear from it. And I carry it as a reminder that I did it.
That even though I thought it would be impossible, very challenging, that it’s way outside of my capabilities. I’m still here and I’ve grown a lot from that experience.
Kshitij Mohan: Oh. So I think great story Denis. It’s a reminder of you did it and I think. That’s how I think you might have added this aspect into your entire approach of building the teams as well.
Denis: Absolutely.
Kshitij Mohan: Perfect, Dennis. I think, to get started with this entire theory and the concept that you bring in, right? I think the first foundational thing that always comes in is psychological safety, right? How do you ensure that you are able to impart or set this psychological safety within teams that fosters productivity and transparency?
I think that’s the most challenging part that most of the teams face today. How do you do that? Or what processes do you think you follow around that?
Denis: It is one of my core, let’s say the aspects of why I’m not just calling myself a trainer or like an agile coach. I don’t like labeling myself an agile coach.
The coaching that I bring is life coaching. But it’s specifically targeted to a tech audience. And I like to separate that out because I’m not here to coach you on how to use Jira, What one story point means. I don’t particularly care about that nuance of, let’s say, methodology or just tooling.
What I care about the people who use this and one of the aspects of my coaching, the life coaching aspect is that whenever I’m working with a team, I’m also working behind the scenes one-on-one, privately with the team lead. I might instruct them okay, I have a feeling if I ask them, they’ll remain silent.
That’s your feeling as well. And that’s usually the first signal, the deadly silence. That’s usually the first signal that the team doesn’t feel safe to speak up. So it’s very hard to ask a team, Hey, is there anything that we could improve? And they’re silent.
They don’t say no, it’s just silence, right? So it’s not true or false. It’s true, false, and null right? And, you want the process to come to a Yes. And then follow up with, okay, where should we start? Usually, leaders get stuck in getting null back and they don’t know what to do with No.
So, one of the first things we do is even check if that’s a problem. Usually, it is, but it’s not on the surface. So usually I get to know a team before we even get anywhere close to it. But I can sense that there’s emotionally, psychologically, some boundaries, right?
So maybe they’re stressed out, just maybe they don’t have the cognitive load to even be thinking about showing up for the training calls. Maybe there’s just something super urgent going on in a company. And one of the things we do is because I’m working on the team from both sides, with the leader, and with the team. Right. We are working on the team from the outside and from the inside at the same time. And one of the things that I might ask, once we know that psychological safety is something that we wanna work on, I might ask the leader privately, Hey, can you like model a behavior of saying you don’t know?
Or could you model a behavior? Could you do me a favor? Could you just, you know, whenever you encounter something that you don’t know about, just speak up and say, Hey, I don’t understand this. Could you explain it to me, Right? So that the leader models the behavior by example, immediately in front of the team because it’s possible that they, that if the team doesn’t feel psychologically safe, that then patterns start emerging.
And then the leader also doesn’t feel psychologically safe, to be vulnerable with the team, right? ’cause they, they might be playing off of each other to no fault of their own. Maybe it was left there by somebody who hired the original team and then they left and then that culture stuck and then everybody just got replaced one by one.
And then nobody knows really why that feeling is there. And nobody really set it up, but nobody’s really working or understanding of, is this a problem? Is it okay? Like, is this normal? And then the teams usually get accustomed to just thinking this is okay by default. And I come in to say, Hey, well, do you want it to be this way?
It’s like, no. But I don’t see what we could do to improve. Right? And that’s then the first step. Okay, what if we could improve on it? Wouldn’t it be better if we could do this and this and this instead?
Kshitij Mohan: And based on your experience, you have found a breakthrough with the leaders easier or breakthrough, the dev teams easier.
So, because I feel that has to be somehow top to bottom driven, right?
Denis: It’s complicated. You know, like when I’m talking to the leader, he’s also not on top right. I’m not talking to the most technically savvy founder, right? I’m talking to the leader of the team, so even they are not on top.
So they might be experiencing this also as a downstream problem with their leader. So I can’t really go to the source all the time. Sometimes it’s, I’d rather bring in another, Another coach who does executive level coaching or like founder level or board level coaching, depending on the type of the company.
And I just focus on the team and I essentially give a commitment to the team of improving the team without really, ’cause I can just get lost going down a rabbit hole, traversing the entire vertical of the company. And, the further away I get from the team, the harder, you know, it just gets at some point, it just gets organizationally.
So, such a large network of communication issues that change just becomes exponentially harder and harder to impact back down to the team.
Kshitij Mohan: Another perfect use case of human emotions are simple, yet complicated. So I think we totally get where you’re coming from.
Denis: But I don’t wanna dodge your question.
You know what’s usually the simplest is speaking up about it. I will speak up, it’s like, Hey, I realized that you and I decided that this was a problem and, you didn’t speak up. Like just now, would it be okay if we talked about and then I sort of model that to sort of weasel it out, but then if I know that if I leave the room, they won’t continue that behavior, right?
Because the safety isn’t permanent. I might bring it in temporarily so that we can discuss it, but it won’t establish itself permanently. Usually what we do is I would then go talk to one of the team members one-on-one to even see whether they want to improve on it. Right? Because you can always solve it from a different direction.
We can solve it from the direction of, if you’re working in a team where you don’t have that, you can sort of model that behavior bottom up. Not to the CTO level. But at least with you and your immediate peers and with your leader because as far as we as human, as employees are concerned that is your immediate impact radius. Your leader, your manager, your supervisor, your team lead, your tech lead, your engineering manager. They are the one human being other than yourself, who has the biggest impact on your career at this company.
Kshitij Mohan: Exactly
Denis: Right. So at least with them, That’s fully in your control, like how you respond to them and what kind of behavior you model yourself that we can solve on an individual level.
But usually, I’m not hired to then coach each engineer individually as well. We sometimes do that outside, of the company program then if they also hire me individually. I even just now had a, a few months back, had a case where I was coaching an engineer. For a very long time, one-on-one and then the team I was working with, they were hiring and I suggested, you know, they’re like, I have someone here I know they’re really good, they’re vetted. And I happen to know that they’re a cultural fit because I’m a fit with them and we are a fit. So I think if you just met in a meeting, you could, you could decide on whether to hire or not within 45 minutes.
Right. And then they ended up hiring that person, you know? So even that, you know, connecting the dots, playing, sometimes I’m playing matchmaker. And then we continue it from that route because then it’s also easier because if I had worked with them, the employer also knows what to expect because I might have trained them in exactly the same ways that I’m training the team on.
So they have, not only do they know the curriculum, they didn’t even miss out on anything. And they have a head start because we’ve been doing it for a lot longer.
Kshitij Mohan: Perfect, perfect. Interesting. Dennis. So, coming to the point of two spectrums, right? So one is where this entire behavioral part comes in, whereas the other aspect is where every team, every company today is in the kiosk of releasing things fast, right?
So in turning into somewhat feature factories, I think that’s a term that’s going on today, right? Yeah. So how do you suggest to balance this out, how CTOs and the leaders could actually stay away from this trap?
Denis: I think staying away from the trap is not a good strategy. I think you should be able to go into the trap, realize that you’re trapped, and then safely get out.
Right. Because if you wanna avoid it and then accidentally step in, you still need to know how to get out of the trip. Right. So I think if you’re talking about it strategically, you would need to know it is like a first aid kit. Like we are not only doing prevention, but we are also gonna teach you what to do if it does happen. And because you know how much energy you need to invest to do, I don’t know, to revise someone or to give them first aid. When you understand how complicated and dangerous that is then you’ll do everything in your power to avoid that being necessary. Right. But it requires both components.
Right. So if I use this sort of first aid parallel to the feature factory, all you need to know a feature factory is a cost center. A feature factory is a subunit, a department, or even just a team or maybe just part of the team that is organized in such a manner that it is optimized for process.
It is not optimized for outcome. Because it is being perceived as a cost center. So if it has a high cost, we want as much output as much as possible from that unit, from that team, from that sub-department, squad, whatever it is drive whereas a profit center is pushing business KPIs.
And so they know that the salaries are fixed and the other fixed, you know, the other cost of goods and services provided is server costs, license fees, and anything else that might be necessary for data movement or security or just ongoing development as a sort of stable, but unpredictable cost, let’s say.
It is important to emphasize that first, you need to know what a profit center looks like and what a cost center looks like. And then you need to be really honest with yourself, which one you are. If you are a cost center and you don’t want to be, that’s important.
Like you want to, you, there has to be some motivation for you to want to become a profit center. Then we can talk about what you asked me, how do we make a profit center out a cost center?
Kshitij Mohan: What’s important aspect is realization that you are a call center and not the profit center.
Denis: Yeah, yeah.
Kshitij Mohan: No, definitely. And, in your experience, so generally how do you ensure or what process you follow that where people actually believe in this. Hey, we are not at all measuring the impact. We are just kind of running behind releasing it. How, how do you do that?
Denis: It depends.
I think we can’t look at it specifically from the outside, you know? And say, Hey, oh, profit center, cost center bad, and you just go around the company and cost center bad, you know, and just point the finger and just like, you’re a cost center and you’re a cost center.
Everybody’s a cost center. No, it’s really important to not look at things as revenue streams, but as value streams. You know, hotels, luxurious hotels really understand this, that, you know if they hire a driver to pick you up from the airport, that person is part of a value stream. They provide value.
They might not immediately provide revenue, you might not even exchange money with them other than giving them a tip. Right. So they’re not an immediate revenue center, but they are part of a value stream of a bigger profit center. So it’s important that when we’re talking about a profit center, it’s usually not a unit. It is a network of collaborative strands of value streams that are sort of branching out from a core revenue stream, and it’s important that, the profit center who is sort of embodying that revenue stream, owns that revenue stream. So if this is a engineering team that builds a product, they own the business KPIs for the product being profitable.
So if you have a product department and the engineering department, These two teams or units of organization are divorced, right? So it’s like I have a task and on weekends you take care of the task. And on weekdays I take care of the task then that, that’s a divorced value stream, right?
So if the product team owns the value stream, the revenue stream and the engineering team just provides a value stream where they just minimize the cost of the engineering team because the cost engineering team is also being used for other product revenue streams, and then that’s defacto a cost center that cannot become a profit center. Right.
Kshitij Mohan: Definitely
Denis: It is the, it is the product team that needs to absorb the engineering team into itself. Right. You can’t make that engineering team in isolation and just say, Hey, you know, create new networks where you no longer when, when you’re working with this product owner, you’re always a cost center just because of the nature of the relationship. So the only way to get out of that is to fire the product owner, you know, in the context of I will no longer service your tasks. Not fire as in leave from the company, but fire as in, okay, I’m now setting up a vertical. I’m vertically assimilating this engineering team into the company by giving it a dedicated product stream or value stream that they own. Right. And usually, this happens on the wrong end. Usually, this first happens on like DevOps or DevSecOps. You know, when they, they become the owners of security and certificates and how much we’re paying AWS and then they own that and then they actually become a profit center because they might actually optimize, hey, if we, instead of, you know, having three sales ops people who are also engineers, we can just promote them to actually be just full-time engineers and do it to the cloud and do this and do that. Then they become a profit center in that space. But in the context of the company, if they don’t control the entire KPI of providing value to the users. And then understanding how the value is then being captured as revenue, and then measuring that and optimizing that.
You need a small team for that. Yeah. And then a small team that’s part of a big organization. That team, even though it’s really flat, needs to be very high up. You can’t have seven managers above them because that is exactly what will diminish the capability of becoming a process.
Kshitij Mohan: You contextually need to get into the details and then find out how exactly the system works. You know that definitely works. And just going one level deep. So by talking about this, efficiency, understanding the impact of, let’s say, what we were talking about, right? So there is this interesting approach of doing releases with event modeling, right? So then try to understand, uh, all the events and then design and define our information systems.
I think that’s something we would also love to know more about, right? So you have been doing that and you know, where the challenges come in, what the effectiveness looks like, and then that’s something. I think we and the users would all love to understand this piece.
Denis: So how much do you know about event modeling? I can talk about this ad-lib for hours, but it would be we practical to know how do you see event model? What do you think it’s?
Kshitij Mohan: Yeah. So I think the simplest way would be for us, as well as just to keep us context in the conversation, would be that, firstly, how simplistically do you see when modeling, and then obviously second how do we design and implement it, which comes with the second.
The first part, what I see, is as a very simple understanding, the events that happen. And planning so that they happen and fall in the right piece. That’s what very simplistically, I would say event modeling is, but yeah, what your thoughts would be.
Denis: That was what I thought event modeling is, so that was my sort of version 1.0 understanding of what event modeling is until I met the person who discovered event modeling Adam Dymitruk.
I was set up three hour podcast episode with them ’cause we just went deep on event modeling and then I realized that event modeling is a sort of upgrade over typical agile processes. Right. So it’s not so much about designing a spec for events, event schemas as much as it is managing a project that has data flow.
Right. So event modeling is more the idea of rather than if, let’s say Kanban is the flow of tasks through a team’s pipeline then event modeling is the flow of data through the lifetime of creating a software project.
Kshitij Mohan: Got it.
Denis: So like if I have a data point that needs to go from point A to point B, how does that data flow in version one?
How does that, and then when I release version two, how does the flow change? And when I release version three, how does that flow change? Okay. We have a new feature now. Does one of the flows split? Is it a new entry point? You know, are all features just essentially. Are we a feature factory? And you can tell from the event model because it feature factories have a very specific structure of a event model. You can spot that a feature factory is a feature factory, which is by the, the topology of the, of the event model because every stream is being completely isolated. There’s very little overlap. And you can essentially build seven features in parallel, independent of everybody else’s, data flow, except for maybe Feature flags and identity management, authentication, security. Yeah, the common modules. Right. So if you see that like it’s completely separate like this data flow is completely separate UI and that data flow is a completely separate UI. And this one has, and this one has, this one has. And then we just piggyback on synchronizing this, these two data points at the very end there because it’s user related as a feature factory. If we can decide to just not build six of those seven features, focus on one, determine if it has market value, if it has market demand at first, and then if it’s actually valuable to us, if we can then, if it’s valuable to the users, and then if it’s valuable to us, if we can capture revenue based on the value that it provides to the user.
Right? And then you can flip it from an event model, just a typical agile. And what it helps with really is the slice, to do vertical slices across planning, because you’ve probably seen this before, where if there’s a typical like let’s say Scrum -esque Scrum inspired story and you put it in Jira you have this idea of, well, what does this look like when it’s finished? But the tasks and the specs are talking about how to create it. But there’s nothing, there’s no communication. Very rarely you might, the good teams have goals and acceptance criteria. The great teams don’t even use stories. Right. So it’s not an upgrade you use something completely different. It’s this idea that if you’re planning your tasks with user stories, well, the story doesn’t say how it’ll evolve. If you’re doing continuous delivery, it doesn’t specifically specify how it’ll end up on production.
It just says what it looks like when it’s done and how, what are the technical details to complete it. But what we should really care about is if I add this feature, what data flow that’s already there, is it piggybacking on, does it interrupt the data flow? Does it augment the data flow? Does something that was previously atomic now become a saga? If this crash is conducting crash independently, you don’t see that flow because you, in a typical story system, you might just be adding things, but you are not actually adding them so that the old code is…
Kshitij Mohan: Together to reach that one common outcome.
Denis: Exactly. Right. So, it’s as if your source code repository was also event sourced. Scrum creates that illusion that if I add seven features then I add the eighth one. I won’t touch the source code of the other seven, and I’ll just append right to the source files.
That’s not the case. Usually you go back and you start touching stuff. That’s what usually. But like badly managed non-modular, like big ball of mud monoliths are every feature you add, you need to keep touching something from the other features that are already in the system. It’s not an append-only source code repository.
Kshitij Mohan: Definitely.
Denis: And that’s what the event modeling tries to sort of highlight. It’s like, hey, if you’re building this feature and you need to touch a line of code in these nine other things, this is probably not the best way to go about it. But usually, this is not visualized. Right. And it’s only visualized partially, very temporarily in one engineer’s head, and only when it’s too late to course correct. When they’re already working on it and they’re stuck on something that would be the correct time to course correct in order.
Kshitij Mohan: But it’s to realize that you would have to have the context of the entire system. And I think that’s where biggest challenge comes.
Denis: And the engineer has that when they’re writing the full end-to-end or integration test. So at least one person at some point will have that, but it’s usually too late in the project. Event modeling brings that further forward, but there’s a trade-off. The trade-off is you can’t really use it well with other project management methodologies. Like the event model has to be the main management methodology. Because the thing is that I really recommend beginner teams to start adopting is, well, now you see what it looks like, and an event model doesn’t just have events on the diagram. It has a historic flow of data. When the user logs in, here’s the user’s credentials, and then here is how the user’s credentials flow to the system. They appear temporarily here, they get transformed, their own account. Then that other piece here, that becomes a session and then this session at some point dies, and then they have to go back and do that thing again in a different kind of flow, and then that’s visualized. And this can also be the case for a bank account or an order or you know, it might go into the system and then we determine that, hey, actually we didn’t fulfill this order, but we forgot that we didn’t fulfill this order and now it’s been two months. Now it’s inappropriate to fulfill the order. So actually we need to go through a different flow but this is hard to express if you don’t think about your features as a data stream. Usually, features are a stream of development focus of, okay, where should we put engineering focus this month? Rather than, how are we adapting the data flow? And what I recommend teams do the, you see the entire diagram, the events are not, the only thing on the diagram, what’s in the diagram is the dependencies between the event streams, the consequences of the event streams, the side effects of the event streams, and for each UI element you can see on the subcutaneous level. So it’s that invisible stuff just beneath the UI, non-technical stakeholders usually call that long darkness of backend stuff that you guys do that we can’t see.
Kshitij Mohan: The black box.
Denis: It’s exactly expressed on the diagram. It’s like it becomes visible. Here it’s under the surface. This is the backend stuff, and you can see it because what we’re building is the flow of the data.
We’re enriching the flow of the data. And what we you can do with event modeling is because you have them left to right sliced on a timeline, following the age of the data stream, you can decide not to start the project from the left side. Usually what teams do they start the project from the left side of the timeline of the data. So if you have a new greenfield project, you know, day one for data points are user registration and login. And then that’s where they would start the project following the age of their data. Whereas that’s usually the most commoditized part of the system that not the engineers should really be wasting time on. But then with the event model, we can say, well this is how it’s gonna end up. That young data age stuff where we are registering people, we’re not gonna waste time on that. Let’s start on the right side. Let’s start on the right side where I have a UI element that shows something really important to the user. You know, if I’m building Instagram, that might be the users feed. And when they come up they need to see a new feed every time. Let’s start with that. And on the subcutaneous level, let’s just fake that. Let’s just serve them random images until we connect the dots on the data pipeline behind the scenes. And let’s make that version one and let’s deploy it. And you can explain that to somebody who is non-technical by just visualizing the event model. But saying here’s the UI updates when this, what I call a projection, which could be and if you saw. Now that Twitter X whatever, twitter’s code was, the algorithm was published on GitHub. And you can see that, they have this sort of same similar system where they’re creating they’re not computing your feed as you log in. They just have it ready as a projection. So if I told you this is what the projection, this is the schema of the projection, looks like if I create a fake UI with a fake instance of that schema, I can create a prototype, no problem. I can create that prototype, possibly even using low code or no code solutions temporarily while the backend team is solving that really complex issue that where the, you know, the seven streams of data meet and then they, something complex happen.
You might actually have something to show and then the project manager can say, well, you know what? For every UI element that we need to update, I want us to at least fake a lot of non-important stuff while you guys are working, like cracking the nut on this really big important thing. I still want us to see progress so that I can, you know, run tests or give it to the users or I wanna know how far away we are from the point where the users notice that we are faking data and that the next valuable step is giving them the real data.
Because if you’re saying no to all that, if you’re building software products, especially as a startup but you’re not even considering that option where version one is a feature Complete, fully blown enterprise-level version of the product. You are a year, 18 months behind the market.
Kshitij Mohan: Yeah. Definitely. I think this kind of helps into detailing, breaking it down, visualizing the right way.
Denis: The breaking down is still, you know, it’s still here. The model doesn’t break down the problem. You still need to ask a lot of questions, so you still need another process.
Event storming, you can still do naturally. And then just instead of leaving it on a board, that then becomes maybe an architecture diagram. You continue storming and you just continue it into the event modeling flow. It’s like, okay, well we are in event storming, but rather than just talking about events, well show me what UI disappears on and then what do we, what do we call the data set that the UI is using?
And okay, who can possibly cause this data set to refresh? Okay. How can the user cause this data set to refresh? How often does that happen? Does it really need to refresh every time the user does this? And then that’s how you have these kinds of conversations on a completely non-technical jargonistic level.
And then you can decide to, you know, There are two, like Miro is great for this ’cause you can just zoom out, create a frame for it, and you can zoom in. And then when the non-technical stakeholders leave the room, the engineers can just zoom into one of them and then add the, the JSON Fields and the schemas.
And then I’m gonna have an entity direction diagram in here. And then when they come back into the room, you can zoom back out and it disappears.
Kshitij Mohan: Perfect. Perfect. Dennis, I think this really helps. Super insightful on how visualization can definitely help and that leads to I think, one last aspect that we would love to talk about is these, the soft skills that you bring in this entire game, right?
And one of the important aspects that helps you grow and progress over time as well. So, quick thoughts on what do you think are the right set of things a leader, a manager should be focusing on, on the software scale aspect?
Denis: I like to think that engineers are very intelligent people that everybody really understands that this is really important. So the question isn’t so much, you know, what should they be working on? And should they be working on their soft skills? I think the really tough question is figuring out instead of what, right?
Right. Because people might be thinking, oh yeah, I’ll learn soft skills if that’s replacing some of my boring meetings or if it’s replacing some of my annoying one-on-ones with my manager. I will learn soft skills if it gives me a little promotion. If the, instead of what is really benign, And sort of passive and on the side.
But I think if you really wanna take your tech career seriously and if you wanna take your, as a leader, as an engineering manager, as a tech leader, uh, or even just a product manager, if you wanna help your team hold themselves accountable, then if they’re behind on soft skills or if they think that that’s the biggest step forward and usually it is.
Then the soft skill training has to happen at the expense of technical specialization, and that’s the tough decision. It’s like, no, don’t learn the new framework. Leave zig and rust alone. Don’t do that new greenfield project. It’s like whatever technology we’re using, it’s good enough like to just use boring commodity software.
And better yourself as a human being. You know, rather than following, trying to follow the trend and getting really anxious about, oh, the AWS has a new certification
Kshitij Mohan: Yeah, everyone worried about the new tech being released every other day
Denis: And, oh my God, and ChatGPT and, now it’s no longer considered private and secure.
So now I need to learn link chain and what’s length chain and. What is it like? Like what I need to catch up on seven years of linear algebra and calculus. It’s like, no. It’s like those tools can wait, but soft skills can’t. Soft skills are your highest predictor of movement in any kind of organization.
Soft skills can help you land positions in FAANG companies, even if you’re technically not really competent. Like it is that impactful. Like, okay, the FAANG companies might be a little bit stretching it ’cause they, you know, if they have nine rounds of interviews with you, they might call you out on something that you actually don’t know.
But you might learn it on the interview. If you know how to prepare, you might, because a lot of engineers just going into interview and they get asked a question and they just freeze. They try to think themselves. Whereas with somebody who is not engineering savvy or didn’t spend a thousand hours on leet code, it’s a huge waste of time if they’re have very good soft skills.
You know, they might call out on the interview, Hey, like this is really awkward, but I don’t really know how to solve this. So I think that’s it for the interview, but could you gimme some pointers on what I should look up or where I could learn more about this and they might actually give them immediately material to look up and learn.
It’s like, do you mind if somebody who is sort of well versed in soft skills might ask, okay, well actually would you consider it cheating or would you mind if I just looked it up now and see where we can get to and like 20 minutes, right? Because that might be a much more. Warm and charismatic and likable approach to just having the interview.
If nothing else, it calms down the interviewer and you should get them on your side and that can go over a very long way. But now I’m talking about this from sort of a freshman sort of intern level for a team that’s has been through all this and there are professionally decoupling has already happened.
You know, the team is now part of this team. The team has this manager, it has this tech stack. So there aren’t as many reversible, malleable decisions anymore. That team also has a lot of cultural depth. So the real question is not should they train soft skills. The question is obviously yes should they train soft skills?
But even if I, even if a team member like really goes up and wide on soft skills, is there anything on the team that prevents them from applying it? That is what I would focus on as a leader. It’s like, is there anything in our culture that prevents somebody who is well-spoken, who is very friendly, who is very open and helps everybody?
Is there anything in our culture that prevents them from embodying that? Like would they be attacked for doing that? Would they be mistreated or ridiculed or, you know, I come from the Balkans where we have this sort of, proud view of, you know, if you don’t know something, you should have a plan.
If you don’t know how to make a plan, you’re probably incompetent, right? So you should hide. You should rather than talking about your problems, about your incompetence, you should just read up on it and prepare for the next meeting. It’s sort of Spartan approach to a more competitive kind of collaboration.
Whereas, you know, the, one of the hardest things that I do with like C-level coaching or just, senior management is I’ll just keep asking them questions until somebody says, I don’t know. And often times people can just, just spend hours running in circles and they will not say, I don’t know.
Right. And then I might even call them out as a coach and I say, look, I’m already asking you these questions because I wanna come to the point and I’ll say it out loud to them to their face. I just wanna get to the point where the answer to the question I’m asking is, you don’t know.
I’m just waiting where we have to go so that people will talk about that. And usually, it’s talking about engineering with somebody from product. Hey, Mr. Product, how long do you think your engineering team needs to build this? And then they will say, I don’t know like they know.
And then once they say that, I might ask them, okay, well what do you think, the revenue estimate is once they finish this feature and implement it? Like you’re head of product, you should not revenue estimate. It’s like, what do you mean? They might have never done that before. They might have only done it in one way. It’s like, figure out what the next product cycle is and then just try to motivate the engineering team so they deliver it. But it gets in the way if that prevents the other arrow from pointing out upwards, which is okay, well we need to have an estimate for how much revenue it’ll provide. cause if you don’t have that, we don’t know what the upper bound of how much cost we can, we can endure building it.
Kshitij Mohan: Yeah. So I think in this example, you touched everything that we talked about, right? From the psychological safety to visualizing the entire impact, and I think coming to the soft skills.
So I think this really sums up our discussion, Dennis. This has been really interesting to hear a totally different perspective on building and leading efficient dev teams. So thank you so much for your time today, Denis, lovely having this conversation with you.
Thank you so much.
Denis: Thanks for inviting me. I really enjoyed it. Great questions.
On our second episode of ‘Beyond the Code’, Host ‘Kshitij Mohan’, founder of Typo welcomes Gregor Ojstersek, CTO at Zorion, Singapore. The focus of their discussion is on establishing strong foundations for engineering teams.
Gregor places significant importance on creating an effective hiring process and highlights the value of assessing soft skills in potential candidates. With remote work becoming a norm, he provides valuable insights on cultivating the right team culture to ensure successful collaboration and productivity.
Lastly, Gregor shares his profound advice for leaders aspiring to guide their team members along the right career paths.
Kshitij: Hello everyone. I’m Mohan your host back with a new episode of Beyond the Code by Typo. Today we have a very special guest with us, Greg.
Greg is an engineering leader, has had almost 10+ years of engineering experience across the startups. Today, he works as a CTO at Zorion, Singapore. The best part, he’s highly passionate about sharing his knowledge, his experiences, and runs his own newsletter, engineering leadership.
Welcome Gregor to the show. Thank you for being here.
Greg: Thanks a lot for having me. I’m excited for this.
Kshitij: Perfect. Thank you Gregor. So Gregor, given your kind of experience and your expertise today, we would love to talk about how to set the right foundations for engineering teams. And when we talk about foundation, I guess the first aspect always is hiring.
We would love to understand from your experiences that what’s the right set of assessments, challenges, what do you think are the right ways? In order to hire right. Engineer into a team. Your thoughts on that, Greg?
Greg: Yeah. Creating a good hiring process is always, a work in progress, right?
It’s never going to be okay, we reset it like this and then it’s always going to work, right? It’s always about putting something in place and learn from it and adjust it and, try to make it better. I have a good kind of a process now that I’ve been interviewing more than about, let’s say more than 200 engineers in general.
And, what works really well for me is to have, for example, a first kind of initial call with engineers that, for example, does like a recruiter, or hiring manager. And, just to check if there’s an overall fit right? For us. On the both sides… And then once, once we have that, we move to, a hiring manager interview.
And that’s where I like to talk about all kinds of things in terms of soft skills, and technical skills as well. Behaviors and things like that. And, once we have that, obviously technical assessment is, where it’s, where we can stop a little bit more and we can talk about, some fine details there.
And because I think, if technical assessment is done correctly, it’s really a good kind of indicator of how successful is the candidate going to be in a particular job. Right? And I always suggest to do a great preparation for a technical interview, that means that you need to understand what kind of skills are you looking for and what kind of aspects of the role do you want to do, they want to fill. Right. And I always suggest creating a scorecard before doing a technical interview. And, don’t just put there any kind of technical skills, but also some soft skills as well skills like collaboration. Is a person team player? Is a person keen to take ownership in general, right? Those are really important aspects of an engineer as well. And once we have that, it’s good to understand what type of technical interview you wish to do. I prefer myself personally, I prefer to ask a lot of open-ended questions.
And then, we drill down to find details later on. Things like, Hey, what have you worked on a previous project? What task was the most, and the hardest task that you worked on a previous project? And then we talk about it and then we drill down to find details on certain queries, certain endpoints, and things like that, that tells me, like gives me a lot of insights of, what is the thinking process of a particular engineer. Right? And, if in case you need to do any kind of coding tasks on a technical interview. I found out that, we all know in bigger companies like all of the main companies, they do algorithmic interviews, right? That’s the best way to go with the technical interview. And that’s because, in most jobs that we do, we don’t actually work on algorithms on a daily basis. Right. So I would try to suggest if you need to do like a coding task like we would give a simpler task and we would ask a lot of follow-up questions on that particular task. And in order to make it more collaborative, not just, okay, hey, here’s a task, you have 20 minutes to solve it. Okay, here’s the solution. If you believe it or not, you know, it’s not that much important that the candidate actually solved the task a hundred percent. But what’s more important for me is that the candidate is asking a lot of clarifying questions. He’s trying to understand the expectations and trying to assess different options and not just immediately trying to jump in the implementations. Those kinds of things, I value quite a lot.
Kshitij: Basically, approach is more important than the actual outcome.
Greg: Yeah, exactly.
Kshitij: Perfect. And like when you talked about this process, right? So I could hear that there is a very clear indicator that soft skills also are an important aspect to do that. And it’s always tough to actually, gorge the right set of soft skills. Right? So any specific practices on that, how you have been doing so?
Greg: Yeah. As I mentioned, things like responsibility and ownership and teamwork and team mentality, and helping others. Those things are really important. And whenever you’re having an interview, you try to assess that kind of a previous experience if the person has shown that experience in some previous roles or previous projects. That’s why we like to talk about what was your role in the project. What did you do here? How did you help the team? How did you help others? Did you mentor any of the engineers? Did you do onboarding as well, did you do any kind of presentations to share your knowledge with others? Things like that are really helpful to trying to assess and overall, how does a personal approach to problem-solving? Do they immediately just jump to implementation or they’re trying to really understand what is the pain point behind it? What is the business value that we are actually trying to resolve here, those kinds of things we need to always keep in mind.
Technical skills can be learned quite fast, especially in a good environment. But, being a good person to work with and a good teammate, those skills are a lot harder to learn.
Kshitij: Perfect. Makes sense Greg! Moving forward Gregor, so you have always been an advocate of remote work, right? And you yourself have been working remotely for so long. So this is what the biggest question that has always been running around is, right, how do you get developers give the right onboarding experience to them, especially while working remote? How do you help them assimilate in the team, get the right info, set up things in? So any thoughts on that, Greg?
Greg: Yeah. In remote work, you’re trying to get better at it. I think we’re still not there yet where we can have a fully-fledged process that well in place. For a successful remote work. But, it’s important that we strive towards getting better at it all the time. You know, for any kind of onboardings, it’s really important to have good documentation in place. And, what I really like to do is if we bring a new engineer to the team, I like to appoint an onboarding buddy, one or potentially two. And they would really be helping that engineer, in general, to get onboarded – a lot easier, a lot faster. Because, if you’re starting and joining a company, you don’t potentially know a lot of people. And if you already have one person that you can go to and that any kind of questions, yeah, I can just ask and learn about a lot of different things from that person, right? So, yeah, documentation, onboarding buddy, and also, good processes in place in terms of like a daily meeting. And, I try to focus a lot more on goals and not so much on tasks and details. That means what we try to do is to create sprint goals. And that is two weekly or weekly sprint goals. And, that means that we are all trying to focus on delivering these goals after the end of the sprint, right? So it’s not about the details of particular tasks, but hey, I know we are all professionals here. I know we are all great engineers. We all love what we do. You know, results are what matters and if you define the outcomes that should be successful, then, you don’t need to go in details in every task in order to make sure that everything is going according correctly, especially in a remote environment, right? You’re not working with people directly and you don’t have a person by your side all the time, right? And the best way is to define goals and hold people accountable, define ownership, define responsibility. And, people are going to do well if they’re assigned ownership and they take ownership themselves and they try to do the best job as possible. Often times you get surprised on how well do they actually perform doing that.
Kshitij: Basically empower them more, and they’ll definitely perform the way even much more than your expectations.
Greg: Yes, exactly.
Kshitij: Perfect. And Greg, Are you completely relying on Slack as a communication channel or any other channels that you feel are really effective in communicating across teams?
Greg: Yeah, we use Slack a lot. And Slack is obviously probably the number one go-to tool for any remote company. And, yeah, it’s good to do some automations on Slack in terms of like, let’s try to put some action items, for our daily meeting. What could be done? What are we trying to do? And so on. Also tools, for example, What works really good, for me in a lot of, different examples was collaboration tools such as Miro or Figma. Right? And, that works really well because you can do collaboration on these tools together, like a brainstorming session or a good pros and cons list altogether. Everyone jumps on this tool and, we’re collaborating on it and we all are able to put things in there. Right. So it’s really good to proactively do it together as a team to brainstorm ideas, to define pros and cons. Maybe we try to define a technical specification or a design decision together on this. So yeah, mirror or Figma, those tools are really important. And obviously, any kind of video meetings or any kind of tools where you can jump on a call anytime are really great. I’m a big advocate for having a camera on and not just jumping on a call because it feels a lot more personal. And, I feel like I’m connecting a lot better with people when I actually see them. If you’re just, speaking about things and just talking without a camera, then it’s similar like being on a phone, right?
But you don’t get to see any kind of nonverbal communication, right? But you get to see a lot of nonverbal communication from being on a camera and, it’s a lot better way to get to know people a little bit more.
Kshitij: Let’s share raw emotions, basically.
Greg: Yeah.
Kshitij: Perfect. And, while building all this, so there is always an important aspect of culture, right? How do you set the right cultural practices even when you are not together? It’s so important to ensure that everyone stays together, aligned, follow the right set of values. I think that’s the biggest challenge.
How do you cater to that in these remote scenes today?
Greg: Yeah, it all starts with the mindset of the team and, you know, having people in the team that understands that software development is a team sport and only great teams build great software. That’s really important to understand. When speaking about mentality, I always like to have driven and motivated people that always like to learn new things. That kind of mindset is contagious and everyone benefits from it, right? Understanding that software development is a constant evolving industry and that we all need to learn is obviously a great mindset to have. And then, it’s important to understand for great teams. Great teams are autonomous. They don’t need or want to be micromanagement. They don’t want micromanagement, therefore, they’re not afraid to take ownership and responsibility of their tasks. And, customer is at its core of what they’re focusing on. Great teams should always think of ways of how to find out what the customer wants, and then prototype and deliver the functionalities that customer needs.
Kshitij: Sure Greg. I think while building remote teams, there is always an important talk about how do you set the right culture, when people are not together, working remotely. So there is always a concern on how do you set the right cultural practices so that everyone’s aligned with common set of values, collaborate better. Any thoughts on that? Greg? How do you set these culture practices right?
Greg: Yeah. It all starts with the mindset of the team and having the people in the team that understands that software development is a team sport. And, only great teams build great software. And, when speaking about mentality, I always like to have driven and motivated people that always like to learn new things.
That kind of mindset is very contagious. Right. And, everyone benefits from it. And, understanding that software development is a constant evolving industry. And that, we all need to learn is a great mindset to have. And, then it’s important to understand that the great teams are autonomous, right? They don’t want to be micromanagement. Therefore, they’re not afraid to take ownership and responsibility of their tasks. And also customers always on their minds. Customers is at its core of what they’re focusing on.
And, great teams should always think of ways of how to find out what customer wants and then prototype and deliver the functionalities that customer actually needs. Another thing that, I found out is that for individuals to focus solely just on their task, that does not do well in a great team. Great teams are always trying to help each other in making sure that if someone is stuck, others are there to support. And, good teams also enjoy doing things like pair programming, more programming because first of all, it’s fun. Second of all, you can resolve problems a lot faster doing it this way. And at the same time, you also focus just on that particular task. And, especially like if you have any juniors on the team doing kind of any pair programming is really a good way to onboard or just share knowledge with a more junior engineer in general.
And, the last thing, what I would say regarding this is that we as engineers, we are here to provide as much business value as possible to the company, that is our focus why we are here. Therefore focusing on that how to provide that value should be the number one motivation for a great team. Not just focus on building great technical solutions, but finding out, what pain points does a business have and how we as a team can resolve some of this pain points. That’s really what is really important for a great team.
Kshitij: Fair point! I think in the end, we are all trying to serve to our customers. So business impact is what matters the most. I think, one question here Greg, so I think the biggest challenge is how do you keep on imparting this thought process right back and forth again and again to the team members, any specific processes that you have been following that, Hey, you know, let’s just stick to what the common goal is.
Greg: Yeah. We talked a little bit about sprint goals, but also I think, what is really important here is to, me as a manager, it’s important for me to have one-on-one meetings with my reports that means, and engineers, right? And, it’s important to make sure that, we always are trying to focus on these values, right? And whenever we see that potentially, like someone is maybe doing something differently or is not focusing on these values, you know, you need to give feedback as soon as possible to that particular engineer. 99% of the times engineers is going to really appreciate giving that feedback because it’s not only for him or her to get to do better on the job, but also they grow a lot more as an engineers. If they’re focusing on these values, because a lot of times people don’t actually understand what do they need to do in order to be successful in a position, right? Whenever someone starts, you need to set the expectations correctly, like hey, these are our core values, is that we’re following, and things like that. And then you need to assess and need to give constant feedback on. I love to give feedback on one-to-one meetings. I don’t like to wait for performance review meetings. We should give them more frequently. It’s a lot better than less frequently.
Kshitij: Perfect. Greg, this is really insightful. I think just one last thing that we all viewers, as we would love to hear from you. So what’s that, Gregor’s magic sauce or what’s that Gregor’s advice to the leaders to learn how to help their members shape their right career path?
So they go more towards the, EM focus, the management part, or they’re more aligned towards the tech, the architect part. Your thoughts on that, Greg?
Greg: Yeah. That is the number one hot topic when I’m talking with any of the engineers and, there’s a lot of uncertainty like we just, which is the direction that a certain engineer wants to grow and that’s perfectly fine, right?
And what I suggest to engineering leaders, it’s really important to have conversations with engineers and talk about their career progression in general and, try to give them options in which direction they wish to grow, give them more insights and, they should be discussed frequently on one-to-one meetings. And, a manager should provide different options. And, an engineer should try to put themselves in that particular position and see how they would actually see themselves in that position.
What I like to see here as well is that engineers also show their motivation and drive and already do like a research. Particular roles and different paths ahead of time. So they already show I’m motivated and driven. I wish to grow. I wish to progress as an engineer. I wish to move to another path.
Hey, what do you suggest? And then, the conversation is a lot better and a lot easier when the engineer actually shows the motivation and drive. You already know that engineer is willing to grow. And it’s a lot easier to help that person.
Kshitij: Definitely. But I think, it would be more tough for, from an engineer aspect, hey, what could be that right path for me? I think that’s always a yeah. And right. So any specific thoughts on how I, as an engineer gets to evaluate myself better?
Greg: Yeah. That, that’s a good point. I’m a big fan of trying and see how it goes.
I like to say trying is the best way of knowing, right? If you don’t try, you don’t know how it actually feels. What does it feel for you? In general. And, does this work actually fulfill you? I would suggest for every engineering leader to provide like opportunities for engineers to take on a role like a manager or architect for at least some time to see how it feels if they enjoy it in general. Right.
For example, would be like a give an engineer like a week or two to be a team lead for that particular team and, just see how it feels for you and, maybe for an architecture path, maybe give an assignment to an engineer to create a design specification that would be focused on a particular functionality.
That’s how an engineer can actually see how does it feel to actually be doing the work of an architect, obviously. Put some mentorship in place and give some guidance for maybe a more senior person that would be really and you mentioned that engineers don’t know yet in which direction to grow most of the time.
That’s also been one of my findings as well. And what I always like to suggest is that if you don’t know in which direction to grow, focus on leadership skills because in every path you are going to grow, leadership skills are going to be needed. And the reason for this is that, the more you grow, the biggest impact they have on the organization and, on the business in general. And, you can’t have a big impact without having good leadership skills.
Kshitij: Perfect. Greg, this is insightful.
Thank you so much for your time today. It was an amazing conversation with you. We would love to keep on supporting you in this entire journey of helping managers, leaders be better at their work. So thank you so much, Greg. Thank you for being with us.
Greg: Thank you for having me.
On our very first episode of ‘Beyond the Code’, Host ‘Kshitij Mohan’, founder of Typo welcomes Francisco Trindade, Director of Engineering at Braze to discuss ways how to lead engineering teams efficiently.
Francisco provides valuable insights into the obstacles faced by engineering teams. He emphasizes that technical challenges are not always the main hurdles; instead, it's often the lack of clear communication and well-defined goals. He also addresses the challenges encountered by engineering managers, highlighting the importance of behavioral aspects in leading teams effectively.Moreover, Francisco unveils his secret sauce for maintaining team efficiency, further enriching his insights on successful team management.
Kshitij Mohan: Hello everyone, I’m Mohan, your host, back with a new episode of Beyond the Code by Typo. Today, we have a very special guest with us, Francisco. Francisco has been an amazing engineering leader for the past 15+ years. He has donned multiple hats across his entire journey. He has been a founder, a manager, and a consultant, right from startups to enterprises.
He had seen it all. Currently, he’s an engineering director with Brace in New York. Welcome Francisco to the show.
Francisco Trindade: Thank you, Mohan. Really happy to be here. And thanks for the lovely intro.
Kshitij Mohan: I think that definitely speaks of the work that you have done, Francisco. So thank you so much for being here with us today.
Perfect. So Francisco, given your amazing experience across the entire journey from a developer to a manager, to a founder, to everything that a leader would want, I think all of us, all of our viewers would love to understand what inspired you? How have you been able to do so much in such a less time?
So would love to hear your insights on this journey part, Francisco.
Francisco Trindade: Yeah, thank you. Well, it took a long time, and I guess I just kept doing one thing after the other. It was interesting. I think I started as a consultant, I think where this idea of being a manager or leader comes from. I started as a consultant back in the day. my first job in my career. And our approach, when consulting, I was an engineer, of course, I was writing code most of the time and being placed in projects and engineer, but a lot of the perspective that we had was how to, and the things that we asked to do was how to improve teams, asking how to improve how teams worked.
And a lot of that was based on process and process. Not just like how to write cards, but how do you the testing, how do you automate the testing, how you write code, the technical and kind of like technical and non-technical systems that are around the team.
And so a lot of what I did for many years was being an engineer but trying to help other engineers and teams to become more efficient. And in that kind of process, I think I noticed that throughout my career a lot of times, the technical challenges weren’t the things blocking the teams, right?
So we used to have a quote that we used to say, that was just like, I’ve never seen a team fail because the engineers were incapable enough, right? So because they didn’t know what they wanted to do like they needed to do. But I think I’ve seen many teams fail because, communication was broken because, the goals were like, is a line because nobody was talking to each other.
So there was a lot of around teams that made things complicated. And I think, and also throughout the process, I felt that I could, because I understood both sides, I was able to work on both sides of that equation of being an engineer and being technical, but also helping organize teams.
And so that was the, so did that. And, At the same time, I started being very interested in startups, and at some point, I stopped being a consultant to then like, join, didn’t start a company which I did in Australia for six years. And that was my first experience trying to prove, almost like trying to prove that I could do it myself or how can, can I?
Okay. Nice. Seems the way that I think they should be.
Kshitij Mohan: That’s how every founder starts with this biggest question of, can I do that myself?
Francisco Trindade: Right. So can I just instead of trying to convince someone else how to run their team, can I just run it the way I want it and, the way I think is correct and see how that works?
And so that was a good experience. And then five years ago is when I moved to the US it was when I first got my first job as an engineering leader that was an engineering manager and then I’ve been doing that for the past five years and did a few companies.
And then I guess in this past five years, I’ve been, of course, applying those principles, applying those things, but also iterating and understanding. Trying to understand more and more about this role that’s relatively new, which is the idea of an engineering manager that and how that could work how can that be done to work well, but to make sense work well?
Kshitij Mohan: Perfect. Definitely Francisco. So one quick question, what was more difficult to you trying to convince yourself or trying to convince others now?
Francisco Trindade: It’s definitely a thing when you are doing it yourself. I think there’s nobody to ask for advice and there’s nobody to talk about, like mostly there’s nobody to ask for advice.
Kshitij Mohan: You just have to figure out everything on your own.
Francisco Trindade: Yeah. You have to. I think you understand a lot that there’s no certainty. When you’re doing your own thing, you have to believe in something and try it and then see the result much later.
So a bit is just like trying, it’s just.
Kshitij Mohan: So this really helps Francisco, I think, in this journey. One question that always comes up, right? So what do you think has been the biggest challenge or the biggest transition phase of your career that you feel was something that was really tough to move on, but yeah, somehow you put it through?
Francisco Trindade: Yeah. I think like moving from I got my first engineering manager, so I was a senior engineering manager, in a few roles a few years ago, when I moved to the US. The first time I was formally doing that because before I was consulting, which was kind of way indirectly try to help teams and then I had my own company, which of course, you’re doing yourself, there’s no one else telling you like what to do, but also there’s no one else that you have to convince, right?
You just can do things that you want. So then moving as a senior manager within a larger, like a midsize startup. It was challenging for a while, because it was a different perspective, right? There’s like, yes, you’re managing a team, but you are within an organization.
There are existing policies and existing beliefs. So how do you find your space within a larger, larger place and find alignment and buy-in for your ideas. I think that’s something that was definitely a kind of thing and adaptation that I have to go through and I think it was a challenging part.
Kshitij Mohan: Definitely. I think we can all relate to Francisco. So now coming to, I think what you have built your expertise in, right? How do you build these effective dev teams? What take to scale these teams sufficiently? So I think any specific thoughts, Francisco, any specific processes that you think you followed by ensuring, Hey! the team stays aligned.
There is enough motivation to encourage for innovation, creative problem-solving, and anything that you could share Francisco.
Francisco Trindade: Yeah. I mean, I definitely don’t want to. I don’t think there’s a recipe for make teams work. I think that’s why it’s an interesting area.
You have to adapt to the situation and companies are different, industries are different, the needs that you have a different but I think most of the principles, I think that I keep going back to is aligning people to the problem.
So more you can align the team to a problem instead of a solution that they need to build, the more they have to, they become experts in the problem. And that’s of course they have product managers and you have people their role is to do that.
But I think you shouldn’t take engineering out of the equation. I think the combination of that and having engineers be part of understanding the problem and understanding the solution and helping frame the solution. I think that is one thing. So alignment seems so problem and then short and feedback loops, right?
And the more you can reduce the loop from like across the spectrum, of course, ultimately like the loop from idea to delivering something that I’m sorry, having the problem to deliver a solution. That’s the main loop, but within that, then you start thinking about where is the planning loop.
Where is the testing loop? Where is how fast can you trade in writing software and you know, automated testing and all these things that you kind of have to, you can try to reduce to them, ultimately. The faster you can get, the more that your team understands the problem, the more and the faster they can get from like having a specific thing needs to do to then deliver something to market or the customer, the better they’re going to do.
Right. Because the more chances they’re going to have to get it right. That’s basically what it boils down to.
Kshitij Mohan: I think perfect. And so you talked about, right, there is so much of this behavioral aspect also while building these fast-moving teams. So I think this is a question that always the first-time managers feel, right?
So since coming directly from maybe someone who writes and leads the stuff to actually leading and managing teams, right? This is definitely a very difficult transition for someone who gets into the shoes. So, what could be those, or what are the things that, from a behavioral perspective, right? A first-time manager should be looking at?
Francisco Trindade: I think the main thing that I keep when I talk to people, that I try, I’ve been trying to do more and more recently is just like help engineers become managers within kind of teams that I lead. And I think like the organization that I lead, and I think the thing that I keep getting, going back to is just like understanding two things, one is that you, you are kind of impact now is the team’s impact.
So you’re kind of like, you know. It’s not about how much you deliver, delivering being how much you write code or how much you write documents or whatever that is but it’s about how much your team does right. And that includes your participation but includes everyone else.
Right. So that’s how you are up to what, that’s what you should be optimizing for. And I think the other challenge, I think that all the other thing that I tried to talk about that I think is a common challenge is the idea that you can, you should actually lead your team, right? There is a thing, a comfortable path of love becoming a manager that I think sometimes is taken, people take, which is like.
I’m just going to listen to what people are telling you. Engineers are telling me and let them decide everything, decide how to work and how to do things. And, that’s my job, right? My job is just making kind of people be heard but I think there’s a lot of that you have to apply of being a leader, you have to just kind of be actively aligning the team and making sure they’re like.
What kind of like grabbing all these ideas that are coming and kind of propositions and ideas and suggestions and actually create something that makes sense, right? Because I think the problem, otherwise we end up with a patchwork of opinions, right? You say, Oh, like every project is team runs differently because it depends on whoever is running it.
Oh, whoever is the, and that becomes confusing and becomes efficient for everyone working around them. So this is just an example, of course, but it’s just the idea of you have as a manager to apply, active leadership to your team and, you are responsible for deciding how the team works.
And it doesn’t have to be that you do everything or that these are all your ideas, but you have to be able to raise the right ideas and kind of combine these perspectives to create a system that works right and create a team that works.
Kshitij Mohan: Definitely. And Francisco, while thinking about this behavioral aspect of leading teams efficiently, right?
Have you ever felt the need that while building all this, there are a certain set of data points that a manager should be wary of, or there is some data-driven things that they should be looking at while building these teams that support and building this entire thing cohesively? Any specific thoughts on that, Francisco?
Francisco Trindade: Yeah, I think ultimately I think again different teams vary and different situations vary, but I think in general, what I try to think about in terms of metrics is roughly like what are you, what amount of time your team is spending in non-value work.
Right. So well, if you think about it if you look at your team. For example, how much time are you spending, like fixing bugs or doing, or improving the code or doing anything that’s not something that the customer or whoever the target market is paying for and of course not only paying. Nobody wakes up in the what amount of time are you working on things that are not driving impact?
Then and people, I think most teams don’t think about that, but I think, and it’s normal for most, for teams to just spend half the time or sometimes more than half the time, just doing things that are not really driving impact. Yeah. And then I think that feedback loops, just like thinking about how has a feedback loop in your team, you can look so how often you release the customers.
How quickly you call the cycle time for your stories? How quick you do PR reviews, anything that you can optimize and make that streamline. So that work moves quicker from beginning to end like that’s a benefit.
So that would be the two main things I would like to look at.
Kshitij Mohan: Sure, Francisco, I think great pointers there. So Francisco, before we end our conversation, one interesting aspect that I, viewers, everyone would love to know. What’s that Francisco’s way of building efficient dev teams?
What’s that magic sauce that people can relate to, listen to, and start implementing in their teams?
Francisco Trindade: Yeah, I don’t I don’t know if there’s a magic sauce, but I think it’s kind of a bit of what I said here before, I think the main thing is just to understand there is a system, right?
Your team is working through a process, right? So and if you’re doing nothing about it, so if you say, okay, you just join a team and just they were working already. There’s a process there and the process might be an informal process, right? It might be they just work the way they work because they’ve been working like that for like, 10 years.
That’s fine and maybe it’s not written, but there are rules, right? I think so as a leader, the more you can understand how the work works. So how you just can observe that and say, okay, this is how engineers write code in my team, this is how requirements are built in my team.
This is how we do testing. the more you become an expert on that and you understand that deeply, the more you can start to think about, okay, now there are problems that I see, okay there’s a problem that’s been raised and I understand how the system works. I can start acting on it to say, okay, if this problem is this, then I can tweak something here to, or I can suggest something here to make sure that problem improves.
And you need to understand how your team works. I think it starts from there.
Kshitij Mohan: I think a million-dollar question. How does your team work? This is great, Francisco.
Francisco Trindade: There is, I mean this is just like, as an example, there is, of course, this is not possible in software, but like when you look at like one thing.
I’ve read a lot and said a lot in the past, the idea of lean production systems. And there was the idea of the person who started that was the Toyota system. He has this idea that he’s like this train manages by like drawing a circle on the factory floor and saying, you have to stand in the circle.
And at the end of the day, you tell me what’s wrong with this process, right? Just observe how people, just stay here the whole day, observing how people are, what people are doing, and then tell me what we can improve by the end of the day. I think that’s a lot of thinking that you should have as a manager, observe how people are doing things, and observe, pair with engineers.
And this read the code. Think about like how to look at the tickets, talk to everyone, and just really become an expert on how that’s done. And then you’re going to naturally start seeing ways to improve it because the thing does always improve like a team or a system.
Kshitij Mohan: Perfect. I think a super, helpful piece of advice, Francisco. Thank you so much for joining this candid conversation today with us, Francisco, and opening your heart out. I’m pretty sure we’re going to get a lot of valuable insights for us as well as for the viewers. Thank you so much.
Francisco Trindade: Thanks so much for having it.
Kshitij Mohan: Thank you! Good day, Francisco.
The field of software engineering is constantly evolving. Engineer leaders and developers need to keep an eye on recent trends and best practices. But, this is not always possible. Since they have been already piled up with their roles and responsibilities.
This is how software podcast comes to the rescue. They are a great way to learn about software engineering on the go. These podcasts are hosted by industry experts and leaders. Hence, allowing you to get much-needed knowledge and insights about this field.
Although, there are hundreds of podcasts out there on a topic. We have curated the list with the best software podcasts you can listen to. Have a look:
This podcast is hosted by Coding Sans, a software development agency. It includes experts who talk about the real-world challenges of engineering managers and how to address them. It includes management tips and tricks, effective recruiting, boosting productivity, fostering positive work culture, and much more.
Hosted by Patrick Gallagher, the weekly podcast covers leadership and management stories. It aims to empower the growing community of software engineering leaders. It also involves quality information about modern software engineering trends and best practices.
This podcast is presented by Plato, Engineering, and the product leadership mentorship program. The podcast episodes deep dive into various topics related to engineering. A few of them include the latest trends in this field, software engineering best practices and challenges faced by engineering communities, and much more. The host also interviews industry experts who offer a wealth of practical advice and insights.
Aydin Mirzaee’s podcast is geared toward engineering managers and leaders. It includes interviews with industry experts that talk about how to lead teams, thought patterns, learnings, and challenges, improving productivity, and so on.
This podcast is hosted by Adam Axelrod and Slava Imeshev who share their insights gained through an experience of 25+ years. It includes tips for developing strong management skills, establishing an effective software development lifecycle, and so on. Besides this, The podcast also sheds light on team building, performance reviews, One-on-One, and project management.
This podcast dives into the dynamic world of software engineering leadership. The host Kovid Batra interviews seasoned industry experts and successful engineering leaders who have mastered inspiring, guiding, and motivating their teams. The topics include fostering a culture of collaboration and transparency, implementing agile methodologies, and team productivity.
This podcast is a round table discussion between three hosts – Allen Underwood, Joe Zack, and Michael Outlaw. They talk about a wide range of engineering design topics. It includes software design patterns, software architecture, database design, and many more. The podcast also comprises videos, informative articles, episode summaries, and newsletter links to make it easier for developers.
This podcast is hosted by Adam Stacoviak and Jerod Santo. They discuss recent open source technology developments and a wide range of development tools. The podcast also covers almost all programming languages, communities, and platforms. The hosts deep dive into these topics by interviewing experts in their respective fields.
This is one of the programming podcasts that discusses how Python applications are used in the real world. The host ‘Michael Kennedy’ interviews guest speakers from the finance, engineering, and software industries. It also includes tips for machine learning, AI startups, Machine learning ethics, running programming language - Python in production, and much more.
Hosted by Jonathan Cutrell. This podcast is for all the newbies and experienced developers out there. It covers recent trends spanning from technology and communication to human psychology. This software engineering podcast is hardly 10 minutes long and can be listened to between busy schedules.
Hosted by Dave Smith and Jamison Dance. This weekly podcast focuses on soft skills for engineers and developers. It includes various topics like career development, communication, conflict resolution, and collaboration. In other words, it comprises the challenges and problems developers face in their day-to-day life.
The Stack Overflow podcast is hosted by Paul Ford and Ben Popper. It is one of the programming podcasts that covers comprehensive topics such as software development, coding, and computer programming. The podcast also brings industry leaders to share interesting insights and answer the queries that are trending in the developer community.
These software engineering podcasts include a wide variety of topics. It includes continuous integration, software testing, deep learning models, and much more. These tech podcasts usually invite guest speakers and industry leaders to give valuable insights about these diverse topics. Hence, making them a great resource for software developers and engineering leaders.
These software engineering podcasts provide valuable learning opportunities to engineering leaders and developers. It keeps them informed of the latest industry trends and innovations. A few of them are artificial intelligence, machine learning, and blockchain. These podcasts also share practical solutions to common engineering challenges and offer tips for optimizing workflow.
Software engineering podcasts are convenient for software engineers and developers. They can listen to them anytime, anywhere as they are available on-demand. This makes it easy to fit into their schedules. It also caters to their personal development as well. As it offers a wide range of topics that would align with their specific interests and career goals.
Software podcasts aren't bounded by geographical locations. Software developers can gain valuable insights and perspectives from professionals across the world. This includes staying informed about worldwide developments in the software development lifecycle, programming languages, software security, and much more.
While technical skills are important, soft skills play a crucial role too. Engineering podcasts also include the importance of soft skills such as time management, problem-solving, decision-making, and communication. Hence, helping developers become effective team members.
Apart from engineering podcast episodes, there are various other resources you can take note of:
These blog posts are written by industry experts, thought leaders, and software development companies who share various aspects of engineering and software development. They share valuable insights, practical tips, and best practices ranging from coding to software testing.
DevOps influencers share their perspectives, insights, and tips on various engineering topics on social media platforms such as LinkedIn and Twitter. They shed light on important software development topics and share their first-hand knowledge.
Tech YouTube channels are another great resource for learning and gaining valuable insights on software development topics. These channels share tutorials, tips and tricks, best practices, and other important information related to engineering.
Engineering newsletters are one of the resources that many developers and engineering managers rely on. These are written by industry experts and thoughtful leaders and include case studies, first-hand knowledge, and their perspectives on engineering topics such as clean code, open source projects, and data science.
There are countless books that cover various programming languages, developer methodologies, and in-depth insights on various topics. It includes front-end development, artificial intelligence, coding, and many more.
The above-mentioned software engineering podcasts are rich sources of knowledge and awareness. They can help you to stay up to date with recent trends, best practices, and other important insights.
Happy listening! :)
Sign up now and you’ll be up and running on Typo in just minutes
