How do engineering leaders stay relevant in the age of Generative AI?
With the rise of GenAI, engineering teams are rethinking productivity, prototyping, and scalability. But AI is only as powerful as the engineering practices behind it.
In this episode of the groCTO by Typo Podcast, host Kovid Batra speaks with Suresh Bysani, Director of Engineering at Eightfold, about the real-world impact of AI on engineering leadership. From writing boilerplate code to scaling enterprise platforms, Suresh shares practical insights and hard-earned lessons from the frontlines of tech.
✅ AI Meets Engineering: How GenAI is transforming productivity, prototyping & software workflows.
✅ Platform vs. Product Teams: Why technical expectations differ — and how to lead both effectively.
✅ Engineering Practices Still Matter: Why GenAI can’t replace fundamental principles like scalability, testing, and reliability.
✅ Avoiding AI Pitfalls: Common mistakes in adopting AI for internal tooling & how to avoid them.
✅ Upskilling for the Future: Why managers & engineers need to build AI fluency now.
✅ A Leader’s Journey: Suresh shares personal stories that shaped his perspective as a people-first tech leader.
Closing Insight: AI isn’t a silver bullet, but a powerful tool. The best engineering leaders combine AI innovation with strong fundamentals, people-centric leadership, and a long-term view.
Kovid Batra: Hi everyone. This is Kovid, back with another episode of groCTO by Typo. Today with us, we have a very special guest who is an expert in AI and machine learning. So we are gonna talk a lot about Gen AI, engineering management with them, but let me quickly introduce Suresh to all of you. Hi, Suresh.
Suresh Bysani: Hello.
Kovid Batra: So, Suresh is an Engineering, uh, Director at Eightfold and he holds a postgraduate degree in AI and machine learning from USC, and he has almost 10 to 12 years of experience in engineering and leadership. So today, uh, Suresh, we are, we are grateful to have you here. And before we get started with the main section, which is engineering management in the age of GenAI, we would love to know a little bit more about you, maybe your hobbies, something inspiring from your life that defines who you are today. So if you could just take the stage and tell us something about yourself that your LinkedIn profile doesn’t there.
Suresh Bysani: Okay. So, thanks Kovid for having me. Hello everybody. Um, yeah, so if I have to recall a few incidents, I’ll probably recall one or two, right? So right from my childhood, um, I was not an outstanding student, let me put it that way. I have a record of, uh, you know, failing every subject until 10th grade, right? So I’m a totally different person. I feel sometimes, you know, uh, that gave me a lot of confidence in life because, uh, at a very early age, I was, you know, uh, exposed to what failure means, or how does being in failure for a very long time mean, right. That kind of gave me a lot of, you know, mental stability or courage to face failures, right? I’ve seen a lot of friends who were, you know, outstanding students right from the beginning and they get shaken aback when they see a setback or a failure in life. Right? So I feel that defined my personality to take aggressive decisions and moves in my life. That’s, that’s one thing.
Kovid Batra: That’s interesting.
Suresh Bysani: Yeah. And the second thing is, uh, during undergrad we went to a program called Net Tech. So it’s organized by, um, a very famous person in India. It’s most of, mostly an educational thing, right, around, uh, cybersecurity and ethical hacking. So I kind of met the country’s brightest minds in this program. All people from all sorts of background came to this program. Mostly, mostly the good ones, right? So it kind of helped me calibrate where I am across the country’s talent and gave me a fresh perspective of looking beyond my current institution, et cetera. Right. So these are two life defining moments for me in terms of my career growth.
Kovid Batra: Perfect. Perfect. I think you become more resilient, uh, when you’ve seen failures, and I think the openness to learn and exposure definitely gives you a perspective that takes you, uh, in your career, not linearly, but it gives you a geometric progression probably, or exponential progression in your life. So totally relate to that and great start to this. Uh, so Suresh, I think today, now we can jump onto the main section and, uh, talk more about, uh, AI, implementation of AI, Agent ai. But again, that is something that I would like to touch upon, uh, little later. First, I would want to understand from your journey, you are an engineering director, uh, and you have spent good enough time in this management and moving from management to the senior management or a leadership position, I would say. Uh, what’s your perspective of engineering management in today’s world? How is it evolving? What are the things that you see, uh, are kind of set and set as ideals in, um, in engineering management, but might not be very right? So just throw some light on your journey of engineering management and how you see it today evolving.
Suresh Bysani: Yep. Um, before we talk about the evolution, I will just share my thoughts about what does being an engineering manager or a leader means in general, and how is it very different from an IC. I get, I get asked this question quite a lot. A lot of people, a lot of, you know, very strong ICs come to me, uh, with this question of, I want to become a manager or can I become a manager? Right. And this happens quite a lot in, in Bay Area as well as Bangalore.
Kovid Batra: Yeah.
Suresh Bysani: So the first question I ask them is, why do you want to become a manager? Right? What are your reasons for it? I, I hear all great sorts of answers, right? Some folks generally come and say, I like execution. I like to drive from front. I’m responsible. I mean, I want to be the team leader sort of thing, right? I mean, all great answers, right? But if you think about it, execution, project management, JIRA management, or leading from the front; these are all characteristics of any technical leader, not just engineering manager. Even if you’re a staff engineer or an architect or a principal engineer, uh, you are responsible for a reasonable degree of execution, project management, planning, mentorship, getting things done, et cetera. After all, we are all evaluated by execution. So that is not a satisfactory answer for me. The main answer that I’m looking for is I like to grow people. I can, I want to see success in people who are around me. So as an engineering manager, it’s quite a tricky role because most of the time you are only as good as your team. You are evaluated by your team’s progress, team’s success, team’s delivery. Until that point, most ICs are only responsible for their work, right? I mean, they’re doing a project.
Kovid Batra: Yeah.
Suresh Bysani: They do amazing work in their project, and most of the time they get fantastic ratings and materialistic benefits. But all of a sudden when you become an engineering manager or leader, you are spending probably more number of hours to get things done because you have to coordinate the rest of the team, but they don’t necessarily translate to your, you know, growth or materialistic benefits because you are only as good as an average person in your team. So the first thing people have to evaluate is, am I or do I get happiness in growing others? If the answer is yes, if that’s your P0, you are going to be a great engineering leader. Everything else will follow. Now to the second question that you asked. This has been, this remained constant across the years from last 25 years. This is the number one characteristic of an engineering leader. Now, the evolution part. As the technology evolves, what I see as challenge is, uh, in a, an engineering manager should typically understand or go to a reasonable depth into people’s work. Technically, I mean. So as the technologies evolves, most of the engineering managers are typically 10 years, 15 years, 20 years experienced as ICs, right?
Kovid Batra: Yeah.
Suresh Bysani: Now, uh, most of these new engineering managers or seasoned engineering managers, they don’t understand what new technology evolution is. For example, all the recent advancements that we are seeing in AI, GenAI, you know, the engineering managers have no clue about it. If the, most of the time when there is bottom up innovation, how are engineering managers going to look at all of this and evaluate all of this from a technical standpoint? What this means is that there is a constant need for upskilling, and we’ll talk about that, uh, you know, in your questions.
Kovid Batra: Sure. Yeah. But I think, uh, I, I would just like to, uh, ask one question here. I mean, I have been working with a lot of engineering managers in my career as well, and, uh, I’ve been talking to a lot of them. There is always a debate around how much technical an engineering manager should be.
Suresh Bysani: Yeah.
Kovid Batra: And I think that lies in a little more detail and probably you could tell with some of your examples. Uh, an engineering manager who is working more on the product team and product side, uh, and an engineering manager who is probably involved in a platform team or maybe infrastructure team, I think things change a little bit. What’s, what’s your thought on that part?
Suresh Bysani: Yeah, so I think, uh, good question by the way. Uh, my general guidance to most engineering manager’s is they have to be reasonably technical. I mean, it is just that they are given a different responsibility in the company, but that’s it. Right? The, it is not an excuse for them, not for not being technical. Yes, they don’t have to code a 100% of the time that’s given. Right. It, it, so how much time they should be spending coding or doing the technical design? It totally depends on the company, project, situation, et cetera. Right? But they have to be technical. But you have a very interesting question around product teams versus platform teams, right?
Kovid Batra: Yeah.
Suresh Bysani: Engineering manager for product teams generally, you know, deals with a lot of stakeholders, whether it is PMs or customers or you know, uh, uh, the, the potential people and the potential new customers that are going to the company. So their time, uh, is mostly spent there. They hardly have enough time to, you know, go deep within the product. That’s the nature of their job. But at the same time, they do, uh, they are also expected to be, uh, reasonably technical, but not as technical as engineering leaders of platform teams or infrastructure teams. The plat for the platform teams and infrastructure teams, yes. They also engage with stakeholders, but their stakeholders are mostly internal and other engineering managers. That’s, That’s the general setup.
Kovid Batra: Yeah. Yeah.
Suresh Bysani: And, you know, uh, just like how engineering managers are able to guide how the product should look like, platform managers and infrastructure managers should, you know, uh, go deep into what platform or infrastructure we should provide to the rest of the company. And obviously, as the problem statement sounds, that requires a lot more technical depth, focus than, than the rest of the engineering leaders. So yes, engineering managers for platform and infrastructure are required to be reasonably technically stronger than the rest of the leaders.
Kovid Batra: Totally. I think that’s, that’s the key here. And the balance is something that one needs to identify based on their situation, project, how much of things they need to take care of in their teams. So totally agree to it. Uh, moving on. Uh, I think the most burning piece, uh, I think everyone is talking about it, which is AI, Agent AI, implementing, uh, AI into the most core legacy services in, in a team, in a company. But I think things need to be highlighted, uh, in a way where people need to understand what needs to be done, why it needs to be done, and, uh, while we were talking a few days back, uh, you mentioned about mentoring a few startups and technical founders who are actually doing it at this point of time, and you’re guiding them and you have seen certain patterns where you feel that there is a guidance required in the industry now.
Suresh Bysani: Yeah.
Kovid Batra: So while we have you here, my next question to you is like, what should an engineering manager do in this age of GenAI to, let’s say, stay technically equipped and take the right decisions moving forward?
Suresh Bysani: Yeah. I, I’ll start with this. The first thing is upskilling, right? As we were talking about in our previous, uh, question, uh, most engineering managers have not coded in the GenAI era, right? Because it’s just started.
Kovid Batra: Yeah.
Suresh Bysani: So, but all the new ideas or the new projects, uh, there is a GenAI or an AI flavor to it. That’s where the world is moving towards. I mean, uh, let’s be honest, right? If we don’t upskill ourselves in AI right now, we will be termed legacy. So when there is bottom up innovation happening within the team, how is the engineering manager supposed to, you know, uh, technically calibrate the project/design/code that is happening in the team? So that is why I say there is a need for upskilling. At Eightfold, uh, what we did is one of our leader, uh, he said, uh, all the engineering managers, let’s not do anything for a week. Let’s create something with GenAI that is useful for the company and all of you code it, right? I really loved the idea because periodically engineering managers are supposed to step back like this, whether it is in the form of hackathons or ideas or whatever it is, right? They should get their hands dirty in this new tech to get some perspective. And once I did that, it gave me a totally new perspective and I started seeing every idea with this new lens of GenAI, right? And I started asking fundamental questions like why can’t we write an agent to do this? Why can’t we do this? Should we spend a lot of time writing business logic for this, right? That is important for every engineering leader. How do you periodically step back and get your hands dirty and go to the roots? Sometimes it’s not easy because of the commitments that you have. So you have to spend your weekends or, you know, or after time to go read about some of this, read some papers, write some code, or it could, it doesn’t have to be something outside. It can be, you know, uh, part of your projects too. Go pick up like five to 10% of your code in one of the projects. Get your hands dirty. So you’ll start being relevant and the amount of confidence that you will get will automatically improve. And the kind of questions that you’ll start asking for your, you know, uh, immediate reportees will also change and they will start seeing this too. They’ll start feeling that my leader is reasonably technical and I can go and talk to him about anything. So this aspect is very, very important.
Now coming to your second question which is, uh, what are the common mistakes people are doing with this, you know, GenAI or this advancements of technologies? See, um, GenAI is great in terms of, you know, um, writing a lot of code on behalf of an engineer, right? Writing a lot of monotonic code on behalf of an engineer. But it is an evolving technology. It’ll have limitations. The fundamental mistake that I’m seeing a lot of people are making is they’re assuming that GenAI or the LLMs can replace a lot of strong engineers; maybe in the future, but that’s not the case right now. They’re great for prototyping. They’re great for writing agents. They’re great for, you know, automating some routine mundane tasks, right, and make your product agentic too. That’s all great. They’re moving with great velocity. But the thing is, there’s a lot of difference, uh, between showing this initial prototype and productionizing this. Let’s face it, enterprise customers have a very high bar. They don’t want, you know, something that breaks at scalability or reliability in production, right? Which means while LLM and Agentic worlds offer a lot of fancy ways of doing things, you still need solid engineering design practices around all of this to make sure that your product does not break in production. So that is where I spend a lot of time advising these new founders or, you know, people in large companies who are trying to adopt AI into their SDLC, that this is not going to be a, you know, magical replacement for everything that you guys are doing. It is, think of it as a friend who is going to assist you or you know, improve your productivity by 10x, but everything around a solid engineering design or an organization, it’s not a replacement for that or at least not yet.
Kovid Batra: Makes sense. I think I’d like to deep dive a little bit more on this piece itself, where if you could give us some examples of how, so first of all, where you have seen these problems occurring, like people just going out and implementing AI or agents, uh, without even thinking whether it is gonna make some sense or not, and if you need to do it in the right way..
Suresh Bysani: Yeah.
Kovid Batra: Can you give us some examples? Like, okay, if this is a case, this is how one should proceed step by step. And I think I, I don’t mind if you get a little more technical here explaining what exactly needs to be done.
Suresh Bysani: Yeah. So let’s take a very basic product, right, which, uh, any SaaS application which has all the layers from infrastructure to authentication to product, to, you know, some workflow that SaaS application is supposed to do. So in the non-agentic/AI world, we are all familiar with how to do this, right? We probably do some microservices, we deploy them in Kubernetes or any other compute infrastructure that people are comfortable with. And you know, we write tons and tons of business logic saying, if this is the request, do this. If this is the request, do this. That’s, that is the programming style we are used to, and that’s still very popular. In the world of agents, agents can be thought of, you know, uh, an LLM abstraction where instead of writing a lot of business logic yourself, you have a set of tools that you author, typically the functions or utils that you call, you, you have in your microservices. And agents kind of decide what are the right set of tools to execute in order to get things done. The claim is there’s a lot of time people spend in writing business logic and not the utils itself. So you write this utils/tools one time and let agents do the business logic. That’s okay. That’s a very beautiful claim, right? But where it’ll fail is if I, if you think about enterprise customers, yes, we’ll talk about consumer applications, but let’s talk about enterprise because that’s where most of the immediate money is, right? Enterprise customers allow determinism. So for example, let’s take an application like Jira or you know, Asana, or whatever application you want to think about, right? They expect a lot of determinism. So let’s say you move a Jira ticket from ‘in-progress’ to say ‘completed’, I mean, I, I’m taking Jira as an example because this is a common enterprise product everybody is familiar with, so they expect it to work deterministically. Agents, as we know, are just wrappers around LLM and they are still hallucinating models, right? Uh, so, determinism is a question mark, right? Yes, we, we, there are a lot of techniques and tools people are using to improve the determinism factor, but if the determinism is a 100%, it’s as good as AI can do everything, right? It’s never going to be the case. So we have to carefully pick and choose the parts of the product, which are okay to be non-deterministic. We’ll talk about what they can be. And we have, we obviously know the parts of the product which cannot be non-deterministic. For example, all the permission boundaries, right? One of the common mistakes I see early startups making is they just code permission boundaries with agents. So let’s say given a logged in user, what are the permissions this person is supposed to have? We can’t let agents guess that. It has to be deterministic because what if there is a mistake and you start seeing your boss’s salary, right? It’s not acceptable. Uh, so similarly, permission boundaries, authentications, authorizations, any, anything in this layer, definitely no agents. Uh, anything that has a strong deterministic workflow requirements, basically moving the state missions and moving from one state to another in a very deterministic way, definitely no agents, but there’s, a lot of parts of the product where we can get away with not having deterministic code. It’s okay to take one path versus the other, for example, you know, uh, uh, how, how do I, how do I say it? Uh, let’s say you have an agent, you know, which is trying to, uh, act as a, as a, um, as a, as a persona, let me put it that way. So one of the common example I can take is, let’s say you are trying to use Jira, uh, and somebody’s trying to generate some reports with Jira, right? So think of it as offline reporting. So whether you do report number 1, 2, 3, or whether you do report number 3, 2, 1 in different order, it’s okay. Nobody’s going to, you know, uh, nobody’s going to make a big deal about it. So you get the idea, right? So anywhere there is acceptability in terms of non-determinism, it’s okay to code agents, so that you will reduce on the time you’re spending on the business logic. But any, anywhere you need determinism, you definitely have to have solid code which obeys, you know, the rules of determinism.
Kovid Batra: Yeah, totally. I think that’s a very good example to explain where things can be implemented and where you need to be a little cautious. I think one more thing that comes to my mind is that every time you’re implementing something, uh, talking in terms of AI, uh, you also need to show the results.
Suresh Bysani: Yeah.
Kovid Batra: Right? Let’s say if I implement GitHub Copilot in my team, I need to make sure, uh, the coding standards are improving, or at least the speed of writing the code is improving. There are lesser performance issues. There are lesser, let’s say, vulnerability or security issues. So similarly, I think, uh, at Eightfold or at any other startup where you are an advisor, do you see these implementations happening and people consciously measuring whether, uh, things are improving or not, or they’re just going by, uh, the thing that, okay, if it’s the age of AI, let’s implement and do it, and everything is all positive? They’re not looking at results. They’re not measuring. And if they are, how are they measuring? Can you again, give an example and help us understand?
Suresh Bysani: Yeah. So I think I’ve seen both styles. Uh, the answer to this largely relies on the, you know, influence of, uh, founders and technical leaders within the team. For example, Eightfold is an AI company. Most of the leaders at Eightfold are from strong AI backgrounds. So even before GenAI, they knew how to evaluate a, a model and how to make sure that AI is doing its job. So that goodness will continue even in the GenAI world, right? Typically people do this with Evals frameworks, right? They log everything that is done by AI. And, you know, they kind of understand if, uh, what percentage of it is accurate, right? I mean, they can start with something simple and we can take it all the way fancy. But yes, there are many companies where founders or technical leaders have not worked or they don’t understand AI a lot, right? I mean, there’s, they’re still upskilling, just like all of us.
Kovid Batra: Yeah.
Suresh Bysani: And they don’t know how to really evaluate how good of a job AI is doing. Right? I mean, they are just checking their box saying that yes, I have agents. Yes, I’m using AI. Yes, I’m using LLMs, and whatnot, right? So that’s where the danger is. And, and that’s where I spend a lot of time advising them that you should have a solid framework around observability to understand, you know, how much of these decisions are accurate. You know, what part, how much of your productivity is getting a boost, right? Uh, totally. Right. I think people are now upskilling. That’s where I spend a lot of time educating these new age founders, especially the ones who do not have the AI background, uh, to help them understand that you need to have strong Evals frameworks to understand accuracy and use of this AI for everything that you are, that you’re doing. And, and I see a huge, you know, improvement in, in, in their understanding over time.
Kovid Batra: Perfect. Anything specific that you would like to mention here in terms of your evaluation frameworks for AI, uh, that could really help the larger audience to maybe approach things fundamentally?
Suresh Bysani: Oh, I mean, so there are tons of Evals frameworks on the internet, right? I mean, pick a basic one. Nothing fancy. Especially, I mean, obviously it depends on the size of your project and the impact of your AI model. Things can change significantly. But for most of the agents that people are developing in-house, pick a very simple Evals framework. I mean, if you, I, I see a lot of people are using LangGraph and LangSmith nowadays, right? I mean, I’m not married to a framework. People can, are free to use any framework, but. LangSmith is a good example of what observability in the GenAI world should look like, right? So they’ll, they’re, they’re nicely logging all the conversations that we are having with, with LLM, and you can start looking at the impact of each of these conversations. And over time, you will start understanding whether to tweak your prompt or start providing more context or, you know, maybe build a RAG around it. The whole idea is to understand your interactions with AI because these are all headless agents, right? These are not GPT-like conversations where a user is trying to enter this conversation. Your product is doing this on behalf of you, so which means you are not actually seeing what is happening in terms of interactions with this LLM. So having these Evals frameworks will, you know, kind of nicely log everything that we are doing with LLM and we can start observing what to do in order to improve the accuracy and, you know, get, get better results. That’s, that’s the first idea. So I, I would, I would start with LangSmith and people can get a lot of ideas from LangSmith, and yes, we can go all fancy from there.
Kovid Batra: Great. I think before we, uh, uh, complete this discussion and, uh, say goodbye to you, I think one important thing that comes to my mind is that implementing AI in any tech organization, there could be various areas, various dimensions where you can take it to, but anything that you think is kind of proven already where people should invest, engineering managers should invest, like blindly, okay, this is something that we can pick and like, see the impact and improve the overall engineering efficiency?
Suresh Bysani: Yes. I, I generally recommend people to start with internal productivity because it is not customer-facing AI. So you’re okay to do experiments and fail, and it’ll give a nice headway for people within the company to upskill for Agentic worlds. There are tons of problems, right? Whether it is, I mean, I have a simple goal. 10% of my PRs that are generated within the company should be AI-generated. It looks like a very big number, but if you think about it, you can, all the unit tests can be written by AI, all the, you know, uh, PagerDuty problems can be, can, can be taken at first shot by agents and write simple PRs, right? There are tons of internal things that we can just do with agents. Now, agents are becoming very good at code writing and, you know, code generation. Obviously there are still limitations, but for simple things like unit test, bugs, failures, agents can definitely take a first shot at it. That’s one. And second thing is if we think about all these retro documents, internal confluence documents, or bunch of non-productive things that a lot of engineering people do, right? Uh, agents can do it without getting any boredom, right? I mean, think about it. You don’t need to pay any salaries for agents, right? They can continuously work for you. They’ll automate and do all the repetitive and mundane tasks. But in this process, as we’re talking about it, we should start learning the several frameworks and improve the accuracy of these internal agents, and thereby, because internal agents are easy to measure, right? 10% of my PRs. My bugs have reduced this much by a month or 1 month. Bugs as in, the overall bugs will not reduce. The number of bugs that a developer had to fix versus an agent had to fix, that will reduce, uh, over time, right? So these are very simple metrics to measure and learn, and improve on the agent’s accuracy. Once you have this solid understanding, engineers are the best people. They have fantastic product context, so they will start looking at gaps. Oh, I can put an agent here. I can put an agent here. Maybe I can do an agent for this part in the product. That’s the natural evolution I recommend people. I don’t recommend people to start agents in the product direction.
Kovid Batra: Makes sense. Great. I think Suresh, this was a really interesting session. We got some very practical advice around implementing AI and avoiding the pitfalls. Uh, anything else that you would like to say to our audience, uh, as parting advice?
Suresh Bysani: Yeah, so, uh, I’m sure there is a lot of technical audience that are going to see this. Uh, upskill yourself in agents or AI in general. Uh, I think five years ago it was probably not seen as a requirement, uh, with, there was a group of people who were doing AI and generating models, and majority of the world was just doing backend/full stack engineering. But right now, the definition of a full stack engineer has changed completely. Right? So a full stack engineer is now writing agents, right? So it doesn’t have to be fine tuning your models or going into the depth of models, right? That is still models experts’ job, you know? Uh, but at least learning to write programs using agents and incorporating agents as a first class citizen in your projects; definitely spend a lot of time on that.
Kovid Batra: Great. Thank you so much. That’s our time for today. Pleasure having you.
Suresh Bysani: Thank you. Bye-bye.
Are your engineering metrics actually driving impact? 🚀
Many teams struggle with slow cycle times, high work-in-progress, and unclear efficiency benchmarks. The right DORA metrics can change that — but only when used effectively.
In this session of ‘The Hows & Whats of DORA’ webinar powered by Typo, host Kovid Batra is joined by:
🎙️ Mario Viktorov Mechoulam — Senior Engineering Manager at Contentsquare & metrics expert
🎙️ Kshitij Mohan — Co-Founder & CEO of Typo
Together, they break down the science of engineering metrics, how they’ve evolved, and their direct impact on team performance, shipping velocity, and business outcomes.
✅ Why DORA Metrics Matter — The role of cycle time, deployment frequency & work in progress
✅ Optimizing Engineering Efficiency — How to balance speed, stability & delivery quality
✅ Avoiding Common Pitfalls — The biggest mistakes teams make with metrics
✅ Connecting Metrics to Business Outcomes — How they influence revenue & customer satisfaction
✅ Getting Leadership Buy-In — Strategies to align executives on the value of engineering metrics
✅ Live Q&A — Addressing audience questions on industry benchmarks, emerging trends & best practices
Kovid Batra: Hi everyone. Thanks for joining in for the DORA Metrics Webinar ‘The Hows and Whats of DORA’, powered by Typo. This is Kovid, your host, and with me today we have two amazing speakers who are the front runners, uh, the promoters of bringing data-driven engineering to the engineering world and making dev teams even more impactful. Please welcome the metrics expert tonight, Mario.
Mario Viktorov Mechoulam: Hello. Hello everybody. I’m very happy to be here again, uh, with you Kovid, and meeting you, Mohan.
Kshitij Mohan: Yup. Same, same here, Mario. Glad to be here, uh, with you and Kovid. So yeah, thanks. Thanks for joining in.
Kovid Batra: Thank you, Mario. Thank you for joining in. And the second guy on the screen, uh, he’s the co-founder and CEO of Typo, Kshitij Mohan. Uh, I’ll be talking more about Kshitij in the coming few seconds and minutes, but, uh, before we get started, I’d like to tell you something. Uh, so my idea of bringing these two people, uh, on this, on this, uh, episode, on this session was to basically bring two of the best guys who I have known in the past few years, uh, Mario and I met recently, but both of them, uh, have very deep knowledge, very deep understanding of how the engineering world works, how engineering metrics particularly work. Uh, Mario has been there to help us out in the last one month for any kind of webinar or podcast and then, he has been there in the industry from the last 15 years, uh, a true metrics enthusiast working with his team at ContentSquare, implementing those metrics, tackling things at the ground level, all the hurdles. And with Kshitij, uh, uh, we, we have, uh, spent almost, uh, three to four years now, uh, uh, and I’ve seen him doing the hard work building Typo, uh, talking to multiple engineering teams, understanding their problems, shaping Typo to where it is today, and, uh, honestly, helping and enabling those teams to, to get more success. So with that, I introduce both of my guests, Mario, and Kshitij to the, to the show. Uh, welcome to the show once again, guys.
Kshitij Mohan: Thank you. Thank you. Thank you so much, Kovid. I think you’ve already said too much about us, so really humbled to, to hear what you are, what you have been saying. But yeah, thanks. Thanks for having us here, man. Yeah.
Kovid Batra: Great guys. So I think, um, Mario, uh, you are going to be, uh, our, our key speaker today, uh, with, of course, but we are looking at a lot of learnings today coming from your end. But before we jump onto that section, I think, uh, I would love to know something about you, the audience would love to know something about you. Uh, tell us something about your hobbies or people, uh, who inspire you, uh, whom you look up to, and what, what exactly what trait in them, what quality in them inspires you.
Mario Viktorov Mechoulam: Right. Uh, I have to go here with my wife, not because she’s listening, uh, but because I’ve never seen anybody so determined and so hardworking. I think for her, nothing is impossible and, uh, I, yeah, I can’t stop admiring her since the day we met and I want to be more like her.
Kovid Batra: Perfect. Perfect.
Kshitij Mohan: You already chose the best answer, Mario. I don’t think we have anything else left to say.
Kovid Batra: Uh, same question to you, uh, Kshitij, uh, who, uh, who inspires you? What quality in them inspire you?
Kshitij Mohan: Sure. I think other than my wife, right? So who is definitely the most hardworking person, the, the bread earner of our house, because you know, how a startup work functions, it runs. So I think I deeply admire Roger Federer, so he’s one of my, my heroes, core to my heart. So I, I am, I’m a, like, deep, uh, sports enthusiast and definitely Federer has been a symbol for me of hard work, persistence, of flawlessness, uh, the, the elegance that he brought to the game. I think this is all what I have been trying to learn and, and implicate all those learnings into what we are building today. So, yeah, I would say that’s, that’s something that I really admire about him.
Kovid Batra: Interesting. No, a really interesting choice. Even I admire him a lot. And, uh, um, the hard work that, I mean, the, the game he has, I think I, I love him more, more for, for that actually. But yeah. Great, great inspiration for you. Uh, perfect, guys. Thank you so much. Uh, I think we jump onto the main section now where we talk about engineering metrics, DORA, beyond, like implementing them, the challenges that you have seen implementing them in the teams. So we’ll start with the first, very basic question. Uh, and the question to you, uh, is, is to you, Mario, uh, why do you think these metrics are important? Of course, you are an enthusiast. You, you do know how it is, uh, to have a team with or without metrics. So why do you think these metrics are important? Why these teams should implement it, and how things are evolving in this space? Like we are talking about DORA, but things have moved beyond it because DORA alone would not be sufficient to suffice, uh, measuring the, uh, engineering efficiency or productivity. So what are your thoughts on that?
Mario Viktorov Mechoulam: Absolutely. Thanks for the question. I think they’re important because, uh, they can be a stepping stone to, to doing better. Um, we are, we are looking into business impact and business results, and I think we can all agree that there might be some metrics that are good proxy indicators on what can go well or what can be improved. So if, if we agree on that, I think we can also agree that it’s smart to measure them. Once we measure them, we, we become accountable of them. So, summarizing a bit, uh, all this loop, um, we need to make space for the team so that they can, um, discuss and analyze what is going on. We need to make sure that there is, if there is any knowledge gap, this knowledge gap is covered so that we can, um, we, we can really, uh, understand what impact there could be in changing something that we have. And of course, we have to prevent the metrics of being misused because otherwise we lose all the trust. And in the end, what we want, want to, to make sure is that we, we have quality data that we, we can base our decisions on. So if we manage to do that, um, that’s already, uh, a big milestone. I think DORA, DORA is great. DORA is one of the best things that we have in the industry. It’s, uh, if I’m not mistaken, the only peer reviewed, um, metrics that we have that has, that they have stood the test of time and scrutiny, which is, which is good. So by all means, um, if you don’t know where to start, DORA, DORA can be a good place. Um, now I think that as with any metrics, just, uh, using. DORA as a target can be, uh, can be, uh, can be wrong. Um, also having, you using specific metric values as a target can also be wrong. Um, so if, if I look a bit, uh, broader, what do I see? I see that many teams nowadays are no longer caught up in these, um, old-fashioned ways, uh, ways of, of doing things. Uh, we, we tried to bring manufacturing, uh, into engineering, and, and that went, uh, very wrong. We, we all remember the, the Gantt charts, uh, multi, multi-year programs that never met the deadlines, these type of things. So to, today, if you want to start with DORA, uh, you might often find that your team is already high-performant. What do I mean with that? If we talk about, uh, lead time for change, uh, if we know that we can already ship in a few hours up to a few days. Uh, if I look at, um, um, the deployment frequency, we know we can ship as many times per day as we need. Uh, we are probably already high performing teams, so what do we do for there? Uh, I think we have to, um, we, we have to look further. And, um, one of the, uh, one of the ways to do that is to, to, to stop putting the focus only on engineering, right? So, um, DORA might be great if you want to, if you already feel that you have a big issue inside your, your coding or your pipeline, uh, areas. Uh, they can also be great if you want to optimize that final 2–5%, but they often cannot change a lot in the grand scheme of things. Right? When we talk about engineering, we are often talking about 10–30% time of the lead time since the moment we a customer requests something, or the moment we, we have an idea that we have to deliver, uh, we want to deliver to our customers, and if we, from this 10–30%, we want to narrow it down further to just the coding part, that’s maybe 10% or less per the 10% of the, of the total time. So we, we are missing a lot. And also by doing that, we are sending a message that this is just engineering. This is not product, this is not design, this is focused on just the team or not looking broader. So what I would do is start expanding with all the metrics. We have customer metrics, we have well-being metrics, we have cycle time, lead time metrics that start taking into consideration much more. We have operational metrics that, uh, for example, um, can, uh, can help us identify how frustrated the customer is. So these, these type of things.
Kovid Batra: Makes sense. I mean, uh, a lot of times I have also seen while talking to the clients while understanding what they’re exactly looking for in these metrics, and I found out they, they started with DORA. They, they were good with cycle time. They were good with deployment frequency to look at and the first go. But as they evolved, they started looking at the bigger picture. As you said, they wanted more metrics, more visibility, not just metrics, but more visibility that DORA was not able to provide. So, I mean, uh, if, if I have to ask you like, at, at, uh, ContentSquare, or, or companies where you have worked previously, how, how did you start and, uh, how it evolved? Can you just share one example so that we, we can more relate to how things evolve when someone starts with DORA and then move to some other metrics that help them help understand a better picture?
Mario Viktorov Mechoulam: Of course. I have to confess that I have never started with DORA. Um, I think that, um, that can be a great place to start if you, if you don’t know where to start. But, uh, if you already are aiming high, then there’s no reason to start with that. So to me, there are two metrics that if we look at, uh, the efficiency, uh, domain of things. So doing the things right, um, might, might be key, key metrics. So one of them is cycle time. So from the moment we start working on something until the moment it, we put it in the customer hands. So this would include not only, um, co, um, uh, pull request, review time and deployment time. We’re including the coding time, we’re including the design time, the conception time, these type of things. Uh, the other one, and, and this is the lagging indicator, right? So by the time we have some actionable, uh, actionable data on this metric, it might be already too late, but we, we, we are still on time to make changes in the future. So I, I, we can talk about that in, in detail. This is one of the, I think, most important things that the team should, should, uh, sit, sit down and do together. The other, which is not a lagging indicator, is work in progress. There is no better indicator for you to realize if you’re being efficient and focused than to look at work in progress. Uh, I mentioned it the last time, but if you have 30 work, uh, 30 things ongoing with a team of five, there is something deeply wrong in, in the way you, you are working with your team.
Kovid Batra: Great. I think that that’s a good example. Great.
Kshitij Mohan: Sorry. Sorry. That’s a great point, Mario. And I think this is where I would like to add few things and talk more around that front as well, right. So, uh, what we have seen personally across our journey as well, right. So, uh, the first question that always comes is that why do we need metrics? So that has been, I think, the first starting point for each and every engineering leader today, which is pretty surprising to us, because like at a fundamental way, as you mentioned, right? So engineering should be run with clarity and not with chaos. I think this is where the core mission statement is what we started off with. And every other critical function in any organization has some indicators, has some metrics, has some goals to follow on which they are tracking and they are moving somewhere or the other, and, and tech being such a, a, I think, uh, so much effort, so much cost, everything being put in, this is really surprising one why still we need to think on, hey, whether should be there any core set of metrics system or not, because there should be. However, I think the biggest challenge that always comes across is, and this is what we have heard most of the folks say at a very first upfront way is that, hey, uh, metrics could be gamed, right? And I think this is what we have been constantly trying to solve in some way or the other end, like trying to figure out, say, do all those discussions that hey, we know, right? So yes, if you put out very, uh, I would say rudimentary metrics, and if you start making people accountable for those metrics on a one-on-one way, then yes, they’re gonna not feel driven by it, but more around by, pushed by them, and that’s where the real, like the gaming of the system starts happening. So hence it also becomes really important that how do you design and define your metrics. I think this is what I think I would love to talk more around and would hear, love to hear your experiences as well that you, okay, there’s a first thought that yes, let’s identify or let’s go and implement this metric system in place, but right, how do you go and decide and define what could be those right areas, uh, we should be starting off with? So I think if you have any thoughts or if you have done that some way or the other, I think that would be really great for everyone to kind of just know what those starting points could look like.
Mario Viktorov Mechoulam: Right. Um, first of all, I think, I think you’re right. Um, there is always the risk that metrics, uh, get gamed. Yeah. Um, that’s why the metric itself should not be the target, nor, nor the value the metric should be additional data that we can use to, to make better decisions. I have, I have evolved what I’ve, I, I do over, over the years, and I don’t think that what I do today is, is perfect. Far, far from it. I think, uh, it’ll continue to evolve a lot, uh, in the, in the coming years. But I think that at least we need, um, two, two main areas or two main domains when we design our metrics. Um, and by the way, one way is to do them alone, to invite the team to do something, but the other is to, uh, to make them part of this, of this decision and this discussion. Sometimes this is easier, sometimes you have more time to do it. Other times, uh, the team asks you, just give me a jumpstart so you know about it. So recommend me something and then we can move from there on. So the two main areas that I think should exist are, um, areas targeting efficiency. So doing the things right. And areas targeting, targeting, uh, effectiveness. So doing the right things, right. We, because we want to be correlating the, the output, uh, of what we do with the, with the impact that we want to see, right? Yeah. And then, uh, be able to adopt there. Uh, with time, I, I realized how important it’s also to, to, um, to have more, um, self-reported metrics, well-being metrics. So two that I think are staple and I think some of the frameworks like SPACE I recommend, um, are, are the well-being and, and the satisfaction of the work you do. And, and the other, for me, it’s very important is the focus time. So in the end, um, I, I don’t think this will come as a surprise to anybody. There was a, a new paper published, I think by, by, uh, one of, well, at least one of the outsources, but the same, uh, for DORA, Nicole, um, I forgot what’s her name.
Kovid Batra: Nicole Forsgren.
Mario Viktorov Mechoulam: Yeah. Um, and, and, and answer, unsurprisingly, they, even though it was a small one, they saw a correlation between, uh, time available to do coding and work being delivered faster and with less defects. Uh, now that study, I, I mean, I, I’ve not, uh, read it, uh, all through yet, but, uh, it was focusing on individual contributors. I think it’s much more important, uh, to focus on teams. Uh, teams are already a local, optimal, right? So let’s not make that even, even more local, uh, with another one. So I think it’s important to, to measure this as a, at a team level. And, and finally, I think we should not forget, especially with the advent of DevOps, that, uh, you own what you ship, and it’s really important that your, your ownership and accountability doesn’t end when you put something in production, right? So I, I like to, to here to track, um, how many defects, uh, end up appearing on production. So this means that potentially there is quality gates that are not good enough, and we might then decide, uh, does it make sense to do a further investment based on the defects that end up in production? But there is only one thing that’s worse than having defects in production, and that is the customer discovering these defects before you. Right? So, if this happens, then you should definitely track these, it means that not only your quality gates are faulty or can be improved. It also means that your monitors and alerts, uh, uh, are lacking because the, yeah, you want to, uh, you want to prevent this frustration.
Kovid Batra: True, I think, uh, in some great insights here, but, uh. Just mentioned is one of the problems that we see. Uh, and then circling back to the hurdles that teams, uh, actually face while implementing these metrics. So gaming of these metrics is one of the problems, but along with that, there comes many more challenges, right? And I think, uh, these are the next things that we want to discuss with you, Mario, uh, with your experience. I think, uh, first thing is people hesitate to start, right? Like even take up these initiatives and think of getting a buy-in from, let’s say the executives, uh, there is push from, uh, peer teams whether it is required or not. So there are many such reasons why people don’t even start. So how do you recommend exactly this initiative should start within teams? Because it’s not about how to implement certain metrics for certain use cases. Of course, that is the next layer of problem that we will need to solve when these metrics are getting implemented. But before that, there is, uh, uh, a lot more to be known on how to take up these initiatives, how these initiatives shape up in a team in the best way possible. So I’m sure you have experiences on that as well. Uh, would you like to throw some light and tell us how, how this works out and how one should start?
Mario Viktorov Mechoulam: Yes. With, with pleasure. Um, so the, the best moment to start is now. Not now. After, after the webinar, of course. There you want, you won’t have find the perfect moment in which, uh, your team will align with the way, uh, that you think your executive will align, uh, with the way you think. That, that’s not gonna happen, magical new budget is not gonna appear. So the best thing that you can do is start right away. There is also free material that can be very helpful. One, one, one book that I always recommend is the ‘Flow Metrics for Scrum Teams’. It’s a free book from the ProKanban organization. I think that that’s great. At least, at least the first chapters, um, help you understand the concept of flow. And after that you have to, uh, you have to crunch some of the metrics. Um, unfortunately, most, most of the popular software that we have, uh, we, we use, like Jara is notoriously bad for anything that, that is not, uh, scrum. So it might be a bit complex. You can also do this manually, but I advise against that. So that leaves us with, uh, the option of, uh, choosing a tool, choosing a tool. Uh, we are lucky to live in a, in a moment where, um, there is, uh, a competing market. So there is, there is plenty of tools to choose from and many of those tools also are nice enough to offer free trials and to onboard you and your teams. So why is this important? Because it is much more important to, um, to get, uh, support from, from, from execs and support from your team if you already have some data to show from it. Yeah. Uh, don’t get me wrong, there is one part which is you still have to sell it and sometimes you have to, uh, maybe over-promise and sometimes you have to, um, shorten all these, all these links and notes that go between starting to implement metric, implement metrics and seeing some results. Sometimes you have to say, oh, we’ll, we move faster, right? Or we’ll be more predictable. That’s not really the end goal. That might be a byproduct. Uh, the end goal is to, to change a bit the culture, to change the way people think to, um, to, to help them see data in the same way they see code reviews or pair programming or test-driven design or, uh, CI uh, CD pipeline, these type of things.
Kovid Batra: Perfect. I think, um, one thing you just mentioned about, um, around the adoption part where you go out, try something, do a POC, and then with that POC, you, you go back to the teams and executives saying what exactly worked out, what could, what could not exactly work out with these kind of tools. So when, when somebody’s into that situation, uh, how do you exactly recommend that one should go about, uh, picking up certain metrics? Can we take an example here and, uh, maybe from your experience that how exactly one should go about picking few metrics, working on those, showing those numbers to the executives, and then moving on to the next step for the wider teams and, uh, the whole organization?
Mario Viktorov Mechoulam: Yes, engineering organization. Of course.
Kshitij Mohan: Also, I think just, just to add one more thing here. So, uh, what we have realized is, and I I’m, I’m pretty sure you might have some experiences around that front as well, that, uh, it’s never possible, uh, to show any change, let’s say in the first 14 days or in within a month or, or, or one and a half months or so, right? So that’s, and the challenge that, hey, so what we usually recommend is that, hey, you need to spend actively, at least the first three months where you build the processes, start, identify, measure, execute, right? But that also becomes one of the core challenging aspects because firstly, if there are no dedicated folks who are working on that front, and then they start slacking. And then the other part is if there are no results, then everything has to be blamed on the, on whatever methodology or whatever the tool that that team is incorporating. So how do you balance that front as well?
Mario Viktorov Mechoulam: Definitely, yeah. Lots of very good points. Uh. So, so yes, you’ll end up having to spend some of your own money possibly, and that is a good thing. It means that you believe in it and it’ll give you more time to, to, to show some results. Uh, second, very important, not to mention any mythology with capital M, any, any framework so that people don’t link that, uh, to something that they can blame afterwards. Yeah, link it to, to outcomes and to information that they can use. Um, and finally, it, it is true that, um, it might be hard to see results quickly. That is why initially I recommend not to go all in and try, uh, 10, 20, 30 metrics. Go with one or two and, and, and one or two, that that can be combined and have, um, have synergies with each other. And so for me, that would definitely be the cycle time and the work in progress. Um, so I, I can tell you what we do, uh, what do we like, what, what do I like doing with cycle time. Um, I, I like to track from start to end, and I think this is a staple for anything because you cannot apply it at team level. But the beauty of it is that then you can apply it at, at group level, and then you can apply that at line level and you can apply it at organizational level. And in each of these flight levels, you can measure something different. For a team, maybe it’s important tasks because you’re seeing how, how, how quickly can we get into flow with the right priorities and sequencing. But then at line level, line level, maybe it’s important because you have a strategic initiative for the year that you really want to see delivered, and that helps you see when it is moving and when it is being blocked, because maybe not all teams are aligned around the same OKRs. So with, with cycle time, what I like doing is every, every two weeks or so, we sit together and we identify everything that has been shipped in this period, and we, and we check the cycle time. And, and you can see, what you can see is the, the, um, bell shape, shape distribution, right? So not, not every, uh, task stays the same time. You, you go from a few hours, up to a few days, maybe a week, sometimes two weeks, or there is more complicated work that sometimes, uh, because of, of its nature, of its, uh, conditions can take even longer. Um, and then this bell-shaped Q curve can also be binomial. So it could have two heads or more heads. Uh, it could have a long, long tail distribution. If you see something uniform, you’re doing it wrong, you’re definitely doing something wrong, right? Uh, but what, where I’m going with this is that in the end, this gives you a spectrum of probability. You know that after a certain time, um, unless, unless the nature of the work that you have to do changes drastically, and that’s unlikely for teams, except for the yearly re-org maybe that, uh, we all do.
Kovid Batra: Yeah, yeah.
Mario Viktorov Mechoulam: Um, or except if the team’s composition changes drastically, this same probability distribution is gonna be maintained. And, and, and after two, three weeks, you already, we will have some degree of confidence of this, of this being maintained. Um, and, and that means that you can use that maybe to forecast a bit the future, to understand what is your base of delivery, what, what’s your attack time. Okay, but what, what do we do? So maybe we see something which is binomial. It has a long, uh, a thin tail distribution. We want to be better. Um, so to be better, what we have to do is we have to narrow this bell, bell shape, right? So we have to reduce the standard deviation, and we have to understand what are the things that occur that are not adding value, that are waste; waiting time, handover, et cetera. So what, what I like doing is we, we look at, at the period and we grab the outliers. So the thing is that had the, the highest cycle time, and we analyze them as a team. No blaming, but we have to go through the events and conditions that made this thing take for example, four weeks or five weeks or whatever. And oftentimes, we have the same culprits. So we are not, uh, we’re not gonna publish a paper by, by doing this. We’re not doing rocket science. You have, um, the slices of work are much larger than what they should. You have scope creep. Uh, you have ill definition. So you had to do something, but it was not clear, we did something else. You have defects, you have waiting time, you have handovers. You have so many things. Uh, you have process issues, you have infrastructure issues, uh, so, so many things that, uh, they’re always the same. So when you analyze two or three of those, it can take you all from half an hour to an hour. But this is, uh, this is the quality, qualitative analysis that is, that is useful. You can already identify some patterns. For me, uh, at one point it was the pipeline was not automated. We could not release every day. Um, some of the times it was, there is a lot of dependencies on this work with other teams. We didn’t identify them earlier. Um, we, you identify these patterns and then this offers you ground to take actions, right? So as a team, you can agree, say, oh, this happened. We know what, what causes it, what actions do we take to prevent that? And over time, you’ll see that the goal is that this, these outliers in the cycle time, they disappear because if they disappear or move or have a lower cycle time, not only, uh, your average, uh, cycle time looks better, but the, the whole standard deviation gets narrower and narrower. Yeah. So at some point, if you can say, oh, my quantile 85 or 95 is below a week, or around a week or below two weeks, that’s already great. And people can decide to gain that or not gain that. But that gives you already an idea of how good are we at sequencing and having a, a cadence of delivery.
Kovid Batra: Yeah, makes sense. Totally makes sense. Very good example there. But, uh, I, I have, uh, one, one doubt here. Uh, but, uh, Kshitij, do you have something to add here or do you have a question?
Kshitij Mohan: No, no, I think that’s fair enough. Uh, but I think one more, uh, just a point to it. So there is also a question, uh, when we are looking at some metrics and maybe could be cycle time or some review times, and also, uh, what some folks have come back and asked us as well that, hey, should we look at the averages, the medians, or should we be looking at, uh, the, the deviations on, on how to act on? So any, any thoughts around that as well, Mario?
Mario Viktorov Mechoulam: Um, I think it depends, but this is one of the lowest hanging fruits in terms of conversation that you have openly with your team. Maybe for which specific metrics should we start with, uh, the team prefers your advice, but this is already something that, uh, but just by looking at the numbers you can have normally for a cycle time, I like taking a look at the 85 quantile because I mean, averages sometimes are too good and we are not doing metrics to tap ourselves on the back or as just a vanity thing, right? So what we, one of the purposes we use the cycle time is to maybe to be able to understand how likely are we to deliver something on time or what’s the cadence, right? So it doesn’t help if we use the quantile, uh, if you use the average, right? Because, um, yeah, so half of the time you’ll, you’ll deliver in, in this amount of time, but then what about the rest? And the rest could go close to the infinite, right? And, and you’re not interested in that. You’re interested in, in doing this. So you can generate some trust with your stakeholders. At some point, when you see, when, when, when, when your stakeholders and, and the exec see that you deliver as long as you’re allowed to put the focus on one thing and have the time, that’s it. Then you, you stop getting the question of when is something gonna be delivered, because they know it’s a matter of letting you do the work.
Kshitij Mohan: Yeah, right.
Kovid Batra: Um, but I think one thing, uh, Kshitij would also be able to relate to this, uh, a lot of teams have come back to us, uh, where they just say that these metrics don’t tell the real picture and we need to understand the context behind it. And you already raised the point around it that the qualitative analysis of these metrics is also very important. So when we say qualitative analysis, in, in my understanding, we are talking about understanding the context around that particular problem in the engineering team for which we are looking at the metrics, and how do we go about it?
Mario Viktorov Mechoulam: Okay. So if I understood the question, um, how do we make sure that when we discuss metrics, we include things that are, um, directly impacting the, the, the metric that we see, right?
Kovid Batra: Yes, yes.
Mario Viktorov Mechoulam: Yes. Uh, this is a bit more complicated. Um, and it’s, uh, so it, it’s unrelated, but you definitely need it. And this is one of the first things that you should do with your teams, and that is generating trust. You, you want to make sure that when you sit together, um, people feel comfortable enough that they tell you the truth without fear of being blamed. Uh, right? So if, if somebody has a perception that this is a problem or this is going wrong, or this is not good, or we lack, lack something, you want to know about it. Yeah. You want, because when you know, when you know about it, you can try to measure it. You can try to do something and see if, uh, the result is moving the needle in the direction that you want to or, or not.
Kovid Batra: Perfect.
Kshitij Mohan: Yeah, I think just to add on to that. So there could be some qualitative data also that could be looked at in a way. So for example, uh, and, and this is something that, that we are also trying to make more robust as well, is that if you can start comparing some qualitative with the quantitative part. So for example, let’s say, if you look at for example PR size of the review time as one of the metrics, right? So that could be definitely one of the ways, uh, where if you are looking at it, then that’s definitely one good indicator. But if you can start correlating it, for example, uh, on the data based directly coming from developer surveys on developer flow. So that becomes a good way to look at a complete picture as well because one way you are trying to look at how exactly at a transactional level, how the pull requests are flowing, for example, and on top of it, let’s say if the developers are coming back and sharing this feedback that, hey, our flow is mostly blocked because of X, Y, Z reasons, then, then this becomes a, a good picture to see at an overall level, hey, this is the real, uh, context that we might need to solve because unless and until we don’t solve this, the review times are always gonna be, uh, spread across, uh, the spectrum. So maybe that could be a few of the ways to add on to the picture as well.
Mario Viktorov Mechoulam: Yeah, definitely.
Kovid Batra: Yeah. I think, uh, to sum up the point, uh, from where we started that what exactly one should take up initially to do that POC and probably go back to the team and the execs to make sure that things are moving and then getting a bigger buy-in for the wider adoption, uh, is looking at one or two important metrics, understanding the quantitative as well as the qualitative part along with it so that it makes complete understanding of what strategies, what action points need to be taken. And then when you have results, you go back to the team and the execs to make sure that, yeah, this is something that we should go ahead with and adopt in the team. So, great guys, I think this, this is one interesting piece that I really wanted to discuss. Uh, other than that, I think a lot of people do it, but they don’t do it the right way. Uh, there are pitfalls to how you, uh, use these engineering metrics or how you implement these engineering metrics. So any examples, uh, that you would like to share, Mario, uh, that you have seen are how not to use the metrics basically?
Mario Viktorov Mechoulam: Uh, yes. Um, yeah, so, so there is three areas that normally you have to take care of when you, when you start using metrics, uh, that is covering the knowledge gap, preventing the metrics from, uh, from being, uh, misused and, um, and right now, I forgot the third one, but, uh, it’ll come up to mind afterwards. Um, one, one of the, one of the key things that we need to do when, uh, we start implementing metrics, uh, is to avoid falling into the pitfall of, uh, keeping everybody busy, 100% utilization. And I understand the context right now is, um, is, is delicate. Um, many companies are looking to optimize the cost to make sure that, um, the, the, the people, the resources are invested in, in what’s best. So this might be translated into are people working on something or are they idle? And, and best is, uh, it’s debatable here. So I, I would like to, to to, um, to start with a question on that, that you can also use for, to ask, uh, to ask your team, uh, which is, I think it comes from Tai Chiana. I could not find the quote, uh, when I looked for it, but, uh, but I think it was him that at least I remember somebody telling me about that. And it is, uh, what, what do you find more bothersome, uh, when you walk into a workplace? Uh, is it, uh, seeing people or resources idle or seeing everybody busy? And if you’re watching this now, you’ll have some time to think. If you’re watching the recording, you can pause and think about the question and think about why. And I, I think most of us, um, even though being ideal sounds, sounds strange, there is a hunch. Our gut feeling is, is is to, to say, no, no, I think seeing everybody busy is, is more bothersome. And, and to help with the answer, I think we have another question, which is, would you go, would you want to go into a hospital that has everybody 100% of the time busy? No, of course. Especially if it’s a life or death situation. Um, so, so keeping, keeping people busy just for the sake of it, um, can be very dangerous and it might slow everything down. Why, why you don’t see it? One, one exercise I like doing with my teams is to try, uh, to, to, to invite them to design what would be, um, what would be the way to determine, uh, our, our system through something that is closer to them, like technology. In this case, I usually use Kafka, uh, producers, consumers, and, and, and the first question I ask them, okay, if you, if you were to design producers and consumers with Kafka in between, uh, would you like that given, you know, what is your, your output, you have an input that is higher than the output, so you’re not able to process in time all the traffic. So what happens then? And naturally, everybody knows that what happens then is that if you have a queue, this queue becomes larger and larger. So the, the service time, uh, tends to influence. Yeah. So, so this is the first lesson. If you, if you have, if you, if you have a system, you want this system to be stable, uh, but you can go further. Um, I don’t think any of us would design, uh, a system with, uh, producers, consumers, and Kafka in between, uh, where you match exactly the input capacity, uh, that you have, right to the, to the processing power. That’s, that’s extremely risky. Yeah, so I think the same thing happens, um, the same thing happens when you, when you work with teams. Uh, you want to have some leave some space for, for maintenance, for downtime, for reflection, for improving, for this type of thing. So that, that’s the second learning. Uh, then we can take it a step further and we can start thinking about where are bottlenecks. So you don’t have a single system, you have multiple, you have a chain of them. Uh, your speed, your delivery, uh, will be as good as the slowest link. That’s right. And, and here we’ve seen this reflected in the teams many time. So who is responsible of the conception, technical design documents? Everybody. Who’s responsible for coding? Everybody. Who is doing pull, pull request review, code review? Everybody. Who’s doing QA? Oh, that poor guy over there. Who’s doing, uh, product validation, UAT? Oh, that, that other person, right? So this is wrong, I think here. Uh, we have to design our system in a way where everybody’s responsible for every, everything, so that we don’t have bottlenecks. There is also the, the forced learning that we can apply through this exercise is, uh, you have to, it’s not about designing the system and living it there. You have to be able to adapt to, to the demands and adjust to demands, right? So sometimes we know there’s gonna be an event and the capacity that we have is not good enough. Um, the, the same thing happened the other way around. So sometimes I’m idle and I feel bad. So instead of going with somebody to do some pair programming, I say, I’m gonna start this thing. What happens next is that the priority, the focus shifts and we have not adjusted, uh, uh, the, the capacity to the demand and that thing, uh, stay, stays for, for weeks or months, uh, and, and contributes to be an outlier eventually. Um, so I think all, all, all these things can, this, this type of exercise that is very close to engineering can help teams understand how these same principles can be applied to teams. In the end, what we want to make sure is that engineers have time to think, product managers have time to think, designers have time to think, teams have time to think; quality time. So being idle, so thinking is not being idle, and this is something very important that we have to, um, that we have to, uh, communicate. And, um, some of the changes we did in our team and, and, and I, I started talking about pitfalls because it’s very easy when you start a team and metrics to try to optimize the metrics by making people busy and, and you normally get the opposite effect. Uh, some of the changes we did was limiting work in progress. Um, you don’t want to have five people in a team, everybody working on a project alone. That’s, uh, that might, might with a, uh, big quotes here give you a boost in, in, in, in speed, or however you want to call it in the short term, but in the long term it’s, it’s, it’s bad. So all this knowledge is gonna be lost when people have to, to, to leave or have to whatever, uh, projects are gonna get sold. So the second thing we did is we favored, uh, pair programming, even more programming. Yeah. Um, so all, all these, all these changes contributed in the end to, um, by, yeah, by do, doing less and achieving more. And sometimes the best thing to go fast is not to, not to start new work.
Kovid Batra: Makes sense. Great.
Kshitij Mohan: ‘Going faster is not necessarily the fastest way to go’ is basically what you wanna say.
Mario Viktorov Mechoulam: Say again?
Kshitij Mohan: Going fast is not always the fastest way to go.
Mario Viktorov Mechoulam: Exactly, exactly.
Kovid Batra: Great, guys. I think, uh, we break for a minute. Uh, we have now the QA session for 15 minutes, so there would be some questions that our audience would like to ask. Uh, so I request the audience to put in all the questions that they have in the next two minutes, uh, so that we can take it up till that time. Uh, you have some music to hear.
Mario Viktorov Mechoulam: Okay.
Kovid Batra: All right. Uh, we have a few questions here now. Uh, I think we can, we are good to go. Uh, I’ll just highlight the first one. This comes from Daniel. How do you handle the continuous nature of the cycle? For example, there might not be one moment of prioritization or there might be a break because of other business priorities taking over between prioritization and engineering started. Interesting question. I think we touched a little bit on this, but Mario, uh, please take this up.
Mario Viktorov Mechoulam: Yes, very good question. Uh, to me, this, this is, uh, very much connected with, uh, how many companies do roadmap and delivery plans. I think we’re often planning way too much ahead and in doing so, we are, um, investing into, into effort and time that is then never capitalized on. So one, one way to, to break this, uh, is to, to do less things. Um, and this applies, uh, both. So I’m, I’m, I’m not against roadmap. I think roadmaps are great. The problem is, is when you start treating your roadmap as a delivery plan or as a strategy, and as you have a, uh, deadlines that are fixed. Um, so one way to do that is do, do less things. What this means is that, uh, if we try to put it to perspective where many teams work together, uh, there is always a chance that something new comes up that, uh, changes the plan that you have so far. So what is the least amount of work that you can start so that you have the minimal risk of being blocked, interrupted and having to switch to something else? And that’s normally one project, maybe two projects. If you, if you have a big team, uh, the same thing can be applied within the team. Uh, I think this connects a bit to one of the points I was making about adjusting, um, capacity to demand. Uh, it’s, uh, there is, if you, if you use Kanban for example, but I’m sure that other, uh, methodologies have different ways. There’s this replenishment meaning, so putting something on the board means that there is a commitment to see it through all the way to the end. So if we are not sure about the priority that something is gonna, uh, is having today, or if we cannot be confident enough that this thing is gonna maintain the, the same priority throughout its cycle, the safety thing might be not to start it to work on something else with somebody else, uh, within your team.
Kovid Batra: And I think I would just like to add here on this question, Daniel, uh, probably if you want to, like, there are unavoidable situations also, we know that, and you need to jump onto other tasks. Uh, then at least, uh, if you’re looking at it from the metrics perspective, that it is gonna, um, like change the complete picture of your cycle time because one of the tasks is lying there and taking too much time. Uh, we can actually go ahead and build a system that either exclude those PRs that are going high in time in the cycle time, or in fact there can be a system to probably reduce the number of hours that just went in vain where there was no activity. So if, if that was something that you were also trying to understand or ask here, uh, that was my take on this question. Yeah.
Mario Viktorov Mechoulam: One, one comment on my end from this, I think, uh, you, you can definitely do that. Uh, there is one, one side effect of doing this though, and which is you won’t be able to communicate, um, to, to the business or to the, uh, people making this decision what is the impact it has on the team. So sometimes it’s, I think it’s better that if we look at metrics, we feel bad, we feel uncomfortable because that’s the trigger to try to do, uh, to try to do something about it. Uh, but while you were talking, Kovid, I, um, I think you, you mentioned something, uh, something important that, that resonated with me and, and gave me another idea, which is, uh, if you work small, um, I think we, yeah, if we manage to work in around, uh, one to three days, uh, task, uh, we can afford to delay something no matter how urgent it is or almost no matter how urgent it is, for a few, uh, for a couple days, uh, to make sure that this is..
Kovid Batra: So, that’s also a good solution here actually, breaking your work into batches, small batches. I think that would be great. Uh, creating small batch of work would really help there. Yeah. Perfect. Uh, moving on to the next question that’s from Nisha. Uh, how do you recommend balancing speed and stability when optimizing DORA metrics? Yeah, I think, uh, uh, yeah, go ahead. Please go ahead.
Mario Viktorov Mechoulam: Okay. Uh, so my, my, my first reflection on this is that speed and stability are the same thing. At least they should be. You want stability to have speed. So, uh, I am of the opinion that unless you’re a startup and you’re at the point where it, it really depends on a few weeks, whether you’re running out of budget or not, or you sign up these, these critical clients, uh, normally stability is gonna have the long term pros, uh, better effects on, on speed. So for me, if you, if you, um, if we are realizing that we are not fast enough to deploy a fix, that to fix and deploy a resolution, uh, that, that’s the first point that we should start addressing.
Kshitij Mohan: Sure. I think, uh, I’ll also just add to it, uh, one, one critical point to what we realized is also depends on the nature of your work or the market that you are in. So what we have realized is, so there are some kinds of users to whom you cannot ship unstable things, you cannot ship unstable features. Uh, whereas when you are going on for maybe some kind of a novelty or just a tryout or a beta thing, then definitely, uh, speed matters because it’s okay if, if it breaks out as well. Uh, but I think that’s also a call that you would have to take on what exactly the situation is and where you have the leeway of prioritizing what, but yeah, that, that’s, that’s the call that, that also comes into play.
Mario Viktorov Mechoulam: Yeah. Very good point.
Kovid Batra: Okay. Uh, I think, uh, we have a question from Narendra. There are different, uh, formula available to calculate metrics. Example, lead time for change is calculated by the time taken for the master branch on production. Uh, on some other sites it says it should be time when the task was taken in into development till the deployment. What is the idle way for this? Okay. Uh, Mario, you wanna take it or Kshitij I think you, you are equally excited to take this up?
Kshitij Mohan: No, I think, uh, fair question, Narendra. So I think it’s a funny take as well, uh, because everyone has their own ways of suggesting what it is, but it, it matters on what you want to actually measure. So basically, if you want to measure your lead time to change and let’s say if you’re in a situation where you would want to understand the time it takes from the inception of when we thought about this work to getting started to actually finally moving into production, you go by, uh, what, what you find a firm, you what, what you found a formula of calculating it from the inception time. But let’s say if you are in a regular, uh, scrum-based approach or you are looking at more on a continuous, uh, CI/CD type of a ecosystem, where you are at, then you might want to look at just the point where you started the work and the time it finally got merged into any of your branches that you would consider. So the way we recommend is, is actually, it should be configurable in a way on what it suits for different teams and different businesses. But yeah, uh, there is no one defined, uh, I would say formula for, for seeing this. You need to look at it at a broader perspective on what exactly translates into your, uh, basically engineering ecosystem. So that’s, that’s what my take would be. But yeah, Mario, if you have anything to add, please, please feel free.
Mario Viktorov Mechoulam: Perfect answer. You, you read my mind.
Kovid Batra: Great. I think we can move on to the next one then. Uh, it’s from Priya. Are there any new or emerging metrics that you believe will become industry standards soon?
Mario Viktorov Mechoulam: Um, good, good question. I don’t know. Uh, I think we are far away from industry standards for, for many things. And, and when there have been some industry standards, often they have been wrong or let’s say miss, things are being mismeasured. Um, what do you think, Mohan? Is there anything?
Kshitij Mohan: Yeah, I think that’s.. Yeah, I think, uh, firstly it’s a very good question to think about that how, uh, this current ecosystem is changing. And I think with the advent of new frameworks coming in, like SPACE, DevEx, DORA, and, and a lot more now coming into, so it’s, it’s, I think it’s a pretty, uh, interesting inflection point is what we see this entirely, uh, I would say the whole metric defining pieces. So, as you mentioned, we are not sure what becomes the norm, uh, but what I feel is they’re not going to be any, uh, one specific way to measure things because what we are seeing is every team, every, uh, organization, every stage that your company’s at, there are so many different nuances that everyone wants to track and understand. Uh, so I believe, I don’t think so there is gonna be, uh, one specific metric, but there are definitely going to be a lot more frameworks coming in, uh, over the next few years that’s gonna help us maybe identify and define the metrics in a better way.
Kovid Batra: Perfect. Uh, moving on. Uh, I think this is the last one we can take. Uh, this is from Vishal. Uh, how do DORA Metrics correlate with business outcomes like revenue growth or customer satisfaction in your experience? Uh, very relevant question I think. Uh, Mario, would you like to take this up?
Kshitij Mohan: Yup.
Mario Viktorov Mechoulam: Yes, sure. Um, so there is, there is not a direct link, right? So your, your metrics, uh, are information that you can use to improve how you ship things. How you ship things, uh, is able, allows you to create business impact, which might not always be direct to the customer. So maybe your business impact is our pipelines are now better, more stable, they’re faster. And by having this type of business impact, we can easily unlock business value. Um, to make sure that the business value is the outcome that we want, we need to also measure. So this is what, when I, when I was talking about, uh, effectiveness metrics, these are normally the business or the product metrics. Uh, so we have to, uh, of course, have everything before that, uh, including a very fast pipeline so we can correlate the, the changes that we ship with the, with the changes and the outcomes that we see.
Kovid Batra: Totally. I think, yeah, uh, so there is no direct impact, but there is definitely, uh, a goal related impact that we can see and there are a few examples that I would like to share here. Uh, like change failure rate, uh, for, for that matter, could be something that you might find very close to, uh, not revenue, but at least customer satisfaction because if the failure rate is higher, then the customer satisfaction will definitely drop down. So you can easily find a correlation there with at least that metric. But metrics like, uh, cycle time, for example, you might not necessarily find a direct impact, but if it’s better, it is really gonna help you ship more features faster, and that ultimately could help you maybe at what stage you are finding a PMF or maybe having more revenue through the next feature that you just released. So, yeah, that, that’s my answer to Vishal’s question.
Kshitij Mohan: And definitely, and I think just to add one last thing to it. So fundamentally we, uh, talk a lot about DORA, uh, but I think somehow this is something that I find very less talked about is that fundamentally DORA is trying to capture, uh, simplistically the velocity, quality, throughput of your systems. And these could be translated into multiple ways and into multiple forms. But if used in the right effective way, there would be some ways that you can start impacting and understanding the overall outcomes. But yeah, they have to be now correlated with what makes, what metrics make more sense to you. So if you already have some key metrics, if you start fitting them around the DORA ecosystem, then that really works well is what we have seen. But yeah, uh, it kind of, uh, depends on your use case as well.
Kovid Batra: Great, Kshitij. Thank you so much. Uh, I think guys, uh, we are, uh, that’s our time, actually. Uh, but before we just go, uh, both of you, uh, it was really great talking to you, uh, learning from you both. Uh, any parting thoughts that you would like to share? Uh, I think we’ll go with Mario first. Uh, Mario, any, any parting thoughts for the audience?
Mario Viktorov Mechoulam: Yes. Um, I hope I’m not repeating myself, but, uh, when we talk about the pitfall of 100% utilization, um, we have to take that into, into the whole business, uh, domain. So oftentimes we are hearing people need to innovate. People need to automate. People need to improve. People need to this. People need to that. It, it’s a zero sum game, right? So if we want people to do that, that type of things, there needs to be a change in culture that accompanies the, the words we talk. And when we do that, we have to be mindful of this, of, of Kafka, right, of the stability of the system if we want people to invest there. And as leaders, as managers, it’s our responsibility to, to enable that.
Kshitij Mohan: Totally. Perfect. I think just to add on to what Mario said. So, exactly. So it should not be a zero sum game. It should be a positive sum game. I think this is all how we should be defining everything for, for the entire ecosystem out there.
Kovid Batra: Alright, thank you. Thank you guys. Uh, it was a pleasure having you both here and there are many more such sessions to come. And Mario, we’ll keep bugging you, uh, to share your insights on those. Till then, uh, this is our time guys. Thank you so much.
Mario Viktorov Mechoulam: Thank you.
Kshitij Mohan: Thank you. Thanks, Mario. Thank you so much.
How do you build a culture of engineering metrics that drives real impact? Engineering teams often struggle with inefficiencies — high work-in-progress, unpredictable cycle times, and slow shipping. But what if the right metrics could change that?
In this episode of the groCTO by Typo Podcast, host Kovid Batra speaks with Mario Viktorov Mechoulam, Senior Engineering Manager at Contentsquare, about how to establish a data-driven engineering culture using effective metrics. From overcoming cultural resistance to getting executive buy-in, Mario shares his insights on making metrics work for your team.
✅ Why Metrics Matter: How the lack of metrics creates inefficiencies & frustrations in tech teams.
✅ Building a Metrics-Driven Culture: The five key steps — observability, accountability, understanding, discussions, and agreements.
✅ Overcoming Resistance: How to tackle biases, cultural pushback, and skepticism around metrics.
✅ Practical Tips for Engineering Managers: Early success indicators like reduced work-in-progress & improved predictability.
✅ Getting Executive Buy-In: How to align leadership on the value of engineering metrics.
✅ A Musician’s Path to Engineering Metrics: Mario’s unique journey from music to Lean & Toyota Production System-inspired engineering.
Kovid Batra: Hi, everyone. Welcome to the all new episode of groCTO by Typo. This is Kovid, your host. Today with us, we have a very special guest whom I found after stalking a lot of people on LinkedIn, but found him in my nearest circle. Uh, welcome, welcome to the show, Mario. Uh, Mario is a Senior Engineering Manager at Contentsquare and, uh, he is an engineering metrics enthusiast, and that’s where we connected. We talked a lot about it and I was sure that he’s the guy we should have on the podcast to talk about it. And that’s why we thought today’s topic should be something that is very close to Mario, which is setting metrics culture in the engineering teams. So once again, welcome, welcome to the show, Mario. It’s great to have you here.
Mario Viktorov Mechoulam: Thank you, Kovid. Pleasure is mine. I’m very happy to join this series.
Kovid Batra: Great. So Mario, I think before we get started, one quick question, so that we know you a little bit more. Uh, this is kind of a ritual we always have, so don’t get surprised by it. Uh, tell us something about yourself from your childhood or from your teenage that defines who you are today.
Mario Viktorov Mechoulam: Right. I think my, my, both of my parents are musicians and I played violin for a few years, um, also in the junior orchestra. I think this contact with music and with the orchestra in particular, uh, was very important to define who I am today because of teamwork and synchronicity. So, orchestras need to work together and need to have very, very good collaboration. So, this part stuck somewhere on the back of my brain. And teamwork and collaboration is something that defines me today and I value a lot in others as well.
Kovid Batra: That’s really interesting. That is one unique thing that I got to learn today. And I’m sure orchestra must have been fun.
Mario Viktorov Mechoulam: Yes.
Kovid Batra: Do you do that, uh, even today?
Mario Viktorov Mechoulam: Uh, no, no, unfortunately I’m, I’m like the black sheep of my family because I, once I discovered computers and switched to that, um, I have not looked back. Uh, some days I regret it a bit, uh, but this new adventure, this journey that I’m going through, um, I don’t think it’s, it’s irreplaceable. So I’m, I’m happy with what I’m doing.
Kovid Batra: Great! Thank you for sharing this. Uh, moving on, uh, to our main section, which is setting a culture of metrics in engineering teams. I think a very known topic, a very difficult to do thing, but I think we’ll address the elephant in the room today because we have an expert here with us today. So Mario, I think I’ll, I’ll start with this. Uh, sorry to say this, but, uh, this looks like a boring topic to a lot of engineering teams, right? People are not immediately aligned towards having metrics and measurement and people looking at what they’re doing. And of course, there are biases around it. It’s a good practice. It’s an ideal practice to have in high performing engineering teams. But what made you, uh, go behind this, uh, what excited you to go behind this?
Mario Viktorov Mechoulam: A very good question. And I agree that, uh, it’s not an easy topic. I think that, uh, what’s behind the metrics is around us, whether we like it or not. Efficiency, effectiveness, optimization, productivity. It’s, it’s in everything we do in the world. So, for example, even if you, if you go to the airport and you stay in a queue for your baggage check in, um, I’m sure there’s some metrics there, whether they track it or not, I don’t know. And, um, and I discovered in my, my university years, I had, uh, first contact with, uh, Toyota production system with Lean, how we call it in the West, and I discovered how there were, there were things that looked like, like magic that you could simply by observing and applying use to transform the landscape of organizations and the landscape systems. And I was very lucky to be in touch with this, uh, with this one professor who is, uh, uh, the Director of the Lean Institute in Spain. Um, and I was surprised to see how no matter how big the corporation, how powerful the people, how much money they have, there were inefficiencies everywhere. And in my eyes, it looks like a magic wand. Uh, you just, uh, weave it around and then you magically solve stuff that could not be solved, uh, no matter how much money you put on them. And this was, yeah, this stuck with me for quite some time, but I never realized until a few years into the industry that, that was not just for manufacturing, but, uh, lean and metrics, they’re around us and it’s our responsibility to seize it and to make them, to put them to good use.
Kovid Batra: Interesting. Interesting. So I think from here, I would love to know some of the things that you have encountered in your journey, um, as an engineering leader. Uh, when you start implementing or bringing this thought at first point in the teams, what’s their reaction? How do you deal with it? I know it’s an obvious question to ask because I have been dealing with a lot of teams, uh, while working at Typo, but I want to hear it from you firsthand. What’s the experience like? How do you bring it in? How do you motivate those people to actually come on board? So maybe if you have an example, if you have a story to tell us from there, please go ahead.
Mario Viktorov Mechoulam: Of course, of course. It’s not easy and I’ve made a lot of mistakes and one thing that I learned is that there is no fast track. It doesn’t matter if you know, if you know how to do it. If you’ve done it a hundred times, there’s no fast track. Most of the times it’s a slow grind and requires walking the path with people. I like to follow the, these steps. We start with observability, then accountability, then understanding, then discussions and finally agreements. Um, but of course, we cannot, we cannot, uh, uh, drop everything at, at, at, at once at the team because as you said, there are people who are generally wary of, of this, uh, because of, um, bad, bad practices, because of, um, unmet expectations, frustrations in the past. So indeed, um, I have, I have had to be very, very careful about it. So to me, the first thing is starting with observability, you need to be transparent with your intentions. And I think one, one key sentence that has helped me there is that trying to understand what are the things that people care about. Do you care about your customers? Do you care about how much focus time, how much quality focus time do you have? Do you care about the quality of what you ship? Do you care about the impact of what you ship? So if the answer to these questions is yes, and for the majority of engineers, and not only engineers, it’s, it’s yes, uh, then if you care about something, it might be smart to measure it. So that’s a, that’s a good first start. Um, then by asking questions about what are the pains or generating curiosity, like for example, where do you think we spend the most time when we are working to ship something? You can, uh, you can get to a point where the team agrees to have some observability, some metrics in place. So that’s the first step.
Uh, the second step is to generate accountability. And that is arguably harder. Why so? Because in my career, I’ve seen sometimes people, um, who think that these are management metrics. Um, and they are, so don’t get me wrong. I think management can put these metrics to good use, um, but this sends a message in that nobody else is responsible for them, and I disagree with this. I think that everybody is responsible. Of course, I’m ultimately responsible. So, what I do here is I try to help teams understand how they are accountable of this. So if it was me, then I get to decide how it really works, how they do the work, what tools they use, what process they use. This is boring. It’s boring for me, but it’s also boring and frustrating for the people. People might see this as micromanagement. I think it’s, uh, it’s much more intellectually interesting if you get to decide how you do the work. And this is how I connect the accountability so that we can get teams to accept that okay, these metrics that we see, they are a result of how we have decided to work together. The things, the practices, the habits that we do. And we can, we can influence them.
Kovid Batra: Totally. But the thing is, uh, when you say that everyone should be onboarded with this thought that it is not just for the management, for the engineering, what exactly, uh, are those action items that you plan that get this into the team as a culture? Because I, I feel, uh, I’ll touch this topic again when we move ahead, but when we talk about culture, it comes with a lot of aspects that you can, you can not just define, uh, in two days or three days or five days of time. There is a mindset that already exists and everything that you add on top of it comes only or fits only if it aligns with that because changing culture is a hard thing, right? So when you say that people usually feel that these are management metrics, somehow I feel that this is part of the culture. But when you bring it, when you bring it in a way that everyone is accountable, bringing that change into the mindset is, is, is a little hard, I feel. So what exactly do you do there is what I want to understand from you.
Mario Viktorov Mechoulam: Sure. Um, so just, just to be, to be clear, at the point where you introduce this observability and accountability, it’s not, it’s not part of the culture yet. I think this is the, like, putting the foot on the door, uh, to get people to start, um, to start looking at these, using these and eventually they become a culture, but way, way later down the line.
Kovid Batra: Got it, got it. Yeah.
Mario Viktorov Mechoulam: Another thing is that culture takes, takes a lot of time. It’s, uh, um, how can we say? Um, organic adoption is very slow. And after organic adoption, you eventually get a shifting culture. Um, so I was talking to somebody a few weeks back, and they were telling me a senior leader for one of another company, and they were telling me that it took a good 3–4 years to roll out metrics in a company. And even then, they did not have all the levels of adoption, all the cultural changes everywhere in all the layers that they wanted to. Um, so, so this, there’s no fast track. This, this takes time. And when you say that, uh, people are wary about metrics or people think that manage, this is management metrics when they, when, when you say this is part of culture, it’s true. And it comes maybe from a place where people have been kept out of it, or where they have seen that metrics have been misused to do precisely micromanagement, right?
Kovid Batra: Right.
Mario Viktorov Mechoulam: So, yeah, people feel like, oh, with this, my work is going to be scrutinized. Perhaps I’m going to have to cut corners. I’m going to be forced to cut corners. I will have less satisfaction in the work we do. So, so we need to break that, um, to change the culture. We need to break the existing culture and that, that takes time. Um, so for me, this is just the first step. Uh, just the first step to, um, to make people feel responsible, because at the end of the day, um, every, every team costs some, some, some budget, right, to the company. So for an average sized team, we might be talking $1 million, depending on where you’re located, of course. But $1 million per year. So, of course, this, each of these teams, they need to make $1 million in, uh, in impact to at least break even, but we need more. Um, how do we do that? So two things. First, you need, you need to track the impact of the work you do. So that already tells you that if we care about this, there is a metric that we have to incorporate. We have to track the impact, the effect that the work we ship has in the product. But then the second, second thing is to be able to correlate this, um, to correlate what we ship with the impact that we see. And, and there is a very, very, uh, narrow window to do that. You cannot start working on something and then ship it three years later and say, Oh, I had this impact. No, in three years, landscape changed a lot, right? So we need to be quicker in shipping and we need to be tracking what we ship. Therefore, um, measuring lead time, for example, or cycle time becomes one of the highest expressions of being agile, for example.
Kovid Batra: Got it.
Mario Viktorov Mechoulam: So it’s, it’s through these, uh, constant repetition and helping people see how the way they do work, how, whether they track or not, and can improve or not, um, has repercussions in the customer. Um, it’s, it’s the way to start, uh, introducing this, this, uh, this metric concept and eventually helping shift the culture.
Kovid Batra: So is, let’s say cycle time for, for that matter, uh, is, is a metric that is generally applicable in every situation and we can start introducing it at, at the first step and then maybe explore more and, uh, go for some specifics or cycle time is specific to a situation in itself?
Mario Viktorov Mechoulam: I think cycle time is one of these beautiful metrics that you can apply everywhere. Uh, normally you see it applied on the teams. To do, doing, done. But, uh, what I like is that you can apply it, um, everywhere. So you can apply it, um, across teams, you can apply, apply it at line level, you can even apply it at company level. Um, which is not done often. And I think this is, this is a problem. But applying it outside of teams, it’s definitely part of the cultural change. Um, I’ve seen that the focus is often on teams. There’s a lot of focus in optimizing teams, but when you look at the whole picture, um, there are many other places that present opportunities for optimization, and one way to do that is to start, to start measuring.
Kovid Batra: Mario, did you get a chance where you could see, uh, or compare basically, uh, teams or organizations where people are using engineering metrics, and let’s say, a team which doesn’t use engineering metrics? How does the value delivery in these systems, uh, vary, and to what extent, basically?
Mario Viktorov Mechoulam: Let me preface that. Um, metrics are just a cornerstone, but they don’t guarantee that you’d do better or worse than the teams that don’t apply them. However, it’s, it’s very hard, uh, sometimes to know whether you’re doing good or bad if you don’t have something measurable, um, to, to do that. What I’ve seen is much more frustration generally in teams that do not have metrics. But because not having them, uh, forces them into some bad habits. One of the typical things that I, that I see when I join a team or do a Gemba Walk, uh, on some of the teams that are not using engineering metrics, is high work in progress. We’re talking 30+ things are ongoing for a team of five engineers. This means that on average, everybody’s doing 5–6 things at the same time. A lot of context switching, a lot of multitasking, a lot of frustration and leading to things taking months to ship instead of days. Of course, as I said, we can have teams that are doing great without this, but, um, if you’re already doing this, I think just adding the metric to validate it is a very small price to pay. And even if you’re doing great, this can start to change in any moment because of changes in the team composition, changes in the domain, changes in the company, changes in the process that is top-down. So it’s, uh, normally it’s, it’s, it’s very safe to have the metrics to be able to identify this type of drift, this type of degradation as soon as they happen. What I’ve seen also with teams that do have metric adoption is first this eventual cultural change, but then in general, uh, one thing that they do is that they keep, um, they keep the pieces of work small, they limit the work in progress and they are very, very much on top of the results on a regular basis and discussing these results. Um, so this is where we can continue with the, uh, cultural change.
Uh, so after we have, uh, accountability, uh, the next thing, step is understanding. So helping people through documentation, but also through coaching, understand how the choices that we make, the decisions, the events, produce the results that we see for which we’re responsible. And after that, fostering discussion for which you need to have trust, because here we don’t want blaming. We don’t want comparing teams. We want to understand what happened, what led to this. And then, with these discussions, see what can we do to prevent these things. Um, which leads to agreement. So doing this circle, closing the circle, doing it constantly, creates habits. Habits create continuous improvement, continuous learning. And at a certain point, you have the feeling that the team already understands the concepts and is able to work autonomously on this. And this is the moment where you delegate responsibility, um, of this and of the execution as well. And you have created, you have changed a bit the culture in one team.
Kovid Batra: Makes sense. What else does it take, uh, to actually bring in this culture? What else do you think is, uh, missing in this recipe yet?
Mario Viktorov Mechoulam: Yes. Um, I think working with teams is one thing. It’s a small and controlled environment. But the next thing is that you need executive sponsorship. You need to work at the organization level. And that is, that is a bit harder. Let’s say just a bit harder. Um, why is it hard?
Kovid Batra: I see some personal pain coming in there, right?
Mario Viktorov Mechoulam: Um, well, no, it depends. I think it can be harder or it can be easier. So, for example, uh, my experience with startups is that in general, getting executive sponsorship there, the buy-in, is way easier. Um, at the same time, the, because it’s flatter, so you’re in contact day to day with the people who, who need to give you this buy-in. At the same time, very interestingly, engineers in these organizations often are, often need these metrics much less at that point. Why? Because when we talk about startups, we’re talking about much less meetings, much less process. A lot of times, a lot of, um, people usually wear multiple hats, boundaries between roles are not clear. So there’s a lot of collaboration. People usually sit in the very same room. Um, so, so these are engineers that don’t need it, but it’s also a good moment to plant the seed because when these companies grow, uh, you’ll be thankful for that later. Uh, where it’s harder to get it, it’s in bigger corporations. But it’s in these places where I think that it’s most needed because the amount of process, the amount of bureaucracy, the amount of meetings, is very, very draining to the teams in those places. And usually you see all these just piles up. It seldom gets removed. Um, that, maybe it’s a topic for a different discussion. But I think people are very afraid of removing something and then be responsible of the result that removal brings. But yeah, I have, I have had, um, we can say fairly, a fair success of also getting the executive sponsorship, uh, in, in organizations to, to support this and I have learned a few things also along the way.
Kovid Batra: Would you like to share some of the examples? Not specifically from, let’s say, uh, getting sponsorship from the executives, I would be interested because you say it’s a little hard in places. So what things do you think, uh, can work out when you are in that room where you need to get a buy-in on this? What exactly drives that?
Mario Viktorov Mechoulam: Yes. The first point is the same, both for grassroots movements with teams and executive sponsorship, and that is to be transparent. Transparent with what, what do you want to do? What’s your intent and why do you think this is important? Uh, now here, and I’m embarrassed to say this, um, we, we want to change the culture, right? So we should focus on talking about habits, um, right? About culture, about people, et cetera. Not that much about, um, magic to say that, but I, but I’m guilty of using that because, um, people, people like how this sounds, people like to see, to, to, to hear, oh, we’ll introduce metrics and they will be faster and we’ll be more efficient. Um, so it’s not a direct relationship. As I said, it’s a stepping stone that can help you get there. Um, but, but it’s not, it’s not a one month journey or a one year journey. It can take slightly longer, but sometimes to get, to get the attention, you have to have a pitch which focuses more on efficiency, which focuses more on predictability and these type of things. So that’s definitely one, one learning. Um, second learning is that it’s very important, no matter who you are, but it’s even more important when you are, uh, not at the top of the, uh, of the management, uh, uh, pyramid to get, um, by, uh, so to get coaching from your, your direct manager. So if you have somebody that, uh, makes your goals, your objectives, their own, uh, it’s great because they have more experience, uh, they can help you navigate these and present the cases, uh, in a much better and structured way for the, for the intent that you have. And I was very lucky there as well to count on people that were supportive, uh, that were coaching me along the way. Um, yes.
So, first step is the same. First step is to be transparent and, uh, with your intent and share something that you have done already. Uh, here we are often in a situation where you have to put your money where your mouth is, and sometimes you have to invest from your own pocket if you want, for example, um, to use a specific tool. So to me, tools don’t really matter. So what’s important is start with some, something and then build up on top of it, change the culture, and then you’ll find the perfect tool that serves your purpose. Um, exactly. So sometimes you have to, you have to initiate this if you want to have some, some, some metrics. Of course, you can always do this manually. I’ve done it in the past, but I definitely don’t recommend it because it’s a lot of work. In an era where most of these tools are commodities, so we’re lucky enough to be able to gather this metric, this information. Yeah, so usually after this PoC, this experiment for three to six months with the team, you should have some results that you can present, um, to, um, to get executive sponsorship. Something that’s important here that I learned is that you need to present the results very, very precisely. Uh, so what was the problem? What are the actions we did? What’s the result? And that’s not always easy because when you, when you work with metrics for a while, you quickly start to see that there are a lot of synergies. There’s overlapping. There are things that impact other things, right? So sometimes you see a change in the trend, you see an improvement somewhere, uh, you see the cultural impact also happening, but you’re not able to define exactly what’s one thing that we need or two things that we, that we need to change that. Um, so, so that part, I think is very important, but it’s not always easy. So it has to be prepared clearly. Um, the second part is that unfortunately, I discovered that not many people are familiar with the topics. So when introducing it to get the exact sponsorship, you need to, you need to be able to explain them in a very simple, uh, and an easy way and also be mindful of the time because most of the people are very busy. Um, so you don’t want to go in a full, uh, full blown explanation of several hours.
Kovid Batra: I think those people should watch these kinds of podcasts.
Mario Viktorov Mechoulam: Yeah. Um, but, but, yeah, so it’s, it’s, it’s the experiment, it’s the results, it’s the actions, but also it’s a bit of background of why is this important and, um, yeah, and, and how did it influence what we did.
Kovid Batra: Yeah, I mean, there’s always, uh, different, uh, levels where people are in this journey. Let’s, let’s call this a journey where you are super aware, you know what needs to be done. And then there is a place where you’re not aware of the problem itself. So when you go through this funnel, there are people whom you need to onboard in your team, who need to first understand what we are talking about what does it mean, how it’s going to impact, and what exactly it is, in very simple layman language. So I totally understand that point and realize that how easy as well as difficult it is to get these things in place, bring that culture of metrics, engineering metrics in the engineering teams.
Well, I think this was something really, really interesting. Uh, one last piece that I want to touch upon is when you put in all these efforts into onboarding the teams, fostering that culture, getting buy-in from the executives, doing your PoCs and then presenting it, getting in sync with the team, there must be some specific indicators, right, that you start seeing in the teams. I know you have just covered it, but I want to again highlight that point that what exactly someone who is, let’s say an engineering manager and trying to implement it in the team should be looking for early on, or let’s say maybe one month, two months down the line when they started doing that PoC in their teams.
Mario Viktorov Mechoulam: I think, um, how comfortable the people in the team get in discussing and explaining the concepts during analysis of the metrics, this quality analysis is key. Um, and this is probably where most of the effort goes in the first months. We need to make sure that people do understand the metrics, what they represent, how the work we do has an impact on those. And, um, when we reached that point, um, one, one cue for me was the people in my teams, uh, telling me, I want to run this. This meant to me that we had closed the circle and we were close to having a habit and people were, uh, were ready to have this responsibility delegated to them to execute this. So it put people in a place where, um, they had to drive a conversation and they had to think about okay, what am I seeing? What happened? But what could it mean? But then what actions do we want to take? But this is something that we saw in the past already, and we tried to address, and then maybe we made it worse. And then you should also see, um, a change in the trend of metrics. For example, work in progress, getting from 30+ down to something close to the team size. Uh, it could be even better because even then it means that people are working independently and maybe you want them to collaborate. Um, some of the metrics change drastically. Uh, we can, we can talk about it another time, but the standard deviation of the cycle time, you can see how it squeezes, which means that, uh, it, it doesn’t, uh, feel random anymore. When, when I’m going to ship something, but now right now we can make a very, um, a very accurate guess of when, when it’s going to happen. So these types of things to me, mark, uh, good, good changes and that you’re on the right path.
Kovid Batra: Uh, honestly, Mario, very insightful, very practical tips that I have heard today about the implementation piece, and I’m sure this doesn’t end here. Uh, we are going to have more such discussions on this topic, and I want to deep dive into what exact metrics, how to use them, what suits which situation, talking about things like standard deviation from your cycle time would start changing, and that is in itself an interesting thing to talk about. So probably we’ll cover that in the next podcast that we have with you. For today, uh, this is our time. Any parting advice that you would like to share with the audience? Let’s say, there is an Engineering Manager. Let’s say, Mario five years back, who is thinking to go in this direction, what piece of advice would you give that person to get on this journey and what’s the incentive for that person?
Mario Viktorov Mechoulam: Yes. Okay. Clear. In, in general, you, you’ll, you’ll hear that people and teams are too busy to improve. We all know that. So I think as a manager who wants to start introducing these, uh, these concepts and these metrics, your, one of your responsibilities is to make room, to make space for the team, so that they can sit down and have a quality, quality time for this type of conversation. Without it, it’s not, uh, it’s not going to happen.
Kovid Batra: Okay, perfect. Great, Mario. It was great having you here. And I’m sure, uh, we are recording a few more sessions on this topic because this is close to us as well. But for today, this is our time. Thank you so much. See you once again.
Mario Viktorov Mechoulam: Thank you, Kovid. Pleasure is mine. Bye-bye!
Kovid Batra: Bye.
In the third session of 'Unlocking Engineering Productivity' webinar by Typo, host Kovid Batra converses with engineering leaders Clint Calleja and Rens Methratta about strategies for enhancing team productivity.
Clint, Senior Director of Engineering at Contentsquare, and Rens, CTO at Prendio, share their perspectives on the importance of psychological safety, clear communication, and the integration of AI tools to boost productivity. The panel emphasizes balancing short-term deliverables with long-term technical debt, and the vital role of culture and clear goals in aligning teams. Through discussions on personal experiences, challenges, and learnings, the session provides actionable insights for engineering managers to improve developer experience and foster a collaborative working environment.
Kovid Batra: All right. Welcome to the third session of Unlocking Engineering Productivity. This is Kovid, your host and with me today we have two amazing, passionate engineering leaders, Clint and Rens. So I’ll introduce them one by one. Let’s go ahead. Uh, Clint, uh, he’s the senior Director of engineering at Contentsquare, ex-Hotjar, uh, a long time friend and a mentor. Uh, welcome, welcome to the show, Clint. It is great to have you here.
Clint Calleja: Thank you. Thank you, Kovid. It’s, uh, it’s uh, it’s very exciting to be here. Thank you for the invite.
Kovid Batra: Alright. Uh, so Clint, uh, I think we were talking about your hobbies last time and I was really, uh, fascinated by the fact. So guys, uh, Clint is actually training in martial arts. Uh, he’s very, very, uh, well trained professional martial arts player and he’s particularly, uh, more interested in karate. Is it right, Clint?
Clint Calleja: Yes. Yes indeed. It’s, uh, I wouldn’t say professionally, you know, we’ve been at it for two years, me and the kids. But yes, it’s, uh, it’s grown on me. I enjoy it.
Kovid Batra: Perfect. What else do you like? Uh, would you like to share something about your hobbies and passions?
Clint Calleja: Yeah, I’m, I’m pretty much into, um, on the, you know, more movement side. Uh, I’m, I’m, I’m into sports in general, like fit training, and I enjoy a game of squash here and there. And then on the commerce side, I need my, you know, daily dose of reading. It, it varies. Sometimes it’s, uh, around leadership, sometimes psychology. Uh, lately it’s a bit more also into stoicism and the art of controlling, you know, thinking about what we can control. Uh, yeah, that’s, that’s me basically.
Kovid Batra: That’s great. Really interesting. Um, the, another guest that we have today, uh, we have Rens with us. Uh, Rens is CTO of Prendio. Uh, he is also a typo product user and a product champion. He has been guiding us throughout, uh, on building the product so far. Welcome to the show, Rens.
Rens Methratta: Hi, Kovid. Uh, you know, it’s good to be here. Uh, Clint, it’s really good to meet you. Uh, very excited to participate and, uh, uh, it’s always really good to, uh, talk shop. Uh, enjoy it.
Kovid Batra: Thank you so much. Thank you so much. Uh, all right, uh, Rens, would you like to tell us something about your hobbies? How do you unwind your day? What do you do outside of work?
Rens Methratta: Yeah, no, um, it’s funny, I don’t have many, I don’t think I have many hobbies anymore. I mean, I have two young kids now, um, and they are, uh, they take up, their hobbies are my hobbies. So, uh, um, so gymnastics, soccer, um, we have, uh, other, you know, a lot of different sports things and piano. So I, I’ve, I’ve learning, I’m learning piano with my daughter. I guess that’s a hobby. Um, that’s, uh, not far asleep, but I’m, I’m enjoying it. But I think a lot of their things that they do become stuff that, um, I get involved in and I really try to, um, I try to enjoy it with them as well. It makes, it makes it more fun.
Kovid Batra: No, I can totally understand that, because having two kids and, uh, being in a CTO position, uh, I think all your time would be consumed outside of work by the kids. Uh, that’s, that’s totally fine. And if your hobbies are aligned with what your kids are doing, that’s, that’s good for them and good for you.
Rens Methratta: Yeah, no, I, I, I think, I think it’s, I, I, I, I love it. I enjoy it. I, it keeps me, you know, I always say, you know, I think there’s a, I remember learning a long time ago, someone said that, you know, how you, uh, the, when you get older, you know, life, life goes by faster. ’cause you kept on doing the same stuff every day and your mind just samples less, right? So, like, they kind of keep me young. I get to do new stuff, um, with, through them. So it’s, it’s been good.
Kovid Batra: Perfect. Perfect. Um, thanks for the, for the introduction. Uh, we got to know you a little more, but that doesn’t stop here. Uh, Clint, you were talking about psychology reading those books. Uh, there is one small ritual, uh, on, on this show, uh, that is again, driven from my, uh, love for psychology, understanding human behavior and everything. So, uh, the ritual is basically that you have to tell something about yourself, uh, from your childhood, from your teenage, uh, that defines you who you are today.
Clint Calleja: Very interesting question. It reminds me of, uh, of a previous manager I used to have used to like, okay, asking this question as well. I think, um, there was a recent one which we just mentioned. Uh, you know, we’re mentioning kids, Rens, you got me to it. The fact that I actually started training martial arts because of the kids, I took them and I ended up doing it myself. Uh, so it was one of those. But I think the biggest one that comes to mind was, um, in 2005, at the age of 22, um, in Malta, you know, we’re a very tightly-knit culture. Um, uh, people, you know, stay living with their parents long, where a small island, everyone is close by. So I wanted to see what’s out there. So I went to live for a year in Germany. Um, and it was, I think this was the most defining moment because for two France. On one side it was the, um, a career opportunity where whilst I was still studying. So for software engineering part-time, um, there was this company that offered to take me on as an intern, but trained me for a whole year in their offices in Germany. So that was a good, uh, step in the right direction career wise, but, uh, outside, you know, of the profession, just on a personal life basis, it was such an eye-opener. It was, uh, this was the year where I realized, um, how many things were, was I taking for granted? You know, like, uh, family and friends. Yeah. Close by when you need them. Um, even simple things like, you know, the sunny weather in Malta, so the sea close by, like, I think this was the year where I became much more aware of all of this and, uh, could be, could reflect a bit deeper.
Kovid Batra: I totally relate to this actually. Uh, for you it happened, uh, I would say a little late because probably you moved out during your, uh, job or, uh, later in the college. For me, it happened in early teenage, I moved out for schooling for host, hostel and there were same realizations that I had and it got me thinking a lot about what I was taking for granted. So I totally relate and, and, and that actually defined me, who am I today. I’m much more grateful towards my parents and, uh, family that I have with me. Yeah.
Clint Calleja: Exactly. Exactly.
Kovid Batra: Yeah. Yeah, yeah. Totally. Rens, it’s your turn now.
Rens Methratta: Yeah. I, I, yeah. I’m, I’m glad, um, I, thinking through this, it was, it was an interesting question. Um, I think, you know, I, I, I’d say me growing up, I grew up on a, with my grandparents, right. And, and we, we had a farm, and I think growing up with them, obviously them being a bit older, I, I think they had a, you know, that there’s, I think you get older, you get a little bit more sense of maturity, kind of, you know, thinking of the world and seeing that at a young age, I think was really good for me because, you know, they were, you know, in farming there’s lots of things that sometimes go wrong. There’s floods, there’s, uh, disease, there’s, yeah, lots of stuff. But you know how they kind of approach things like, you know, they’re, you know, they were, they were never about, you know, let’s, let’s blame anyone, let’s do this, let’s, you know, really focus on, hey, let’s stay calm. Let’s focus on solving the problem. Let’s figure it out. Kind of staying positive. And, and I think that was really helpful for me. I think in setting an example, and really the biggest thing they taught me was like, you know, there are certain things you just can’t control. You know, just focus on things you can control and worry about those. And, you know, and, and, and, and that’s it. Really be positive in a lot of ways. Yeah. And I, I carry that with me a lot. And I think there’s, you know, there’s a lot of stuff you can stress out about, but there’s only so many things you can control and you kinda let go of everything else. So, so totally. That’s kind of, keep that with me.
Kovid Batra: Totally makes sense. I mean, uh, people like you coming from humble backgrounds are more fighter in nature. Uh, they’re more positive in lives, they’re more optimistic towards such situations. And I’ve seen that in a lot of, a lot of folks around me. Uh, people who are privileged do not really, um, get to be that anti-fragile, uh, when situations come, they break down easily. So I think that defines who you are. I totally relate to that. Perfect. Great. Thank you. Thank you for sharing this. Uh, alright guys. Uh, I think now we will move on to the main section, uh, whatever this particular unlocking engineering productivity is about. Uh, uh, today’s theme is around, uh, developer experience and of course the experience is that you have, you both have gathered over your engineering leadership journey. So I’ll start with a very fundamental thing and I think, uh, we’ll, we’ll go with Rens first. Uh, so let, let’s say, Rens, we, we’ll start. Uh, what according to you is engineering productivity? I mean, that’s the very fundamental question that I ask on this episode, but I want to hear out, the audience would want to understand what is the perspective of engineering leaders of such high performing teams when they talk about productivity?
Rens Methratta: Yeah, I think, you know, a lot of ways I, there there’s, are the, obviously the simple things, metrics you like, um, you know, velocity, things like that. Those are always good. Those are good to have. But from my perspective, um, and the way that I, I think really good teams function is, uh, making sure the teams are aligned with business objectives, right? So what we’re trying to accomplish, common goals, um, regardless of, you know, how big an organization is, I think if, um, and it gets harder when you get bigger, obviously, right? It’s like identifying, uh, the layers between your impact and then maybe the business is higher. Maybe it’s easier for smaller teams. Um, but, but regardless, I think that’s, that’s always been what I’ve seen that the outcome, a linking to the outcomes that makes the most sense, and understanding productivity. So like, hey, these are, this is, this is what their goals are. You know, I think OKRs work really well in terms of structuring that as a, as a framework. Right. But realistically I’m saying, Hey, here’s, here’s what we as a team are trying to accomplish. Uh, you know, here’s how we’re gonna measure it based on some sort of, you know, whatever the business metric is or the key outcome is. And then let’s work on fi, let’s work on figuring it out. And then, then, then, then basically how we, how we do that is okay. We, uh, I think my approach has always been, um, this is what we want to do. This is what we think we need to do to do, uh, do it. And then what are we gonna commit to? Like, when do we think, what are we gonna commit to? When are we gonna get it done, right? And how well do we do to that? Right? So I think that’s how we tie it all together. Um, so basically just yeah, uh, you know, getting us all line aligned on objectives, right? And making sure the objectives have meaning to the team. Like I, I, it’s always hard when people feel like why am I doing this, right? And, and that’s always the worst, right? But if it’s clear that, hey, we, we know how this is gonna make an impact on our customers or the business, and they can see it. Um, and then, but then aligning to, okay, we see it, we see the problem, here’s a solution, we think it’s gonna work. Uh, here’s what we’re committing to, to fix it. And then, then, then it’s really measuring, you know, how well did we meet on committing, getting to that? You know, did we re, did we deliver what we said we’re gonna deliver? Did we deliver it on time? Those are things that we kind of look at.
Kovid Batra: Got it. Got it. What, what do you have to say, Clint? Uh.
Clint Calleja: It’s, uh, it, it’s, uh, my, my definition is very much aligned. Like, uh, from a, a higher perspective. To me, it all boils down. And, um, how well are we, uh, and how well and quickly are we delivering the right value to the user? Right? And, uh, this kind of, uh, if we drill down to this, um, this means like how quickly are we able to experiment and learn from that as our architecture is allowing us to do that as quickly as we want. How well are we planning and executing on those plans, uh, with least disruptions possible, like being proactive rather than be reactive to disruption. So there’s, you know, there’s a whole, uh, sphere of accountability that we, we, we need to take into consideration.
Kovid Batra: Makes sense. I think both of you, uh, are pointing towards the same thing. Fundamentally, if I see it, it’s about more about delivering value to the customer, delivering more value, which aligns with the business goals, and that totally makes sense. But what, what do you guys think, uh, when it comes to, uh, other peers, uh, other engineering leaders, do you see the same perspective, uh, about engineering productivity, uh, Rens?
Rens Methratta: Um, I think in general, yes. I think, I think you end up and I, and I think sometimes you end up getting caught in. Um, I, you know, sometimes you get caught up in just hitting, trying to hit a metric, right? And then losing track of, you know, are we working on the right things? Is this, is this worthwhile? I think that’s when it’s, it could be, uh, you know, maybe problematic, right? So I, you know, I even in my early in my career at this, if they, where I’ve, I’ve done that, like, hey, you know, let’s, let’s be really as efficient as possible in terms of building a metrics organization, right? We’ll do kind of, everything’s our small projects, right? And we’ll get these things in really quickly. And, you know, I I, I think that, you know, what I learned is in that situation, like, yeah, we’re, we’re doing stuff, but then the team’s not as motivated. The, you know, we’re not, it’s not as collaborative, the outcome isn’t gonna be, um, as good. Like I think if we have, I think the really key thing is from my perspective, is keeping having a, a team that’s engaged, right? And being part of the process and proactive. Right. And obviously measuring to what the outcomes are, but, um, that’s side of my, where I feel it’s great when we, when we go to a, like a, a, uh, or a retrospective or a sprint planning where we’re like, Hey, teams are like, I don’t think this works. Like I, I, the worst part is when you get like crickets from people, like, okay, this is what we wanna do. Like, and no, no real feedback. Right? I think I really look for, you know, how engaged teams are, you know, how in terms of solving the problem, right? Um, and that’s, and I think that a lot of that cross collaboration, right? And how, um, and building a, a kind of environment where people feel empowered to kind of ask those questions, be collaborative, ask tough questions too, right? Like, I, I love it when an engineer says this, this is not gonna work, right? And it’s great. I’m like, yeah, let’s tell me why. Right? So I, I think if we can build cultures that way, that, that, that’s, that’s ideal.
Kovid Batra: Makes sense. Perfect. Uh, Clint, for you, uh, do you see the same perspective and how, how things get prioritized in that way?
Clint Calleja: I, I particularly love the focus and the tension on the culture, the cultural aspect. I think there’s, there’s more to it that we can unpack there, but yes, in general, um, I think actually when, when I heard this question, it reminded me of when I realized the needs of data points, not just for the sake of data points, of KPIs, but what I started to see as the company started to grow is that without sitting down and agreeing on what good looks like, what are the data points that we’re looking at, I started to see, um, a close definition, but not, not exact definition, which still left, you know, openness to interpretation. And there were cases as we grew, uh, bigger and bigger where, for example, I felt we were performing well, whereas someone else felt differently. And then you sit down and you realize, okay, this is the crux of the problem, so we need that. That was the eureka moment where like, okay, so this is where we need data points on team performance, on system performance, on product performance in general.
Kovid Batra: Yeah. Makes sense. I think both of, both of you have brought in some really good points and I would like to deep dive into those as we move forward. Uh, but before, like we move on to some specific experiences around those pointers, uh, Clint, uh, in your journey, uh, over the last so many years, there must have been some counterintuitive things that I would have that you would’ve realized now, uh, uh, that are not aligned with what you used to think earlier, how productivity is driven in teams. Are there any, anythings? Is, is that thing ringing a bell?
Clint Calleja: Uh, well, if you ask me about learnings on, uh, you know, things that I used to think are good for productivity and now I think they’re not, and I evolve them, I think I keep having these one and one out, right? Um, but again, like, uh, the alignment on piece, key set of indicators rather than just a few was one of those big changes in my, in my leadership career, because I went from using sprint, um, as the only data points to then extending to understanding why the DORA metrics better, why actually SPACE matters even more because they’re the, um, the, the wellbeing factor and how engaged people are. So, uh, I realized that I needed to form a bigger picture of data points in order to be able, able, able to understand all the picture. And again, not just the data points, the quantitative data points, I also needed to fill in the gaps with the qualitative parts.
Kovid Batra: Sure. I think, yeah, that goes hand in hand, uh, alone, either of those is not sufficient to actually look at what’s going on and how to improve on those factors. Perfect. Makes sense. Rens, for you, uh, there must have been some learnings over the years and, uh, anything that you find was intuitive earlier, but now it’s counterintuitive? Yeah.
Rens Methratta: Yeah, no, I think I, learnings every day. Um, but I, I, yeah, in general, maybe what Clint said, right? So you, I did end up at some point overindexing on like some of the quantitative stuff, right? And it’s like, and, and you lose track of what are you trying to do, right? So, hey, I did, we did really well. We, um, you know, we’re doing, um, in terms of, uh, you know, we, we got through our sprints, we got, we were getting to the, uh, we’re doing planning where, hey, our meeting times are low, right? Or these, these are so many things you can, there’s so many things you can look at, and then you lose pic, then lose track of the greater picture, right? So I, I do think of, you know, identifying those north stars, right? And these was referencing, right? Those what we think are important, saying, Hey, what are, how are we measuring to that? And also then also that helps you make sure you’re looking at the right metrics, potentially, right? And putting them in the right context, right? So, you know, it doesn’t matter your, if your velocity’s great, if you’re not building the right things, right? If you, it doesn’t matter if you’re like, so those are the things I think you kinda learned. Like, hey, sometimes it’s just. Um, you know, simplify, you know, the, you know, the what you want, what you, the what you, what you look at, right? And, and try to, try to think through like a, how are, how are we as a team meeting that? And also try to, primarily from a team perspective, right? Getting alignment on that. Like, Hey, this is what we’re, this is the goal we’re trying to get to. And I, I feel like that’s when you get most, uh, commitment from the team too. Like, Hey, uh, it’s easy. I know what we’re trying to do it, and it, it, it, it motivates people to be like, yep, this is what we’re trying to get to. It’s, it’s, it’s something to celebrate when we get to it, right? Otherwise, it just gets, I, it’s, it’s not hard. It’s, it’s it’s hard to celebrate. Like, oh, we got, we got X velocity. I’m like, ah, that’s not, that’s not right. So yeah, I think that’s a better learning, simplifying, right? And, and, um, and also, you know, simplifying in a way and then defining the metrics based on those core metrics like the, uh, and so they all flow down so that it, it aligns, right? And people, you can point something easily, easily and say, this is why it’s important. Right? Um, yeah, I think that’s really important when you communicate to people, Hey, look, this is problematic. Uh, we need to, we might need to take a look at this. And be able to really simplify, say, this is why it’s important, this is why it’s problematic. Uh, this is why it’s gonna impact our North Star. Right? I think that makes conversations a lot easier.
Kovid Batra: Totally, makes sense guys. I think having the right direction along with whatever you are doing on day-to-day basis as KPIs is very important. And of course, to understand a holistic picture, uh, to understand the developer’s experience, a team’s experience to improve overall productivity, not just quantitative, but qualitative data is equally important. So I think to sum up both of your learnings, I think this is a good piece of insight. Now, um, we will jump onto the next section, section, but before that, I would like to, uh, tell my audience, our audience that uh, if they have any questions, we are gonna have a QnA round at the end of the session. So it’s better you guys put in all your questions in the comments right now so that we have filtered it out by the end of the episode. And, uh, moving on now. So guys, uh. The next section is about specific experiences that we are gonna deep dive into from Rens and Clint’s journeys. Uh, we’ll start with you, Clint. Uh, I think the, the best part about your experience that I have felt after stalking you on LinkedIn is that, uh, you, you have had experience of going through multiple acquisitions and, uh, you work with smaller and larger organizations, high performing teams. Uh, this kind of experience brings a lot of exposure and we would want to learn something from you. How does this transition happen? And in those transitions, what, what should an engineering leader should be doing, uh, to make it more, uh, to not make it overwhelming and to be more productive and do the right things, create the impact even during those transitions?
Clint Calleja: Uh, yes. Uh, we’ve been through a, I’ve been through a couple of interesting experience, and I think like, uh, I dare to say, for me, they were like, especially the acquisition, uh, where HR was acquired was, um, uh, a unique, a very unique experience to big companies merging together. Um, it’s very easy for such a transition to be overwhelming. I mean, there’s a lot of things to do. Um, so I think the first key takeaway for me is like, clear communication, intentional, um, communication, regular, and, uh, making sure that we as a leader, like you’re making yourself available to support everyone and to help to guide others along this journey. Um, it’s, then there’s the other side of it that, you know, uh, it, it, such an experience is. Um, does not come without its own challenges, right? Uh, the outcomes are big. Um, uh, and in engineering leadership specifically, you know, that there’s a primary, um, area that you start to think about is, okay, the, the systems, what does it mean when talk about technology stacks the platforms? But it’s something not to underestimate, is also the ways of working in the culture when merging with companies because, uh, I, I ca, I ca I started to, uh, coming to the realization that I think there’s more effort required than planning there, than in the technology side, um, of the story. So, very interesting experience. Um, how to get the teams up and running. I mean, my experience last year was very, again, very, very challenging in a good way. You know, I started in a completely new. Department with about 55 people. 70% of them were new to me coming from the parent company. So we needed to, we already had goals to deliver by June and by September. So it, yes. Talk about overwhelm. And I think one of the, one of the key, um, exercises that really helped us, um, start to carve out, um, some breathing space was these iterations of higher level estimations of the things that we need, um, to implement. Uh, they started immediately enabling us to understand if we needed to scope, if we needed to have discussions to either delay or the scope or bring more, uh, people to the mix. So, and following that, you know, kickstarting, we needed to give some space to the teams to come together, start forming their ways of working. The same time getting a high level understanding of what we can commit to. And from there it’s all, again, about regular communication and reflections. It’s like, okay, biweekly, let’s have a quick update, um, and let’s call a spa. The spa. If we’re in the red, let’s call it out. I’d rather, you know, we’d rather know early so that we can do something about it where there’s time rather than, I’m not sure if you’ve ever seen the situation, but you see a status in the green for almost all a quarter. All of a sudden you get to the last two weeks and then the red. So.
Kovid Batra: Makes sense. Um, while, while we were, uh, initially talking, you said there is a lot to unpack on the, on the developer experience part. I’m sure, uh, that that’s something very core to you, your leadership style, where you ensure a good, uh, developer experience amongst your team. So now you shifted to a new team, uh, and in general, wherever you have been leading teams, uh, are there any specific practices around building a good developer experience that you have been following and that have been working for you? And if there are, uh, can you just share something?
Clint Calleja: That’s a very good question, because I, I see different teams, right? So I’ve done different exercises with different teams, but in this particular case, where I started from was I, I realized that, okay, when you have a new, uh, line being formed, mixed cultures coming from different companies, I said, okay, the one thing I can start with is at least providing, um, a community culture, um, where people feel safe enough to speak up. Why? Because we have challenging goals. We have a lot of questions. There are areas that are known. If people won’t be able to speak up, will, you know, the probability of surprises is gonna be much, much higher.
Kovid Batra: Right.
Clint Calleja: Um, so what are some elements, you know, some actions that I’ve taken to try and improve here? So I think when it comes to leading teams directly in general, we find much more support because even if you look at the Agile manifesto, it talks about a default team where you have a number of engineers who have a trio, ideally, you know, enabled to do decision making. There’s a pattern of reflections that, uh, happen, as Rens said in the retrospectives. Ideally actions get taken. There’s a continuous cycle of improvement. What I found interesting was that beyond one team, right, when I started to lead other leaders or managers, I could see a much bigger opportunity in this team of leaders or team of managers to actually work together as a team. By default, we’re all kind of more focused on our scope, making sure that our people, you know, are, are, are, are, uh, well supported and, uh, and heard and that our team is delivering. But I, I think it’s also worth thinking about if we’re calling it developer experience, let’s call this the manager experience of how much can we help each other out? How much can we support each other to remember that we’re people before managers, you know, like, uh, I dunno, it’s not the first time I, I went to work where I wasn’t feeling so great. So I needed to fine tune myself, expectations on what to produce. So if this is not shared outside with my, with my lead, with my manager, or with my peers, you know, their expectations cannot adjust accordingly. So there’s, there’s a lot of this that I try to, to prioritize by, uh, simple gestures like sharing my weekly goals, trying to encourage my managers to do the same.
Kovid Batra: Yeah.
Clint Calleja: So we can understand the, we try to take one too much in end of week reflection. Think of it like a retrospective, but between managers to say, okay, hey, it was much more disruption than I anticipated this week, and it’s okay. Part of it is actually the psychological safety of being able to say, oh, my short 400%, I only achieved 50. It’s okay. But I learned, right, and I think in terms of metrics, another exercise that I immediately tried to restart in my new line was this exercise that I call the high altitude flight. And this was an exercise where as leaders, we connect those KPIs, um, with qualitative data, like, uh, the weekly pulse and feedback from 15Five, for example. Mm-hmm. And we talk about it on a monthly basis. We bring those data points on a board, you know, start asynchronous, we raise the right questions, uh, challenge each other out and this way we were regularly bringing those data points into the discussion and making sure we’re prioritizing some actions towards them.
Kovid Batra: Totally. I think, um, after talking to so many engineering leaders, one common pattern that I’ve seen, uh, in some of the best leaders is they, they, they over communicate, like in, in a very positive sense I’m saying this, uh, they, they tend, because everyone feels that, uh, a lot of times you’re in a hybrid culture, in a remote culture where as much as you communicate is less actually. So, having those discussions, giving that psychological safety has always worked out for the teams, and I’m sure your team would be very happy in the way you have been driving things. Uh, but thanks, thanks for sharing this experience. I’ll get back to you. Uh, I have a few questions for Rens also on this note. Uh, so Rens’ journey has also been very interesting. He has been the CTO at Prendio and uh, recently I was talking to him about some of the recent initiatives that he was working on with the team. And he talked about some, uh, copilot and, uh, few other automated, uh, code analysis tools that he has been integrating in the team. So Rens, could you just share some experience from there and how that has, uh, impacted the developer experience and the productivity in your teams?
Rens Methratta: Um, yeah, I’d be happy to. It’s been, I think there’s a lot of, a lot of change, uh, happening in terms of capabilities with, uh, AI, right. And, and how we best utilize it. So like, we’ve definitely seen it, you know, as, as models have gotten better, right, I think the biggest thing is we have a, you know, relatively large code base and um, and newer code base for things. And so it’s, it was always good for like, maybe, maybe even like six months ago we would say, Hey, it’s, we can look at some new code, we can improve it, write some unit tests, things like that. But you know, having an AI that has like a really cohesive understanding of our code base and be able to, um, you know, have it, you know, suggest or build, uh, code that would work well, it wasn’t hap, it wouldn’t happen, right. But now it is, right? So I think that’s, that’s coming, the probably the biggest thing we’ve seen in the last couple months and really changing, um, you know, how we think about development a bit, right? Kind of moving, uh, we’ve done some, you know, a lot of this is AI first development, like it changed mindset for us as a team, right? Like how do we, how do we build it? Um, you know, lots of new tools. I think, Kovid, you mentioned there’s tons of new tools available. Yeah. It’s changing constantly, right? So, um, you know, we’ve spent some time. Looking at, looking at some of the newer tools, um, we’ve actually, uh, agreed to as of now, uh, a tool, we, we actually gonna moved everyone over to Cursor. Right. ’cause I just on terms of, um, like what the capabilities it provided and, and, and that, so, uh, and then similarly outside of code, yeah. It’s like, uh, there are tools that, you know, typo has the, uh, you know, for the pull requests, the, you know, uh, uh, summary, things like that’s really helpful, right, for things of that, even on the, and then automated testing, uh, there’s a bunch of things that I think are really changing how we work and make us more productive. And, and it’s, it’s challenging ’cause it’s, you know, it’s, obviously, and it’s good. It’s, it’s a lot of new stuff, right? And it’s really re-making us rethink how we do it. Like, um, you know, developing. So we built, uh, some things now from an AI-first approach, right? So we have to kind of relearn how we do things, right? We’re thinking things out a bit more, like defining things from a prompt first approach, right? What are our prompts, what are our templates for prompts? Like, it’s, it’s been really interesting to see and good to see. Um, uh, and I think, yeah, it definitely made us, uh, more productive and I think we’ll get more productivity as we kind of embrace the tools, but also kind of embrace the mindset. It’s, um, I think for the folks for who’s actually used it as most, and you can kind of see like when they first start utilizing it to maybe where they’re now, like the productivity increase has been tremendous. So that’s probably the biggest change we’ve seen recently. Um, but it, it’s an exciting time. We’re, we’re looking forward to kinda learning more and, and it’s something that we have to, um, you know, we really have to, um, get a better understanding of, uh. But again, which also like challenges too. I would say that too. Right? So, uh, like previously we had a good understanding of what our velocity would be. I am, I mean, right now it’s a good, maybe a good thing, like our velocity would be better, right? And it’s higher. So like, you know, uh, even engaging effort, things like that, it’s, it’s com, it’s a lot of new things that we’re gonna have to learn and, and figure out and, um, reassess. Um, but, um, but yeah, I, I mean, I, I think if I, if I look at anything that’s been different recently, that’s been probably the biggest thing and the biggest change for us in terms of how we work. And then also in kind of incorporate, making sure that we incorporate that into our existing workflows or existing development, uh, structure. That’s, I think it’s a lot of new changes for our team, um, trying to help, help us do it, uh, effectively and making sure we’re thinking about it, but also like giving our team power to like try new stuff has also been really cool too.
Kovid Batra: Perfect. Perfect. And, uh, my next question is actually to both of you. Um, you both are trying to implement, let’s say, AI, uh, think you’re trying to implement a better communication, better one-on-ones, bringing that psychological safety, everything that you guys do, I’m sure you, you both have some way to measure the impact of that particular initiative. So how do you guys actually, uh, measure the impact of such initiatives or such, uh, let’s say AI tooling that you brought in, bring into the picture. Uh, maybe Clint, you, you can go ahead.
Clint Calleja: I don’t have examples around AI toolings and in general, it’s more, you know, about utilizing the, actually deciding which of those KPIs are we actually optimizing for for this quarter. So I am guessing, for example, in Rens’ case we were talking about how much AI already is influencing, uh, productivity. So, um, so I would, um, assume or expect a pattern of decreased cycle time because of, uh, the quicker time, uh, to, to implement certain code. Um, I think the key part is something that Rens said a while ago is not focusing a lot on the KPI per se, just for the sake of that KP, but connecting it even in the narrative, in the communication, when we set the goal with the teams, connecting it to the user value. So some, for example, some experiences I’ve had. Okay. I had an, an interesting experience where I did exactly that. I just focused on the pickup time without a user connection. And this is where I got the learning. I’m like, okay, maybe I’m optimizing too much about the, the data points. Whereas eventually, we started shifting towards utilizing MTTD, for example, to, uh, reduce the impact of service disruptions on our customers by detecting, um, disruptions internally, uh, using SLOs to understand proactively if we’re eating too much into the other budget. So we actually act before an incident happens, right?
Kovid Batra: Um, right.
Clint Calleja: So, uh, it’s different, uh, different data points. And when going back to the wellbeing, what I found very interesting, I know that there are the engagement surveys that happen every six months to a year usually. Uh, but because of that time frequency, it sets wellbeing as a legging indicator. When we started utilizing, um, 15Five, for example, there are other tools like it, but the intention is, for every one-on-one, weekly or biweekly, you fill a form starting with how well did you feel from 1 to 5. Because we were collecting that data weekly, all of a sudden the wellbeing pulse became a leading indicator, something that I could attribute to a change, an intentional change that we decided to do in leadership.
Kovid Batra: Makes sense. Rens, for you. I think, uh, the question is pretty simple again, uh, like you, you are already using typo, right?
Rens Methratta: We are, yeah.
Kovid Batra: But I would just rephrase my question to ask you like, how do use such tools to, uh, make sure maybe your planning, your execution or your automation or your reflection is in place. Uh, how, how do you leverage that?
Rens Methratta: Yeah, and, and I think, I think it’s, uh, maybe understand the same thing. I think, uh, and aligning those two, you know, what the objectives are, right? So I love, uh, I know primarily the sprint retrospective like it, but not the detail, like more on just, um, as a collective team, we said, Hey, this is what we are trying to accomplish, this, we have a plan to do this. We’ve agreed to, um, hey, this is what we have to get done for, you know, these next couple of weeks to make it right. And then it’s, you know, really having the, all that in one place to see like, uh, we said we’re gonna, we need to get all this stuff done. Um, you know, we, this is how, this is how we did, right? So there’s, for us, there’s multiple tools to put together. We have ticketing with Jira, we have obviously Git to kind of get little controls, but then having all that merged into one place we can easily see like, okay, this is what we committed to, this is what we did. Right? And then, and then if, then basically having, being able to say, okay, I will, well, okay, one, okay, here’s where we are. Do we need to, what do we need to do to kind of, uh, kind of problem solve? Are we behind? What do we, what should we do? Right? Having those discussions is great. And then also being like, okay, well, um, and so then it’s again, can we still meet these goals that we wanna do from an objective perspective? What’s holding us back? I think getting to the point where we can have those conversations easily, right? That’s, that’s what the tools, uh, well, and for Typo, that’s what we really use it for, right? So in, instead of, uh, because it’s the context that all those individual stats provide, right? That’s more important. Uh, and and that context towards how does that, at the end of the day, that aligns to what our overall goal is, right? We have this goal, we’re trying to build this or, uh, change this, right? And for our customers, or because of a reason, uh, and, and being able to see like how we’re doing, uh, to that, right? In a, in a, in a good summary is really, is really, uh, is what we find the most useful and then so we can take action on it, right? Um, otherwise if we might, yeah, sometimes you kind of, you look at all these individual stats and you kind of, you, you lose track of it if you just look at those individually. Kind of. But if you have a holistic view of here’s how we are doing, uh, which, which we use it for, that, that really helps.
Kovid Batra: Perfect. Perfect. Clint, do you have anything to add on to that?
Clint Calleja: Not specifically, not at this stage.
Kovid Batra: Alright, perfect. Uh, I think, uh, thanks, uh, both of you for sharing, uh, your experiences. Now I think it’s time for us to move on to the QnA section. And I already see, uh, we are, uh, flooded with a few questions here and, uh, we’ll take a minutes break right now and, uh, in the meantime I will just pick on the questions that we need to prioritize here. Alright.
All right, so, uh, there are some interesting people here who have come up. Uh, Clint, I’m sure you have already seen the name. Uh, Paulo uh, the, the guest from the last session and one of our common friends, uh, uh, I’ll just pull up his question first. So I think, uh, this question, uh, Clint, you can take up. Uh, engineering productivity is a lot about the relationship with the product. As senior engineering leaders, what does a great product lead look like?
Clint Calleja: Very good question. Uh, hi Paulo. Um, well, I, I, I, I’ve seen a fair share, right? Uh, of, uh, good traits in, in product, product leads. That’s not me, right? No, that’s not you. Um, I, I think what I can speak for is what I, I tend to look for, um, and first and foremost, I tend to look for in a partner, um, uh, so ideally no division, because that division, um, easily, um, gets, uh, downstream, you know. You start to see that division happening in the teams as well. There’s the, secondly is in the alignment of objectives. So, um, I always tend to lean on my product counterpart to understand more about the top priorities of our product goals. And I bring, uh, which would answer some of the questions here, I bring in the picture, uh, the top, um, technical solvency, uh, challenges. In order to sustain those product goals. And this way, uh, we find a balance on how to set up the next set of goals for a quarter or half a year. Right. And we build together a narrative that we can share both upwards and with the rest of our teams. Uh, and another characteristic, yes, is regular, um, is actually the teamwork element. Uh, a while ago I explained the differentiation, the opportunity I’ve seen, uh, amongst team leads or managers to work together as a team as well. I think the way I like to see it is as a leader, you have at least three teams. You have the people that, uh, you work for, that report to you. You have your trio as another team, and then there’s the, um, the managers in the department, the other leaders in the department, which is yet another team. So in the product lead, I do lean on for, uh, one of my teams to be one of my team, uh, peers.
Kovid Batra: Makes sense. Perfect. Alright, uh, moving on, uh, to the next question. Uh, that’s from, uh, Vishal. Uh, what are the, some of, what are some of the best practices or tools you have found to improve your own productivity? Rens, would you like to take that?
Rens Methratta: Uh, sure. Um, I’m trying to think. I, I, there’s a lot of tools obviously. I think, I think at the end of the day, I. Um, more than anything else, I would say communication is the biggest thing, right? I would think for productivity. Yeah. From a team perspective. Like, um, like I’ve, you know, I, I’ve, I I’ve worked in a lot of different, uh, types of places from really large enterprise companies to really small startups. Right? And, and I think the common, the common thing, regardless of, of whatever tools we do is really one, how, how well do we, how well are we connected to what we’re building? How well are we, do we as a team understand what we’re trying to build and the overall objectives, right? And, and, um, I think that just, you know, that itself, uh, more than anything is what drives productivity. So like I, you know, I’ve, uh. I, I think the most productive I’ve ever been is, uh, we, we, I was in a startup. We were, uh, we had this one small attic space in the, in, in this, uh, in our, in our city, in, in Cambridge. There was five of us in one room for like, uh, we were, but we were constantly together communicating. Um, and so, uh, and, and then we had, we had a shared vision, right? So we were able to do a lot of stuff very quickly. Um, I think that, so I think what I look into is some of the tools that maybe help us now. It is challenging, I would say, with everyone being remote, right? Distributed. That is probably one of the biggest challenges I, I have for productivity. Um, so, you know, trying to get everyone together. Video calls are great. We try to make sure everyone goes on video, uh, but like at least, you know, try to get, um, as much of that, um, workflow of thinking through like, uh, being together even though we’re not together as much as possible. I, I think that helps a lot. Um, and tools that..
Kovid Batra: Have you, uh, have you tried those digital office tools like, uh, you are virtually in an office?
Rens Methratta: Yeah, we tried that. Uh, I think it’s okay. Uh, we tried some of the white, the whiteboarding tools as well. Right. It, it’s okay. Yeah. You know, quite, and it’s, it’s honestly, it’s, it’s good. Um, but I, you know, the interesting thing I’ve really found, and I, if possible, even if we, if we met one person live for in, in person, even once, right? Yeah. I feel like the relationship between the teams are so much different. So no matter what, no matter how far away we try, we try to get everyone together at least who wants to meet because it is just, uh, I think even like, um, how people’s expressions are, how they are in real life, it, it is so hard to replicate. Right?
Kovid Batra: Totally. Totally. Yeah.
Rens Methratta: And, uh, and those nuances are important in terms of communication. So, um, and, but you know, outside of that, I mean, yeah, I think whatever the things that I would say are the things that can simplify, uh, objectives, right? Make sure it’s clear, uh, anything that would, uh, make, make that easy and straightforward, uh, I think that’s, that’s the best. And then it’s making sure you have easy ways to talk to each other and communicate with each other to kind of, uh, yeah, keep track of what we were doing.
Kovid Batra: Uh, I could see a big smile on Clint’s face when I talked about this virtual office tool. Is, is there an experience that you would like to share, Clint?
Clint Calleja: Uh, not, not really. Like it was, it was fun to hear the question because I’ve been wondering about it as well, but I have to agree with Rens. I think nothing beats, you know, the change that happens after an in-person meetup.
Kovid Batra: Sure.
Clint Calleja: The, the relationships that get built from there are, take a different, you know, a different go to..
Rens Methratta: It is, it is different. Yeah. I, I don’t know why, but if I’ve met someone in person for, I feel like, I know, I feel like I know ’em at a much deeper level than, uh, even though we’re, you know, uh, on video for a long time. It just, it is a different experience.
Kovid Batra: Totally. I think there is another good question. I, I think you both would relate to it. Have you guys had an experience to, uh, work with the Gen Z developers, uh, recently or, or in the last few years?
Rens Methratta: I, I mean, I probably, I’m trying to think through like what Gen Z would be. Yeah.
Kovid Batra: I, I, I get that in my circle, uh, a lot that dealing with the Gen Z developers is getting a little hard for us. And there’s like almost 10 to 12 years and maybe more age gap there. And the thing, and things have changed drastically. So, uh, people find it a little hard to understand and empathize, uh, on, on that front. So do you have anything to share? By the way, this is a question from Madhurima. Uh, yeah.
Rens Methratta: I think, well, I think in general, I think I will just say maybe not, maybe Gen Z, but just in general for junior, more junior developers we bring on board like younger developers, I think it’s, it has been challenging for them too because I think a lot of it’s been remote, A lot of their experience has been remote, right? Um, I think it is harder to acclimate and, and that that a lot of the stuff I’ve learned when I remember, uh, coming up as a software engineer and that’s, a lot of that experience has been like, you know, getting in, meeting with people, whiteboarding, getting through that, right. And having those relationships, um, was really beneficial. So I definitely think it’s harder, um, in that sense. Uh, I, I do think we’ve, uh, personally tried to try to get, um, you know, people who are more junior developers, you know, try to more opportunities to, um, you know, uh, more coaching, um, uh, and, and also like, uh, more one-on-one time just to try to help them acclimate to that because I think we’ve identified that it is harder, especially if we’re being remote first. Um, I haven’t had any, um, I don’t think anything, yeah, I know the memes of the Gen Z developers. I haven’t got any meme worthy stuff or experiences for Gen Z developer. Hasn’t been that, so I’ve maybe, I’ve been lucky, so, but I, I do, but I would empathize with that. It is harder for junior devs because, you know, we are in a much more, you know, uh, remote world and it, it, it’s harder to make those connections.
Kovid Batra: Totally. All right.
Clint Calleja: I think, uh, if I, if I may add something to this, I, uh, maybe what I, I’d add is I, I don’t have a specific way to deal with Gen Z developers because what I try to do is I try to optimize for inclusivity. Okay, there’s Gen Z, but there are many other, you know, cultures and subcultures that require specific attention. So at the end of the day, what I found to be the, at least the best way forward, is a good, strong set of values that are exemplified, that comes from the company, a consistent way of sharing feedback, uh, and the guidelines of how feedback is shared, and of course, making space for anyone to be heard in their preferred, uh, way, you know, they’d like to communicate and you can easily understand this if, you know, as just a part, part of your onboarding, you ask people to provide the user manual for you to understand how is it the best way, you know, for these people to communicate, to get the feedback. So think of it this way, it’s like, okay, providing the support for interfaces which are consistent for everyone, but then being available, uh, for everyone to communicate and get the support the way they prefer it, if that makes sense.
Kovid Batra: Okay. Totally. Alright, uh, thanks guys. Moving on to the next question. Uh, this is from Gaurav. Uh, how do you balance short-term deliverables with long-term technical debt management? Also, how to plan them out effectively while giving some freedom to the engineering teams, some bandwidth to explore and innovate and delve into the unknowns. Uh, Clint, would you like to go first?
Clint Calleja: Sure. Uh, when I, when going through this question, the first thing that came to mind, something that I wanna be clear, I’m not an expert of, but I started, you know, trying and iterating upon is the definition of an engineering strategy. Uh, because this is exactly what I used to try and understand, get a di.. So there’s this, the, the book, uh, ‘Good Strategy Bad Strategy’. So I try to replicate the tips from there. And it’s basically getting a diagnosis of, okay, where’s the money coming from? What are our product goals? And there are other areas to cover. And then coming up with policies, guiding policies. So the, you know, your team knows the direction we want to go, and some high level actions that could be really and truly could become projects or goals to be set as OKRs, for example, I don’t know. Uh, we realized the need from the diagnosis. We realize the need, we need to simplify our architecture, for example. So then I connect that engineering strategy and actions to goals, so that the teams have enough freedom to choose what to tackle on, uh, first, uh, whilst having enough direction on my end.
Kovid Batra: Makes sense.
Clint Calleja: So I’m still fine tuning on how, how good that strategy is. Right. But it’s, it really helps me there.
Kovid Batra: Perfect. Uh, the other part of the question also mentions about giving engineering teams that bandwidth, uh, that freedom to innovate and delve into the unknown. So, of course, one part of the question does get answered from your strategy framework, but in that, how, how much do you account for the bandwidth that teams would need to innovate and delve into the unknown? Uh..
Rens Methratta: I, I can deal with that or Clint, either way, I, I think..
Clint Calleja: Go, go, go, go.
Rens Methratta: No, uh, it’s, it’s an interesting point. Like, um, we look at it, I, I think in, in general, like I, we define it like an overall architecture. We try to, for everything we do, like here’s our high level where we want to be from a technical perspective, right? And then whatever solutions we’re trying to do, we, we always wanna try to get to that. But there’s always these, you know, the short and long term and, and how much do we give engineers ability to innovate? We really look at it this way there. If it’s something we need to do right away and we say, Hey, look. Uh, and then, um, and typically if someone has a really great idea and then just like, let’s, let’s do it. Uh, I think our overall question is, okay, worst case scenario, what’s our long, how long would this take to, uh, completely redo to get back to our architecture? Right? Um, and if it’s, if it’s like, Hey, if it’s not gonna, it’s, it’s not gonna increase in, it’s not gonna increase in complexity to redo this a year from now if we, if this is the wrong mistake, right? If we, if the, so we, we are much more lenient towards let’s try something, let’s do this, right? If we think worst case scenario, it’s not gonna be exponentially worse if we put this into production to, to roll this back. Right. And so, uh, if it’s something that is gonna say like, oh, this is gonna lead us down a path where if we’re, this is gonna be, we’re never gonna be able to be fix this, right? Or it’s gonna take us so much effort to fix this, then we’re much more careful and we’re like, well, let’s, let’s see, you know, we might not wanna give as much leeway there. So that’s, that’s kinda how we balance it out typically.
Kovid Batra: Makes sense. Makes sense. Perfect. Uh, moving on, uh, probably the last question. Uh, this is from Moshiour. Uh, what’s your approach to balancing new feature development with improving system? I think this is what we have already taken up. Do you have practical guidelines for deciding on when to prioritize innovation versus strengthening your foundations? Uh, Moshiour, I think we just answered this question, uh, in the previous question. So, we’ll, we’ll, uh, give this a pass for now, uh, and move on to the next question. Okay. There is another one from Paulo. Uh, how much of engineering productivity do you attribute to great engineers versus how work and information flows among individuals? So, Rens, would you like to take that?
Rens Methratta: Um, this is like a yes and yes. Like, I mean, uh, I, I, I think, uh, really great engineers have like, you know, really great productivity, right? It’s, it’s, it’s, it’s a both, it’s a both thing, right? So if you have, um, we’ve seen, I think we’ve kind of seen it from, I get more experienced, like, uh, even on the let’s recent stuff on the AI side. Like we, we playing around with folks who’ve really have gotten understand, understood our, like really solid understanding of our technical infrastructure, but can, you know, learn to use those tools effectively. The output is, is like maybe 10x, but someone who’s, um, you know, not as solid on like maybe some of our existing code base technical understandings and utilizing it is, is still improving. It’s like, you know, maybe 2x, 3x, right? So you definitely see that difference. Um, and I think that’s important. Um, but I, I think, you know, the other part about that is communication between the teams and how you do it and making sure that, similarly going back to productivity, like are we, are we building the right things? Right? We can build, yeah, you know, a lot of, a lot of stuff very quickly, but it might not be worth it if we don’t communicate well, we’re probably building completely different things. So I, I think it goes hand in hand. Um, I, you know, I think, I don’t think there’s a really way to. Uh, it’s not an, it’s not an ‘or’, it’s really an ‘and’.
Kovid Batra: Perfect. No, I think it’s, it’s well answered. Clint, do you have anything to add here?
Clint Calleja: It’s, uh, very much in line with Rens, I think, and even, you know, even in fact the KPI, the KPI suggest looking at the holistic of a theme. So once I do believed that, you know, great engineers, the experience an engineer brings will make a difference. It’s not the first time I’ve also seen great engineers not compatible with a team, and they, you know, the, the, it doesn’t work out. So you start to see that the productivity is not really, uh, improving. So yes, you need great engineers, but, uh, there’s a very big emphasis. I think it goes, it’s beyond 50/50. I think there’s a bigger emphasis, in my opinion, on the ways of working, the respectful ways of working, small details. I don’t know, like, um, when is, when should I expect my teammate to pick up a pull request during the sprint? Um, how do I make it easier for them? Should opening up a request with 50 change files, embedding refactoring with a bot fix, does that make it, you know, small things. But I think this is where, um, you can reduce a lot of friction and may make, uh, bring more harmony.
Kovid Batra: Okay. Makes sense. Um, you guys, I think we are already, uh, done with our time today, but, uh, I feel bad for other people who have put in questions, so I just wanna take one more, uh, this sounds interesting. Uh, are you guys okay to extend it for like 2–3 more minutes?
Rens Methratta: Sure.
Kovid Batra: Perfect. Uh, this question comes from Nisha. Uh, how to align teams to respond to developer surveys and use engineering metrics to improve overall experience and performance. So I think both of you have some experience here. Uh, clint is, uh, already, uh, a promoter of having communication, having those one-on-ones with teams. So, and for, uh, Rens, I know he’s using Typo, so he’s already into that setup where he is using engineering metrics and developer surveys with the, with the developers. So both of your opinion would be great here. Uh, Rens, would you like to go first?
Rens Methratta: Um, yeah. To Nisha’s question, um, I’ve never had good luck with like, surveys and, uh, with like developers, quite honestly. They’re just not, um, you know, I think a lot of it is, uh, time spent and, and, and, you know, I, I try to try to do one-on-ones with people, um, and just, you know, get an understanding of how people are doing. Um, I, I, you know, um, we’ve done, tried to do surveys and it’s, you know, people, it becomes, people aren’t, you know, I don’t think the, the responses get, um, less and less valid in some ways if, if it becomes robotic, uh, in a lot of ways. So I, I really think, I think aligning to how people are doing is, from my perspective, is really more, more hands-on, more one-on-one discussions and conversations.
Kovid Batra: Makes sense. How, how did that work for you, Clint? Uh..
Clint Calleja: I, uh, what, what, what Rens just, uh, just, just explained, uh, resonates with a lot of my experiences in the past. It was, uh, a different and eye-opening experience at Hotjar, where I’ve seen the use of, the weekly use of such a survey being well, um, being, um, well adopted. And when I joined Hotjar, I joined as an individual contributor, as a front end engineer. So the first time I had to fill one of these, first I was like, okay, I have to do this every week. But the thing that made me change my mind was the actions I was seeing coming out, the benefits for me that I was seeing coming out from my lead. This wasn’t just a form, this was becoming the talking points of the one hour session I had with him every week. Actions get taken out, which were dedicated to me. So it was a fun fact. This was the first remote experience for me, but the one-on-ones felt like the most tailored I’ve ever had. So think..
Kovid Batra: That’s interesting. Yeah.
Clint Calleja: If I can sum up on the developer surveys, um, I understand that the less people can under an attribute, their input to actual outcomes, to actual change then, you know, why spend the effort? So on, on my end, what I try to do as much as possible is not just collect the data. Here’s a summary of the points. Here are some actions which are now part of this strategy. Remember the connection of the strategy. And here’s why when we are trying to attack what. So again, not a silver, uh, silver bullet.
Kovid Batra: Yeah. Yeah.
Clint Calleja: And then the second part on engineering metrics, I think here, uh, I really rely on engineering leaders to be the glue of bringing those data points into the retrospectives. So the engineering managers are in the best position to connect those data points with the ways of working and the patterns seen throughout the sprints. And in an end of sprint review, you know, express, okay, here are the patterns that I see. Let’s talk about this. Let’s celebrate this because it’s a, you know, huge milestone.
Kovid Batra: Makes sense. Great. Uh, Rens, you wanna add something?
Rens Methratta: No, I, I, I would agree. I think that’s a good, I that’s a good call out. Uh, yeah. Getting, maybe having more action oriented from the surveys would provide different results. Um, and we, we, we tried something where we try to do our, do our one-on-ones as a, as, as a daily survey. Yeah. I didn’t think it was successful because it, it didn’t, I think people weren’t, um, weren’t seeing that individual response back from them. Right. It was just more like data collection for data aggregation purposes. Yeah. Wasn’t, which wasn’t, people didn’t seem to value it.
Kovid Batra: Perfect. Perfect. Thank you so much guys. Uh, this was an amazing session. Uh, thank you for your time. Thank you for sharing all your thoughts. It’s always a pleasure to talk to you, to talk to folks like you who are open, take out time from their busy schedules and give it for the community. Thanks once again.
Clint Calleja: Thanks for the invite. Yeah. And nice to meet you guys.
Rens Methratta: Same here, Clint.
Kovid Batra: All right, guys. That’s our time. Signing off for today. Bye-bye. Okay.
How do you transition from being a strong Engineering Manager to an effective VP of Engineering? What challenges do leaders face as they scale their impact from team execution to organizational strategy?
In this episode of the groCTO Podcast, host Kovid Batra speaks with C S Sriram, VP of Engineering at Betterworks, about his career journey from an engineering manager to a VP role. He shares the hard-earned lessons, leadership principles, and mindset shifts that helped him navigate this transition.
✅ From IC to Leadership: How Sriram overcame early challenges as a new engineering manager and grew into an executive role.
✅ Building a High-Performing Engineering Culture: The principles and frameworks he uses to drive accountability, innovation, and efficiency.
✅ Balancing Business Goals & Technical Excellence: Strategies to prioritize impact, make trade-offs, and maintain quality at scale.
✅ The Role of Mentorship & Coaching: How investing in people accelerates engineering success.
✅ Scaling Leadership with Dashboards & Skip-Level 1:1s: How structured communication helps VPs and Directors manage growing teams effectively.
✅ Closing with Inspiration: Sriram shares a poem he wrote, reflecting on the inner strength and vision required to succeed in leadership.
Kovid Batra: Hi everyone, this is Kovid, back with another episode of groCTO by Typo. Today with us, we have a very special guest. He's VP of Engineering at Betterworks, comes with 20+ years of engineering and leadership experience. Welcome to the show, Sriram.
C S Sriram: Thanks. Thanks so much for having me over, Kovid, and thanks for the opportunity. I really appreciate it.
Kovid Batra: No, it's our pleasure. So, Sriram, uh, today, I think we have a lot to talk about, about your engineering and leadership experience, your journey from an engineering manager to engineering leader. But before we get started on that, there is a small ritual that we follow on this podcast. To know you a little more, we would like to ask you one question. Tell us something about yourself from your childhood, from your teenage that defines you, who you are today. So you have to share something from the past, so that we get to know the real Sriram.
C S Sriram: Sure. Yes. Uh, uh, I think the one thing that I can recall is something that happened when I was in my seventh standard. My then school principal, her name is Mrs. Anjana Rajsekar. I'm still in touch with her. She's a big inspiration for me. She founded and she was running the school that I was studying in. She nudged me towards two things which I think have defined my life. The first thing that she nudged me towards was computers. Until then I hadn't really touched a real computer. That school was the first place where I wrote my very first logo and basic programs. Uh, so that was the first thing. And the second thing that she nudged me towards was just writing in general. And that gave me an interest towards, uh, languages, towards, uh, writing, reading, uh, poetry, short stories, novels, all of that. I think that she kind of created those two very crucial parts of my identity and that's what I would like to share.
Kovid Batra: That's really inspiring actually. Teachers are always great in that sense. Uh, and I think you had one, so I really appreciate that. Thanks for sharing. And, Sriram, is there anything from your writing piece that you would like to share with us? Anything that you find really interesting or that you wrote sometime in the past, which you think would be good to share here?
C S Sriram: Oh, I wasn't prepared for that. Uh..
Kovid Batra: No, that's fine.
C S Sriram: Maybe, maybe towards the end. I'll try and see if I can find something towards the end.
Kovid Batra: Sure, no problem. All right. So getting started with the main section, just to iterate this again, we are going to talk about your engineering leadership journey, specifically from an Engineering Manager to a VP of Engineering at Betterworks. I think the landscape changes, the perspective changes, and there are a lot of aspiring engineering managers engineering leaders who are actually looking towards that career path. So I think this podcast would be really helpful for them to learn and to understand what exactly needs to be there in a person to go through that journey and what challenges, what opportunities come on the way, how to tackle them. So, to start with, I think tell us about your first engineering management experience when you moved in, uh, from, uh, from, uh, let's say a tech lead or an individual contributor role to an EM role and how things changed at that point. How was that experience for you? Was that overwhelming or that came in very easily to you and you were there when you, when you actually arrived in that particular role or responsibility?
C S Sriram: I was a programmer once. So I'll start from index 0 instead of index 1. So I had a, uh, index 0 programmer, uh, engineering management experience where I was given the designation of Engineering Manager for about a month. And I ran back to my CEO and said that I'm not doing management. Uh, take the designation away from me, take the people away from me. I'm not doing it anymore. Uh, that was the index 0 and index 1 was when I started my own software consultancy, roughly about 10 years ago.
Kovid Batra: Okay.
C S Sriram: And then I didn't realize I would have to do management. I just wanted that thrill of running my own business. I guess to paraphrase Shakespeare, you know, "Some people are born managers. Some people are made managers. Some people have management thrust on them." So it was thrust on me. It was my necessity that I got into management and for the first five years, I really messed it up. Because I was running a business, I was also trying to get some coding done for the business. I was also trying to win sales. I was trying to manage the people, recruit them and all of it. I didn't do a great job of it at all. And then when I joined Betterworks was where I think I really did something meaningful with, uh, engineering management. I took the time to study some first principles, understood where I went wrong and corrected. So yeah, that's how I got into management. And it was, uh, it wasn't scary the first time because I didn't know I was doing it. Uh, so I didn't know I was doing a lot of things wrong, so there was no fear there. Uh, but the second time around, when I started in Betterworks, I was very scared that, uh, of a lot of things. There were a lot of insecurities. The fact that I was letting go of control and most of the time intentionally, that was a very scary thing. But yeah, it's, it's comfortable at the moment.
Kovid Batra: Perfect. Perfect. But I'm sure that experience of running a business would have brought a lot of aspects which you could have not learned if you were in a trivial journey of a job where you were a software engineer and then moved into, let's say a tech lead or a management role. I'm sure that piece of your entrepreneurship would have taught you a lot more about bringing more value or bringing more business aspect to the engineering. Was it so?
C S Sriram: A 100% yes. I think the main thing that I learned through that was that software doesn't exist in isolation. A team doesn't exist in isolation. You building the most beautiful user experience or design, you building the most beautiful software, uh, most beautiful piece of code that you've ever written, uh, means nothing if it doesn't generate some sort of business value. I think that was the biggest lesson that I took away from that, because we did a lot of work that I would call as very good engineering work, but extremely poor from the business side. I understood that importance that, you know, it is, it always has to be connected to some business outcome.
Kovid Batra: Great. I think there must be some good examples, some real life examples that you would like to share from your engineering management stint that might revolve around having a good culture, that might revolve around building more or better processes in the team. So could you share something from your start of the journey or maybe something that you're doing today?
C S Sriram: Definitely. Yes, I can. I think I'll start with, uh, the Betterworks/Hyphen journey. So when I joined, it was called Hyphen. We were an employee engagement, uh, SaaS platform. We had a team of really talented engineers and a very capable, uh, Director of Product, uh, and an inspirational CEO. All the ingredients were there to deliver success. But when I joined the team, they hadn't completed even a single story. Forget about a feature, a complete, uh, you know, product; they hadn't completed, uh, a single story in over two quarters. What I had to do in that case was just prioritize shipping over everything else. Like there were a lot of distractions, right? The team was talking about a lot of things. There was recruitment. There was the team culture, process, et cetera, et cetera. I think the first thing that I did there was after a month of observation, I decided that, okay, sprint one, somebody has to ship some things. And just setting that one finish line that people have to cross, that built up the momentum that was required, uh, and it kept pushing things forward. And I got, uh, hands-on in a way that I wouldn't have got hands-on before. Like usually I would've jumped into the code and started writing code myself. That was my usual approach until then. This time I got hands-on on the product side. Uh, I worked with the, uh, director of the product, uh, to prioritize the stories, to refine acceptance criteria, uh, give a sprint goal and then tell everybody that, okay, this is the goal. This is what is included. This is what is not included. Get it done. And it happened. Uh, so that's how that got started.
Kovid Batra: Perfect. So I think when you're sharing this, this is from your initial phase when you actually start working as an Engineering Manager and working directly with the product, uh, managing the team, uh, getting into that real engineering management role, bridging that gap. What exactly led you or made you understand that priority? Like, you went in, saw a lot of things distracting you, people and culture changes. So, initially when you moved into such a space, which is completely new, right? What exactly made you realize, okay, one thing is of course, they didn't ship anything for, let's say a good amount of time, so you had to prioritize that and you went in with that goal. But if you just focus on one thing, do not take people along, there is a lot of resistance that you get. So when you were deciding to do this, uh, you cannot be ruthless when you are joining in new. So was there any friction? How did you deal with it? How did you bring everyone on the same page? Is there anything specific you would like to share from that part?
C S Sriram: Yeah, yeah. See, the diagnosis was actually pretty straightforward because I had a very supportive CEO at that time. Orno, that was his name. So he was very supportive. When I told him that, okay, I'm going to take a month to just observe. Don't expect any changes from me. Uh, in the first month, uh, I don't want to just start applying changes. He was very supportive of that, and I was given a month to just observe and make my own notes. Once I diagnosed the problem, the application of solution took a bit of time. The first thing was to build culture. Uh, now a lot of people talk a lot of things about, uh, culture. Uh, to me, or what culture means is what are the negotiable and non-negotiable policies within your team? Uh, like what is acceptable? What is not acceptable? Uh, and even in acceptable, what are the gray areas? That there may be some areas where you have a bit of negotiation that is allowed. Uh, so that was the first thing that I wanted to sort out. The way I did that first was, like I said, I spent a month studying the team and then I proposed a set of working rules. I talked about working hours. Uh, that was the time when we were all in office. So presence in, uh, office, the work, how do we do work handoff? How do we make decisions? All of those things. Uh, and these, uh, I presented some of them saying that, see, I am tasked with getting some things done. So these are non-negotiable for me. Uh, like you are doing this, uh, you don't have the space to negotiate and say that you are not going to be in office for two weeks, for example. Or you're not going to say that, uh, I won't write automated tests. Those are my, uh, you know, addition areas. I'm owning them. But you can say that, uh, I will be 10 to 15 minutes late because of Bangalore traffic. So we had that kind of agreement that was made and we had an open discussion about it. That was the first presentation that I made to the team saying that these are our working rules and this is how we'll proceed. And I need explicit agreement from all of you. If anybody is not going to agree, you let me know, we'll negotiate and we'll see where we can get to. Now, once that happened, uh, there was a question of enforcing the policy. And I think this is where I failed in my previous attempt at management. I had a set of policies, but I wasn't very consistent in enforcing them. And this time I had a system where I said that, okay, if someone strayed from a policy, someone said that they'll do something, but they haven't done it, my usual reaction would have been either if I thought it wasn't so important, ignore it. Or if it was important, you know, just go ballistic, go lose your temper and ask questions and, uh, you know, do that boss kind of stuff. This time I took a different approach, which was curiosity over trying to being, uh, you know, trying to be right. So I spent a bit of time to understand why did, you know, this miss happen? Why did this person stray from the agreed policy? Was it because the policy itself wasn't well-defined? Uh, or did they agree to the policy without fully understanding it? Or was it just a, you know, human error that can be corrected? Or is it an attitude issue that I can't tolerate? Now in most cases, what happened is once I started putting these curious questions and I started sharing them, people started aligning themselves automatically because nobody wants to be in that uncomfortable position of having to explain themselves. It's just human nature to, you know, avoid that and correct themselves. So that itself gave me the results most of the time. In a few cases, uh, the policy wasn't well-defined or it wasn't well-understood, in which case I had to refine it and make sure it is explained very clearly. And the last thing was, uh, in a few cases where despite repeated feedback, they couldn't really correct themselves. I had to make the decision saying that, okay, this person is not suited for what I want and I'll have to let them go. And we've made some decisions like that also.
Kovid Batra: I think setting those ground rules becomes very important because when you go out and just explicitly do something, assuming that, okay, this is, uh, this is something that should be followed and people are not aligned on that, that creates more friction than, uh, if they're beforehand aware of what needs to be done, how need, how it needs to be done. So I think stepping into that role and taking up that responsibility, it's a good start to first diagnose, understand what's there, and then setting some ground rules with negotiables and non-negotiables. I think it makes a lot of sense. And when you're sharing those specific details, it all the way more aligns with my thought of how one should go out and take up this responsibility. But Sriram, uh, when you jump into that role there are a lot of things that come into your mind that you need to do as an Engineering Manager. What are those top 3-4 things that you think you need to consistently deliver on? I mean, this could be something very simple, related to how fast your teams are shipping. It could be something related to what's the quality of the work that is coming out. So, anything. But, in your scenario, what were your business priorities? According to that, you as an engineering manager, what were your KPIs or what were those things that you mostly aligned with and tried to deliver consistently?
C S Sriram: Yeah, so two things mattered most. And I think it still matters even today for me. The first is what business value is a team delivering. A lot of people get confused where they say they have high-performing teams when actually the teams are just shipping features very regularly, uh, instead of creating business value, uh, like, that's something that I ask my managers a lot as well. Like, what is the business problem that your team is solving? Not just what is the feature that they are shipping next? So that is the first thing. So, um, having a very clear sprint goal, if you're doing a sprint goal, a quarterly goal that says that this is the business outcome that we are achieving. Maybe you're trying to increase the signups. Maybe you're trying to increase the revenue. You're trying to increase the retention. You're trying to solve a specific problem for a customer. A customer is struggling with a particular business outcome at their end, and that is what your software is solving. And once you set, set that as the priority, then adjusting your scope, adjusting what you want to deliver to meet that outcome becomes very easier, very easy. Like I've seen cases where we thought we will have to deliver like 10 or 15 use cases for a feature, but narrowing it down to five, uh, gave us more results because we've been solving what was most valuable for the customer rather than shipping everything that we thought we have to ship. So that is one of the biggest metrics that I try to use. Like, what final business outcome can I connect this team's output to?
Kovid Batra: Makes sense. Almost every day we deal with this situation when, so when I say 'we,' people who are into those position where they have to take some decisions that would impact the business directly. Of course, a developer also writes code and it impacts the business. But I hope you understand where I'm coming from. Like you are in that position where you're taking decisions and you are managing the team as well. So there is a lot of hustle bustle going on on a day-to-day basis. How did you make space for doing this? Uh, that prioritizing even more, highlighting those five things out of those 15 that needs to be done. What kind of drive you need or what kind of process setting you need for yourself to come to that point? Because I strongly believe I have talked to so many engineering leaders and engineering managers, this one quality has always stood out in all high-performing, uh, engineering leaders and engineering managers. They value the value delivery. Like, anything else comes second. They are so focused on delivering value, which makes sense, but how do you make that space? How do you stay focused on that part?
C S Sriram: Uh, see, I think anybody who makes a transition to management from engineering has a big advantage over there. If you are a good engineer you would have learned to define the problem well before you solve it. Uh, you would have learned to design systems. You would have learned to visualize you know, the problem and the solution before you even implement it. Like, a good engineer is going to draw a high-level and a low-level system diagram before they write the first line of code. They will write tests before they write the first line of code. It is just about transposing that into management. This means that before your team starts working on anything crucial, you spend that focus time, and that's where I think a lot of engineering managers get confused as well. I see a lot of engineering managers talking about, Oh, I'm always in meetings. Uh, I don't know what to do. I'm always running around. Uh, having that focus time for yourself, where you are in deep work, trying to define a problem and to define its solution, that makes a huge difference. And when people try to define a problem, I think it always helps to use some sort of standard frameworks. Like right now, uh, as an engineering leader, most of my problem definitions are strategy definitions. Uh, like what policies you know, should the team pursue for the next one to two quarters? What policies drive things like recruitment, uh, promotion, compensation, management, et cetera, et cetera? Now I try to follow some sort of framework. Like I try to follow a policy diagnosis, risk and actions framework. That is how I define my you know, uh, policies. And for each of those problems that you're trying to define, there are usually standard frameworks that are available so that you don't have to break your head trying to come up with some way of defining them. I think leaning on that sort of structure helps as well.
Kovid Batra: Got it.
C S Sriram: And over time, that structure itself becomes reusable. You will tweak it. You will see that some parts of the structure are useful, some parts are not, and it gets better over time.
Kovid Batra: Makes sense. For an engineering manager, I think these are some really good lessons and coming with specific examples that you have taken, I think it becomes even more valuable. One thing that I want to always understand, how much you prioritize quality over fast shipping or fast shipping over quality?
C S Sriram: Yeah. Uh, okay. So I had, uh, an ex, uh, manager who is my current mentor as well, and he keeps saying that he says that 'slow is smooth and smooth is fast.'
Kovid Batra: Yeah, yeah.
C S Sriram: Okay, so I don't aim for just shipping things fast, but I aim to create systems that enable both speed and quality. I think a lot of engineering managers, they always try to improve immediate speed and that's almost an impossibility. Like you can't fix a pipeline while things are running through it already, uh, you need to step away from the pipeline and you're going to get speed results, you know, speed outcomes. Over time, quality outcomes over time. I think that is the first step towards speed and quality. You need to accept that any improvement will take a little bit of time. Now, once you accept that, then defining these things also, again, makes a huge difference. If it's speed, what is speed for you? Is it just shipping features out or is it creating value faster? The best way of increasing speed I've seen is just measuring team cycle time. Like you don't even have to put in any solutions in place, just measuring and reporting the cycle time to the team automatically starts moving things forward because nobody likes to see that it takes two weeks to move a ticket to 'done' in there. And people start getting curious and they start finding out, okay, I'm not moving that fast. I'm actually working a lot more than at that speed, but I've moved only one ticket in two weeks. That's not acceptable. Then you see things changing over there. Same thing with quality also. I like to define what quality clearly means. Like what is a P0, P1 test case that you cannot afford to miss? What are acceptable non-functional requirements? Like, well, you know, uh, not every team has to build the most performant solution. There may be a team that might say that, okay, a one second latency is acceptable for us. A hundred requests per second throughput is more than sufficient for us. So building with that in mind also makes a huge difference. And once you do that, for quality, I would always say the best thing to do is to shift quality left. The earlier you enforce quality in your process, the better it is. And there are standard techniques to do that. You can use mind maps, you can use the three Amigo calls, automated tests, et cetera, et cetera. One example that I can think of is that when I was working with Hyphen, uh, there were a set of data reporting screens, a set of reports which all had very similar kind of charts, grouping and filters. So I spent time with QA to develop some mind maps where we listed all the use cases for all the reports, that were common to all the reports. And we kind of had these mind maps put up during these print review calls during the QA review calls and all of it. If a developer is going to start development, they have it on their screen before they start developing. The developer develops to match those quality requirements rather than trying to catch up with the quality later on. Uh, and this is another example that I like, uh, analogy that I like using as well. Developers, when they write code, they should write as if they are writing an exam where the answers are already available to you and you should really try to score the highest marks possible. Uh, no need to keep anything secret or anything. I think that's an approach that testers should also adopt. You write the exam with every answer available and you score the maximum marks.
Kovid Batra: Makes sense. So I think in your EM journey, if you have to sum it up for us, when was the point when you felt that, okay, uh, you're doing good and these are the top 2-3 things which you did as an EM that really made you that visible, made you that accomplished in a team that you were ready for the next role?
C S Sriram: Got it. I think it took me about a year at Hyphen. So that would be about six years after I started engineering management. So 1 in 5 years running my own consultancy and then 1 year at Hyphen. the outcome that made me feel that okay, I've done something with engineering management was that we ship the entire product. It was a migration from JavaScript to TypeScript, from an old UI to a new UI, a complete migration of a product that was already in use. We hit $2 million ARR and we got acquired by Betterworks. So those were good, uh, you know, outcomes that I could actually claim as victory for myself and for the team. And that was, uh, what I thought was success at that time. But what really feels like success right now is that engineers from that time call me and tell me that you know, working with me during that time was really good and they are yet to find that kind of culture, that kind of clarity. So that is, you know, that turned out to be a good success.
Kovid Batra: Makes sense. Okay, so now moving from that point of engineering management to a leader, how has your perspective changed? I think the company altogether changed because now you are part of Betterworks, which is a bigger organization. You're working with global teams who are situated across different countries. How your perspective, how your approach to the overall delivery, value delivery has changed, I would like to hear that.
C S Sriram: Yeah. So, Betterworks, I would split it into two halves, two and a half years, two and a half years, uh, you know, at Betterworks, uh, leaving that first year at Hyphen. The first two and a half years I was working towards more of a directorship kind of role where I wanted to own complete execution. That was a time I learned how to manage managers, how to get a few other things done as well, like, uh, tie that, uh, you know, the engineering teams outcome, uh, output to the business outcome. The first principle that I learned through that, uh, and the second two and a half years was really about strategy, about executive management. Now, the first principle that I learned that was your first team changes once you start getting on this journey. Until you're an engineering manager, the team that you manage is your team. You belong to that team. That's kind of the outcome that you always look at. Once you start this journey towards engineering leader, that is not your first team anymore. Your first team is the team that you work with, which is your Co-Directors, Co-VPs, your, you know, immediate boss. That leadership team is the core team. You're creating value for that team. And the team that you manage is a "tool" that you use to get those results. Uh, and I would, you know, put a quotation mark around the "tool" because you still need to be respectful and empathetic towards people. It's not just using them, but that's, that's kind of the mindset that you need to adopt. The side effects of this mindset is that you have to learn to be alone, right? At least when I was an Engineering Manager and all of it, uh, there were these moments when you could gossip and complain about what's happening and all of it, the higher up you go, the lesser, uh, you know, you have space for all of that. Um, uh, you, like, who can you go and complain when you have all the power to, you know, do anything. You have the power to do everything that you want. So you have to learn to be alone and to operate by yourself. So that is the second side effect of that. The next principle that I learned was to give up what you take or built. Luckily, it came on, came easily to me at that point. I'm really thankful for that. Like I had built this whole product and, you know, we completed the migration and we got acquired by Betterworks and all of it was something that I was really proud off. But the moment the first opportunity came, I delegated it to someone else. Now, if I had held on to that product because it was my baby, I wouldn't have had the opportunity to scale Betterworks India. We went from I think around five or six engineers, today we are almost 45+, uh, engineers in India. That sort of a 5x scale, 7x scale would have been very difficult to achieve if I had held on to any of the babies that I was building at that time. So that sort of giving up things, uh, is something that's very important. And the next thing that I learned was to coach engineering managers. You basically have to repeat what you did with your developers. Like with, once you manage developers, you don't develop. You delegate. You try to ask them questions. You nudge them and you guide them. You need to repeat the same process with managers as well. That's another thing that I had to learn. And the last thing that I had to learn was setting up teams for success. This was a big challenge because most of my managers were first-time managers at that time. So the potential for failure was huge. So I had to take my time to make sure I set boundaries within which they can make mistakes, fail, and learn. And that was a balance because I couldn't set boundaries that were so safe that they'll never make a mistake.
Kovid Batra: Yeah, that makes sense.
C S Sriram: And at the same time, I, yeah, yeah.. Because it has to be that space. I think you know that, uh. And at the same time, the boundaries can't be so open that they can, they make mistakes that can turn into disasters. And luckily I had good leaders at Betterworks, uh, who guided me through that. So that worked very well. And I also had to spend a lot of time sharing these success stories and learnings with peers and with leadership. Uh, that was something that I didn't invest a lot of time in as a manager. That sort of story building, narrative building both within the team and outside the team, that was another skill that I had to learn.
Kovid Batra: Perfect. So when you talk about the story building and bringing up those stories to your team, which is the leadership, what exactly would you tell them, can you give some example? Like in, for someone who's listening to you right now, what kind of situations, and how those situations should be portrayed to the leadership team would bring a better visibility of your work as an engineering director to the overall leadership?
C S Sriram: Sure. Yes. I think a classic example would be compensation. So I can go back to that just around the COVID time where suddenly investment was booming. The job market was booming. Every candidate that we were trying to hire had three to four offers. We were not assured of the candidate joining us even after they came on board and people were coaching our engineers left, right, and center as well. So that was a crazy time. Betterworks is a very prudent business. That's something that I'm always thankful for. We don't go and spend money like water just because we've got investment. And this means that now as an Engineering Manager, if I'm going to go and talk about compensation, about business planning and all of it with my leadership team, most of the time, I'm just going to say that, hey, this person is demanding so much. That person is demanding so much. I don't know what to do. That is an Engineering Manager approach, and it is justified because an Engineering Manager, depending on what sort of company and what sort of scale you are in has limited scope on what they can actually do in these cases. But the story that you take as an engineering director is you spend time collecting data from the market to see what is the market compensation rate. You see how many exits have happened in your team. How many of those exits are because of compensation, what percentages have those people been offered outside in the market. You collect all that data. You can't even stop at saying that, okay, I'll put all this data in front of management and I'll tell them that see, we are losing people because we are not able to match requirements. We need to change our, uh, you know, numbers. Even that is not sufficient because that is still a director-level, uh, you know, solution that you can offer. If you want to offer a truly executive-level, you are going to look at costs in the business. You're going to look at optimizations that you can do. You're going to come up with a system saying that this is how compensation can be managed. Again, most of the stories that I tell to my executive team come to the point where it's like, there is a problem there is potential solutions, and usually I even recommend one solution out of the solutions that I'm already suggesting. Uh, and this really helps the leadership team as well, because when I think of my boss or my CEO, they are possibly dealing with 20 things that are more complex than I've ever seen in my life.
Kovid Batra: Right.
C S Sriram: So how can I ensure that A, I get the decision that I think is right. And at the same time, I give them enough information so that they can correct me if my decision is wrong. Uh, both are crucial. You know, one of the scariest things that can happen to me is that I get a decision that I want and the decision turns out to be wrong. So giving myself..
Kovid Batra: That's a balanced approach where you are giving the person an option, an opportunity to at least make your decision even better if it is possible and if you're missing out on something. So that totally makes sense. And putting out things to the leadership in such way and how you're solving them would be really good. But one thing that I could understand from your EM to an EL transition you start becoming more cost and budget kind of things being, start coming in more as compared to an EM position. Is it right?
C S Sriram: 100% yes. That's what I've seen with all the great engineering leaders that I've worked with as well. Yes, they love engineering. They get into, uh, engineering, architecture and development at whatever, all levels of interest and time that they have. But there is always a question of how much value am I getting for the money that I'm spending? And I think that is a question that any manager who wants to become a leader should learn to ask like, uh, I think about two and a half years ago when I was asking my then manager, how do I get into leadership? That was the first thing that he said, "Follow the money. Try to understand how the business works. Try to understand where sales comes from. Try to understand where outflow goes." That made a huge difference.
Kovid Batra: Totally. Makes sense. I think this is something that you realize more when you get into this position. But going back to an EM role also, if you start seeing that picture and you emphasize more on that part, automatically your visibility, the kind of work that you're doing becomes even better. Like you're able to deliver what business is asking. So, totally agree. But one thing always surprises me and I ask this multiple times because everyone has a different approach to this problem, which is now you have a layer of managers who are actually dealing with developers, right? And there are situations you would want to really understand what's exactly going on, how things are quality-wise, speed-wise, and you really don't have that much time that you go out and talk to 45 engineering leaders , engineering managers, engineers, to understand what's exactly going on with them. So, there must be some approach that you are following to have that visibility because you can't just go blind and just say, "Okay, whatever engineering managers are doing, how I'm coaching them would work out wonders." You have to like trust them, but then you have to have a check. You have to understand what exactly is going on. So how do you manage that piece as a director here at Betterworks?
C S Sriram: Yeah, no, that was a very interesting coaching experience for me, where I worked with each of my managers for almost over six months to help them build that discipline. Like any good software engineer will tell you, pulling is never a good idea. If you think of your manager as a software service, you don't want to ask them every half an hour or one hour 'what's the update?' Uh, I like push-based updates. So I help them set up dashboards. So you know, dashboards that talk to them about their team's delivery, their team's quality, uh, their team's motivation and general status and all of it. Uh, and I work with them to design it for their purpose. Uh, I think that was the first thing that I was very clear about. This is not a dashboard that I'm designing so that they can present a story to me, but it's a dashboard that they are using to solve their problems and I'm just peeking in to see what's happening. So that made it very usable. I use those dashboards to inform myself. I ask the questions that I would expect a manager to ask from them. And over time, you know, they got into the habit of asking it themselves because in every 1-on-1 we'd spend 10-15 minutes discussing those numbers. By the time we did it for three to six months, it had become internalized. They knew to look for, you know, signs, they knew to look for challenges. So that became quite natural from there on. And I again want to emphasize on that one part that these were dashboards that were designed to solve their problems. If there was a dashboard or information that I had to design to relay some information or story to a leadership team or to some other team or something like that, that would be something very different. But this is primarily a dashboard that a team uses to run itself. And I was just peeking into that. I was just looking at it to gather some information for myself. So that made a big difference. The second thing that I also did was skip-level 1-on-1s. It took me, I think, almost six months to learn how to do skip-level 1-on-1s, uh, because the two challenges that I faced with skip-level 1-on-1s was it turned out to be another project status update session initially. I was getting the same information from 2-3 places, which was inefficient. It was also a waste of time for the engineers to come and report what they've already done. And the second thing also was, there were a lot of complaints coming in my skip-level 1-on-1s initially as well. And especially more so because many of the engineers that I was doing skip-level 1-on-1s with were engineers who I managed earlier. So I had to slowly cut that relationship and just connect them to their new managers. And I started turning the skip-level 1-on-1s into sessions where I can coach and I can give people some guidance. And I can also use it to get the pulse of the team. Like, is the team generally positive or is the team generally frustrated? And who are the second-level leaders that I need to be aware of? Whose stories I have to carry on? Who I think can become the core of the business after my first-level leaders? So I changed the purpose of the skip-level 1-on-1s and over time that also developed into a good thing.
Kovid Batra: Great. Great. there is a lot that we can go in and talk about this, but we are running out of time. So I will put a pause to this session here, but before we end this session for us, I would love for you to share one of those best learnings that you think as an engineering leader made you an accomplished one, and you think that can drive real growth for someone who is in that position and looking for the next job.
C S Sriram: Got it. Yeah. The one thing that, uh, was a breakthrough learning for me was mentorship and coaching. My then boss, uh, who moved on to another company, I spoke with him and I turned him into a mentor. His name is Chris Lanier. Uh, he's an exceptional executive. I connect with him very regularly to discuss a lot of challenges that I face. It helps me in two ways. The first thing it helps me is I get an outsider's perspective to solve certain problems that, uh, I can't even take to my leaders because those are problems that I am expecting no answers for. So that is the first thing that I get. And the second thing is the more you grow in this career, the bigger the imposter syndrome gets. So that reassurance that someone with the kind of experience and the success that he has, still goes through all of those things; that's quite reassuring. You know, you steady yourself and then you move forward. The next thing that I would also recommend for anybody who is looking at going into this role is to get a coach. A coach is different from a mentor. A coach is going to diagnose challenges that you have and work on specific areas. Like I had two specific challenges, uh, about two years ago. Betterworks was really generous enough to give me a coach at that time. Challenge number one was that my peer-to-peer relationships were terrible. Like, I didn't have a relationship at all. It's not even that, you know, they were poor relationships. There's no relationships at all. Uh, an introvert like me, I didn't see the value of doing it as well. The second thing was public speaking skills. Almost 40% of my speaking was filler words. So I worked on both of those with the help of a coach and got those two addressed and they made a huge difference. So I would highly, and at this level, you can't afford unknown unknowns, like you can afford it at an engineer level. You can afford it at a manager level. If you don't know what you're missing, that can turn into a disaster for both the business and for you at the executive level. So a mentor and a coach are two things that I would highly recommend.
Kovid Batra: Makes sense. And I think I can't agree more on that front because we as humans have this tendency to be in our zones and think that, okay, whatever we are doing is fine and we are doing the right things. But when a third person perspective comes in, it humbles you down, gives you more perspective to look at things and improve way faster than you could have done from your own journey on or your own mistakes that you make. So I totally agree on that. And with that, I think, thanks a lot, Sriram. This was a really good experience.
C S Sriram: Yeah, sorry to, sorry to interrupt you. If you've got a minute, I did pick something to read. You asked at the beginning, something from my writing, do we have a minute for that?
Kovid Batra: Yes, for sure. Please go ahead.
C S Sriram: Cool. Perfect. Okay. This is something that I wrote in 2020. Uh, it's a poem called "No Magic". This is how it goes:
There is no magic in this world.
No magical letter shall arrive
to grant us freedom from the cupboard under the stairs,
and the tyrants who put us there.
No wizard shall scratch our door
with his mischievous staff
and pack us off unwilling on an adventure
that will draw forth our hidden courage.
No peddler shall sell us a flying horse
made of the darkest ebony
to exile us away to mystic lands
and there to find love and friendship.
No letters, no wizards, no winged horses.
In our lives of facts, laws, and immovable rules,
where trees don’t walk, beasts don’t talk,
and we don’t fly.
Except…
when we close our eyes and dream some dreams,
of magic missiles that bring us freedom,
of wily wizards that thrust us into danger,
of soaring speeds that lead us to destiny.
And thence we fly from life to hope and back again.
Birds that fly from the nest to sky and back again.
There is no magic in the world
but in the void of the nests of our mind.
The bird with its hollow bones,
where will it fly, if not in the unreachable sky?
Kovid Batra: Amazing! I mean, I could get like 60% of it, but I could feel what you are trying to say here. And I think it's within us that makes us go far, makes us go everywhere. It's not the magic, but we need to believe the magic that we have in us. So I think, a really inspiring one.
C S Sriram: Thanks. Thank you so much.
Kovid Batra: Great, Sriram, this session was really amazing. We would love to connect with you once again. Talk more about your current role, more into leadership. But for today, I think this is our time. Thank you so much. Thank you for joining.
C S Sriram: Absolutely. Thanks for having me, Kovid. I really enjoyed it.
In this episode of the groCTO by typo Podcast, host Kovid Batra speaks with Sheeya Gem, Director of Engineering and Product Strategy at ShareFile, about her experiences leading dev teams through mergers and acquisitions.
Sheeya discusses the importance of building collaborative relationships with stakeholders, maintaining effective communication, and fostering a shared purpose among teams. She emphasizes the significance of continuous learning, adaptability, and leveraging tools and processes to keep projects on track. The conversation also touches on managing cultural transitions, supporting teams through change, and ensuring successful integration post-acquisition. Finally, Sheeya shares valuable parting advice for engineering leaders, promoting trust, shared purpose & continuous learning.
Kovid Batra: Hi everyone. This is Kovid, back with another episode of the groCTO by typo podcast. Today with us, we have a special guest who has 20+ years of engineering and leadership experience. She’s not just a tech leader, but also an innovator, a business-minded person, which is a rare combination to find. Welcome to the show, Sheeya.
Sheeya Gem: Hi, Kovid. Thank you for inviting me. It’s a pleasure to join you today.
Kovid Batra: The pleasure is all ours. So Sheeya, guys, uh, let me introduce her a little bit more. Uh, she’s the Director of Engineering and Product Strategy at ShareFile. So ShareFile is a startup that was acquired by Progress from Citrix and, uh, the journey, uh, I was talking to Sheeya, was really interesting and that’s when we thought that we should conduct a podcast and talk about this, uh, merger and acquisition journey that she has gone through and talking about her leadership experiences. So today, uh, the, the main section would be around leading dev teams through mergers and acquisitions, and, uh, Sheeya would be taking us through that. But before we jump onto that section, uh, Sheeya, I think it’s a ritual. This is a surprise for you. Uh, so we get to know our guests a little more, uh, by knowing something which is deep down in their memory lane from their childhood or from their teenage, uh, that defines them today. So give us an introduction of yourself and some of those experiences from your childhood or teenage that define who you are today.
Sheeya Gem: Oh, you got me here. Uh, um, so my name is Sheeya Gem and, um, I am, I, I’m from Bangalore and, uh, grew up in Bangalore. This was when Bangalore was, was, was much smaller. Um, it was, uh, it was considered a retirees paradise back then. And, uh, growing up, my mom was a very strong, um, mentor and, and, and, and a figure in my life. She’d read to me when I was very young. Um, lots of stories, lots of novels, lots of books. So she was an English Lit major. And so, so she’d have all these plays. So I grew up listening to Shakespearean plays. Um, and, uh, one of the books that she’d read and it still sticks with me, and, and actually there’s, I actually have a little frame of this at this time. And it says, “She believed she could, so she did.” And it’s powerful. It’s powerful. Um, I’m sorry. I lost her a few years ago. And, uh, it’s, it’s defined me. It’s a big part of who I am, um, because at every stage in your life, and, and this has been true for me, um, at every stage I have challenged myself, and it’s, it’s my mom. It’s that voice. It says, “You can do what you need to do because you believe in it and you know it’s going to be true.”
Kovid Batra: I’m sorry for your loss, but I think she would be resting in peace and would be happy to see you where you are today and how she has inspired you to be who you are today. Uh.
Sheeya Gem: Thank you. Thank you.
Kovid Batra: All right, Sheeya. Thank you so much for sharing that and it means a lot. Uh, on that note, I think we can move on to the main section. Uh, yeah. Uh, so I think, uh, your journey at, at Progress ShareFile, uh, starts from the acquisition part, right? Uh, so tell us about how, how this acquisition happened and, uh, how things went at that time, some stories that would be, uh, lessons for the engineering leaders and engineering managers sitting out there listening to this.
Sheeya Gem: Yeah. Yeah. Um, so for most leaders who are part of an acquisition, you kind of are part of the conversations as you lead up to the, to the acquisition. And for ShareFile, this journey really started a few years ago. I’m just going to really quickly go through ShareFile’s story. ShareFile is a startup from Raleigh, North Carolina. Um, and it’s, it started up in the early 2000s and was bought by Citrix in 2012 and was part of the Citrix suite of products for, uh, for about 10 years, 10–12 years. And at that time, um, uh, a private equity group called Cloud Software Group acquired Citrix and as part of their portfolio, they have several other products as well. And that’s when ShareFile’s really acquisition journey started and as part of our strategy, ShareFile decided to go back to its roots and the roots of ShareFile was a vertical market strategy. And so for the past 2–3 years, um, and, and this was a fantastic ride because we got to innovate at a scale that we never could. CSG gave us the backing and the financing, the funding and the support and ShareFile had the right amount of talent to make things happen. As leadership, we knew that an acquisition was going to be our, our exit. So we were aware of that and we were very transparent with our, with our entire teams, everybody knew that an acquisition was on the radar. And as such, when Progress started talking to us, um, and ShareFile started sharing our financials, you know, how we do our business and all of those things, we, we knew it was, it was coming. So as such as leaders, you’re part of the journey that makes a successful exit. So the acquisition was a successful exit for us. And then it also starts the next part of your journey where you’re now with a company that has acquired you because they believe in your fundamentals, they believe in your team; and as leadership, it becomes important for us to make sure that that transition is successful and that merger goes as it needs to go.
Kovid Batra: So when you joined, uh, Progress, this was basically a new team coming into an existing company and that experience itself could be a little overwhelming. I haven’t gone through any such, uh, experience in my life, but I can just imagine and trying to relate here. That can be a little overwhelming because the culture completely changes. Um, you are in a setup where people know you, there is defined leadership which you are a part of, you’re part of the overall strategy and then defining, giving directions. But suddenly when you move here, things can change a lot culturally, as well as in terms of the goals and, uh, how things operate. So when this happened with you, was this an overwhelming experience or it came easily? And in either of the cases, how you handled it?
Sheeya Gem: Uh, was it an overwhelming experience? Um, not necessarily. It is an experience. It is different. And, and most humans coping with change and dealing with change is, is hard. And, um, and I think it’s important to recognize that different people are going to handle that change differently. And in many ways, it actually is almost the grieving of the loss of one thing before moving to the next thing, and as leaders, it’s important to make room for that, to give people a chance to, to absorb the change that’s happening, but to continue to be there to support, to provide that clarity, be transparent in what’s happening, where we’re going, and, and just knowing that, you know, some people are probably going to bounce right back. The two days they’re back, they’re okay. And some people are going, it’s going to take longer. It’s, it’s almost like those seven stages of grieving, uh, you know, and to make room for that and to know that, that kind of change from what was, people were comfortable with that, people probably excelled in that, going through the uncertainty of what is to come is a normal human reaction, and I think that’s where leaders shine, to know that this is a normal human reaction. I recognize it. I respect it. And I’m here for you when, when you’re ready to move to the next step.
Kovid Batra: Makes sense. So when you moved here, what exactly was your first initiative or what was that major initiative that you took up after moving in here that made you, uh, put down your feet and get back to work and outshine that, uh, outshine that particular initiative?
Sheeya Gem: Um, are you talking about post-acquisition, the steps that we took? Is that what you’re thinking about? Okay. So, all right. So maybe I could frame it this way. A company exists pre-acquisition. It has a set of goals. There’s a vision. There’s a strategy, right? Everybody is comfortable with it. You’re probably talking about it in your all-hands, in your small group meetings and every leadership meeting that you have in any kind of ‘ask me anything’. The leadership team is talking about what you’re saying. This is our vision. This is our goal. This is the strategy. Once the acquisition happens, you’re now looking at the goal, strategy, and vision of the new company. Now, likely they’re related because there was a reason that the acquiring company went ahead and bought this company. There’s a relationship there, but there’s also likely things that are going to be different. As an example, it’s possible, in our case, this is the situation, Progress has a heavy enterprise footprint. And so some of the strategy and goals are going to be a little different compared to, um, an SMB market where ShareFile continued to, uh, to excel. So, but are there commonalities? Yes. And, and I think this is where, again, leadership comes in where we say, “Hey, this is what we were pursuing. This continues to be our plan and our strategy. This is where ShareFile, Progress’ strategy comes in and in order to manage the transition and have success on both sides, we talk about what needs to happen next. And often what happens is in a mature acquisition, and this is often the case, there is a, there is, there’s plenty of time for companies to say, “Okay, I’m slowly going to bring in the new set of goals that we need to work towards.” Some companies don’t change at all. As an example, when IBM acquired Red Hat, for five years, Red Hat did what they always did. There was no change. Eventually, right, the goal started shifting and changing to align more with IBMs. So different companies have different trajectories. However, what’s common, what needs to happen is communication. Leaders need to be talking to their teams all the time, because without the communication, this is where that uncertainty creeps in. People don’t have the answers, so they start looking for answers and those answers may not be right. So at this time for leadership, it’s important to double down and say, “This is our strategy. This is a strategy for Progress. This is a transition plan to move towards a new strategy. Or it could be that for the next six months, guys, it is business as usual. We’re going to continue with our existing strategy. And over time, we’ll start bringing in aspects of the, of the acquiring company strategy.” So key thing here, support your teams, keep communicating.
Kovid Batra: So at that, during that phase, uh, what was your routine like? Every, uh, board meeting you had, after that, or every leadership meeting you had, you used to gather your team, communicate the things that you had with them, or you waited for a little while, uh, thought through things, how it should be put to your team? Because it’s, it’s a question of, uh, how you communicate it to your teams, because you understand them better, in what state they are, how they’re going to perceive it. So I’m just looking for some actionable here.
Sheeya Gem: Yeah.
Kovid Batra: Like how exactly you did that communication because having that communication definitely seems to be the key here. But how exactly it needs to be done? I want to know that.
Sheeya Gem: Yeah, yeah, you actually almost answered the question here. Uh, so you’re 100% right, right? You don’t necessarily come out and throw little bits of information here and there because that’s not a coherent strategy. Yes, the leadership is continuing to meet and it’s okay to tell your teams that the leadership, leadership teams are continuing to meet and are working through this. But yes, eventually, when we are in a place where we have a handle on how we’re going to do things, that’s when the communication comes up. Like I said, it’s important for teams to know, yes, we’re working with you, we’re thinking through things and then set a clear date, call the meetings, it’s usually like an all-hands kind of situation and then plenty of time for Q&A, gather your teams and present in a format that’s, that’s most comfortable for that culture. And, and sometimes it’s, it’s an ‘ask me anything’ kind of format. Sometimes it’s a chat by the fire kind of, kind of informal thing. And sometimes, and we actually did this year. We did an all-hands, had plenty of time for Q&A, and that evening we took our teams to the closest hangout place that we have. We usually gather there Thursday evenings for beer, and leadership was there and we answered questions. It was an informal setting and sometimes it’s important to, to, you know, go to a location that’s not your usual place of work. So a good restaurant, um, a place where you can maybe just, just chill a little bit, right? And, and, and have those conversations and there you’re able to meet people where they are and then connect with them on that 1-on-1 level and, and maybe answer questions a little bit more deeply.
Kovid Batra: One thing if I have to ask you, which you think you could have done better during that phase, uh, would be?
Sheeya Gem: What could I have done better? Um, it’d be terrible to say we got everything right. Uh, so here’s the thing. No matter how well you manage this, because remember I said that everybody’s going to go through those different stages of change, you will always see people where somebody is, is more agitated, feeling a little bit more anxious than other, right? And, and by, just by the reality of communications, where we say, “Okay, a month from now, we’re going to address this.” There are some people who are going to hit that stage of ‘I need to know now’ two weeks before that. And in that situation, it’s hard, but maybe what people can do is if you’re close enough to that, to be able to just reassure people a little bit more. Um, I think that’s something that, that I certainly could have done a little bit more of, but it’s also one of the situations where you’re kind of like weighing it. How much do I, should I be talking about this where not everything is clear and how much should I just hold? Um, so, so there is that balanced conversation that happens.
Kovid Batra: And in that situation, do you think is it okay to come out and say that I am in a phase where even I am processing the information? More like being vulnerable, I would say. Not exactly vulnerable, but saying that we are in a phase where we are processing things. I don’t want to say anything which, uh, maybe makes you more anxious instead of giving you more certainty at this phase. So making statements like this as a leader, is it okay?
Sheeya Gem: I think it is. I think it’s important to your point. Vulnerability is key where you trust your teams and you’re expecting them to trust you. So showing that vulnerable side, uh, builds empathy and helps people, uh, relate to you more. Um, what I would be careful though is some people could perceive that differently. Oh, leadership doesn’t have all the answers. So yeah, know your audience, know your audience.
Kovid Batra: Makes sense. Yeah, all right. I think, uh, this was really interesting. Anything, uh, Sheeya, uh, that you think had really driven you and made you who you are as an engineering leader in your whole career, not just at ShareFile, but in general I’m asking, what are those few principles or frameworks that have really worked out for you as a good leader?
Sheeya Gem: Yeah, um, I think it’s learning. For me, I, I have this desire to learn and, um, and I believe that no matter a situation, right, you can have a good situation or you could have a bad situation. No matter the situation, though, where you win is learning, learning from the situation, no matter what that situation is. So when you exit that situation, you have learned, you are a better person because you have learned from that situation. So, so that’s, that’s a big takeaway for me and, and something that, that I, maybe your audience will enjoy and that is for humans, you know, there are some things that are going to go really, really well and some things that are going to be downright awful and I think that’s life. But in each of these situations of the mindset is, “Hey, I’m put in a situation that I haven’t dealt with before. What can I take away from this?” You exit that situation as a winner, no matter what the situation was. And I’ve applied that through my life where, um, I’ve, I’ve, I’ve had the, uh, the good luck to work at some fantastic companies and, and be mentored by, by amazing people, um, from Etrade to eBay, uh, Citrix, several companies along the way. And at each of them, uh, when I changed jobs, I went into a job that was just a little different from what I did, and it kind of like opened up things for me. Um, and it helps you learn. So that would be a good takeaway where every time you go into something, try something just a little different. Uh, it changes your perspective. It, it builds empathy. When you do a little bit of marketing, you now have empathy for your marketing department a little bit more. When you do a little bit of work that, that’s not just pure engineering, it helps you see things in a different light and gives you a different perspective.
Kovid Batra: Touching on the marketing bit. I think, uh, the last time when we were talking, you mentioned that you have this urge, you have this curiosity all the time, and I think it’s driven from the same fact, learning, that you work with different teams to understand them more. So do you have any experience, like very specific experience where you had a chat with a sales guy or a marketing team person that led you to build something, like engineer something and build something for the customers?
Sheeya Gem: Yeah, yeah. Uh, that’s a good topic. Um, a part of leadership is besides guiding your teams, it’s about the collaborative relationships you build with other stakeholders. And a lot of people, when we hear the word ‘stakeholder’, we kind of like mentally take a step back. But what if we consider all of those stakeholders, people who are in that journey together with us? Because ultimately, that’s why they’re here. Um, it’s to be successful. And to define success in a way that resonates with each person is the concept of building collaborative relationships. It goes to the heart of shared purpose. Um, so as we were building some new innovative products, um, and, and I, ShareFile is a tech company and which means the product is tech. Who knows more about the product and the tech than the engineers who are building it, right? They are the builders However, all of the other stakeholders that we’re talking about are instrumental to making the product successful. That’s why they’re all here. So for me, it started becoming a case of saying that “Hey, we have uncovered this new way to do something and we believe there is an audience for this. There is a market for this.” Then the first set of people that we start talking to is being able to work with product management to say, “ What do you see? What have you seen in the field? You’re talking to customers all the time.” And it becomes, starts becoming this, this little bit of a cycle where they feed information to you and you’re feeding information back and it’s a loop. It’s, it’s becoming this loop that’s continuing to build and continuing to grow. Um, so there is a, there’s a fantastic book. Um, I think it’s called ‘Good to Great’. Um, and in that the author talks about the flywheel effect and that’s exactly what this is. So as you’re talking to product and you’re building that, that, that coherent thought of, “Okay, I have something here. I may have something really, really big.” The next step is talking to sales because sales tends to be the biggest cheerleader of the product in the market. They’re selling. This is their whole goal. They are your cheerleaders. And so then the next step of building that relationship with sales and saying, “Hey guys, what are you seeing? If I were to build something like this, what do you see, um, in the way it plays out in the market?” And you put that early version of the product in front of sales. Give them a prototype. Ask them to play with it. And most companies don’t tend to do this because sometimes there are walls, sometimes there’s a little bit of a, does sales really want to look at my prototype? They do, because that’s how they know what’s coming next. You’re opening that channel up, right? Similarly with marketing, to be able to say, I have something here. Do you think we could do some marketing spend to move this forward? And just like that you’ve built shared purpose because you’ve defined what success looks like for each group.
Kovid Batra: Right. That’s really interesting. And the, the last word ‘shared purpose’, I think that brings in more, uh, enthusiasm and excitement in individuals to actually contribute towards the same thing as you’re doing. And on that note, I, I think, uh, I would love to know something from you about how you have been bringing this shared purpose, particularly in the engineering team. So just now you mentioned that there could be, uh, walls which would prevent you from bringing out that prototype to the sales team, right? So in that exact situation, uh, what, what way do you think would work for teams, uh, and the leaders who are leading, let’s say, a group of, let’s say, 20 folks? I’m sure you’re leading a bigger team, but I’m just taking an example here that how do you take out that time, take out that bandwidth, uh, with the engineering team to work on the prototype? Because I’m sure the teams are always overloaded, right? They would always have the next feature to roll out. They would always have the next tech debt to solve, right? So how do you make sure that this feeling of shared purpose comes in and then people execute regardless of those barriers or how to overcome those barriers?
Sheeya Gem: Yes. Um, to have something like shared purpose work, you absolutely need the backing of your entire leadership org. And I’ve been very, very lucky to have that. Uh, from the Chief Product Officer to the CEO, to the Chief Technology Officer, we were aligned on this, completely and totally aligned on this. And so what this translate then, translates to then is investments, right? You talked about tech debt and how teams are always loaded, but if your entire leadership team is bought into that vision, then the way you set the investment profile itself is different, where you might say that, you know, half of the org is going to totally and completely focus on innovation. We are going to build this. Right. Then you have that, that organizational support. Now as leadership, as we are building that, when you start talking to your teams about the level of organizational support that you have, and remember, engineers want to build things that are successful with customers. Nobody wants to build something and put it on a shelf in their house. They want it on the market. That is the excitement of engineering. So to then be able to say that, “Hey! We believe in this. Our leadership believes in this. Our stakeholders are excited about this.” It’s the kind of excitement and adrenaline adrenaline pump that happens that nothing else gives that cheer. And that’s what we saw happen with our teams, that getting behind a vision, making that strategy your own, knowing that you are a key contributor to that success of the product and hence the success of the org, that is a vision that sustains and feeds itself. And, and that’s what we were able to build. Um, that’s something that I made the time for every day. You talk to your teams, you connect with your teams, you’re talking to your engineering managers, you’re talking to the principal engineers, and every time there is, there is concern, and there will be many, many concerns along the way, and I’m not going to have all the answers. That’s normal. I should not have all the answers, because if I have all the answers, then the thinking is limited to the max of my thinking, and a group’s thinking is always greater, right? The sum of that group’s thinking is always greater than any one individual’s thinking. So then it starts becoming a case of, this is the problem that we’re trying to solve. How best would we solve it? And when you put it in front of the brightest people in the room, the answers that you get to that problem, the solutions that you get, breaks through every bound that you can see.
Kovid Batra: So do you usually practice this? Like, uh, every week you have a meeting with your team and there are some folks who are actually working on the innovation piece or maybe not every week, maybe in a month? I, I am not sure about the cadets, but in general, what’s the practice like? How, how do you exactly make sure that that is happening and people are on track?
Sheeya Gem: Yeah, we actually meet every week and then any number of informal conversations throughout the day, right? You run into someone in the elevator, you have two minute conversation. You run into someone in the hallway, you have a two minute conversation. But yes, as leadership, we meet, uh, every week. And when I say leadership, and this is where my definition of leadership may be different from maybe some parts, some others. And, and, and to me, leadership is not just a title that’s given to someone. A lot of people think that one year, once you’re a manager, you’re a leader. The truth of it is, you’re going to see leaders in engineers, people who think differently, people who, um, who can drive something to success, people who can stand behind something because they know that area and know what to do next. They’re all leaders. So in my leadership meeting, I actually have a mix of engineering managers. I have principal engineers. I even have some, a couple of junior team leads because they are that good. And that group meets every week. And we talk about the biggest problems that we have and it becomes a group problem solving effort. We draw action items from that and then smaller groups form from there, solve, come back to the meeting next week and they talk about how they are, how they are going about it. So it is very much a team environment and a team success, um, metric the way we go behind things.
Kovid Batra: Makes sense. Um, one last thing that I would want to touch upon is that when you are doing all these communication, when you are making sure you’re learning, your team is having a shared purpose, everyone is driven towards the same goal, one thing that I feel is it is important to see how teams are moving, how teams are doing on different parameters, like how fast they’re moving, how good quality code is being produced there. And you mentioned, like you lead a team of almost a hundred people where there are few engineering managers and then engineers out there. As a Director of Engineering, there is no direct visibility into what exactly is happening on the ground. How do you ensure that piece, uh, in your position right now that everything which you think is important and critical, uh, is, is there, is on the tack on the track?
Sheeya Gem: Yeah, yeah, this is where tools come in. Also, very clear processes. Um, my recommendation is to keep the processes very lightweight because you don’t want people to be caught up in the administration of that process. But things like your hygiene, it’s important. You closed a story, close the story, right? Or let us know if you need help. Uh, so that becomes important. Um, there are lots of project management tools that are available on the market. Um, and again, like I said, lightweight, clear process. Uh, the ability to be able to, um, demonstrate work in progress, things like that. And that’s something else that we have. Um, we have this practice called show, tell and align and, um, we meet every week and this is all of engineering, and just like the title says, you show whatever you’ve got. And if you’re not in a position to show, you can talk about what you’ve got. And the purpose of it is to drive alignment and it’s, it’s, it’s an amazing meeting and we have a fantastic manager who runs that meeting. There’s a lot of energy there and we have no rules about what you can show or where you can show it. You know, some, some, some companies have rules like, oh, it needs to be in production for you to do. No, no, no, I want to see it if it’s on your dev laptop. I want to see it. Your team leads to want to see it. Uh, so we keep it very, very easy. And in that meeting, every senior leader who attends that meeting is encouraged to come in as an engineer and as an engineer only. Uh, they’re supposed to leave their titles at the door. It’s, it’s, it’s, it’s, it’s a challenge. It’s a challenge, but no one can come in and say, “Hey, I didn’t approve that!” Because you’re coming to this meeting as an engineer, which means if, if, and sometimes we’ve had, you know, directors and VPs who have something to share because they’re able to leave the title at the door. Uh, so it’s, it’s been a great practice for us, this ability to, to show our work in progress. Um, “Oh, look, I got this done.” Uh, “Here’s a little notification tab that I was able to build in three days. I’m going to show this to the team.” Or, or “Here’s a new framework that I’m thinking about and I found this. I’m going to show this to the team.” Uh, so this is a regular practice, um, at ShareFile and now at Progress.
Kovid Batra: Perfect. Perfect. Great, Sheeya. I think, uh, this was a really, really interesting talk, uh, learning about communication, learning about learning all the time, having a shared purpose. Show, tell, and align, that was interesting on the last piece. So I think with this, uh, we, we come to the end of this episode. It was really, really nice to have you here and we would love to have you again. Is there any parting advice for our audience that you would like to share? Uh, most of us are like engineering managers, aspiring engineering leaders or engineering leaders. If you would like to share, please go ahead.
Sheeya Gem: Um, we covered a lot of topics today, didn’t we? Um..
Kovid Batra: Yeah.
Sheeya Gem: Uh, what do I have for our, um, for our engineering managers? Trust your teams, but trust and verify. Um, and this is where, you know, some of the things we talked about, things like OKRs, things about lightweight process comes in. Trust, but verify. That’s important. Uh, the second part of it is shared purpose. You want to build that across your, not just your teams, but all of the stakeholders that you’re interacting with. So people are driving in the same direction, uh, and we’re all moving towards the same success and the same set of goals and every opportunity is a learning opportunity.
Kovid Batra: Great! Thank you, Sheeya. Thank you so much once again. Great to have you today.
Sheeya Gem: It was a pleasure. Thank you for inviting me on your show.
In this episode of the groCTO Podcast, host Kovid Batra interviews Anton Zaides, the Director of Engineering at Taranis and author of the Leading Developers newsletter. Their discussion focuses on the challenges and strategies involved in leading development teams versus platform teams.
He recounts how his early interest in gaming and experiences as a guild master in World of Warcraft shaped his leadership style, teaching him valuable lessons in social intelligence and teamwork. Maher outlines his proprietary framework for peak performance focusing on shared understanding, trust, and competence, and highlights the significant benefits of leveraging generative AI tools like GitHub Copilot for improving productivity. The episode also delves into the complexities of implementing new technologies and managing distributed teams, underscoring Maher’s strategies for overcoming these challenges through continuous learning and fostering a collaborative culture.
Kovid Batra: Hi everyone. This is Kovid, back with another episode of groCTO by Typo. And today with us, we have a very special guest who is coming to the show for the second time, but first time for this year. That’s Anton. Welcome to the show, Anton.
Anton Zaides: Thank you, Kovid. Great to be back.
Kovid Batra: So let me introduce Anton. Uh, so Anton, guys, is Director of Engineering at Taranis, a company from Tel Aviv. And, uh, he is also the author of Leading Developers, which is a trending newsletter, at least on my list. And he is having almost 18,000 subscribers there, writing some great articles we are really fond of at groCTO. So congratulations to that, Anton, and welcome to the show again.
Anton Zaides: Thank you so much.
Kovid Batra: All right. Uh, so today’s topic of discussion is one of the topics from Anton’s newsletter, which is ‘Leading Dev Teams Vs Platform Teams’. This was a very interesting topic. Uh, I read the whole newsletter, Anton, and I really found it very interesting and that’s the reason I pulled you off here. And, uh, before we like jump into this, I’m really curious to ask you a few questions about it. But before that, I just want to know, uh, how was your last year? How did 2024 go? What are your plans for 2025? So that we get to know a little more about you.
Anton Zaides: So 24 was very busy. I had my, uh, I had my first kid at the beginning of the year, so a year ago, and got promoted a month after that. So it was a year full of..
Kovid Batra: Super hectic.
Anton Zaides: Yeah! Hectic, career, family, and I think a small one would be in my, uh, first international conference, uh, back in September, which was a great experience for me, you know, like talking in English with an audience. So I would say lot of family, lot of career. And in the next year it’s more about family. I’m right now taking a 7–8 months break and I’m planning to work on my own thing. Early child education, mainly helping parents, children, like my own kid’s age. Just a bit of technology and also learn about it. You know, I feel parents don’t really know what they’re doing. So that’s my goal for next year, to be a better father and use technology for that.
Kovid Batra: No, that’s really amazing. I know this is, I think there are a few experiences in a human’s life and this is one of those which changes you completely. And, and in a, in a very good way, actually. Uh, when you’re young, you usually do not love to take responsibilities. Nobody loves to do that. But when such kind of responsibilities come in, uh, I think you, you grow as a person, there is something that, uh, something else that you explore in your life, at least I would, I’ve seen, uh, in my friend circle and of course, I can relate to what you’re saying also. So, congratulations and all the best. Uh, we really feel that you would do great here as well.
Anton Zaides: Thank you. Thank you. Definitely. We’ll try.
Kovid Batra: Yeah. All right, Anton, uh, coming to the main section, uh, talking about platform teams and dev teams, uh, this topic is very unique in, uh, in a way that nobody usually gets to talk about it in detail, in depth the way you have done it. Of course, a lot of generic articles are there. I’ve read a lot. This session could be a really good guide for someone who is, uh, in a position where they are moving into these roles from, uh, leading dev teams to platform teams. They could really have some learnings from what you have experienced in the past. So, first question to you actually, why did this topic come to you? What happened in your personal experience that made you realize that, okay, this could be something that an engineering manager or a tech lead who is switching between these kind of responsibilities would be interested in knowing?
Anton Zaides: Going back, I first started in a classic dev team, right? I wrote code like everyone else for a few years, and then I switched to the platform side, DevOps side, more infrastructure, and led the team there for a couple of years. And I decided to switch back. So it was two switches I did. And in my last role as an engineering manager of a classic product-facing, you know, user-facing team, I felt that most of the other engineering managers in the organization, they don’t really know how to work with the platform team. We have a DevOps platform team that provide us, you know, all the tools, they help us, and I felt they don’t really understand, uh, how to approach them, how to help them, how to connect them to the business. So they just really liked working with my team and I always got what I wanted and I pushed the agenda for that. And it really, really helped my developers too, right? Because they got close to the platform developers and they understood it better, that made them better developers. And I felt like this connection can help other engineering managers who never experienced how difficult it is to be in a platform or DevOps team. I’m using the terms, uh, interchangeably, but, uh, let’s call them platform for now. So I felt that, you know, I can show the other side and I hope it will help other engineering managers to see the difficulties and stop being annoying, because, you know, we are the, we are the clients. It’s very, very hard to satisfy developers for platform teams. It’s almost impossible. You’re always too slow. You’re always like, too many bugs. You’re always not prioritizing me enough. So I wanted to show a bit of the other side. So that was the focus of the article, like showing the inside of a DevOps team with some tips, product teams on how to help the, those DevOps teams. That was the idea.
Kovid Batra: Hmm. Interesting. Interesting. So this was some real pain coming out there and like you telling people, okay, this is what the picture is so that they know what’s going on. Right. I think that makes a lot of sense. And I think a lot of people connected to that. And even I like the article a lot. Um, I was reading one section, uh, from the article, which mentions about, like this is something which is really, really hard to manage, right? Uh, because the, the expectations are very hard and you just now mentioned about, uh, it’s, it’s very hard to satisfy the developers and then the requirements are changing too fast. So these were the first two things I remember from your article which were, you, you touched base upon. So can you just give me some examples and the audience about how you see things are changing really fast or how it is becoming very difficult for you to manage these demanding clients, actually?
Anton Zaides: First of all, I think when your clients are technical and they are inside the company, they feel the privilege to tell you how to do things and prioritize your work, right? Because they say, Oh, why does it take you a month? So, I know I can do it for a week, right? They feel they can do the platform work and they kind of push the platform teams. Um, I had an example where when I was doing the platform team, we were responsible for, I don’t want to get too technical, but we had, uh, you know, database services like Postgres, MongoDB, Redis, right? Storage databases. So we were in a private cloud and we were responsible for, uh, providing those database as a service. What do you have in AWS and GCP? You just can request one. So we needed to do the same in our own private cloud, which is quite complex. And we provided PostgreSQL and MongoDB and Redis. And every day another developer says like, why don’t you do Cassandra? Or why don’t you do CouchDB? Like they felt like they know what needs to be done and they didn’t. They never thought, you know, in my opinion, Postgres is perfect for 99.9% of the startups and their products, but the developers felt like they need to push me to provide them new database just because they wanted to use new technologies, right? And now I heard like, uh, for example, we have Jenkins, right? So in my company, I heard developers complain, why Jenkins? It’s so slow. We need to replace it for something faster. Right. And this is something as a product team, you’ll never hear your client tell you, why do you use React? You need to use Vue. Right? It’s faster. It’s, they don’t care, right? They care about the end result. And here the comments like this, like does somebody really know how hard it is to replace Jenkins with another tool? What are the costs? What are the benefits? Why do it? So So they feel very comfortable, like, suggesting and giving their opinion, even if nobody really asks them, I would say. That’s one thing.
And the other one about the priorities is it’s actually, I would say sense of urgency that there are a lot more fires in the platform teams. For example, if you have, uh, we had the case of a GPU problem, right? You know, the world has, uh, not enough GPUs. So we had, we use, uh, the cheaper version of GPUs where they don’t promise you enough. And then we had a bottleneck and we needed the GPUs, but we couldn’t get them. And now we needed to change all the infrastructure to request the higher GPUs and kind of balance them to save prices. And this is a project that took one month and it’s completely stopped what they’re working on, which was also important. And you have so many incoming things like that, you know, you have an alert somewhere, right? Something is crashing. Very often it’s the developer’s problem. But if you see, uh, prod crashing, you say, okay, it’s, it’s the DevOps. They don’t have enough memory or they don’t have enough nodes or something like that. And then you kind of need to debug and then you understand it’s the developer’s problem. You tell them and then they debug and come back to you because they don’t do their job well. So this all back and forth makes it very, very, very hard to concentrate. I remember sitting in, you know, you have this tap on the shoulder, “Please help me a bit. Uh, please explain to me why this is not working.” Uh, clients usually in a product team, you have customer support, you have customer success. You have so many layers that isolate the developers from distractions, right? And you can see it straight here. Your clients are sitting by your side and they just go over and sit by you expecting you to help them. I think product developers would have been crazy if your client would come up to you and say, “Oh, this. I see an error, help fix it now.” So, yeah, I agree. Those are the two things that, that make it, uh, very hard, clients being opinionated and always distracted.
Kovid Batra: Right. I think from the two points that you mentioned, uh, there is always unwanted suggestions, recommendations, and then there is, there is this explanation when you do not want to be directly interacting with them, there should be a first level of curation on whether the problem belongs to the platform team or to the developer, there should be some level of clarity there and then probably there should be deep diving into what’s going on, who’s responsible. So what I felt is, let’s say just hypothetically, uh, five years down the line, you are an engineering leader who is managing the complete tech for, for an org. Uh, you have platform team, you have your development team, right? What advice or what kind of culture you would like to set in? Because it seems like a problem of a culture or perception where people like blame the platform teams or do not empathize with the platform teams that much. So, as an engineering leader down the line who is leading two different teams, what kind of culture you would like to set in or what kind of practices you would want to set in so that platform teams who are equally critical and responsible and accountable for things as development teams are operating neck to neck? Or I’m not, I’m short of words here, but I hope you get the sense of what I’m trying to say.
Anton Zaides: Yeah, I think I got it and, it’s, it’s a small thing that we’ve actually tried, but I think if I would have been the decision maker to be on a biggest scale, actually to switch places for at least a while. So I believe that platform and DevOps knowledge is super useful for every engineer, right? Not always the other way around. So I truly believe that every product engineer should know about platform, at least the basics, not every platform engineer should know React, right? Depends on what they work in, but I would put the product engineers and put them for a month, uh, helping the platform teams in a project. Like, everyone should do a bit of platform work to understand, to see how they work, right? They can work in Kanban and not your usual scrum to see how they’re day to day. If you see from the other side, like if you need to provide support to your own team, right, you are the pipeline. You will see how many requests are coming through and the other way around. I feel that we had, uh, for two sprints, like for a month, we had one of the platform developers in our team because he wanted to experience the life of a developer to understand the problem better and the usage of his own systems. And it was really, really mind opening for him too, to understand why we complain, what he thought was so easy to understand that it’s our problem. Once he sat with us and tried and developed and, uh, released some backend code to production and understood it’s not that easy. And so this connection of switching places and it has some cost, but I feel it’s worth it.
And the second one I would say is connect, like the road map shouldn’t be different, right? They should be much more connected. So when you’re building the platform roadmap, you should have, of course, the engineering managers, but not only when you build it. Like, they should be there at every release kickoff, every, every time they should be part of the platform roadmap. This is the easy part. The harder part is to explain to the platform people the your product, right, how is your 3–4 months going to look? What are you working on? What do you expect? And not just the managers, which is what usually happens, right? You have a manager sitting with a manager, discussing and stuff like that. The people underneath need to understand that, uh, sit there. For example, a platform engineer should hear customer success stories that he indirectly helped because a big part of the problem that when you work in the platform team, you don’t really affect the business bottom line, right? You help developers create solutions, but if you can have those stories of how you helped someone deliver something faster and what was the impact on the company, it creates like a shared responsibility because next time you will want to help them faster. You will want to understand the problem better because you feel the impact. Saying, “I released the service to production in five minutes instead of three hours.” That’s nice. But saying, “I released the feature a week earlier and a bigger deal was, uh, agreed by the customer because of the DevOps team.” Right? Doing this connection. It’s not always easy, but in a couple of cases, we were able to do that connection. Um, platform work directly to business outcomes. I feel that would be something that we try, uh, much more. Um, so yeah, if I had to choose one, it’s just, uh, switching the places a bit, we had a concept called ‘DevOps Champions’, but it can be ‘Platform Champions’, uh, where you pick one developer from each product team and they have a weekly meeting with the platform team and like hear about the latest news, ask questions. And for example, they are the point of contact before you can contact the platform team. You have someone in your team who is interested in platform and he gets more, uh, he gets like, I would say Slack, direct Slack access to the DevOps team They know like this person, if you ask, we will drop everything and help them. And they, they do trust. And then the whole team talks to one person instead of to the DevOps team. And, and this helps a bit. So I hope it was not too confusing. So if I sum it up, I say switch places and have a dedicated platform, uh, representative inside the product teams and also connect the platform team to the business side. Yeah.
Kovid Batra: That really makes sense. Uh, this point which you mentioned about bringing DevOps Champions, right? Like who are going to be the point of contact for the product teams to share knowledge, understand things. Going back to your newsletter, uh, you mentioned about bringing more visibility and recognition also. So is this dev champs, DevOps Champions some way of recognition also that you want to bring in into the teams to have a better culture there? I mean, basically these teams lack that level of recognition just because they’re not, again, directly impacting the business. So they don’t really get to see or feel what exactly they have done is, is this an outcome or consequence of that?
Anton Zaides: No, I think it’s a bit different because the champions are product engineers, like who are originally from inside the team. So if I have five developers, one of them will be like, uh, will wear the platform hat, but he will be a product engineer and he will get to, to, uh, learn from them and work with them, the ones who are interested. For the recognition, I’m talking about recognition of the pure platform engineers, which are usually in the dark and separate there. And there it’s about what we, we discussed a bit earlier, also sharing their stories, but also public acknowledgement. That’s something that I really, I have the privilege of having a LinkedIn, you know, and I constantly write there. So I, I did a couple of shoutouts for our platform engineers after nice projects, and they really, really appreciated it because, you know, people usually, you know how it is. If it works, they don’t hear about platform, only when it breaks. So they don’t get like kudos for nice projects and stuff like that. So I really try both on LinkedIn, but also in internal companies like channels, you know, saying nice words, uh, appreciating the work, stuff like that.
Kovid Batra: Makes sense. Makes sense. Totally. I think, uh, one thing I would be interested in knowing, like any of the projects that you took up as a platform team lead and completed that project. What was the mindset, what was the need, uh, and then how you accomplished it? Just deep diving into that process of being a platform team lead, uh, leading a project to make the lives of your developers, uh, better and maybe making them more productive, maybe delivering faster.
Anton Zaides: So let me think, it’s been a while, right? It’s four or five years ago since I was there. But I think if I go back, right, my team’s role was to deliver database as a service for our customers, right? Customers and developers, they want, uh, whatever PostgreSQL, uh, MongoDB and they, it’s hard for me to explain to people how it is without a public cloud. I was in a government agency, so there was no GCP, AWS, Azure. It was like everything, you need to create everything. It was an air gapped environment. Because of, you know..
Kovid Batra: Uh, information, regulation.
Anton Zaides: Regulation, information, you couldn’t use stuff like that. So we need to do everything from, from scratch. And one thing that, uh, we were a small team, so all the communication was, uh, we didn’t have like a portal, right? I know it’s very hard to imagine a world without the public cloud, but it was like emails and messages, please create me a database and stuff like that. And one very small annoying thing was the extensions and Postgres. You have many default extensions, like you have PostGIS, like for geographic extensions, you have like, uh, for using it as a vector database, you have many extensions, and we wanted to help them use those extensions, right? Because every time they needed a new extension, they need to send us an email. We need to check it. We needed to roll it out and stuff like that. So I know it’s, I think it’s not what ideally what you, uh, meant because it was quite a small project, but I saw that pain and we kind of went and figured out the top 20–30 extensions that did some templates and did some UI work, which is quite rare for platform teams, right? Because you hate UI, usually if you’re in platform. At most, you can do some backend, but you prefer to do like, you know, flash scripts and stuff. So we did some basic, uh, interface with React, HTML, CSS. So to create this very ugly portal, which I think people appreciated. It makes the work easier. And I think the good, the good platform teams are not afraid of writing a bit of code and using like graphical interface to a small portal or like, uh, if you want to request to see stuff like that instead of waiting for product teams to help them create a nice screen and stuff like that. Now with Cursor and, you know, and all the LLM, it can take you 30 minutes to do everything you need. Like, you have APIs, you can put them where they can use buttons to do like that, you need to request something. So I think like that barrier, if I go back to the story to break the barrier and not say, okay, I can only do backend stuff. That’s how it works. I will. And just think about the next step and go where it’s, it’s uncomfortable. I had, I was lucky because I had the background as a product developer, so it’s easy for me. But all of my team members, there was like, no, no way we’re going to write React. No, it’s not our job and stuff like that. So I had to, to force them a bit, force them and I actually enjoyed it because you know, it’s It’s, it’s rarely in the platform that you can actually see something immediately
Kovid Batra: This was an interesting experience and how this experience would have changed in case of such kind of requirement when it comes to dev teams, like, because we are just comparing like a while leading dev teams is different from leading platform teams. So in this situation, of course, there was a barrier. Uh, there was a problem which the platform teams had to solve, but it came with a solution that platform teams are usually not inclined towards like building the UI, right? If a similar kind of a situation had to come in for the dev teams, how do you think it would have been easier or difficult for you to manage as a manager?
Anton Zaides: I would say as a dev team, you have a product manager, you have UX designers, and you get a ready Figma of how it should look like, and you just implement it in, in a couple of days, right? It’s so much easier because someone is doing the research of talking to the customers. Some platform teams have a product manager, right? I would not say, but they for sure don’t have a UX designer working with them, because the system is internals and everybody say, “Oh, just make it good enough. Uh, these are our people anyway. You don’t need to make it beautiful.” So this, this is usually how it works. And in the product team, for me as a manager, it’s so much, much less work for me. The product manager, uh, doing most of the work. And I would just like, you know, manage the people a bit, coach them. But as a platform team, I did it, like 50% of my job I did product management. For some of the time I did have a dedicated product manager, but some of that I didn’t and I needed to kind of fill the hole myself. Yeah, because in platform team, it’s the first team where you cut the product manager. You say, “Oh, it’s internal. No need. Uh, the engineering manager can manage.”
Kovid Batra: That’s even my point, yeah. So even I, I felt so, like for platform teams, do you think it is even important to have a product manager? Because the tech lead or probably the engineering manager who’s involved with the team would be a good start to make sure like things are falling in the right places and understanding the problem. See, ultimately for a product manager, it is very important to be more empathetic towards the client’s problems and be able to relate to it. The more they relate, The more fit is there, the better solutioning they can design. Right. Similarly for an engineering manager who is leading the platform team, it would be more of a product role and it makes more sense also, as per my understanding. What do you have to say about that?
Anton Zaides: I have had experience with product managers with platform team who didn’t come from an engineering background and it was always a failure in my experience. Uh, I would say it’s better to have no product manager to let the engineering manager do the job. And ideally in, in that team after, I think it was after a year and a half, one of the engineers, like she mentioned she wants to become a product manager. This is her career path and then it’s a perfect fit, right? If you have an engineer who wants to become a product manager from inside the company, then it can work great. But I feel that in the platform case, the product manager must have an engineering background. Otherwise, like you can try to learn to be technical, but it would just be, it would be a different language. It would be, it’s not like product teams. Yeah, I agree. I feel it’s, uh, yeah, it just doesn’t work in my experience.
Kovid Batra: Makes sense. By leading a platform team where you find this kind of a fit where some engineer who is interested in becoming a product manager comes in and plays a role, I think I sense that there is definitely a need of a person who understands the pain, whether that person is an engineer or the engineering manager who is working as a product manager, but you definitely need that kind of a support in the system to make sure that requirements are flowing in correctly, right?
Anton Zaides: Yeah, I agree.
Kovid Batra: And most of the time what I have seen or felt is that engineers usually shy away or the engineering team shies away from being involved that aggressively towards client requirements. So when it comes to platform teams, how do you bring that extra level of empathy towards customer problems? Of course, they are developers, they relate to the problem, but still, I feel that in a world where we live dealing with real world problems, being a developer, you still get to see some side of it because you’re a human, you’re living in the, in that world. But when it comes to platform teams, it’s all technical. You have seen things, but still, it’s more like you are just solving a technical problem. So the empathy towards deep diving into the problem and bringing up a solution, does it become harder or easier when you are raising a product manager in an engineering team for platform teams?
Anton Zaides: I think it’s quite hard and I think this is the role of the engineering manager, of the platform engineering manager. Like I feel the product managers still have difficulty bridging that gap. I would say that platform engineers, either by experience or by character, they care more about the technical side. You know this term of product engineer, which is like pure product engineer, not like software engineer, like the people who decide what to build. Platform engineers, from my experience, care about the technical side, like much, much more, right? They want to build excellent solutions, they are excited by crazy bugs and they are excited by saving costs, stuff that most people are less excited by that. And yeah, it’s, it’s purely the job of the engineering manager. Like, as a platform manager, you need to show the pains of the developers too. That’s much more than in a product team where the PM filled that gap. I feel that even if a PM is an ex-engineer, in my experience, somehow, like, if the engineering manager won’t do it, the developers will resist much more the PM. Right? I think that’s what comes to mind. You have much more resistance in the platform team because they want to stay in the code. They don’t want to join customer meetings. They don’t want those things. Just want to code. So you need to, you know, like, uh, peel the shell and try to bring developers to share their stories, send them for a month for a development team, as we discussed, which they will hate probably. So you need to, to, push a bit. And the PM, it’s not, they are not his or her direct report. So they have limited power and you can actually, I would not say force, but kind of help them hardly along that path, uh, of understanding the user brains. Yeah.
Kovid Batra: Great, Anton. I think, um, thanks. Thanks for this interesting talk and helping us deep dive into the platform teams and the dev teams and how they differ in their core DNA. Uh, I think there were some great insights about how things change when you are leading a platform team, that from the expectations, from the kind of mindset that the developers come with, the unwanted suggestions, and like how you bring more connectedness to the business and recognizing teams. So I think this was a very interesting talk. Before we moved from the session, uh, is there any advice, uh, parting advice that you would like to give to the audience?
Anton Zaides: My main advice would be to the product leaders, product engineering managers to try much harder to understand the pain of the platform teams in your organization and how can you help them. Schedule 1-on-1s with the platform engineering manager, be more involved because they will appreciate that help and they might not even know they need your help. And in my experience, you will benefit for sure.
Kovid Batra: Makes sense. Makes sense. I think this would not only help reducing the friction, but will also help, uh, in bringing a better and a collaborative effort to build better product also like better platforms also.
Anton Zaides: For sure.
Kovid Batra: Great, Anton. Thank you. Thank you so much once again, uh, it was great having you on the show. Thank you.
Anton Zaides: Thank you, Kovid. It was great being here.
In this episode of the groCTO Podcast, host Kovid Batra welcomes Maher Hanafi, VP of Engineering at Betterworks, to discuss engineering productivity hacks. Maher shares insights from his 16+ years of engineering and leadership experience, emphasizing the importance of passion and individualized growth paths for team members.
He recounts how his early interest in gaming and experiences as a guild master in World of Warcraft shaped his leadership style, teaching him valuable lessons in social intelligence and teamwork. Maher outlines his proprietary framework for peak performance focusing on shared understanding, trust, and competence, and highlights the significant benefits of leveraging generative AI tools like GitHub Copilot for improving productivity. The episode also delves into the complexities of implementing new technologies and managing distributed teams, underscoring Maher's strategies for overcoming these challenges through continuous learning and fostering a collaborative culture.
Kovid Batra: Hi, everyone. Welcome back to groCTO by Typo. Uh, this is Kovid, your host, wishing you all a very, very happy new year. Today, we are kicking off this year’s groCTO Podcast journey with the first episode of 2025, hoping to make it even better, even more insightful for all the listeners out there. And today, for the first episode, uh, we have our special guest, Maher Hanafi. He’s VP of Engineering at Betterworks, comes with 16 plus years of engineering and leadership experience. Welcome to the show, Maher.
Maher Hanafi: Thank you, Kovid. Thank you for having me and happy new year.
Kovid Batra: Same to you, man. All right. Uh, so, Maher, uh, today we are going to talk about some engineering productivity hacks from a VP’s perspective. But before we jump onto our main discussion, uh, I think there is a lot to know about you. And to start off, uh, we would like to know something about you that your resume or your LinkedIn profile doesn’t tell. Something from your childhood, which was very eventful and then defines you today. So would you, would you like to take the stage and tell us about yourself?
Maher Hanafi: Well, that’s a great way to start the conversation. Thank you for asking this. Um, yeah, it’s not something that is on my resume and in my bio, but um people who know me know this. So I’m into gaming and I used to play video games a lot when I was a kid, to the point that I wanted my career to, to be in gaming. So I have a telecommunication background, engineering background. And then, as soon as I finished that, and I was ready to go to the market to start working, I decided to completely go and pursue a career in gaming. So what I did is, um, I looked into the gaming job, game developer jobs, and I figured out everything they’d need to, um, to have, to be had as a game developer. And I learned that. I taught myself these things and two years later I was working for Electronic Arts. So a great story there is like this passion I had as a kid for many years led me to, um, go into and pursue that career. Another part of that same story, as a gamer, I used to play a lot of, uh, massive multiplayer online video games, like MMOs. Uh, one of the biggest one is World of Warcraft, and at that time, I used to play the game a lot to the point that I was a guild master, meaning I was leading a big team, uh, hundreds of people, um, telling them, you know, kind of a leadership position. So in other words, I was a manager, uh, before I even started my career as an, as an engineer, or, uh, before I became an Engineering Manager later. So that taught me a lot of things from, you know, social intelligence and how you manage people and how you hire and fire and kind of manage productivity and performance, which will be the topic of today. So happy to be going to that later in a moment.
Kovid Batra: Oh, that’s very, very interesting. So I think, uh, before you even started off your leadership journey, you, you were actually leading a team. Though it was just gamers, but still it must have taught you a lot.
Maher Hanafi: Absolutely. Yeah, I learned a lot and I’m so grateful to that experience and a lot of what I did there are things that I brought to my career and I used as a, as a manager, um, to, to get to the engineering level.
Kovid Batra: Perfect. Perfect. I think it’s time. Let’s, let’s move on to something, uh, which is around the topic. And before, before, again, we jump onto that, uh, tell us something about Betterworks, your role and responsibility as a VP of Engineering over there. How is it like at Betterworks?
Maher Hanafi: Yeah. So, Betterworks, we are an enterprise, uh, SaaS company. So we develop an enterprise performance management software for global big companies, all the tools and suite of tools they need to manage performance internally, uh, for big companies. Again, this is more challenging when you have a, you know, departments and team and business units, and like you’re just globally distributed. Managing performance in general is very challenging. So we build and provide all these tools for, for our big customers. I’m currently the VP of Engineering. I lead all our engineering teams. Uh, we’re split between India and the US, and yeah, uh, I do different things. I, obviously, lead the technical perspective from a vision and strategy and architecture, help the team make the right decisions, build the right software, and also I contribute a lot to our strategy over time and vision, including AI. So this was one of the most recent, you know, kind of areas of focus of mine to help the team and the company deliver generative AI integrations and features and hand feature on top of what we offer, which is obviously very, very kind of important these days to be on top of that and deliver. So that’s what I do. And again, as a VP of Engineering, there’s a lot of things that get into that, including, you know, managing the team, managing productivity, ensuring that everything is being efficient and effective in having an impact.
Kovid Batra: Talking about productivity and efficiency, I think, um, I was just stalking your profile and like, I was stalking you on LinkedIn and I realized like, you have had this good journey from being a developer and then manager and then leader, right? I would want to understand how your perspective towards improving team efficiency and team productivity has changed while you were working as a manager and now working as a VP, like how, how your perspective has changed?
Maher Hanafi: Yeah. I mean, working as a, you know, going from an IC to a manager is one thing, is like going from this, you hear this a lot, going from being a player to being a coach, maybe captain/coach. So you have your scope, which is small. Usually you have your team, which is also usually small. The areas of expertise in terms of like stack and technology is also small most of the time. So when I started my journey as a manager, I was managing mobile teams and mobile development teams. So that was my area of expertise when I turned into management. But then when you get into more like senior management and the Director of Engineering and VP of Engineering, you, your scope is growing and you will be turned more horizontal than vertical, right? Like your depth of expertise gets kind of, uh, get to a certain level where you cannot go any deeper if you want to manage bigger teams. And add to that, you get involved into managing managers and you become like a coach of coaches. So the whole dynamics change over time and your areas of focus change and you become less hands-on, less technical, but still you need to keep up with things that are happening. If you go online and search for VP of Engineering, you’ll find a lot of people saying that VP of Engineering is like the hardest job in the engineering technology stack or all the roles because it has this challenge of going horizontal, trying to be as vertical as possible, managing managers and managing performance and again, focus on impact. So I think the mindset, the way my mindset changed over time is I needed to let go some of my biggest passions when, you know, I used to code and I used to go deeper into little details and very specific stacks and go more horizontal, but keep myself really up to date with things, so I can go and speak to my teams, their language and help them move the needle or what with what they do and still be a someone who can bring a vision that everyone can stand behind. So it’s a completely different game over time, but it’s organic, you know, you cannot just hop on overnight to into a new role like this and just expect yourself to be successful. So there’s a lot of learning, a lot of education You need to keep up with everything that is happening as much as you can obviously And then help your team execute and find the gaps in your own set of skills, technical, non-technical skills to be the best VP of Engineering you can to help your team proceed.
Kovid Batra: So if I have to ask about one more, like one of the hardest things for you, when you had to change yourself and you moved into this role, what was it?
Maher Hanafi: I think, definitely, going very horizontal because I think when I turned more into senior leadership positions in engineering management, I found myself very quickly into completely outside of my comfort zone, right? Like I used to do, you know, I started with gaming, obviously, that was my area of expertise. And then I learned mobile, which was a passion of mine. And then I was, that was my space. I was very comfortable there. I can do anything. I can be very efficient and I can lead a team to deliver on these areas. But then overnight, you take over, you know, web development and backend technologies and then cloud native, you know, distribution systems. So overnight you find yourself completely outside of the zone where you’re very comfortable and your team is looking up for you to guide sometimes, right? And it’s very hard for you to do any of that if you are able to speak the language to catch up with these technologies, to be someone people can stand behind in terms of like, uh, trust in terms of guidance. So that’s the moment where I felt like, “Oh, this is not the, this is not a thing I can keep doing the same way I used to do other things before. Now I need to get myself into continuous learning more proactively even ahead, you know, going a little bit ahead of my initial plans and managing teams.” So, very quickly I turn on, “Okay, what is web development? What are the key areas and components and technology stacks? How can I manage a team that does that? How can I learn back end very quickly? How can I learn infrastructure and data and then QA and security and all of that?” So as you go into these roles, again, your scope is going to grow, you know, significantly, and you need to catch up with these technologies, again, to a certain level of depth. I cannot go as deep as I went into mobile and into other technologies I was very hands-on in, but you need to have that level of depth that is good enough to drive these teams to really be a source of trust and confidence and people can stand with you as a leader, and again, be productive and perform.
Kovid Batra: Right. I think that makes a lot of sense, actually. But the thing is, like, when you are in that dilemma that how, whether you should go vertically deep into the topic or you have a responsibility to like, go horizontal as well, how do you take that call, “Okay, this is where I have to stop”, and like “This is how I would be guiding my team.”? Because when you’re talking to technologists and specifically in your case you were coming from a mobile and then a gaming background and then you took up other technologies. Anyone who is expecting some guidance there would be much deeper into that technology. So what would be that situation? Let’s say, I am that person who has technically, probably spent three, four years already in web development and you have come in as a VP and you’re trying to have a conversation with me and telling me that, okay, this is how you should be taking up things. Don’t you think that I would be the person who already knows more hands-on than you? And then in that situation, how could you guide me better?
Maher Hanafi: Well, that’s, that’s where a mix of soft skills and hard skills get into the game. And that’s where you can get into the VP of Engineering role is to be smart and socially capable of navigating these situations, right? So first of all, all the hard skills, as I said, you need to go and learn the minimum to be able to speak the language. You cannot go to, again, back end engineers and start telling them things and telling them stories about your front end engineering background. It doesn’t work. So you need to get to a certain level of learning and efficiency in the stack and the technology to be able to at least speak at a high level. And then, the other thing is where the soft skills get into the game. You need to be vulnerable. You need to be very clear about your level of expertise. You need to highlight your team members as the experts and create this environment of collaboration where you come as a leader, but they are the expert in the field, and together you can make, you can move the needle, together you can make things happen. So build that kind of trust relationship that will, that is based on their competence and your leadership and together you can really get things in motion. It’s very hard for someone who doesn’t have the strong IC technical hands-on background in a specific stack to come and lead them from a technical perspective purely with their own leadership. And that’s, in another language, that’s not a good leadership framework or management style if you just come in and guide the whole team to do what you want them to do. So that’s where, again, your soft skills get into the play where you come in and say, okay, what’s the vision here? What’s the plan what you have been going through? What are the challenges? And then, over time as you get more mature and more experienced as a leader, you’ll find a way, you’ll find a way to make it work. But again, I think you need to really get your ego outside of the room. Get and talk to these individuals. Make sure they understand you are here to support them and guide them from a leadership perspective, but they are still the expert in the fields and you count on them and give them space to experiment, give them space to own and lead and drive things. And that’s what leads to good collaboration between the leaders and the team behind.
Kovid Batra: Totally makes sense. Totally makes sense. So, um, moving on to the part where we talk about managing the teams, making them more efficient, making them more productive, what do you think, is there a framework that fits for everyone? Do you follow a framework to improve the overall engineering productivity, developer productivity in your teams?
Maher Hanafi: Honestly, this is a very kind of hard question, right? There is no pattern. There is no formula, one size fits all here for performance and for productivity. As a leader, you need to get into learning what your team is about, what the challenges they are facing, what kind of combination of skills, again, hard and soft skills you have in the team to figure out what is missing and how can you address this. But there is still like, even if this is not like a, there is no specific framework, I personally have been following a framework that helped me a lot in my journey. This is based, this is a twist of Daniel H. Pink, um, kind of autonomous team or the art of mastery, based on his book Drive. It’s by someone called, I think, John Ferguson Smart, and it’s a combination of three things. Shared understanding, which is mainly making sure that everyone in your team has the same understanding of what you are trying to do, what is the vision, and get that level of alignment, because sometimes teams cannot perform if they don’t have the same definition of something. Like if you want to build a feature and two parts of your team have this different understanding of that feature, that’s not going to lead to a highly performant outcome. So shared understanding is key and sometimes we miss this as leaders. We, we kind of delegate this to other people or other departments like product and project management say, “Okay, well, you, you, you define what is the statement and let the team work on it.” But as an engineering leader, you need to make sure your team has that same alignment.
The second thing is I list, I actually, I talked about this earlier is trust. I think trust is, again, really underrated when it comes to engineering leadership and we focus on technical and like this and that, but to build the value of trust in your team, to make sure, again, what I said earlier, talk to your team and tell them you are the expert. I’m here to help you get the best out of your expertise. And then, they should trust you also as a leader, as someone who can really help them navigate these things, not worry about the external noise and focus on what they need to deliver. And this leads to peak performance, which hopefully we’re going to get to at some point. The third part of this is competence, and this is mainly about hard skills which are, you know, very related to how efficient they can be at their, their, the stack and the technology they’re working on and all of that. So it’s more about the deep knowledge. So now defining shared understanding, trust and competence, you have overlap between these things, shared understanding and trust gives flexibility. So if you and your team members have the exact same understanding and you trust them, you can give your team the flexibility to do whatever they want. They work in their own way, the best way that works for them and own and kind of drive a higher level of ownership and use their own better judgement to get to the delivery. And flexibility works a lot to improve performance. So if you give people the flexibility they need, they can be very successful. The overlap between trust and competence provides excellence; meaning that if you trust them and they have the right skills, they will deliver the best outcome from a technology perspective. They will build the best code they can, because they trust their own frameworks and practices. Obviously you need, as a leader, you need to make sure it’s all aligned across the teams and not, it’s not based on individuals. And then last overlap is between shared understanding and competence. You get the focus. So if they have the skills and they have a clear understanding, they can be very focused on delivering exactly the right desired outcome you have for the team.
So this is the framework I use. It’s very kind of, um, very vague from, from, from distance. But when you start using it and really try to put together some specific goals and expectations to get higher on all of these, you get the center of all of these overlap, which is a very highly autonomous team that master their technology and the work they do. And again, they can have, deliver the highest impact possible. So that’s one of the frameworks, obviously there are more, but that’s one I really, that really resonated with me. Uh, I have the books, I have the TED, I mean, I watched the TED talk from Daniel H. Pink, which is really great, I recommend it to everyone.
Kovid Batra: Perfect. I think shared knowledge, competence, flexibility, trust, like when you are putting it out there as a framework, I’m sure there are some specific processes, there are some specific things that you are doing to ensure everything falls into place. So can you just give like one example that is most impactful in implementing each of these pieces? Like one, one thing that impacts a lot that you are practicing.
Maher Hanafi: Yeah. Yeah, that’s a good point. And again, that was one framework, but there is a very popular framework, PPT, right? Like people, process and technology. These are key factors influencing engineering productivity and you need to work on them. The one focused on people has two sub, sub parts, which are the individual of part of people, and then there’s the team. So you need to make sure for the individual factors, you work on skills and experience and growth development. You need to make sure people have the motivation, engagement, work life balance, and all of that. And for the team, you need to focus on communication, collaboration, team dynamics. So one good example is I worked at companies where there were very distributed teams, including contractors, you know, engineering teams. there are some in-house engineering, there are contractors engineering, the in-house are distributed, the contractors are distributed. When I joined this company, people were naming the other parties by the name of the contractor, like the company, like, “Oh, this part of the software is like owned by this and that part is owned by us, the in-house engineers.” Based in the West, as an example. And I was so confused because for me, an engineering team is one engineering team, even if it’s distributed, like these boundaries are just geo-based boundaries. They cannot be just also deep into the engineering process in work. So what I did is I made sure like all these kind of boundaries, you know, are removed, virtual boundaries are removed. Engineering team is aligned. They use the same framework. They use the same language. They use even at some point, the same technology stacks as much as possible by aligning on design patterns, uh, building SDKs, building shared components. And that kind of created more dynamics between these teams that got them to deliver higher productivity and higher impactful software. Because at the beginning, again, there was, like every team was delivering their own standards, their own patterns, even their own stacks. Like some part was written in Python. The other part was no, the other part is in Go. They were just serving each other and in a handoff process, like, “Oh, you want this? Here you go. You have this service build.” And he does this and you have an API. But as soon as you, as a manager, I needed to put resources in different teams and focus on one areas. When I had to manage that mobility of the engineers, they were going into new piece of software saying like, “I’m not familiar with the stack and I’m not.. Even for me, even if I’m familiar with the stack, I’m not familiar with the design patterns that are in this stack in this piece of software.” And for me, that was a challenge. So, one big part we forget about improving productivity is making sure from a technology perspective, the tools, the stack, the design patterns are aligned as much as possible. You introduce new systems like CI/CDs and observability to make sure things are moving along really quickly.
And then the, the second part of this is as you said earlier, it’s the process, like what methodology you have, what kind of channels to communicate, work, you know, how efficient is your workflow as a team and what kind of practices you have introduced to your teams. And these practices should be as aligned as possible across everyone, you know, including, you know, distributed teams to achieve higher performance and higher productivity in general. That was, again, that was one of the biggest learning I had when I, when my teams started scaling up and also going more distributed from a, from a geo-based location ensuring that it’s not just a handoff process between software engineers. It was more about alignment. And I think that that solution can scale with the scale of the problem as well.
Kovid Batra: Makes sense. Perfect. Perfect. I think with that, I would like to know some of your initiatives that you would have worked in the last year or must be planning a few more initiatives this year to actually impact your engineering productivity. Is there something that was challenging last year for you? You accomplished something out of it or are still working on that?
Maher Hanafi: Yeah. So, one of the biggest areas I focus on is this again, individual and team factors, the people side of things, right? Again, technology, we talked about this enough, in my opinion, process as well, but the people side of things could be tricky. And it takes a lot of time and experience to get to a place where you can have as a leader, as an engineering leader, you can have an impact on the people. So some of the biggest initiatives I work on is ensuring on the individual side of things, we have a continuous learning development of skills for everyone on the team, no matter what level they’re in, even if you are the most highly senior engineer principal and architect level, there’s still something for you to learn. There is a new area to discover in engineering and software and hands-on work, but also maybe in some other soft skills. So providing resources, time and, you know, availability to go and explore different areas that definitely could be driven by their own passion and that’s another framework I want to bring, which is something as a, going back to the first question, you know, the story of my childhood and all of that, I was passionate about video games and I wanted to work in that space because I think when people work on their passion, they can really break the limits of what’s possible. So that’s something I always bring to my work and I get to my team and I say, let’s work together on aligning on where you want to be next and how can we achieve that. And I never bring my own pattern of growth and maybe success and say, Oh, like I go to a Director of Engineering and say, “If you want to be a VP of Engineering, this is what you need to do based on what I did.” No, everyone is different. Every path and journey is different. And I, what I do is I work with them to define their own definition to get to their own definition of success. And I say, “What makes you successful? What makes you happy in working on things that you’re very excited about? What makes you more motivated and engaged?” So the other tool or framework I use is really collaborate with individual and teams to identify their own definition of success. And then I add to it some spices, I would say, from my own recipe and from my own experience as a leader to just kind of tweak it a little bit. But most of the time that’s what I focus on is like, “Tell me exactly where you see yourself. What’s your passion about?” And this could be completely like 180 degrees. It could be doing like a software engineering on the backend and then when I go into AI. And I help them to transition there, again, over time. And I think that’s the key. And I, I think, and I hope I was able to turn around a lot of people in, in, in getting into higher productivity and performance because of this, because I never go to someone and say, “You need to do this. To be successful, you need to follow this path.” I always try to listen and get their own definition of success and work with them through this and then say, “Okay, based on everything you said, based on your passion, based on your motivation and where you want to be and with my own tweaks, This is what we need to do. And I will do followups with you and we’ll work together to achieve that.” This is something, again, if you talk to anyone I worked with in the previous companies or better works today, this is something that resonates really well with people. They recognize as a working efficient way to get better over time. And when you achieve this on the individual level, obviously your teams in general will be impacted and you’ll create some sort of like leadership and ownership and people driving things. And everyone is pushing the boundaries of what you can do as an engineering team in general. And it has been very efficient. And for me as an engineering leader, that’s where I get my rewarding experience. This is where I feel I had an impact. And this is where I was able sometimes again, to turn around completely low performance into high performance.
Kovid Batra: But I think in this case, as much as I agree to what you’re saying really resonates and in fact, that could be true for any department, like any leader enabling team members in the direction where they are passionate about, would something, would be something that would energize the whole, whole team. But still, I feel that there is a lot of complication that gets added because at the end of the day, we are humans. We have changing desires, changing passions, and then a lot of things get complex. So while you implement this framework in an engineering team, what kind of challenges you have seen? Is there sometimes some kind of a shortage of a particular skill set in the team because a lot of people are more passionate about doing the back end and you have less front end engineers or maybe vice versa. So there could be a lot of such complications there. So any challenges that you’ve seen while implementing these things?
Maher Hanafi: Absolutely. I mean, you said there are some complications and challenges, but there’s a lot. I mean, there are a lot of complications and challenges when you work as an engineering leader. This is again, as I said earlier, some people call it the most difficult position to be in because you’re, you’re managing different things. Again, we talked about people, process and technology. We, we talked about hard and soft skills, but on the, on this side, when you’re trying to implement something like this, some of the examples I can bring up here to the conversation are the initiatives you have running, maybe some of the greatest initiatives you have happening in the engineering team, like, uh, at Betterworks, as an example, we are, we have been building generative AI, you know, enhanced features and bringing these great technologies, we have been kind of refactoring, revamping some of our technologies to build newer, better systems. And, but you still have the other old legacy systems. You have things are running in production that you need to maintain. You have incidents to manage and stuff like that. And sometimes you have, you know, resources, people, teams are watching other teams and other people doing other exciting stuff, and they are still like doing the old stuff. And as an, again, an engineering leader, your job is to make sure that there’s a good dynamic. There’s a good culture of, again, trust and shared understanding that these things are happening to everyone at the same time. It’s just that it takes a little bit more time in process and priorities to get there. So it’s part of that, again, earlier, when I talked about the own definition of success is to really know where everyone is eager to be doing as, again, an individual. And then, when you talk to the team in general, you need to see what you’d listen to their feedback and understand their point of view. So sometimes some teams will say, “Okay, well, we have been coding in this part of the software for like three or four years now, and nothing is moving too much.” Versus other teams where like every quarter, they have a new feature, they have great stuff, it’s being communicated and published. And it gets a lot of like credits and all of that. So you need to make sure you have the right process in your team to be able to rotate the projects, to rotate the excitement, to get people to, again, own and lead to experiment. So some of the initiatives we do are always you know, hackathons, you know, give people time to just do something completely different from what they do on a daily basis. So that will, you know, trigger the creativity of everyone, the passion again, and you can see where everyone’s mind is at and what they want to do. So again, it’s, it’s a little bit tricky. It’s not that easy. It’s not like, Oh, everyone will be doing this. And then six months later, you’ll be doing something more fun. But that’s where, again, your presence as an engineering leader is so important. Your vision is so important. You need to people to have your teams behind you in terms of vision and trust that it’s going to happen in that kind of way of rotation and mobility and everyone will be impacted.
So, absolutely, it’s one of these challenges you see, like people trying to get into more exciting projects while you have some support. One other thing you need to do as a leader is to ensure these kind of single point of failures and you cannot. afford to have one person or one team that is just expert, very deeply expert in one area. And it creates this environment where you are afraid of two things, these team or these individuals leaving and creating a gap in knowledge, or these people being stuck in that knowledge and cannot afford to do anything else. Even if they are passionate about it or they are bored of that, you know, they, they have been building this service for too long. They want to experiment something else, but you cannot let them go because you say you’re the only expert. So my job is ensure that knowledge transfer is happening, people getting into new systems, delegate a little bit and offer everyone option to get out and do something else that they’re excited about. It’s a dance, right? It’s a push and pull. You need to get into understanding how things work. and be involved a little bit deeper to be more effective as an engineering leader.
Kovid Batra: I think the core of it lies in that you have to be a good listener, not like exactly ‘listening’ listening, but being more empathetic and understanding of what everyone needs and the situation needs and try to accommodate every time because it’s going to be dynamic. It’s going to change. You just have to keep adjusting, keep tweaking, calibrating according to that. So it totally makes sense.
Maher Hanafi: And the funny part is, uh, the funny part is a lot of this I learned while playing video games. That’s gonna connect to the first question you asked. You know, when you play a video game, you’re a guild master of like 200–300 people. And you know, you go and do these raids and experiences and then you have loot to share. And you need to make decisions and everyone wants something. Yeah, you kind of build up some experience early on about people dynamics, about making sure how you make people happy and how you navigate conflicts in opinions. And sometimes when you have very senior people also, you have a clash of opinions. So how would you navigate that? How would you make sure they can work in an environment where everyone has a strong opinion about things? So yeah, a lot of this I learned early on in my journey before even I got into engineering, while playing video games and dealing with people, which is really great.
Kovid Batra: Cool. I think that’s on the people part. And I think that was really, really insightful. I think we should have some, instead of books, have the list of games that one should play early on in their life to be a manager.
Maher Hanafi: Yeah.
Kovid Batra: So moving on from people like you mentioned about technology, right? What happened in 2024 or you’re planning for 2025 in technology to make your teams even more efficient?
Maher Hanafi: Yeah, I would say a few things. Focus on technology. There are, I would say, three big pillars. One of them is really addressing poor designs, poor patterns in your software. We underestimate this again as, underthink about it as a problem that is impacting productivity and performance. When engineers are dealing with older legacy software that has poor designs, it takes time. It introduces more bugs. No matter how skilled they are, it’s challenging. So really as an engineering leader, you need to always make sure there’s time to recover, time to pay back technical debt, time to go back and redesign, refactor, and reinvent a little bit your software stack to get people to enjoy newer, more modern architecture that will lead to high performance and productivity. Things can happen fast when you have the right patterns that are more accurate, more modern today. Again, this is very, this is something I do on a, you know, frequent basis at Betterworks and before, one of my key areas of focus as an engineering leader is to help teams pay back technical debt, build better software so they can be more productive. The second thing is investing, I would say. Investing in tooling and platforming. I mean, we always forget about platform engineering as a pillar to software engineering in general, but being able to build the right continuous integration, continuous delivery system, CI/CD, you know, have proper observability in place to get all these logging and monitoring and alerts you need to be able to know and quickly debug and figure out things. It helps a lot and it makes sure, you know, it creates a good level of confidence of the team in terms of the quality of the code. And again, you can, it’s, it’s a lot of things are happening most recently, and this is where I’m going into a third kind of component that is impacting performance and productivity from a technical perspective is generative AI. And we have seen over the last two years now, the development of these co-pilots, the coding assistance. And it’s true. It’s not fully there. It’s not fully efficient so far, but it’s very effective to get a certain level of delegation to AI when it comes to like, as an example, writing tests for functions you have, for helping you optimize some of the code base, even migrate from a stack to another. So it’s a, it’s becoming a powerful tool capable of learning from your stack and your, your software learning over time as well, adapting, and even solving some problems and some real problems at some point. As a very good example at Betterworks today, we have a, you know, top-down approach to adopting generative AI. Everyone at the company is really encouraged and asked to leverage AI in their own areas of expertise and for engineering in particular, we ask everyone to use these co-pilots and coding assistants to leverage the new ideas coming up out there to experiment and really to bring use case and say, “Okay, I have been using this to achieve this thing.” I think there are very key areas again, PR, pull request work and improvement, writing tests and even infrastructure in the future seems like infrastructure could have a big area of impact when AI helps optimize infrastructure, not to build everything from scratch on behalf of people. I don’t think AI will replace software engineers, honestly, but it will make them better software engineers capable of achieving way more, be more productive and more performant. And I think that’s the goal.
Kovid Batra: Makes sense. I think when you said redesigning and taking up the new patterns, getting rid of the old ones, or if it’s about, let’s say, rewriting code pieces, generative AI is actually putting in as a fundamental piece everywhere, right? And there could be a lot of use cases. There are a lot of startups. There are a lot of tools out there. But according to you, while you were researching that which areas should be now on higher priority from an engineering standpoint and AI could really be leveraged, I think you would have first checked this tool has evolved in this area, and this could be a right fit to be used right now. Like you mentioned about co-pilots, right? It can write a better level of code and it can actually be integrated. We can try new IDs to ensure that we have better code, faster code in place. Are there any specific tools, I mean, if you’re comfortable sharing names or telling us, what could work better for other teams as well, other engineering leaders, other engineering teams outside, out there, uh, any examples or anything that you found very interesting?
Maher Hanafi: I mean, the number one tool is obviously GitHub Copilot. A lot of teams today are on GitHub anyway. So it’s very well embedded into the system and you know, a lot of plugins for all the IDE’s out there. So I think it’s the first one that comes to mind. Also now they released the free license tier that will help a lot of people get into it. So I think that’s the no brainer. But, uh, for me, I will go a little bit off a tangent here and say that one of the best ways to experiment with, E gen AI as a software engineer could be to run gen AI locally on your machines, which are things we can do today. And personally, even a, as, as an, an engineering leader not being very, very hands-on today. You know, I found out that something like a combination of Ollama which helps you run systems, I mean LLMs locally and open source models out there like, uh, the Llama 3 models or the Mistral models. You can have, you can have a local assistant to do a lot of things, including code assistant and writing code and refactoring and all of that. And add to, if you add to that some IDEs like cursor, now you can use your ID connected to your own LLM, that again, if you have the level of experience to maybe go and fine tune it over time and use, leverage Ollama to also include, do some rag and bring some more code and bring some documentations to think in very good examples on how you do tests as an example, it could be a very strong tool for more experienced engineers. And I think one of the biggest area Gen AI would have an impact is testing. I think testing, the testing pyramid has always been to fully automate, the ambition is to automate as much as possible. And I think with gen AI, there will be more use cases to just do that. If you leverage generative AI to write tests, I think you will have a bigger, better suite of tools to ensure that your quality of code is meeting a certain level to test for edge cases you didn’t think about when you were writing code. So I think testing is one area. The other area would be in general research, honestly, in learning as a software engineer, if you have a co-pilot or just any LLM or chat based LLM, like chatGPT or Gemini or Claude, you can go and really, you know, learn about things faster. Yes, it does a lot of things for you. Like, as an example, you can copy paste a function, say, “Hey, can you optimize this?” The key if you’re leveraging generative AI is learning. It’s not to delegate. I mean, some people might think, “Oh, I don’t have to worry about this. I’m going to write random code, but then the, uh, gen AI will optimize it for me.” The key is for you to learn from that optimization that was offered to you. And we should not forget, you know, LLMs are not perfect and you can think about them as another software engineer, maybe more experienced for sure, but an engineer who can make mistakes. So it’s your part to be really curious and critical about the outcome you get from GenAI to make sure you’re at the same time leveraging the tool to learn, to grow, and to have a bigger impact and be more productive.
Kovid Batra: Yeah, I think these are some of the hard truths about AI, uh, code assistance, but lately I’ve been following a few people on LinkedIn, and I’ve seen different opinions on how Copilot has actually helped in improving the code writing speed or in general, the quality. There is a mixed opinion. And in such situations, I think any engineering org which is implementing such technology would want to have clarity on whether it is working out for them or not, and it’s completely possible that it works out for some companies and it doesn’t for some. In your case, do you like measure specific things when you, let’s say, implement the technology or you implement a new process just to, like, improve productivity, is there something that you specifically look at while implementing those at the beginning and the end to ensure, like, okay, if this is working out or not?
Maher Hanafi: Yeah, I mean, some things are measurable. Some things are not measurable, honestly, and this is known, you know, the challenge is to measure the immeasurable to find out where this technology is having impact without having tangible metrics to measure. And you need to use proxies based on that. You need to collect feedback. You need to get some sort of an assessment of how you feel about your own productivity as an engineer using these tools. So we do that every once in a while. Again, we have a very specific internal strategy and vision that is driven by, I mean, that is focused on using and leveraging generative AI in every area of the business, and one of them is software engineering. And when we started, one of the very good use cases, again, was QA and writing tests. And we have been measuring how much time it takes, I would say, a software development in tests to write the suite of tests for a new piece of code. We try to compare both, you know, ways the old ways, which is mainly kind of manual, like let’s look at this, let’s write all the tests that are needed or define the test suite for these, and then the other way is QA, you share the QA, the concept, the requirements, the acceptance criteria, and then you expect it to generate for you the test. And we have noticed that the time that takes an engineer in a software development engineering test to get to the desired outcome is way more significant. I don’t have exact percentages or numbers, but it’s like it takes 20 percent time versus, you know, a hundred percent to just achieve the whole test suite. So for, you know, this area of like bringing generative AI, it’s good, but again, we should not forget that these tests, you know, have to be reviewed. The human should be in the loop. I don’t believe in a lot of things to be fully automated and you don’t have to worry about, and you don’t have to look back. But I also, on another end, I really believe that Gen AI will become table stakes in software engineering. The same way we had these great IDs developing over time, the same way we had autocomplete for code, the same way we had process and tools to improve our quality of code, the same way we had patterns and, you know, things, I think Gen AI will become that thing that we all use, we all have, it’s common knowledge and it’s going to be a shift in the way we work as software engineers. You know, we used to use a lot of Stack Overflow and go and search and do this and do that. All that will be replaced now in your own environment, in the work and the flow of work and you will have all the answers you need. I don’t think it will take over software engineering 100 percent and like you don’t have to write anything and you hear, and you see this in LinkedIn, as you said, you hear like, oh, this was developed. I think these are, as of today, these are naive, you know, thinking about software engineering. You know, you can build a proof of concept, you can build some basic, one single feature aspects, but as you get to build enterprise, you know, distributed systems, this doesn’t scale to that level. But the technology is evolving and GenAI is doing its best to get there, and we’re here for it. We’re here to support that, and we’re here to learn it, and use it. But again, we all go back to the same saying of like a software engineer who’s leveraging generative AI will be more productive and efficient than a software engineer who doesn’t.
Kovid Batra: Makes sense. All right. I think with that, we come to the end of this episode. I could continue talking to you. It’s super, super exciting and insightful to hear all the things that you have been doing. I think you are a really accomplished engineering leader. It is very evident from what you’re saying, what you’re doing at the organization, at your organization. It is very difficult to be in this overwhelming position. It, it, it looks like that it is very overwhelming. So any piece of advice to all the other engineering leaders who are listening to you? How to keep that sanity in place while managing this whole chaos?
Maher Hanafi: I think it’s a matter of, again, going in circles here, but it’s, it’s a passion, right? I think you need to have the level of passion to be able to navigate this role. And the passion is what keeps you pushing the boundaries in making things that are complex and hard and challenging look easy and look fun and enjoyable, right? Some parts of my work are hard and tough, but I honestly enjoy them and I go through them with a positive attitude, it’s like, “This is a tough conversation I need to have. This is it. You know, I’m going to bring my principal engineers. We’re going to talk about something. And I know everyone will have an opinion, but you know what? We need to leave this meeting with a decision.” And, you know, you need to have the passion to be able to navigate these complexities. Being someone who is very driven about solving problems, navigating people dynamics, passion about technology, obviously, and have a good mindset of getting, you know, getting to the finish line. So we, you have been asking about a lot of frameworks and other frameworks, which again, very popular one is get things done. GTD. As an engineering leader, a VP for Engineering, you need to get things done. That’s your job. So you need to be passionate about that. Get to the finish line. So it’s a lot of things here and there. I don’t recommend engineering leadership in general. For people who are very passionate about just pure technical things, people who are very passionate about coding, it’s, it’s going to be very hard for them to detach from coding and technology aspect and get into navigating these things. So when you get to this level, you focus about different things from just the perfect code that you’ll ever write, and it’s more about the perfect outcome you can get out of the resources you have and have an impact. I use this word a lot. I think engineering leaders are all about impact and all about getting the best resources or the best outcomes from the resources they have and even minimize our resources, obviously, time and money in this case. So it’s not easy. But if you have the passion, you can make things happen and you can turn these complex things into fun challenges to have and solve them and really get that rewarding experience at the end where you go, “You know what? I came here, there was a big challenge, there was a big problem, I helped the team solve it, let’s move on to the next big thing.” And I think that’s my advice to people who are looking to become engineering leaders.
Kovid Batra: Perfect. On point. All right, Maher. Thank you. Thank you so much for your time. And we would love to have you again on the episode for sure, sometime again, and talk more in depth, what you’re doing, how you’re leading the teams.
Maher Hanafi: Thank you again. Thank you so much. I really appreciate it. Thank you for having me on, on your podcast.
In this episode of the groCTO Podcast, host Kovid Batra interviews David Archer, the Director of Software Engineering at Imagine Learning, with over 12 years of experience in engineering and leadership, including a tenure at Amazon.
The discussion centers on successfully integrating acquired teams, a critical issue following company mergers and acquisitions. David shares his approach to onboarding new team members, implementing a buddy system, and fostering a growth mindset and no-blame culture to mitigate high attrition rates. He further discusses the importance of having clear documentation, pairing sessions, and promoting collaboration across international teams. Additionally, David touches on his personal interests, emphasizing the impact of his time in Japan and his love for Formula 1 and rugby. The episode provides insights into the challenges and strategies for creating stable and cohesive engineering teams in a dynamic corporate landscape.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of groCTO podcast. And today with us, we have a very special guest. He has 12 plus years of engineering and leadership experience. He has been an ex-Software Development Manager for Amazon and currently working as Director of Engineering for Imagine Learning. Welcome to the show, David. Great to have you here.
David Archer: Thanks very much. Thanks for the introduction.
Kovid Batra: All right. Um, so there is a ritual, uh, whosoever comes to our podcast, before we get down to the main section. So for the audience, the main section, uh, today’s topic of discussion is how to integrate the acquired teams successfully, uh, which has been a burning topic in the last four years because there have been a lot of acquisitions. There have been a lot of mergers. But before we move there, uh, David, we would love to know something about you, uh, your hobbies, something from your childhood, from your teenage or your, from personal life, which LinkedIn doesn’t tell and you would like to share with us.
David Archer: Sure. Um, so in terms of my personal life, the things that I’ve enjoyed the most, um, I always used to love video games as a child. And so, one of the things that I am very proud of is that I went to go and live in Japan for university and, and that was, um, a genuinely life-changing experience. Um, and I absolutely loved my time there. And I think it’s, it’s had a bit of an effect on my time, uh, since then. But with that, um, I’m very much a fan of formula one and rugby. And so, I’ve been very happy in the last, in the post-COVID-19 years, um, of spending a lot of time over in Silverstone and Murrayfield to go and see some of those things. So, um, that’s something that most people don’t know about me, but I actually quite like my sports of all things. So, yeah.
Kovid Batra: Great. Thanks for that little, uh, cute intro and, uh, with that, I think, uh, let’s get going with the main section. Uh, so integrating, uh, your acquired team successfully has been a challenge with a lot of, uh, engineering leaders, engineering managers with whom I have talked. And, uh, you come with an immense experience, like you have had been, uh, engineering manager for OVO and then for, uh, Amazon. I mean, you have been leading teams at large organizations and then moving into Imagine Learning. So before we touch on the topic of how you absorbed such teams successfully, I would love to know, how does this transition look like? Like Amazon is a giant, right? And then you’re moving to Imagine Learning. Of course, that is also a very big company. But there is definitely a shift there. So what made you move? How was this transition? Maybe some goods or bads, if you can share without getting your job impacted.
David Archer: Yeah, no problem. Um, so once upon a time, um, you’re correct in terms of that I’ve got, you know, over 12 years experience in the industry. Um, but before that, I was a teacher. So for me, education is extremely important and I still think it’s one of the most rewarding things that as a human you can be a part of. Helping to bring the next generation, or in terms of their education, give them better, uh, capabilities and potential for the future. Um, and so when somebody approached me with the position here at Imagine Learning, um, I had to jump at the chance. It sounded extremely exciting and, um, I was correct. It was extremely exciting. There’s definitely been a lot of movement and, and I’m sure we’ll touch on that in a little while, but there is definitely a, a, quite a major cultural shift. Um, and then obviously there is the fact that Amazon being a US-centric company with a UK arm, which I was a part of, um, Imagine Learning is very similar. Um, it’s a US-centric company with a US-centric educational stance. Um, and then, yeah, me being part of the UK arm of the company means that there are some cultural challenges that Amazon has already worked through that Imagine Learning still needed to work through. Um, and so part of that challenge is, you know, sort of educating up the chain, if you like, um, on the cultural differences between the two. So, um, definitely some, some big changes. It’s less easy to sort of move sideways as you can in companies like Amazon, um, where you can transition from one team to another. Um, here, it’s a little bit more, um, put together. There’s, there’s, there’s only one or two teams here that you could potentially work for. Um, but that’s not to say that the opportunities aren’t there. And again, we’ll touch on that in a little bit, I’m sure.
Kovid Batra: Perfect. Perfect. All right. So one, one question I think, uh, all the audience would love to know, like, in a company like Amazon, what is it like to get there? Because it takes almost eight to 10 years if you’re really good at something in Amazon, spend that time and then you move into that profile of a Software Development Manager, right? So how, how was that experience for you? And what do you think it, it requires, uh, in an Engineering Manager at Amazon to be there?
David Archer: That’s a difficult question to answer because it changes upon the person. Um, I jumped straight in as a Software Development Manager. And in terms of what they’re looking for, anybody that has looked into the company will be aware of their leadership principles. And being able to display their leadership principles through previous experiences, that’s the thing that will get you in. So if you naturally have that capability to always put the customer first, to ensure that you are data-driven, to ensure that you have, they call it a bias for action, but that you move quickly is kind of what it comes down to. Um, and that you earn trust in a meaningful way. Those are some of the things that I think most managers would be looking for, and when interviewing, of course, there is a technical aspect to this. You need to be able to talk the talk, and, um, I think if you are not able to be able to reel off the information in an intrinsic manner, as in you’ve internalized how the technology works, that will get picked up. Of course it will. You can’t prepare for it like you can an exam. There is an element of this that requires experience. That being said, there are definitely some areas that people can prepare for. Um, and those are primarily in the area of ensuring that you get the experiences that meet the leadership principles that will push you into that position. In order to succeed, it requires a lot of real work. Um, I’m not going to pretend that it’s easy to work at a company like Amazon. They are well known for, um, ensuring that the staff that they have are the best and that they’re working with the best. And you have to, as a manager, ensure that the team that you’re building up can fulfill what you require them to do. If you’re not able to do that, if you’re taking people on because they seem like they might be a good fit for now, you will in the medium to long-term find that that is detrimental to you as a manager, as well as your team and its capabilities, and you need to be able to then resolve that potential problem by making some difficult decisions and having some difficult conversations with individuals, because at the end of the day, you as a manager are measured on what your team output, not what you as an individual output. And that’s a real shift in thinking from being a, even a Technical Lead to being an Engineering Manager.
Kovid Batra: That’s for sure there. One thing, uh, that you feel, uh, stands out in you, uh, that has put you in this position where you are an SDM at Amazon and then you transitioned to a leadership position now, which is Director of Engineering at Imagine Learning. So what is that, uh, one or two traits of yourself that you might have reflected upon that have made you move here, grow in the career?
David Archer: I think you have to be very flexible in your thinking. You have to have a manner of thinking that enables for a much wider scope and you have to be able to let go of an individual product. If your thinking is really focused on one team and one product and it stays in that single first party of what you’re concentrating on that moment in time, then it really limits your ability to look a little bit further beyond the scope and start to move into that strategic thinking. That’s where you start moving from a Software Development Manager into a more senior position is with that strategic thinking mindset where you’re thinking beyond the three months and beyond the single product and you’re starting to move into the half-yearly, full-yearly thinking is a minimum. And you start thinking about how you can bring your team along for a strategic vision as opposed to a tactical goal.
Kovid Batra: Got it. Perfect. All right. So with that, moving to Imagine Learning, uh, and your experience here in the last, uh, one, one and a half years, a little more than that, actually, uh, you, you have, uh, gone through the phase of your self-learning and then getting teams onboarded that were from the acquired product companies and that experience when you started sharing with me on our last, last call, I found that very interesting. So I think we can start off with that point here. Uh, like how this journey of, uh, rearranging teams, bringing different teams together started happening for you. What were the challenges? What was your roadmap in your head and your team? How will you align them? How will you make the right impact in the fastest timeframe possible? So how things shaped up around that.
David Archer: Sure. Initially, um, the biggest challenge I had was that there was a very significant knowledge drain before I had started. Um, so in the year before I came on board and it was in the first year post-acquisition, the attrition rate for the digital part of the company was somewhere in the region of 50%. Um, so people were leaving at a very fast pace. Um, I had to find a way to plug that end quickly because we couldn’t continue to have such a large knowledge drain. Um now the way that I did that was I, I believe in, in the engineers that I have in front of me. They wouldn’t be in the position that they’re in if they didn’t have a significant amount of capability. But I also wanted to ensure that they had and acquired a growth mindset. Um, and that was something that I think up until that point they were more interested in just getting work done as opposed to wanting to grow into a, a sort of more senior position or a position with more responsibility and a bigger challenge. And so I ensured that I mixed the teams together. We had, you know, front enders and back enders in separate teams initially. And so I joined them together to make sure that they held responsibility for a piece of work from beginning to end, um, which gave them autonomy on the work that they were doing. I ensured that I earner trust with that team as well. And most importantly, I put in a ‘no-blame culture’, um, because my expectation is that everybody’s always acting with the best of intentions and that usually when something is going wrong, there is a mechanism that is missing that would have resolved the issue.
Kovid Batra: But, uh, sorry to interrupt you here. Um, do you think, uh, the reasons for attrition were aligned with these factors in the team where people didn’t have autonomy, uh, there was a blame game happening? Were these the reasons or, uh, the reasons were different? I mean, if you’re comfortable sharing, cool, but otherwise, like we can just move on.
David Archer: No, yeah, I think that in reality there, there was an element of that there, there was a, um, a somewhat, not toxic necessarily culture, but definitely a culture of, um, moving fast just to get things done as opposed to trying to work in the correct manner. And that means that people then did feel blamed. They felt pressured. They felt that they had no autonomy. Every decision was made for them. And so, uh, with more senior staff, especially, you know, looking at an MNA situation where that didn’t change, they didn’t see a future in their career there because they didn’t know where they could possibly move forward into because they had no decision-making or autonomy capability themselves.
Kovid Batra: Makes sense. Got it. Yeah, please go on. Yeah.
David Archer: Sorry, yes. So, um, we’re putting these things in place, giving everybody a growth mindset mentality and ensuring that, um, you know, there was a no-blame culture. There were some changes in personnel as well. Um, I identified a couple of individuals that were detrimental to the team and those sort of things are quite difficult, you know, moving people on who, um, they’re trying their best and I don’t deny that they are, but their way of working is, is detrimental to a team. But with those changes, um, we then move from a 50% regressive attrition to a 5% regressive attrition over the course of 23 and 24, which is a very, very significant change in, um, in attrition. And, uh, we also, at that point in time, were able to start implementing new methodologies of bringing in talent from, from below. So we started partnering with Glasgow University to bring in an internship program. We also took on some of their graduates to ensure that we had, um, for once with a better phrase, new blood in the team to ensure that we’re bringing new ideas in. Um, and then we prepared people through the training programs that they should need.
Kovid Batra: I’m curious about one thing, uh, saying that stopping this culture of blame game, uh, is definitely, uh, good to hear, but what exactly did you do in practice on a daily level or on a weekly level or on every sprint level that impacted and changed this mindset? What, what were the things that you inculcated in the culture?
David Archer: So initially, um, and some people think that this might be a trite point, but, um, I actually put out the policy in front of people. I wrote it down and put it in front of people and gave them a document review session to say, “This is a no-blame culture, and this is what I mean by that.” So that people understood what my meaning was from that. Following that, um, I then did have a conversation with some of the parts of, you know, some people in other parts of the company to say, “Please, reroute your conversations through me. Don’t go directly to engineers. I want to be that, that point of contact going forward so that I can ensure that communication is felt in the right manner and the right capacity.” And then, um, the, the other thing is that we started bringing in things like, um, postmortems or incident response management, um, sessions that, that where we, I was very forceful on ensuring that no names were put into these documents because until that point, people did put other people’s names in, um, and wanted to make sure that it was noted that it was so and so’s fault. Um, and I had to step on that very, very strongly. I was like, this could have been anyone’s fault. It’s just that they happen to be at that mine of code at that point in time. Um, and made that decision, which they did with a good intention. Um, so I had to really step in with the team and every single post mortem, every major decision in that, that area, every sprint where we went through what the team had completed in terms of work and made sure we did pick out individuals in terms of particularly good work that they did, but then stepped very strongly on any hint of trying to blame someone for a problem that had happened and made it very clear to them again that this could have happened to anyone and we need to work together to ensure it can’t happen to anyone ever again.
Kovid Batra: Makes sense. So when, when this, uh, impact started happening, uh, did you see, uh, people from the previous, uh, developers, like who were already the part of Imagine Learning, those were getting retained or, uh, the ones who joined after acquisition from the other company, those developers were also getting retained? How, how did it impact the two groups and how did they like, gel up later on?
David Archer: Both actually. Yeah. So the, the staff who were already here, um, effectively the, the, the drain stopped and there weren’t people leaving anymore that had had, you know, some level of tenure longer than six months, um, at all from that point forward, and new staff that were joining, they were getting integrated with these new teams. I implemented a buddy system so that every new engineer that came in would have somebody that they could work alongside for the first six months and show that they had some, somebody to contact for the whole time that they were, um, getting used to the company. And, uh, I frequently say that as you join a company like this, you are drinking from a fire hose for the first couple of months. There’s a lot of information that comes your way. Um, and so having a buddy there helped there. Um, I added software engineering managers to the team to ensure that there were people who specifically looked after the team, continue to ensure there was a growth mindset to continue to implement the plans that I had, um, to make these teams more stable. Um, and that took a while to find the right people, I will say that. Um, there was also a challenge with integrating the teams from our vendors in, um, international, uh, countries. So we worked with some teams in India and some teams in the Ukraine. Um, and with integrating people from those teams, there was some level of separation, and I think one of the major things we started doing then was getting the people to meet in a more personal manner, bringing them across to our team to actually meet each other face-to-face, um, and realize that these are very talented individuals, just like we are. They’re, they’re no different just because they, you know, live a five and a half hour time zone away and doesn’t mean that they’re any less capable. Um, they just have a different way of working and we can absolutely work with these very talented people. And bringing them into the teams via a buddy, ensuring that they have someone to work with, making sure that the no-blame culture continued, even into our contractors, it took a while, don’t get me wrong. And there were definitely some missteps, um, but it was vital to ensuring that there was team cohesion all the way across.
Kovid Batra: Definitely. And, uh, I’ve also experienced this, uh, when talking to other, uh, engineering leaders that when teams come in, usually it is hard to find space for them to do that impactful work, right? So you, you need to give those people that space in general in the team, which you did. But also at the same time, the kind of work they are picking up, that also becomes a challenge sometimes. So was that a case in your scenario as well? And did you like find a way out there?
David Archer: It was the case here. Um, there definitely was a case of the, the work was predefined, if you like, to some extent by the, the most senior personnel. And so one of the things that we ensured that we did, uh, I worked very closely with our product team to ensure that this happened is that we brought the engineers in a lot sooner. We ensured that this wasn’t just the most senior member of the team, but instead that we worked with different personnel and de-siloing that information from one person to another was extremely important because there were silos of information within our teams. And I made it very clear that if there’s an incident and somebody needs some help, and there’s only one person on the team, um, that is capable of actually working, then, um, we’re going to find ourselves in, in a real problem. Um, and I think people understood that intrinsically because of the knowledge loss that had happened before I started, or just as I was coming on board, um, because they knew that there were people who, you know, knew this part of the code base or this database or how this part of infrastructure worked, and suddenly we didn’t have anybody that had that knowledge. So we now needed to reacquire it. And so, I ensured that the, you know, this comes from an Amazon background, so anybody that, that has worked at this company will know what I’m talking about here, but documentation is key. Ensuring document reviews was extremely important. Um, those are the kind of things, ensuring that we could pass on information from one person to another from one team to another in the most scalable fashion, it does slow you down in delivery, but it speeds you up in the longer term because it enables more people to do a wider range of work without needing to rely on that one person that knows everything.
Kovid Batra: Sure, definitely. I think documentation has been like always on the top of, uh, the priority list itself now whomsoever I’m talking to, because once there are downturns and you face such problems, you realize the importance of it. In the early phase, you are just running, building, not focusing on that piece, but later on, it becomes a matter of priority for sure. And I can totally relate to it. Um, so talking about these people, uh, who have joined in and you’re trying to integrate, uh, they definitely need some level of cultural alignment also, like they are coming from a different background, coming into a new company. Along with that, there might be requirements, you mentioned like skill development, right? So were there any skill development plans that worked out, that worked out here that you implemented? Anything from that end you want to share?
David Archer: Yeah, absolutely. So with joining together our teams of frontend and backend developers, um, that’s obviously going to cause some issues. So some developers are not going to be quite as excited about working in a different area. Um, but I think with knowing that the siloing of information was there and that we had to resolve that as an issue and then ensuring that people who are being brought on via, you know, vendors from international countries and things like that, um, what we started to do was to ensure that we put in, um, pairing sessions with all of our developers. Up until that point, they kind of worked on their own and so, um, I find that working one-to-one with another individual tends to be the fastest way to learn how the things work, work in the same way as, um, a child learns their language from their parents far faster than they ever would from watching TV. Um, although sometimes I do wonder about that myself with my daughter singing baby shark to me 16 times and I don’t think I’ve ever sung that. So let’s see where that goes. Um, but having that one-to-one, um, relationship with the person means that we’re able to ask questions, we’re able to gain that knowledge very quickly. Having the documentation backing that up means that you’ve got a frame of reference to keep going to as well. And then if you keep doing that quite frequently and add in some of the more abstract knowledge sharing sessions, I’m thinking like, um, a ‘launch and learn’ type sessions or lightning talks, as well as having a, a base of, sort of a knowledge base that people can learn from. So, obvious examples of things like Pluralsight or O’Reilly’s library. Um, But we also have our own internal documentation as well where we give people tutorials, we walk people through things, we added in a code review session, we added in a code of the sprint and a session as well for our um, sprint reviews that went out to the whole team and to the rest of the company where we showed that we’re optimizing where we can. And all these things, they didn’t just enable the team to, to become full stack and I will say all of our developers now are full stack. I’d be very surprised if there are any developers I’m working with that are not able to make a switch. But it also built trust with the rest of the company as well and that’s the thing with being a company that has been acquired is that we need to, um, very quickly and very deliberately shout about how well we’re doing as a company so that they can look at what we’re doing and use us, as has frequently been the case recently actually as a best practice, a company that’s doing things well and doing things meaningfully and has that growth mindset. And we start then to have conversations with the wider company, which enables things like a tiger team type session that enables us to widen our scope and have more same company. It’s kind of a spiral at that point in time because you start to increase your scope and with doing that, it means that your team can grow because you know, that they know that thing, that they can trust us to do things effectively. And it also gives, going back to what I said at the beginning, and people more autonomy, then more decision-making capabilities they need to get further out into a company.
Kovid Batra: And in such situations, the opinions that they’re bringing in are more customer-centric. They have more understanding of the business. All those things ultimately add up to a lot of intrinsic incentivization, I would say. That if I’m being heard in the team, being a developer, I feel good about it, right? And all of this is like connected there. So I, it totally makes sense. And I think that’s a very good hack to bringing new, uh, people, new teams into the same, uh, journey where you are already continuing. So, great. I think, uh, with that, we have, uh, come to, uh, the end of this discussion. And in the interest of time, we’ll have to pause here. Uh, really loved talking to you, would love to know more such experiences from you, but it will be in the, maybe in the next episodes. So, David, once again, thanks a lot for your time. Thanks for sharing your experiences. It was great to have you here.
David Archer: Thank you so much and I really appreciate, uh, the time that you’ve taken with me. I hope that this proves useful to at least one person and they can gain something from this. So, thank you.
Kovid Batra: I’m sure it will be. Thank you. Thank you so much. Have a great day ahead.
David Archer: Thank you. Cheers now!
In the first session of the ‘Unlocking Engineering Productivity’ webinar series, host Kovid Batra from Typo welcomes two prominent engineering leaders: Paulo André, CTO of Resquared, and Denis Čahuk, a technical coach and TDD/DDD expert.
They discuss the importance of engineering productivity and share insights about their journeys. Paulo emphasizes the significance of collaboration in software development and the pitfalls of focusing solely on individual productivity metrics. Denis highlights the value of consistent improvement and reliability over individual velocity. Both guests underline the importance of creating clarity and making work visible within teams to enhance productivity. Audience questions address topics such as balancing technical debt with innovation and integrating new tools without disrupting workflows. Overall, the session offers practical strategies for engineering leaders to build effective and cohesive teams.
Kovid Batra: All right. Time to get started. Uh, welcome everyone. Welcome to the first episode, first session of our new, all new webinar series, Unlocking Engineering Productivity. So after the success of our previous webinar The Hows and Whats of DORA, we are even more excited to bring you this webinar series which is totally designed to help the engineering leaders become better, learn more and build successful, impactful dev teams. And today with us, uh, we have two passionate engineering leaders. Uh, I have known them for a while now. They have been super helpful, all the time up for helping us out. So let me start with the introduction. Uh, Paulo, Paulo André, uh, CTO of Resquared, a YC-backed startup. He has been the, he has been ex-engineering leadership coach for Hotjar, and he has, he’s an author of the Hagakure newsletter. So welcome to, welcome to the unlocking, uh, engineering productivity webinar, Paulo.
Paulo André: Thanks for having me. It’s a real pleasure to be here.
Kovid Batra: Great. Uh, then we have Denis. Uh, he’s coming to this for the second time. And, uh, Denis is a tech leadership coach, TDD expert, and author of Crafting Tech Teams. And he’s also a guitar player, a professional gamer. Uh, hi, hi, Denis. Welcome, welcome to the episode.
Denis Čahuk: Hi, thanks for inviting me again. Always a pleasure. And Hey, Paulo, it’s our first time meeting on stage.
Paulo André: Good to meet you, Denis.
Kovid Batra: I think I missed mentioning one thing about Paulo. Like, uh, he is like a very, uh, he’s an avid book reader and a coffee lover, just like me. So on that note, Paulo, uh, which book you’re reading these days?
Paulo André: Oh, that’s a good question. Let, let me pull up my, because I’m always reading a bunch of them at the same time, sort of. So right now, I’m very interested, I wonder why in, you know, geopolitical topics. So I’m reading a lot about, you know, superpowers and how this has played out, uh, in history. I’m also reading a fiction book from an author called David Baldacci. It’s this series that I recommend everyone who likes to read thrillers and stuff like that. It’s called the 6:20 Man. So.
Kovid Batra: Great.
Paulo André: That’s what I’m reading right now.
Kovid Batra: So what’s going to be the next superpower then? Is it, is it, is it China, Russia coming in together or it’s the USA?
Paulo André: I’ll tell you offline. I’ll tell you offline.
Kovid Batra: All right. All right. Let’s get started then. Um, I think before actually we move on to the main section, uh, there is one ritual that we have to follow every time so that our audience gets to know you a little more. Uh, this is my favorite question. So I think I’ll, I’ll start with Paulo, you once again. Uh, you have to tell us something from your childhood or from teenage, uh, that defines you, who you are today. So over to you.
Paulo André: I mean, you already talked about the books. I think the reason why I became such a book lover was because there were a ton of books in my house, even though my parents were not readers. So I don’t know, it was more decorative. But I think more importantly for this conversation, I think the one thing about my childhood was when they gifted me a computer when I was six years old. We’re talking about 88, 89 of the type that you still connected to your big TV in the living room. So that changed my life because it came with an instruction manual that had code listings. Then you could type it in and you can see what happens on the screen and the rest is history. So I think that was definitely the most consequential thing that happened in my childhood when you consider how my life and career has played out.
Kovid Batra: Definitely. Cool. Um, Denis, I think the same question to you, man. Uh, what, what has been that childhood teenage memory that has been defining you today?
Denis Čahuk: Oh, you’re putting me on the spot here. I’ll have to come up with a new story every time I join a new webinar. Uh, no, no, I had a similar experience as Paulo. Um, I have an older brother and our household got our first computer when I was five-six years old, first commodore 64. So I learned how to code before I could read. Uh, I knew, I knew what keys to press so I could load Donald Duck into the, into the TV. Um, yeah, other than that when I, when I got a little bit, you know into the teenage years, I, um, World of Warcraft and playing games online became my passion project when I, when I received access to the internet. Um, so that’s, you know, I played World of Warcraft professionally, semi-professionally for quite a few years, like almost an entire decade, you know, and that, that was sort of parallel with my, with my sort of tech career, because we’re usually doing it in a very large organization, game-wise. Yeah. And that, that, that had a huge influence because it gave me an outlet for my competitiveness.
Kovid Batra: That’s interesting. All right, guys. Thanks. Thanks for sharing this with us. Uh, I think we’ll now move on to the main section and discuss something around which our audience would love to learn from you both. Uh, so let’s, let’s start with the first basic fundamental definition of what productivity, what dev productivity or engineering productivity looks like to you. So Paulo, would you like to take this first? Like, how do you define productivity?
Paulo André: So you start with a very small question, right? Um, you actually start with a million-dollar question. What is productivity? I’m happy to take a stab at it, but I think it’s one of those things that everyone has their own definition. For what it’s worth, when I think about productivity of engineering teams, I cannot decouple it from the purpose of an engineering team. And then ultimately, the way I see it is that an engineering team serves a business and serves the users of that business in case it’s a product company, obviously, um, but any, any kind of company kind of has that as the delivery of value, right? So with that in mind, is this team doing their part in the delivery of value, whatever value is for that business and for those users, right? And so having that sort of frame in mind, I also break it down in my mind, at least, in terms of like winning right now and increasing our capacity to win in the future. So a productive team is not just a team that delivers today, but it’s also a team that is getting better and better at delivering tomorrow, right? And so productivity would be, are we doing what it takes to deliver that value regardless of the output? Um, it is necessary to have output to have results and outcomes, but at the end of the day, how are we contributing to the outcomes rather than to the, um, the just purely to the outputs? And the reason why I bring this up has to do obviously with sometimes you see the obsession about things like story points and you know, all of that stuff that ultimately you can be working a lot, but achieving very little or nothing at all. So, yeah, I would never decouple, um, the delivery of value from how well an engineering team is doing.
Kovid Batra: Perfect. I think very well framed here and the perspective makes a lot of sense. Um, by the way, uh, audience, uh, while we are talking, discussing this EP, please feel free to shoot out all the questions that you have in the comments section. We’ll definitely be taking them at the end of the session. Uh, but it would be great if you could just throw in questions right now. Well, this was an advice from Denis, so I wouldn’t want to forget this. Okay. Uh, I think coming back, Denis, what’s your take on, uh, productivity, engineering productivity, dev productivity?
Denis Čahuk: Well, aPauloal said, that’s a million dollar question. I think, I think coming from a, from like a more analytical perspective, more data-driven perspective, I think we like to use the, the financial analogies, metaphors a lot for things like technical debt and, you know, good story points. It’s all about estimating something, you know, value of something or, or scale of something, scope of something. I think just using two metaphors is very useful for productivity. One is, you know, how risky is the team itself? And risk can come from many different places. It can be their methodologies, their personalities, the age of the company, the maturity of the company. The project can be risky. The timing on the market can be risky, right? So, but there is an inherent risk coming from the team itself. That’s, that’s what I mean. So how risky is it to work with this team in particular? Uh, and the other thing is to what degree does the team reason about, um, “I will produce this output for this outcome.” versus “I need to fill my schedule with activity because this input is demanded of me.” Right? So if I, if I use the four pillars that you probably know from business model canvases for activity, input, output, outcome, um, a productive team would not be measuring productivity per se. They will be more aligned with their business, aligned with their product and focusing on what, which of their outputs can provide what kind of outcomes for the business, right? So it’s not so much about measuring it or discussing it. It’s more about a, you know, are we shifting our mentality far enough into the things that matter, or are we chasing our own tail, essentially, um, protecting our calendars and making sure we didn’t over-promise or under-promise, etc.?
Kovid Batra: Got it. Makes sense.
Paulo André: Can I just add one, one last thing here, because Denis got my, my brain kinda going? Um, just to make the point that I think the industry spends a lot of time thinking about what is productivity and trying to define productivity. I think there is value in really getting clear about what productivity is not. And so I think what both Denis and I are definitely aligned on among other things is that it’s not output. That’s not what productivity is in isolation. So output is necessary, but it is not sufficient. And unfortunately, a lot of these conversations end up being purely about output because it’s easy to measure and because it’s easy to measure, that’s where we stop. And so we need to do the homework and measure what’s hard as well, so we can get to the real insight.
Kovid Batra: No, totally makes sense. I think I relate to this because when I talk to so many engineering leaders and almost all the time this, this comes into discussion, like how exactly they should be doing it. But what, what is becoming more interesting for me is that this million dollar question has suddenly started raising concerns, right? I mean, almost everywhere in like in business, uh, people are measuring productivity in some or the other way, right? But somehow engineering teams have suddenly come into the focus. So this, this perspective of bringing more focus now, why do you think it has come into the picture now?
Paulo André: Is that for me or Denis? Who should go first?
Kovid Batra: Anyone. Maybe Paulo, you can go ahead. No problem.
Paulo André: Okay. So, look. In, in my opinion, I think I was thinking a little bit about this. I think it’s a good question. And I think there’s at least three things, three main things that are kind of conspiring for this renewed focus or double down on engineering productivity specifically. I think on the one hand, it’s what I already mentioned, right? It’s easier to measure engineering than anything else. Um, at least in the product design and engineering world, of course, sales are very easy to measure. Did you close or not? And that sort of thing. But when it comes to product design and engineering, engineering, especially if you focus on outputs is so much easier to measure. And then someone gets a good sense of ROI from that, which may or may not be accurate. But I think that’s one of the things. The other thing is that when times get more lean or things get more difficult and funding kind of dries up, um, then, of course, you need to tighten the belt and where are you going to tighten the belt? And at the end of the day, I always say this to my teams, like, engineering is not more special in any way than any other team in a company. That being said, when it comes to a software company, the engineering team is where the rubber meets the road. In other words, you do absolutely need some degree of engineering team or engineering capacity to translate ideas and designs and so on into actual software. So it’s very easy to kind of just look at it as in, “Oh, engineers are absolutely critical. Everything else, maybe are nice to have.” Or something of that, to that effect, right? And then lastly, I think the so-called Elon Musk effect definitely is a thing. I mean, when someone with that prominence and with, you know, the soapbox that he has, comes in and says, you know, we’re going to focus on engineers and it’s about builders and even Mark Andreessen wrote an article like three years ago or so saying it’s time to build, all of that speaks like engineering, engineering, engineering. Um, and so when you put that all together and how influencible all of us are, but I think especially then founders and CEOs are kind of really attuned to their industry and to investors and so on, and I think there’s this, um, feedback loop where engineering is where it’s at right now, especially the age of AI and so on. So yeah, i’m not surprised that when you put this all together in this day and age, we have what we have in terms of engineering being like the holy grail and the focus.
Kovid Batra: Uh, Denis, you, you have something to add on this?
Denis Čahuk: I mean, when it comes to the timing, I don’t think anything comes to mind, you know, why now? What I can definitely say is that engineering of everything that’s going on is the biggest cost in a, in a large company. I mean, it’s not, not to say that it’s all about salaries or operational expenses, but it is also from a business’s perspective, engineering is, you know, if I put a price to the business being wrong on an experiment, the engineering side of things, the product engineering side of things defines most of that cost, right? So when it comes to experiments, the likelihood of it succeeding or not succeeding, or the how fast you gain feedback to be able to, you know, to, to think of experiment feedback as cashflow, you know, you want the big bet that you do once every three months, or do you want to do a bunch of small bets continuously several times per day? You know, all of that is decided and all of that happens in engineering and it also happens to be the biggest fiscal costs. So it makes sense that, hey, there’s an, you know, there’s a big thing that costs a lot, that is very complex and it’s defining the company. Yeah, of course, business owners would want to measure it. It will be irresponsible not to. It doesn’t mean that it, that productivity from a team’s or an engineer’s, an individual’s perspective is the most sensible thing to measure. But I, you know, I understand the people that would intuitively come to that conclusion.
Kovid Batra: Yeah. I think that makes a lot of sense. And what do you think, like, this should be done that, that is totally, uh, understandable, but when is the right time to start doing this and how one should start it? Because every time our engineering leader is held accountable for a team, whether big or small, there is a point where you have to decide your priorities and think about things that you are going to do, right? So how and when should an engineering leader or an engineering manager for a team should start taking up this journey?
Paulo André: I think Denis can go first on this one.
Denis Čahuk: Well, I would never, you know, I would never start measuring. So I coach teams professionally, you know, they, they reach out to me because something about my communication on LinkedIn or newsletter resonated with them regarding, you know, a very no-nonsense way of how to deal with customers, how to communicate, how to plan, how to not plan, how to, how to bring, you know, that excitement into engineering, that makes engineering very hyperproductive and fun. And then they come to me and ask, well, you know, “I want to measure all these things to see what I can do.” I think that context is always misleading. You know, we don’t just go in, you know, it’s not a speedometer like the, I think the very, very first intuition that people still have from the 90s, from the, from the, like the initial scrum and Kanban, um, modes of thought that, “Oh, I can just put up speedometer on the team and it will have a velocity and it, you know, it will just be a number.” Um, I think that is naive. That is not what measuring is. And that is not the right time ever to measure that. Like that I think is my say. Um, the right time to measure is when you say, “I am improving A or B. I am consciously trying to figure out continuously, consciously trying to figure out what will make my teams better.” So a leader might approach, “Okay. If I introduce this initiative, how can I tell if things are better?” And then you can say, “Well, I’ll eyeball it or I’ll survey the team.” And at a certain point, the eyeballing is too inaccurate or it requires too many disagreeing eyeballs, or, um, you run the risk of a survey fatiguing the team, so it’s just way too many surveys asking boring questions, and when you ask engineers to do repetitive, boring things, they will start giving you nonsense answers, right? So that would be the point where I think measuring makes sense, right? Where you basically take a little bit of subjective opinion out, with the exception of surveys, qualitative surveys, and you introduce a machine that says, “Hey, this is a process.” You know, it’s one computer talking to the other computer, you know, in the case of GitHub and similar, which seems to be the primary vector for measurement. Um, can I just extract some metrics of, you know, what are the characteristics of the machine? It doesn’t tell you how fast or how slow it’s going. Just what are the characteristics? Maybe I can get some insights too and decide whether this was a good idea or a bad idea, or if we’re missing something. But the decision to help your teams improve on some initiative and introducing the initiative comes first. And then you measure if you have no other alternative or if the alternatives are way too fuzzy.
Kovid Batra: Makes sense. Paulo, would you like to add something?
Paulo André: Yeah, I mean, I think my, my perspective on this is not very different from, from Denis. Uh, maybe it comes from a slightly different angle and I’ll explain what I mean. So, at the end of the day, if you want to create an outcome, right? And you want to change customer behavior, you want to create results for the business, you’re going to have to build something. And where I would not start is with the metrics, right? So you asked Kovid, like where, where do we start in this journey? I would say do not start with the metrics because in my mind, the metrics are a source of insight or answers to a set of questions. And so start with the questions, right? Start with the challenges that we, that you have to get to where you want to be, right? And so, coming back to what I was saying, if you want to create value, you’re going to have to build something, typically, most of the time, sometimes it creates value by removing something, but in general, you are building and iterating on your products. And, and so with that in mind, what is going back to first principles? What is the nature of software development? Well, it’s a collaborative effort. Nobody does everything end-to-end by themselves. And so with that in mind, there’s going to be handoffs. There’s going to be collaboration. There’s going to be all, all of that sort of flow, right? Where, where the work goes through a certain, you can see it as a pipeline. And so then when it comes to productivity, to me is, is, you know, from a lean software development perspective is how do we increase the flow? If you think of a Kanban board, how do you go, you know, in a smooth way, as smooth as possible from left to right, from something being ready for development to being shipped in production and creating value for the user and for the company? And so if you see it that way with that mental model, then it becomes like, where is the constraint? What is the bottleneck? And then how do we measure that? How do we get the answers is by measuring. And so when it comes to the DORA metrics that you guys obviously with Typo provide, um, you know, a good, good insight into, and, and other such things, generally cycle time, lead time really allows us to start understanding where’s this getting stuck. And that leads to then conversations around what can we do about that? And ultimately everybody can rally around the idea of how do we increase flow? And so that’s where I would start is what are we trying to do? What is getting in our way? And then let’s look at the data that we have available without going too crazy about that into like, what can we learn and where can we improve and where’s the biggest leverage?
Kovid Batra: Makes sense. I think one, one good point that you brought here is that software development is a collaborative effort, right? And every time when we go about doing that, there are people, there are teams, uh, there are processes, right? Uh, how, how would you define in a situation that whether you should go about measuring, uh, at an individual-level productivity, a developer-level productivity, and, uh, and then when, when we are talking about this collaborative effort, the engineering productivity? So how do you differentiate and how do you make sure that you are measuring things right? And sometimes the terminologies also bring in a lot of confusion. Uh, like, I would never perceive developer productivity to be something, uh, specific to developers. It ultimately boils down to the team. So I would want to hear both of you on this point, like how, how do you differentiate or what’s your perspective on that? When you talk to your team that, okay, this is what we are going to measure, uh, your teams are not taken aback by that, and there is a smooth transition of thought, goals when we are talking about improving the productivity. Uh, Paulo, maybe you could answer that.
Paulo André: I was trying to unmute myself. I was actually gonna.. Um, and then it feels free to kind of like interject at any point with your thinking as well. You know, if I follow up on what I was just saying that this is a team sport, then the unit of value is going to be the team. Are there individual productivity metrics? Yes. Are they insightful? Yes, they can be. But for what end? What can you actually infer from them? What can you learn from them? Personally, as an engineering leader, the way I look at individual productivity metrics is more like a smoke alarm. So, for example, if someone is not pushing code for long periods of time, that’s a question. Like, what’s going on? There might be some very good reasons for that, or maybe this person is struggling and so I’m glad that I saw that in the, in the metrics, right? And then we can have a conversation around it. Again, the individual is necessary, but it’s not sufficient to deliver value. And so I need to focus on the team-level productivity metrics, right? Um, so that’s, that’s kind of like how I disambiguate, if you will, this, these two, like the individual and the team, the team comes first. I look at the individual to understand to what degree is the individual or the individuals serving the team, because it comes back to also questions, obviously, of performance and, and performance reviews and compensation and promotions, like all of that stuff, right? Um, but do I look at the metrics to decide on that? Personally, I don’t. What I do look at is what can I see in the metrics in terms of what this person’s contribution to the team is and for the team to be able to be successful and productive.
Kovid Batra: Got it. Denis, uh, you have something to add here?
Denis Čahuk: It’s, it’s such an interesting topic that sort of has nuances from many different perspectives that my brain just wants to talk about all three at the same time. So I want to sort of approach every, like, do a quick dip into all three areas. First is the business side, right? So, uh, for example, let’s take a, let’s take the examples of baseball and soccer. Um, off, when off season comes for baseball. Baseball is more of an individual sport than soccer, you know, like the individual performance stands out way more than in soccer when everything’s moving all the time. Um, it’s, it’s very difficult to individuate performance in soccer, although you still can and people still do and it’s still very sexy. Um, when it’s off season, people want to decide, okay, which players do we keep? Which players do we trade? Which players do we replace? You know, this is completely normal, and you would want to do this, and you would want to have some kind of metrics, ideally, merit-based metrics of, yeah, this person performed better. Having this person on the team makes the team better. In baseball, this makes perfect sense. In soccer, not so much, but you still have to decide, well, how much do we pay each player? And you can probably tell if you’re following the scene that every soccer player is being, you know, their salary, their, their, um, their contracts are priced individually based on their value to the brand of the team, all the way to public relations, marketing, and yes, performance on, on the field. Even if they’re on the bench all the time, you know, they might have a positive effect on the team as a coach or as a mentor, as a captain. Um, so if you did bring that into that, that’s one aspect. So now bringing it back into software teams, that’s the business side of things. Yes, these decisions have to be made.
Then there’s the other side of things, which is how does the team work? You know, from my perspective, if output or outcomes can be traced back to one individual person, I think there’s something wrong. I think there’s a lot of sort of value left on the table if you can say, “Oh, this thing was done by this one person.” Generally, it’s a team effort and the more complex the problems get, the harder it is, you know, look, look, for example, NASA, um, the Apollo missions. Which one engineer, you know, made the rocket fly? You don’t have an answer to that because it was thousands of people collaborating together. You know, which one person made a movie? Yes, the director or the producer or the main actor, like they are, they stand out when it comes to branding. But there were tens of thousands of people involved, right? So like to, you know, at the end of the day, what matters is the box office. So I think that that’s what it really comes down to, uh, is that yes, generally there will be like a few stars and some smoke alarms, as Paulo mentioned, I really liked that analogy, right? So you’re sort of checking for, hey, is anybody below standard and does anybody sort of stand out? Usually in branding and communication, not in technical skill. Um, and then try to reason about the team as a whole.
And then there’s the third aspect, which is how productive does the individual feel? You know, how productive, if somebody says they’re a senior with seven years of experience, how productive they, do they feel? Do they get to do everything they wanted to in a day? You know, and then keep going up. Does the product owner feel productive or efficient? Or does the leader feel that they’re supporting their teams enough, right? So it also comes down to perception. We saw this recently with the usages and various surveys regarding AI usage and coding assistance, where developers say, “Yeah, it makes me feel amazing because I feel more productive.” But in reality, the outcomes that it produces didn’t change, or it was so insignificant that it was very difficult to measure.
So with those three sort of three angles to consider, I would say, you know, the way to approach measuring and particularly this individual versus team performance, is that it’s a moving target. You sort of need to have a plan for why you’re measuring and what you’re measuring and ideally, once you know that you’re measuring the right things when it comes to the business, it’ll be very difficult, um, to trace it back to an individual. If tracing it back to an individual is very easy, or if that’s an outcome that you’re pursuing, I would say there’s other issues or potential improvements afoot. And again, measuring those might show you that measuring them is a wrong, is a bad idea.
Paulo André: Can I just add one, one quick thing again? Like, this is something that took me a little while to understand for myself and to become intuitive, which is not intuitive at all. Um, but I think it’s an important pitfall to kind of highlight, which is if we incentivize individual behaviors, individual productivity, that can really backfire on the team. And again, I remind you that the team is the unit of value. And so if we incentivize throughput or output from individual developers, how does that hurt the team? It doesn’t sound very intuitive, but if you think about, for example, a very prolific developer that is constantly just taking on more tickets and creating more pull requests, and those pull requests are just piling up because there’s no capacity in the team to review them, the customer is not getting any value on the other side. That work in progress is just in lean terminology. It’s just waste at that point, right? But that developer can be regarded depending on how you look at it as a very productive developer, but is it? Or could it be that that developer could be testing something? Or could it be that that developer is helping doing code reviews and so on and so forth, right? So again, the team and individual productivity can lead to wildly different results. And sometimes you have teams that are very unproductive despite having very productive developers in them, but they are looking at the wrong, sort of, in my opinion, wrong definition of what productivity is and where it comes from, and what the unit of value is, like I said, it’s the team.
Kovid Batra: Yeah.
Denis Čahuk: Can I jump in quickly, Kovid?
Kovid Batra: Yeah.
Denis Čahuk: There’s something I’ve always said. Um, it’s very unintuitive, and I can give you a complete example from coaching, that it throws leaders off-guard every time I suggest it, and it ends up being a very positive outcome. I always ask them, you know, “What are you using to assign tickets? Are you assigning them?” And they say, “Yes, we use Jira.” Or something equivalent. And I tell them, And I ask them, “Well, have you considered not assigning the tickets?” Right? And, well, who should own it? And I say, “Well, it’s in the team’s backlog. The team owns it. Stop assigning an individual.” Right? And they’re like, and they’re usually taken aback. It’s like, “What do you mean? Like, it won’t get done if I don’t assign it.” No, it’s in the team’s backlog, of course it’ll get done. Right? And if not, if they can’t decide who will do it, then that’s a conversation they should have, and then keep it unassigned. Or, alternatively, use some kind of software that allows multiple people to be assigned. But you don’t need to, because the moment you start, you know, Jira, for example, had like a full activity log, so I comment on it, you comment on it, you review, I review, we merge, I merge, I ask a question. You have a full paper trail of everybody who was involved. Why would you need an owner, right? So this idea of an owner is, again, going back to lean activities and talking about handoffs, right? So I hand it off to you, you’re now the owner, and you’ll hand it off to somebody else. Well, and, but having many handoffs is an anti-pattern in itself, usually in most contexts. Actually the better idea would be, how can we have less people than we have? How can we have less handoffs then we have people? If there are seven people in the pipeline, there shouldn’t be seven handoffs, you know, how can we have just one deliverable, just one thing to assign and seven people working on it? That would be the best sort of positive outcome because then you don’t cap, you know, how much money you can put around a problem because that allows you to sort of scale your efforts in intensity, not just in parallelism. Um, and usually that parallelism comes at a very, very steep cost.
Paulo André: Yeah.
Denis Čahuk: Um, so incentivizing methods to make individual work activity untraceable can unintuitively have, and usually does, drastic and immediate positive, positive benefits for the team. Also, if the team is lacking in psychological safety, this will make it immediately sort of washed over them and they’ll have to have some like really rough conversations in the first week and then things drastically start improving. At least that’s my experience.
Paulo André: Yeah. And the handoff piece is a very interesting one. I’ll be very quick, uh, Kovid. When we think about the perspective of a piece of work, a work package, a ticket or whatever, it’s either being actively worked on or it’s waiting for someone to do something about it, right? And if we measure these things, what we, what we realize, and it’s the same thing if you go to the airport and we think about how often, how much time are we actually spending on something like checking in or boarding the plane versus waiting at some of the stages, the waiting time is typically way more than the active time. And so that waiting time is waste as well. That’s an opportunity. Those delays, we can think about how can we reduce those and the more handoffs we have in the process, the more opportunity for delay creeps in, right? So it’s, it’s a very different way of looking at things. But sometimes when I say estimates and so on, estimates is all about like active time. It’s how long it’s going to take, but we don’t realize that nothing is done individually, and because of the handoffs, you cannot possibly predict the waiting times. So the best that you can do is to reduce the handoffs, so you have less opportunity for those delays to creep in.
Kovid Batra: Totally. I think to summarize both of your points, I would have understood is that making those smoke alarms ready at individual level and at process level also ready so that you are able to understand those gaps if there is something falling apart. But at the end of the day, if you’re measuring productivity for a team, it has to be a collaborative team-level thing that you’re looking at and looking at value delivery. So I think it’s a very interesting thing. Uh, I think there’s a lot of learning for us when we are working at Typo that we need to think more on the angle of how we bring in those pointers, those metrics which work as those smoke alarms, rather than just looking at individual efficiency or productivity and defining that for somebody. Uh, I think that, that makes a lot of sense. All right. I think we are into a very interesting conversation and I would like to ask one of you to tell us something from your experience. So let’s start with you, Denis. Um, like you have been coaching a lot of teams, right? And, uh, there, there are instances where you deal with large-scale teams, small teams, startups, right? There are different combinations. Anything that you feel is an interesting experience to share here about how a team approached solving a particular problem or a bottleneck in their team that was slowing them down, basically like not having the right impact that they wanted to, and what did they do about it? And then how, how they arrived to the goal that they were looking at?
Denis Čahuk: Well, I can, I can list many. I’ll, I’ll focus on two. One is, generally the team knows what’s the problem. Generally, the team knows already, hey, yeah, we don’t have enough tests, or, ah, yeah, we keep missing deadlines, or our relationship with stakeholders is very bad, and they just communicate with us through, you know, strict roadmaps and strict deadlines and strict expectations. Um, that’s a problem to be solved. That’s not, you know, it doesn’t have to be that way. So if you know what the problem is, there’s no point measuring, because there’s no, there’s no further insight to be gained that, yeah, this is a problem, but hey, let’s get distracted with this insight. No, like, you know what the problem is, you can just decide what to do, and then if you need help along the way, maybe measurements would help. Or maybe measurements on an organizational level would help, not, not just engineering. Um, or you bring on a coach to sort of help you, you know, gain clarity. That’s one aspect. If you know what the problem is, you don’t need to measure. Usually people ask me, Denis, what should I measure? Should I introduce DORA metrics? And I usually tell them, Oh, what’s the main problem? What’s the problem this week? Oh yeah, a lot of PRs are waiting around and we’re not writing enough tests. Okay, that’s actionable. Like, that’s enough. Like, do you want more? Like, but do you need a bigger problem? Because then you just, you know, spend a lot of time looking for a problem that you wish was bigger than that so that you wouldn’t have to, right, because that’s just resistance that just either your ego or trying to play it safe or trying to put it into the next quarter when maybe there’s less stress and right, there isn’t. That’s one aspect.
The other aspect, you know, this idea of.. How did you phrase it? An approach that works that aren’t generally approaches that work. You know, I always say that everything we do is nowadays basically a proxy to eliminating handoffs, right? Getting the engineers very close to the customer and, um, you know, getting closer to continuous delivery. Continuous integration at the very minimum, but continuous delivery, right? So that when software is ready, it’s releasable on demand, and there isn’t like this long waiting that Paolo mentioned earlier, right? Like this is just a general form of waste. Um, but potentially something that both of these cases handle unintuitively that I like to bring in as a sort of more qualitative metric is, um, the reliability of the team. You know, we like to measure the reliability of systems and the whole Scrum movement introduced this idea of velocity, and I like to bring in this idea of, let’s say you want to be on time as a leader. Um, I’m interested in proving the theory that, hey, if you want to be on time, you probably need to be on time every week, and in order to be on time on the week, you probably need to be on time every day. So if you don’t know what an on-time day looks like, there’s no point planning roadmaps and saying that deadlines are a primary focus. Maybe the team should be planning in smaller batches, not with, not trying to chase higher accuracy in something very large. And what I usually use as a proxy metric is just to say, how risky is your word? Right, so how reliable is your promise? Uh, and we don’t measure how fast the team is moving. What I like to measure with them is say, okay, when do you think this will be done? They say Friday. Okay. If you’re right, Monday needs to look like this. Tuesday needs to look like this. Let me just try to reverse engineer it from that. It’s very basic. And then I’m trying to figure out how many days or hours or minutes into a plan they’re off-track. I don’t care about velocity. So no proxy metrics. I’m just interested if they create like a three month roadmap, how many hours into the three-month roadmap are they off-course? Because that’s what I’m interested in, because that’s actionable. Okay. You said three months from now, this is done. One month from now, there’ll be a milestone. But yesterday you said that today something would be done. It’s not done. Maybe we should work on that. Maybe we should really get down to a much smaller batch size and just try to make the communication structures around the team building stuff more reliable. That would de-stress a lot of people at the same time and sort of reduce anxiety. And maybe the problem is that you have a building-to-deploying nuance and maybe that’s also part of the problem. It usually is. And then there might be a planning-to-building nuance that also needs to be addressed. And then we basically come down to this idea of continuous delivery extreme programming, you know, let’s plan a little bit. Let’s Build a little bit. Let’s test it. Let’s test our assumptions. And behind the scenes once we do that for a few days, once we have evidence that we’re reliable, then let’s plan the next two weeks. Only when we have shown evidence of the team understands what a reliable work week for them looks like. If they’ve never experienced that and they’ve been chasing their own tail deadline after deadline, um, there’s not much you can do with such a team. And a lot of people just need a wake up call to see that, “Hey, you know what? I actually don’t know how to plan. You know, I don’t know how to estimate.” And that’s okay. As long as you have this intention of trying to improve or trying to look for alternatives, not to become better.
Kovid Batra: I think my next question would be, uh, like when you’re talking about, uh, this aspect in the teams, how do you exactly go about having that conversations or having that, that visibility on a day-to-day basis? Like most, most of the things that you mentioned were qualitative in nature, right, as, as you mentioned, right? So how, how do you exactly go about doing that? Like if someone wants to understand and deploy the same thought-process in a team, how should they actually do and measure it?
Denis Čahuk: Well, from a leader’s perspective, it’s very simple, you know, because I can just ask them, “Hey, is it done? Is it on anybody’s mind today?” Um, and they might tell me, “Yeah, it’s done, but not merged.” Or, “It’s waiting for review, but it’s done, but it’s kind of waiting for review.” And then that might be one possible answer. Um, it doesn’t need to be qualitative in the sense that I need a human for that. What, you know, what I’m looking for is precision. Like, is it, is it definitively done? Was there an increment? You know, did we test our assumptions? What, is there a releasable artifact? Is it possible to gain feedback on this?
Kovid Batra: Got it.
Denis Čahuk: Did you, did you talk to the team to establish if we deploy this as soon as possible, what question do we want to answer? Like what feedback, what kind of product feedback are we looking for? Or are we just blindly going through a list of features? Like, are we making improvements to our software or is somebody else who is not an engineer? Maybe that’s the problem, right? So it’s very difficult to pinpoint to like one generic thing. But a team that I worked with, the best proxy for these kinds of improvements from the leader was how ready they felt to be interrupted and get course correction. Right? Because the main thing with priorities in a team is that, you know, the main unintuitive thing is that you need to make bets and you need to reduce the cost of you being wrong, right? So the business is making bets on the market, on the product and working with this particular team with these particular individuals. The team is making bets with implementation details to a choice of technology, ratio between keeping the lights on, technical debt and new features, support and communication styles, you know, change of technology maybe. Um, so you need to just make sure that you’re playing with the market. The upside will take care of itself. You just need to make sure that you’re not making stupid mistakes that cost you a lot, either in opportunity or actual fiscal value. Um, but once you got that out of the way, you know, sky’s the limit. A lot of engineers think that we’re expensive. It’s large projects. We gotta get it right the first time. So they try to measure how often they got it right the first time, which is silly. And usually that’s where most measurements go. Are we getting it right the first time? We need to do this to get it right the first time, right? So failure is not an option. Whereas my mantra would be, no, you are going to fail. Just make sure it happens sooner rather than later and with as little intensity as possible so that we can act on it while there’s still time.
Kovid Batra: Got it. Makes sense. Makes sense. All right. Uh, Paulo, I think, uh, we are just running short on time, but I really want to ask this question to you as well, uh, just like Denis has shared something from his experience and that’s really interesting to know like how qualitatively you can measure or see things every time and solve for those. In your experience, um, you have, uh, recently joined this startup as, as a CTO, right? So maybe how does it feel like a new CTO and what things come to your mind when you would think of improving productivity in your teams and building a team which is impactful?
Paulo André: Yeah, I joined this company as a CTO six months ago. It’s been quite a journey and it’s, so it’s very fresh in my mind. And of course, every team is different and every starting point is different and so on, but ultimately, I think the pattern that i’ve always seen in my career is that some things are just not connected and the work is not visible and there’s lack of clarity about what’s value, uh, about what are the goals, what are the priorities, how do we make decisions, like all of that stuff, right? And so, every hour that I’ve been putting into this role with my team so far in these six months has been really either, either about creating clarity or about developing competence to the extent that I can. And so the development of competence is, is basically every opportunity is an opportunity to learn, both for myself and for anyone else in the team. And I can try to leverage my coaching skills, um, in making those learning conversations effective. And then the creation of clarity in my role, I happen to lead both product and engineering, so I cannot blame somebody else for lack of clarity on what the product should be or where it should go. It’s, it’s on me. And I’ve been working with some really good people in terms of what is our product strategy? What do we focus on and not focus on? Why this and not that? What are we trying to accomplish? What are those outcomes that we were talking about that we want to drive, right? So all of that is hard to answer. It’s deceptively difficult to answer. But at the end of the day, it’s what’s most important for that engineering productivity piece, because if you have an engineering team that is, you know, doing wasted work left and right, or things are not connected, and they’re just like, not clear about what they should be doing in the first place, that doesn’t sound like the ingredients for a productive team, right? And ultimately, the product side needs to answer to a large extent those, those difficult questions. So obviously, I could go into a lot of specific details about how we’re doing this and that. I don’t think we have at least today the time for that. Maybe we can do a deep dive later. But ultimately, it’s all about how do I create clarity for everyone and for myself in the first place so I can give it and then also developing the competence of the people that we do have. And that’s the increasing the capacity to win that I was talking about earlier. And if we make good progress on these two things, then we can give a lot of control and autonomy to people because they understand what we’re going for, and they have the skills to actually deliver on that, right? That’s, that’s the holy grail. And that’s motivation, right? That’s happiness. That’s a moment at work that is so elusive. But at the end of the day, I think that’s what we’re, we’re working towards.
Kovid Batra: Totally. I’ll still, uh, want to deep dive a little bit in any one of those, uh, instances, like if you have something to share from last six months where you actually, when prioritized this transparency for the team to be in, uh, how exactly you executed it, a small instance or a small maybe a meeting that you have had and..
Paulo André: Very simple example. Very simple example. Um, one of the things that I immediately noticed in the team is that a lot of the work that was happening was just not visible. It was not on a ticket. It was not on a notion document. It was nowhere, right? Because knowledge was in people’s minds, and so there was a lot of like, gaps of understanding and things that would just take a lot longer than they think they should. And so I already mentioned my bias towards lean software development. What does that mean? First and foremost, make the work visible because if you don’t make the work visible, you have no chance of optimizing the process and getting better at what you do. So I’ve been hammering this idea of making the work visible. I think my team is sick of me pointing to is there a ticket for it? Did you create a ticket for it? Where is the ticket? And so on. Because the way we work with Jira, that’s, that’s where the work becomes visible. And I think now we got to a point where this just became second nature, uh, for all of us. So that would be one example where it’s like very basic fundamental thing. Don’t need to measure anything. Don’t need complicated KPIs and whatnot. What we do need is to make the work visible so we can reason about it together. That’s it.
Kovid Batra: Makes sense. And anything which you found very unique about this team and you took a unique approach to solve it? Any, anything of that sort?
Paulo André: Unique? Oh, that’s a, that’s a really good question. I mean, everyone is different, but at the end of the day, we’re all human beings trying to work together towards something that is somehow meaningful. And so from that perspective, frankly, no real surprises. I think what I’m, if anything, I’m really grateful for the team to be so driven to do better, even if, you know, we lack the experience in many areas that we need to level up. Um, but as far as something being really unique, I think maybe a challenge our team has to really deal with tough technical challenges is around email deliverability, for example, that’s not necessarily unique. Of course, there’s other companies that need to debate themselves with the exact same problems. But in my career, that’s not a particular topic that I have to deal with a lot. And I’m seeing, like, just how complex and how tricky it is to get to get right. Um, and it’s an always evolving sort of landscape for those that are familiar with that type of stuff. So, yeah, not a good, not a good answer to your question. There’s nothing unique. It’s just that, yeah, what’s unique is the team. The team is unique. There’s no other team like this one, like these individuals doing this thing right here, right now in this company in 2024.
Kovid Batra: Great, man. I think your team is gonna love you for that. All right. I think there will be a lot more questions from the audience now. We’ll dedicate some time to that. We’ll take a minute’s break here and we’ll just gather all the questions that the audience has put in. Uh, though we are running a little out of time, is it okay for you guys to like extend for 5–10 minutes? Perfect. All right. Uh, so we’ll take a break for a minute and, uh, just gather the questions here.
All right. I think time to get started with the questions. Uh, I see a lot of them. Uh, let’s take them one by one on the screen and start answering those. Okay. So the first one is coming from, uh, Kshitij Mohan. That’s, uh, the CEO of Typo. Hi, Kshitij. Uh, everything is going good here. Uh, so this is for Denis. Uh, as someone working at the intersection of engineering and cloud technologies, how do you prioritize between technical debt and innovation?
Denis Čahuk: It’s a great question. Hey, Kshitij. Well, I think first of all, I need to know whether it’s actual debt or whether it’s just crap code. You know, like it’s crappy implementation is not an excuse for debt, right? So for you to have debt, there are three things needed to have happen. At some point in the past, you had two choices, A or B. And you made a choice without, with insufficient knowledge. And later on, you figured out that either something in the market changed or timing changed, or we gained more knowledge, and we realized that we, that now the other one is better, for whatever reason. I mean, it’s unnecessary that it was wrong at the time, but we now have more information that we need to go from A to B. Uh, originally we picked A. Now you also need to know how much it costs to go from A to B and how much you stand to gain or trade if you decide not to do that, right? So maybe going from A to B now cost you two months and ten thousand euros and doing it later next year, maybe it’s going to double the cost and add an extra week. That’s technical debt. Like the, the nature of that decision, that’s technical debt. If you, if you made the wrong decision in, in the past and you know it was the wrong decision and now you’re trying to explore whether you want to do something about it, that’s not technical debt. That’s just, you know, that’s you seeking for excuses to not do a rewrite. So it’s, first of all you need to identify is it debt. If it is debt, you know the cost, you know the trade-off, you know, you know, you can either put it on a timeline or you can measure some kind of business outcome with it. So that’s one side.
On the, on the innovation side, you need to decide what is innovation exactly? You know, is it like an investment? Is it a capital expense where I am building a laboratory and we’re going to innovate with new technologies? And then once we build them, we will find, um, sort of private market applications for them or B2B applications for them. Like, is it that kind of innovation? Or is innovation a umbrella term for new features, right? Cause, cause that’s operational. That’s much closer to operational expense, operational expense, right? So it’s just something you do continuously and you deliver continuously, and that innovation that you do can continuously feature development will also produce new debt. So once you’ve got these two things, these two sides figured out, then it’s a very simple decision. How much debt can you live with? How fast are you creating new debt compared to how fast you’re paying it off? And what can you do to get rid of all the non-debt, all the crap, essentially? That’s it, you know. Then you just make sure that you balance out those activities and that you consistently do them. It isn’t just, oh yeah. We do innovation for nine months and then we pay off debt. That usually doesn’t go very well.
Kovid Batra: I think this is coming from a very personal pain point. Now we’re really moving towards the AI wave and building things at Typo. That’s where Kshitij is coming from. Uh, totally. I think, thanks, thanks, Denis. I think we’ll move on to the next question now. Uh, that’s from, uh, Madhurima. Yeah. Hey Paulo, this one’s for you. Uh, which metric do you think is often overlooked in engineering teams but has significant impact on long-term success?
Paulo André: Yeah, that’s a great question. I’m going to, I’m going to give a bit of a cheeky answer and I’m going to say, disclaimer, this is not a metric that I track with, we track with, with my team, and it’s also not, I don’t know, a very scientific way or concrete way of measuring it. However, to the question, what is overlooked in engineering teams and has significant long-term impact, or success, on long-term success, that’s what I would call ‘mean time to clarity’. How quickly do we get clear on where we need to be and how do we get there? Right? And we don’t have all the answers upfront. We need to, as Denis mentioned earlier, experiment and iterate and learn and we’ll get smarter, hopefully, as we go along, as we learn. But how quickly we get to that clarity in every which way that we’re working. I think that’s, that’s the one that is most important because it has implications, right? Um, if we don’t look at that and if we don’t care about that, are we doing what it takes to create that clarity in the first place? And if that’s not the case, the waste is going to be abundant, right? So that’s the one I would say as an engineering leader, how do I get for myself all the clarity that I need to be able to pass it along to others and create that sense that we know where we’re going and what we don’t know, we have the means to learn and to keep getting smarter.
Kovid Batra: Cool. Great answer there. Uh, let’s move on to the next one. I think this one is again for Paulo. Yeah.
Paulo André: Okay, so you know what? Maybe this is going to be a bit, uh, I don’t know what to call it, but considering that I don’t think the most important things are gonna change in the next five years, um, AI notwithstanding, and what are the most important things? It’s still a bunch of people working together and depending on each other to achieve common goals. We may have less people with more artificial intelligence, but I don’t think we’re anywhere near the point where the artificial intelligence just does everything, including the thinking for itself. And so with that in mind, it’s still back to what I said earlier, um, in the session. It’s really about how is the work flowing from left to right? And I don’t know of a better, um, sort of set of metrics than the DORA metrics for this, particularly cycle time and deployment frequency and that sort of stuff that is more about the actual flow. Um, but like, you know, let’s not get into the DORA metrics. I’m sure the audience here already knows a lot about it, but that’s, that’s, I think, what, what is the most important, um, and will continue to be critical in the next five years, um, that’s, that’s basically it.
Kovid Batra: Cool. Moving on. All right. That’s again for, oh, this one, Denis. How do you ensure cloud solutions remain secure and scalable while addressing ever-changing customer demands?
Denis Čahuk: Well, there’s two parts to that question. You know, one is security, the other one is ever-changing customer demands. I think, you know, security will be a sort of an expression of the standard, or at least some degree of sensible defaults within the team. So the better question would be, what do engineers need to not have to consciously, to not have to constantly and consciously and deliberately think about security, right? So do they have support by, are they supported by a security expert? Do they have platform engineering teams that are supporting with security initiatives, right? So if there’s a product team that’s focusing on product, support them so that they also don’t have to become an expert in security, cause that’s where all the problems start, where you basically have a team of five and they need to wear 20 hats and they start triaging the hats and making trade-offs in security, you know. And usually, usually large teams that are overwhelmed, love doing privacy or security trade-offs because they don’t have skin in the game. The business has skin in the game, right? And then when you individuate incentive to such a degree that it becomes dysfunctional, um, security usually doesn’t bode well. Um, at least not till there’s some incident or maybe some security review or some inspection, et cetera.
So give the teams what they need. If they’re not a security expert, provide them support. Um, and the same thing with scalability. Scalability is also something that can benefit more from tighter collaboration, more so than security. Um, so just make sure that the team is able to express itself as a team through pair programming or having more immediate conversations rather than just, you know, asynchronous code review conversations or stand up conversations way at the end of the cycle. At the end of the cycle when the code is written and it’s going into merging or QA, it’s too late, the code is written, right? So you want the preempt. That solution is being created by the team being able to express itself as a team rather than just a group of individuals, being the individual goals.
Kovid Batra: Cool. I think, uh, we have a few more questions, but running way out of time now. Uh, maybe we can take one more last, last question and then we can wrap it up.
Paulo André: Sounds good. Okay, so this one is for me, right? How do I approach, uh, integrating new tools and frameworks into engineering workflows without disrupting productivity? That, that final piece is interesting. I think it also starts with how we frame this type of stuff. So there is a cost to making improvements. I don’t think we can have our cake and eat it, too, necessarily. And it’s just part of the job, and it’s part of what we do. And so, um, you know, for example, if you take the time to have a regular retrospective with your team, right, is that going to impact productivity? I mean, you could be coding for an extra hour every two weeks. It’s certainly going to have some impact. But then it also depends on what is the outcome of that retrospective, and how much does it impact the long-term, um, you know, capacity to win of the team. So with that in mind, what I would say is that the most important thing I find is that you don’t just, again, as an engineering leader, as an engineering manager, you just don’t, you don’t just download certain practices and tools and frameworks on the teams. You always start from what are we trying to solve here and why does it matter and get that shared understanding to the point where we’re all looking at the same problem roughly the same way. We can then disagree on solutions, but we agree that this is a problem worth solving right now, and we’re gonna go and do that. And so the tools and the frameworks are kind of like downstream from that. Okay, now what do we need to gain the inside? Oh, now what do we need to solve the problem? Then we can talk about those things. Okay? So as an example, one thing I’m working on now with my team, I mentioned this earlier, I believe is like, uh, a bit of a full-on product delivery, product discovery and delivery, um, process, right? That includes a product strategy, um, that shouldn’t change that much that often. And then there are a lot of tools and frameworks that we can use. Tools, we use three different types of projects in Jira, for example. And when it comes to frameworks, we’re starting to adopt something called opportunity solution trees, which is just a fancy way of saying what outcomes are we trying to generate, what opportunities do we see to, to get there and what are the solutions that can capitalize on these opportunities, right? That sort of thing. But it all starts with we need to gain clarity about where we’re gonna go as a business and as a product and everything kind of comes downstream from that, right? So I think if you take the time and this is where I’ll leave it. If you take the time and I think you should to start there and to do this groundwork and create this shared context and understanding with your teams, everything else downstream becomes so much easier because you can connect it to the problem that you’re solving. Otherwise, you’re just talking solutions for problems that most people will think they are inexistent or they just look completely different, right? And this takes work, this takes time, this takes energy, this takes attention, takes all of those things. But frankly, if you ask me, that’s the work of leadership. That’s the work of management.
Kovid Batra: Great. Well said, Paulo. I think Denis has a point to add here.
Denis Čahuk: Yeah, I had a conversation this week with one of the CEOs and founders of one of Ljubljana, Slovenia’s biggest agencies, because we were talking about this. And, and, and they asked me this question, they said, “Denis, you don’t have a catalog. Like, what do you do? Like, how do, how does working with you look like? Do we do a workshop or something?” And I said, and I asked, “Do you want to do a workshop? And, and I saw on their face, they said, “Well..” I told them, “Yes, exactly, exactly. That’s why I don’t have a catalog because, because, because the workshops are this, I will show you how a great team works, right? I will give you all of this fancy storytelling about how productive teams work, and then you’re like, “Great. Cool. But we’re not that and we can’t have that in our team.” So great, now I’d go away because I’m, because I’d feel demoralized, right? Like that’s not a good way of approaching working with that team. I, I always tell them, “Look, I don’t know what will help you. You probably also don’t know what will help you. We need to figure it out together. But generally, what’s more important than figuring out how to help you is to figure out how much are you willing to invest consistently in improvement? Because maybe I teach you something and you only have 10 minutes. That’s the wrong way about it, right? I need to ask you how much time do you have consistently every week 15 minutes? Okay, then when I need to teach you something that you can put in practice every 15 minutes Otherwise, I’m robbing you of your time. Otherwise, I’m wasting your time. If you have three hour retrospectives and we’re putting nothing into action, I’m wasting your time, right? So we need to personally figure out like what is consistent for you? What kind of improvement, how intense do you want it? How do you know if you’re making progress?”
Those two are the most important things, because I always come to these kinds of questions about new tools and frameworks because people love asking me about, “Hey, Denis. Can you do a TDD workshop?”, “Denis, can you do a domain-driven design workshop?”, “Denis, can you help us do event storming?” And I always say, “If what you need is that one workshop, it’s not going to solve any problems because I’m all about consistent improvement, about learning, about growing your team, about, you know, investing into the people, not about changing, you know, changing some label or some other label.” And I always come back to the mantra of what can you do consistently starting this week so that the product and the team is much better six months from now? That’s the big question. That’s, that should be the focus. Cause if you need to learn something, you know, go do a certification that takes you a year to perform correctly, and then you need to renew it every year. That’s nonsense. This week, what can we do this week? Start this week, apply this week, and then consistently grow and apply every single week for the next six months. That would be huge. Or you can go to a conference and send everybody on vacation and pretend the workshop was very productive. Thank you.
Kovid Batra: Perfect. I think that brings us to the end of this episode. Uh, I think the next episode that we’re going to have would be in the next year, which is not very far. So, before we depart, uh, I think I would like to wish the audience, uh, a very Happy New Year in advance, a Merry Christmas in advance. And to both of our panelists also, Paulo, Denis, thank you, thank you so much, uh, for taking out time. It was really great talking to you. I would love to have you both again here. talking more in depth about different topics and how to make teams better. But for today, that’s our time. Anything that you would like to, that you guys would want to add, please feel free. All right. Yeah, please go ahead.
Denis Čahuk: Thanks for inviting us.
Paulo André: Yeah, exactly. From my side, I was just going to say that thanks for having us. Thanks also to the audience that has put up with us and also asked very good questions, to be honest. Unfortunately, we couldn’t get to a few more that are still there that I think are very good ones. Um, but yeah, looking forward to coming back and deep diving into, into some of the topics that we talked about here.
Kovid Batra: Great. Definitely.
Denis Čahuk: And thank you for Kovid for inviting us and for introducing us to each other and to everybody backstage and at Typo for, they’re probably doing a lot of annoying groundwork at the background that makes all of this so much more enjoyable. Thank you.
Kovid Batra: All right, guys. Thank you. Thank you so much. Have a great evening ahead. Bye!
In this episode of the groCTO Podcast, host Kovid Batra is joined by Ben Matthews, Senior Director of Engineering at Stack Overflow, with over 20 years of experience in engineering and leadership.
Ben shares his career journey from QA to engineering leadership, shedding light on the importance of creating organizations that function collaboratively rather than just executing tasks independently. He underscores the need for cross-functional teamwork and reducing friction points to build cohesive and successful teams. Ben also addresses the challenges and opportunities presented by the AI revolution, emphasizing Stack Overflow’s strategy to embrace and leverage AI innovations. Additionally, he offers valuable advice for onboarding junior developers, such as involving them in code reviews and emphasizing documentation.
Throughout the discussion, Ben highlights essential leadership principles like advocating for oneself and one’s team, managing team dynamics, and setting clear expectations. He provides practical tips for engineering managers on creating value, addressing organizational weaknesses, and fostering a supportive environment for continuous growth and learning. The episode wraps up with Ben sharing his thoughts on maintaining a vision and connecting it with new technological developments.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of groCTO podcast. And today with us, we have an exciting guest. This is Senior Director from Stack Overflow with 20 plus years of experience in engineering and leadership, Ben Matthews. Hey, Ben.
Ben Matthews: Thanks for having me. I just wanted to cover you there.
Kovid Batra: All right. So I think, uh, today, uh, we’re going to talk about, uh, Ben’s journey and how he moved from a QA to an engineering leadership position at Stack Overflow. And here we are like primarily interested in knowing how they are scaling tech and teams at Stack Overflow. So we are totally excited about this episode, man. But before we jump on to the main section, uh, there is a small ritual that we have. So you have to introduce yourself that your LinkedIn profile doesn’t tell you about.
Ben Matthews: Okay. Uh, well, that’s not in my LinkedIn profile. Well, um, So I am the Senior Director of Engineering at Stack Overflow for our community products, but something about myself that’s not, uh, I, I love to snowboard. I’m a huge fan of calzones and I’m a total movie nerd. Is that what you had in mind?
Kovid Batra: Yeah, of course. I mean, uh, I would love you to talk a little more, even if there is something that you want to share that tells about you in terms of who you are. Maybe something from your childhood, from your teenage, anything, anything of that sort that you think defines you who you are today.
Ben Matthews: Uh, yeah. Um, yeah, that’s a great question. Of, of really just getting into tech in general, a lot of that did come from some natural inclinations, uh, that have kind of always been there. For the longest time I didn’t think I would really enjoy technology. There was the stereotype of the person who sat in the corner, just coded all day and never talked to people like kind of the Hollywood impression of what a developer was. That didn’t seem very appealing. I like interacting with people. I like actually making some tangible differences, but once I actually dug into it and actually saw like there was that click that a lot of people have the first time that you compile and run your code and you’re like, wait, I made that happen. I made that change and that’s what kind of the addiction started. But even after that, I still loved interacting with people. Um, and I think we were very lucky. I came at a time where the industry was starting to change, where it was no longer people working in isolation. This, this is a team sport now, like developers have to work together. You’re working with other departments. And that’s actually kind of what I really enjoy. I love, I love interacting with people and building things that people like to work with. So, um, that’s really kind of what sings to me about tech is it’s a quick way to build things that other people can interact with and bring value to them. And I get to do it together with another team of people who, who enjoy it as well. So I would say like, that’s kind of what gets me out of bed in the morning of trying to help people do more with their day and build something that helped them.
Kovid Batra: Great, great. Thanks for that intro. Um, I think, uh, I’m really interested to start with the part, uh, with your current role and responsibility at Stack Overflow. Uh, like, uh, like how, uh, you, you started here or in fact, like, we can go a little back also, like from where you actually started. So wherever you are comfortable, like, uh, you can just begin. Yeah.
Ben Matthews: Yeah. Um, so the, the full journey has its interesting and boring parts altogether, but how it really started was out of school, I still had that feeling of I didn’t know if development was for me because of the perception I had. But I actually got my first job as a quality assurance engineer for a small startup. Uh, now the best part about working at a small company is that you’re forced to wear multiple hats. That, you know, you don’t just have one role. I was also doing tech support. And then I also looked at some of the code. I helped to do some small code reviews. And from there, I thought like, you know, I would love to take a shot at doing this development thing. Maybe, maybe I would like it more. Um, and then I did, I kind of got that high of like, I pushed this live and people are using it and you know, that’s mine and they’re enjoying it and that kind of became addictive to me, of where I really liked being a developer. So I really leaned into that. Um, and then enjoying that startup and having a great mentor there, uh, that really kind of, I set a foundation for how I view, how I want to develop and the things I want to build, uh, of really taking the point of view of how I’m creating value for the users. And my, and my next role, I actually worked for a marketing agency doing digital marketing. Um, and that took that up to 11 of the number of things I had to interact with and be prepared for. Like every week or every couple weeks I had a new project, a new customer, a new problem to solve, and I had to use usually with code, sometimes not with code. We’re solving these problems and creating value and getting that whole high level view of working on databases, kind of doing QA for other people doing development front and back, and I got to see what I really like to do. But I also got an insight into how organizations work, how pieces of a company work together, pieces of a development team work together, and how that really creates value for, for users and customers, which in the end, that’s what we’re here to do is to create value for people.
Um, so my next role after that is my first foray into leadership. I went to another digital agency leading a small development team. And, um, it had its highs and lows. There was definitely a learning curve there. Um, there, there was that ache of not being able to develop of, of enabling other people to develop.
Kovid Batra: Yeah. And this was, and this was a startup or this was an organization like, uh, medium or large-scale organization?
Ben Matthews: This was a medium-sized organization, much more, uh, founded, they, they were trying to start up a new tech department, so I had a little freedom in setting some standards. But it was a mature organization. Um, they kind of knew what they wanted to accomplish. Um, so like then I had a big learning curve, excuse me, of what it’s like to work there, how do I lead people, how do I set expectations for them, um, how do I advocate for myself and others, and, you know, I had plenty of missteps that like looking back now, there’s a bunch of times I wish I could go back and say, “Nope, this is totally the wrong direction. Your instincts are wrong. You need to learn and grow.” Um, and then after that I went to a couple of other organizations of doing leadership there, some very, very large, some smaller, getting that whole view of kind of ins and outs and the stacks of what I would like to be. Then I landed here on Stack which has been a terrific fit for me of, of getting to work directly with users and, uh, and knowing that the people I’m leading are customers, of Stack Overflow just as much as they are employees here, which is very satisfying. We really feel like we’re helping people. I get to have a big impact on a very large application and, um, there’s still a lot of freedom for me to, to execute in the vision. Working with the other leaders here has been a joy as well, since we’re kind of like-minded, which I think is very important for people looking for a place to land. Uh, I know in a lot of interviews, you rarely get to interact with people who will be your peers, but when you do, like really see how well do you bounce off of each other, um, are you all alike? Cause that’s not great. Or are you all different? That’s not great either. You want to have like a little bit of friction there so you can create great ideas. And I think that’s what we have at Stack and it’s been wonderful.
Kovid Batra: No, I think that’s great. But, uh, one question here. Like, um, you were very, uh, passionate about when you told how you started your journey, uh, with the, with the startup, you got an exposure, uh, from the business level to, uh, product teams to developers, and that really opened your mind. Um, would you recommend this for anyone who is beginning their journey in, in, in tech, like, uh, would this be a recommended way of going about how you, uh, set your foundation?
Ben Matthews: Yeah, that’s a great question. I think a lot of people are going to have very different journeys. Um, that I think, you know, one thing that really stuck out to me actually just recently talking to someone when I was, I was at a panel just this past weekend and the variety of journeys that people took of where they started. I think one of the most fascinating ones was someone who was not in tech at all. They’ve been a teacher for 15 years, teaching parts of computer science and design, never professionally worked on one. And now they’re breaking into it now and having a lot of success. Um, I mean, I think my advice to people is like, like your journey is not right or wrong, whatever you’re trying to get to, I think there’s plenty of ways to get to it. What I would say that you do want to focus on though, is that you keep challenging yourself of what I thought I would be working on now is certainly not, uh, what I’m actually working on today, uh, even, whether, I think that’s at all levels, whether at senior, uh, executive, down to like junior engineer, uh, from year to year, the technology landscape changes. How we organize people and execute on that changes. Um, so whatever that journey is, whatever you think it’s going to be, I’m 99 percent sure it’s going to be different than what you envisioned and you have to be prepared to shift that way and keep learning and challenging yourself and it’ll be uncomfortable but that, that’s part of the journey.
Kovid Batra: Yeah, I think that’s the way to go, actually. Then that’s the area when you learn the maximum I think. Uh, so yeah, totally agree with that. Uh, when, uh, when you reflect back, when you see your journey from a QA to a Senior Director at Stack Overflow, I’m curious to know, like, do you know what is that quality in you, uh, that made you stand out and grow to such a profile in, in a, in a reputed organization?
Ben Matthews: Yeah, I think, um, I had a great mentor that pointed out a lot of things that weren’t obvious to me. Um, and I think being a developer, um, I think sometimes for, for us being a people leader is it doesn’t come as naturally sometimes because we tend to think more functionally, which isn’t a bad thing. But there’s some things that at least for me, it didn’t jump out, obviously. I remember one great piece of feedback that took me from just a team manager to get me into a higher level piece was really advocating for yourself. Uh, that didn’t come naturally to me. And I don’t think that comes naturally to a lot of people in our industry. Um, some like to just label it as bragging or see it as bragging, but if you’re not being proud of your successes, other people won’t know they’re there. But it’s not even just for you, but you should be bragging and, and communicating the successes of your team, communicating the successes of your organization. That’s a big part of letting people know of what’s worked, what hasn’t. So one that you can keep doing it. But also other people can emulate it, emulate it and other people in your organization can see you there. There needs to be a profile there. You need to be visible to be a leader. Uh, and I separate that from manager. Being a manager, you don’t necessarily have to be visible. You, there’s very good managers that don’t like to be in the limelight. They’re still supporting their people and moving things forward. But if you’re going to be a leader and set an example and set hard expectations of the vision of where things are going to go, you need to be visible and part of that is advocating and communicating more broadly.
Kovid Batra: Sure. Makes sense. Okay, coming back to your, your current, uh, roles and responsibilities at Stack Overflow. I’m sure working with developers, uh, who know, uh, what the product is about and they are themselves the users. What is that, uh, one thing that you really, uh, abide by as a principle for leading your teams? How, how you’re leading it differently at Stack Overflow, making things successful, scalable, robust?
Ben Matthews: Yeah. Um, and that’s a great question. Cause every organization is different, I’ve had to tackle this problem in different ways at different places. At Stack, I’ve been very fortunate that, uh, there’s already a very talented group of people here that I’ve been able to expand on and keep growing. Um, people tend to be very passionate about the project already, the project and products that we build. That’s a great benefit to have as well. You’re not really trying to talk people into the vision of Stack Overflow, that they were users before there were customers. So that, that was great. But, um, but with that also comes like a different way of how do you leverage the most out of people given this hand? Um, and I know it’s partially a cliché, but with that vision that’s already there with already talented people, um, kind of the steps of making sure you’re setting clear expectations for your folks, setting that vision very loudly, broadly, and clearly to them, um, and then making sure they have all the resources they need to do that. Sometimes it’s time, sometimes it’s, it’s some money or equipment. And then lastly, kind of getting out of their way and removing all the roadblocks. Those three steps are kind of the big parts that I think are general rule of thumb, but, um, given that a lot of other friction points were out of the way, I could really lean into that.
A great example was, uh, I had a team that, uh, was trying to work on a brand new product that, uh, no, it didn’t quite work out before, but we were going to give it another try. We were starting over. And looking at some of the things that went well and what didn’t, it was honestly just a clear lack of vision was their problem. They kept changing directions often. And I was talking to product of like, “Hey, what went wrong?” And they had their own internal struggles. We had our struggles and just aligning that saying like, “Hey, this is going to be a little bit more broad. We’re specifically trying to accomplish this. How do we do it?” And from a bottom-up approach, they set the goals, they set what they think the milestone should be, and that was so much more successful. Um, like that formula that doesn’t work everywhere, but it really thrives here at Stack of like, “Hey, what do you think? How is the best way to execute this?” And we tweak it, we manage it, we keep it on the rails. But once they started moving into it, um, it actually launched and became very successful. So that’s another way of like, kind of reading your team, reading the other stakeholders and, and leveraging their strengths.
Kovid Batra: But what I feel is that, uh, it’s great. Like this approach works at, uh, Stack, but usually what I felt is that when you go with the bottom-up approach, uh, there is an imbalance, uh, like developers are usually inclined towards taking care of the infra, managing the tech debt and not really intuitively prioritizing your, uh, customer needs and requirements, even though they relate to it at times, at least in case of Stack, I can say that. But still there is a, there is a bias in the developer to make the code better before looking at the customer side of it. So how, how do you take care of that?
Ben Matthews: That’s a, that’s a great point. Um, and just to be clear to other developers listening, I love that instinct if you have it, it’s so valuable that you want to leave code better than you found it. But, uh, to what your point, I think that goes back to setting those clear expectations again of, “Hey, like this is what we’re going to accomplish. This is how we need to do it. Um, if we can address tech debt along the way, you need to justify that. I give you the freedom to justify that. But in the end, I, I’m setting these goals. This is what has to happen by then and I’m happy to support you and what we need to get there.” Um, and then also sharing advice and, and, and you know, learning where the minds are on some of those paths. Uh, some people have experience in making these mistakes like I have. I’ve, uh, tried to say, “Well, we could also do this and then also do this and then also do our goal.” And then we’ve taken on too much, and we’re, you know, we’re trying to do too many things at once that we can’t execute.
So you’re right in that. Just kind of not giving any clear direction or expectations, things can kind of go off the rails and what they want to work on isn’t always what we need to focus on. I think there’s a balance there. But, uh, yeah, I mean, setting those expectations is a key part to those three steps, I would say arguably the most important part. If they don’t know which way they’re supposed to be aiming for, they can’t execute on it.
Kovid Batra: Makes sense. Okay, um, next thing that I want to know is, uh, in the last few, few, not actually, actually few years, it’s just been a year or two when the AI wave has like taken over the industry, right? And everyone’s rushing. Um, I’m sure there was a huge impact on the user base, but maybe I’m wrong, on the user base of Stack because people go there to see code, uh, libraries and like code which is there. Now, uh, ChatGPT and tools like that are really helping developers do like automated code. Uh, how you have, uh, taken up with that and what’s your new strategy? I mean, of course you can say everything here, but I would love to know, like how it has been absorbed in the team now.
Ben Matthews: Now, um, I think for the most part, we’ve kind of worn our strategy on our sleeve. Our, our CEO and Chief Product Officer and our CTO have talked about this a bit of, I mean, Stack is, is there to help educate and empower technologists of the world. This is a new tool that’s part of the landscape now and there are a lot of companies that are concerned about it or feel like it’s a doomsday. Um, we’re embracing it. It’s a new way for information to get in and out of people’s hands. Uh, and this is something we were going to try to be a part of. I think we’ve made some great steps of leveraging AI, uh, we’re trying to build some partnerships with people to kind of get a hand on the wheel to make sure that like this is going in the right direction. But, um, there’s technical revolutions every couple years, and this is another one. Uh, and how Stack fits into it is we’re still going to try to provide that value to folks and AI is a new part of it. Uh, we’re building new products that leverage AI. Um, we actually have a couple that are hopefully going to be launching soon that try to improve the experience for users on the site, leveraging AI. We’re going to try to find new ways for people to interact with AI to know that Stack Overflow is a part of what that experience is and to kind of create a cycle there. Um, But it’s changed how people work. But I think Stack Overflow is still a big part of that equation. Uh, we are a big knowledge repository, uh, like along with Reddit or, or news articles, like all of these things need to be there to even power AI. That, that’s sort of the cycle. Like, um, that has to go there. Without human beings, without a community generating content, AI is pretty powerless. But, um, so there has to be a way for us to keep that feedback loop going. And we’re excited that of all the opportunities to be a part of that and find new ways to keep educating people.
Kovid Batra: Definitely. I think that’s a very good point, actually. Like, without humans feeding that information, at least right now AI is not at that stage that it can generate things on its own. It’s the community that would always be driving things at the end. So I also believe in that fact. My question, uh, a follow-up question on that is that when such kind of, uh, big changes happen, how, how your teams are taking it? Like, at Stack, how people are embracing it, particularly developers? I’m just saying that if there are new products that we are going to work on or new tech that we are going to build, how people are embracing it, how fast they are adopting to the new requirements and the new thought process which the company’s adopting?
Ben Matthews: Uh, through the context of AI or just in general?
Kovid Batra: Just, just in the context of AI.
Ben Matthews: Oh yeah. Um, well, in a fun way, there’s been a wide range of opinions on how for us to embrace or to try to channel the AI capabilities that are now very pervasive in the industry. Um, um, so first part of it starts with a lot of that we’re trying to gather as much data and information we can. Again, we have a good user base. So we’re able to interact with them and ask them questions. We’re looking at behavior changes. And so from there, we try to make a data informed decision to our teams of like, “Hey, this is what we’re seeing. So this is what we’re going to try.” Um, I mean, the beauty of data is there’s a bunch of ways to interpret it and our developers are no different. They have some thoughts on, on the best ways to go about it. But I think this also goes to a general leadership technique is you’re never going to get unanimous consent on an idea. If that’s what your requirement is, you’re never going to move forward. What you do have to get is people to at least agree that this is worth trying or like understand that I might be wrong. And a lot of people feel like this is the best way, so we’ll give it a shot. Uh, and that’s something I’ve been proud of to be able to achieve at Stack. It’s something that is very important for a leader of saying, “Hey, I know you don’t agree, but I need you to roll along with me on this. I understand your point. You’ve been heard, but this is the decision we’re making.” Um, a lot of people agree with the idea. Some don’t, but trying to get the enthusiasm and I think also connecting the dots on those ideas with the larger picture. I think that’s also something people miss a lot during these revolutions of if you start out with like vision A. And then something big happens and now you have vision B, um, you still have to connect the dots in like, “Hey, we’re still trying to, to like provide value the same way. We’re still the same company. We’re in this new thing that you’re doing. This dot still connects to what we want to do. There’s still a path there. We’re not like totally pivoting to block chain or something like that. It’s not a huge change for us.” So I think that also motivates people like we’re still trying to build the same vision, the same power for the company. We’re just doing it in a different way. And what you’re doing is still really creating value. I think that’s a big part for leaders to, to keep people motivated.
Kovid Batra: Makes sense. When it comes to, uh, bringing developers on board and nurturing them, I think the biggest challenge that I have always heard from managers, particularly is, uh, getting these new-age, uh, junior developers and the fresh ones coming into the picture. Um, any thoughts, any techniques that you have used to, uh, bring these people on board, nurture them well, and so that they can contribute and create that impact?
Ben Matthews: Yeah. Uh, onboarding people is a huge thing that I try to give the other managers that work for me that are bringing on new team members. Um, uh, I mean, a big part of it, it goes back to empowerment, but I think a lot of it is also the same challenges we’ve had I think for decades, of me even having my own Computer Science degree. In my first development job, there was a huge gap of what I learned in school versus what I’m doing day-to-day as an actual developer. Uh, as far as I can tell, that hasn’t really changed that much. People come in from bootcamps or not. Uh, funny we’ve had a really good experience of people that don’t have formal degrees coming in, who have just been coding their whole time. They tend to actually have an easier time working within a team. That’s not to disparage any Computer Science degree, it’s still very valuable, but it’s just to highlight the gap between what you actually do and what they’ve been training. A great example is, um, of what we try to get junior engineers to really focus on initially, it’s like just doing code reviews. That is a huge part of what we do in modern development. It’s a great way for you to understand the code base, understand how your team works, understand like kind of the ins and outs and where some of the scary parts of the code are. And, um, and even though that can be intimidating, the best thing I think you can do in a code review is just ask questions of like, “Hey, I see you’re doing this. This doesn’t make sense to me. Can you explain why?” And after time, even a senior engineer will read them and be like, “You know what? That is kind of confusing. Why did we do it that way? Let me..” And they’ll even update their PR. I think that’s one of the best tools to get a junior engineer up to speed is just like get them in the code and reviewing it.
Um, the other part of kind of the unsung hero of all of software development that never gets enough love is just documentation, of having them go through some of the pieces of the product, commenting and documenting how things work. That, one, it helps onboard other people, but two, that, that forces them to have an understanding of how parts of the code work. Uh, and then from there at their own pace, here at Stack, we, we try to have people push code to production on day one. Uh, we find something small for them to do, work them through the whole build pipeline process so they can see how it works and like, kind of get that scary part of the way. Like something you wrote is now in production on Stack Overflow in front of hundreds of millions of people. Congratulations! But let’s just get that part out of the way. Um, but then how they can actually understand the code and keep building things, take on new tickets, work with product, size, refinement, all of that, we just ease them into that in their own pace, but keeping them exposed to that code through documentation and PRs really shortens the learning curve.
Kovid Batra: Cool. Makes sense. I think, uh, most of the things, uh, that I have seen, uh, working out for the developers, for, uh, the, the teams that are working well, the managers play a really, really good role there. Like the team managers who are leading them play a very good role there. So before we like end this discussion, I would love for you, uh, to give some parting advice to the engineering managers who are leading such teams, uh, who are looking forward to growing in their career also, uh, that would be helpful for them. Yeah.
Ben Matthews: Yeah. I, I, I, uh, I would say three big points that were big for me from that mentor. One, I’ve already spoke on of advocating for yourself. And, um, and for you, your team and your people, that’s a big part of getting visibility to, to try to grow, to show that you’re being successful. And, and, and honestly, just helping your other peers be successful. It’s a great way for people to see that you’re good at what you do. Another thing that, that I think people could focus on is building an organization that functions and not just executes. Those are kind of two different things, though they sound similar. For I can have a front end team that is great at pumping out front end code or building a new front end framework, and that’s valuable. They’re executing. But they have to work in concert with our back end team or DBA team, with product to align things, getting those things to work together, that’s an organization that functions. And though it may seem like you might be slowing down one to get them to work in tandem or in line with another one, um, that’s actually what’s really going to make your organization successful. If you can show that you have teams working together, reducing friction points and actually building things as one unit, that shows you’re being a good leader, you’re setting a clear vision and you’re, you’re creating the most value you can out of that organization. Um, and last I would say is, um, really identifying friction points or slowdowns in your organization, owning them and setting a plan on how to tackle them. There I had a natural inclination as I was moving up to hide my weaknesses, like to hide what was not going well in my organization. Um, and because of that, I wasn’t able to get feedback from my fellow leaders, from my manager or help. Um, but I would say if you have a problem that you’re tackling, own it and be like, “Hey, this is what’s going on. This is a problem I’m having here. So I’m going to address it.” And welcome any thoughts, but that’s another success story to share that you can tackle problems and things that are going wrong and also advocate for those. Uh, show that you can address problems and keep improving and making things better.
Uh, those three things I think have really helped me move forward in my career of kind of that mindset has made my organizations better, made my people better and let people know that, um, you know, I’m there to try to create the most value I can in the organization.
Kovid Batra: Makes sense. Thank you, Ben. Thank you so much for such a, such a great session, uh, and such great advice. Uh, for today, uh, in the interest of time, we’ll have to stop here, but we would love to know more of your, uh, stories and experiences, maybe on another episode. It was great to have you today here.
Ben Matthews: Thank you, Kovid. It was great to be here.
In this episode of the groCTO Podcast, host Kovid Batra engages in a comprehensive discussion with Geoffrey Teale, the Principal Product Engineer at Upvest, who brings over 25 years of engineering and leadership experience.
The episode begins with Geoffrey's role at Upvest, where he has transitioned from Head of Developer Experience to Principal Product Engineer, emphasizing a holistic approach to improving both developer experience and engineering standards across the organization. Upvest's business model as a financial infrastructure company providing investment banking services through APIs is also examined. Geoffrey underscores the multifaceted engineering requirements, including security, performance, and reliability, essential for meeting regulatory standards and customer expectations. The discussion further delves into the significance of product thinking for internal teams, highlighting the challenges and strategies of building platforms that resonate with developers' needs while competing with external solutions.
Throughout the episode, Geoffrey offers valuable insights into the decision-making processes, the importance of simplicity in early-phase startups, and the crucial role of documentation in fostering team cohesion and efficient communication. Geoffrey also shares his personal interests outside work, including his passion for music, open-source projects, and low-carbon footprint computing, providing a holistic view of his professional and personal journey.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of groCTO Podcast. Today with us, we have a very special guest who has great expertise in managing developer experience at small scale and large scale organizations. He is currently the Principal Engineer at Upvestm, and has almost 25 plus years of experience in engineering and leadership. Welcome to the show, Geoffrey. Great to have you here.
Geoffrey Teale: Great to be here. Thank you.
Kovid Batra: So Geoffrey, I think, uh, today's theme is more around improving the developer experience, bringing the product thinking while building the platform teams, the platform. Uh, and you, you have been, uh, doing all this from quite some time now, like at Upvest and previous organizations that you've worked with, but at your current company, uh, like Upvest, first of all, we would like to know what kind of a business you're into, what does Upvest do, and let's then deep dive into how engineering is, uh, getting streamlined there according to the business.
Geoffrey Teale: Yeah. So, um, Upvest is a financial infrastructure company. Um, we provide, uh, essentially investment banking services, a complete, uh, solution for building investment banking experiences, uh, for, for client organizations. So we're business to business to customer. We provide our services via an API and client organizations, uh, names that you'd heard of people like Revolut and N26 build their client-facing applications using our backend services to provide that complete investment experience, um, currently within the European Union. Um, but, uh, we'll be expanding out from there shortly.
Kovid Batra: Great. Great. So I think, uh, when you talk about investment banking and supporting the companies with APIs, what kind of engineering is required here? Is it like more, uh, secure-oriented, secure-focused, or is it more like delivering on time? Or is it more like, uh, making things very very robust? How do you see it right now in your organization?
Geoffrey Teale: Well, yeah, I mean, I think in the space that we're in the, the answer unfortunately is all of the above, right? So all those things are our requirements. It has to be secure. It has to meet the, uh, the regulatory standards that we, we have in our industry. Um, it has to be performant enough for our customers who are scaling out to quite large scales, quite large numbers of customers. Um, has to be reliable. Um, so there's a lot of uh, uh, how would I say that? Pressure, uh, to perform well and to make sure that things are done to the highest possible standard in order to deliver for our customers. And, uh, if we don't do that, then, then, well, the customers won't trust us. If they don't trust us, then we wouldn't be where we are today. So, uh, yeah.
Kovid Batra: No, I totally get that. Uh, so talking more about you now, like, what's your current role in the organization? And even before that, tell us something about yourself which the LinkedIn doesn't know. Uh, I think the audience would love to know you a little bit more. Uh, let's start from there. Uh, maybe things that you do to unwind or your hobbies or you're passionate about anything else apart from your job that you're doing?
Geoffrey Teale: Oh, well, um, so, I'm, I'm quite old now. I have a family. I have two daughters, a dog, a cat, fish, quail. Keep quail in the garden. Uh, and that occupies most of my time outside of work. Actually my passions outside of work were always um, music. So I play guitar, and actually technology itself. So outside of work, I'm involved and have been involved in, in open source and free software for, for longer than I've been working. And, uh, I have a particular interest in, in low carbon footprint computing that I pursue outside of, out of work.
Kovid Batra: That's really amazing. So, um, like when you say low carbon, uh, cloud computing, what exactly are you doing to do that?
Geoffrey Teale: Oh, not specifically cloud computing, but that would be involved. So yeah, there's, there's multiple streams to this. So one thing is about using, um, low power platforms, things like RISC-V. Um, the other is about streamlining of software to make it more efficient so we can look into lots of different, uh, topics there about operating systems, tools, programming languages, how they, uh, how they perform. Um, sort of reversing a trend, uh, that's been going on for as long as I've been in computing, which is that we use more and more power, both in terms of computing resource, but also actual electricity for the network, um, to deliver more and more functionality, but we're also programming more and more abstracted ways with more and more layers, which means that we're actually sort of getting less, uh, less bang for buck, if you, if you like, than we used to. So, uh, trying to reverse those trends a little bit.
Kovid Batra: Perfect. Perfect. All right. That's really interesting. Thanks for that quick, uh, cute little intro. Uh, and, uh, now moving on to your work, like we were talking about your experience and your specialization in DevEx, right, improving the developer experience in teams. So what's your current, uh, role, responsibility that comes with, uh, within Upvest? Uh, and what are those interesting initiatives that you have, you're working on?
Geoffrey Teale: Yeah. So I've actually just changed roles at Upvest. I've been at Upvest for a little bit over two years now, and the first two years I spent as the Head of Developer Experience. So running a tribe with a specific responsibility for client-facing developer experience. Um, now I've switched into a Principal Engineering role, which means that I have, um, a scope now which is across the whole of our engineering department, uh, with a, yeah, a view for improving experience and improving standards and quality of engineering internally as well. So, um, a slight shift in role, but my, my previous five years before, uh, Upvest, were all in, uh, internal development experience. So I think, um, quite a lot of that skill, um, coming into play in the new role which um, yeah, in terms of challenges actually, we're just at the very beginning of what we're doing on that side. So, um, early challenges are actually about identifying what problems do exist inside the company and where we can improve and how we can make ourselves ready for the next phase of the company's lifetime. So, um, I think some of those topics would be quite familiar to any company that's relatively modern in terms of its developer practices. If you're using microservices, um, there's this aspect of Conway's law, which is to say that your organizational structure starts to follow the program structure and vice versa. And, um, in that sense, you can easily get into this world where teams have autonomy, which is wonderful, but they can be, um, sort of pushed into working in a, in a siloized fashion, which can be very efficient within the team, but then you have to worry about cohesion within the organization and about making sure that people are doing the right things, uh, to, to make the services work together, in terms of design, in terms of the technology that we develop there. So that bridges a lot into this world of developer experience, into platform drives, I think you mentioned already, and about the way in which you think about your internal development, uh, as opposed to just what you do for customers.
Kovid Batra: I agree. I mean, uh, as you said, like when the teams are siloed, they might be thinking they are efficient within themselves. And that's mostly the use case, the case. But when it comes to integrating different pieces together, that cohesion has to fall in. What is the biggest challenge you have seen, uh, in, in the teams in the last few years of your experience that prevents this cohesion? And what is it that works the best to bring in this cohesion in the teams?
Geoffrey Teale: Yeah. So I think there's, there's, there's a lot of factors there. The, the, the, the biggest one I think is pressure, right? So teams in most companies have customers that they're working for, they have pressure to get things done, and that tends to make you focus on the problem in front of you, rather than the bigger picture, right? So, um, dealing, dealing with that and reinforcing the message to engineers that it's actually okay to do good engineering and to worry about the other people, um, is a big part of that. I've always said, actually, that in developer experience, a big part of what you have to do, the first thing you have to do is actually teach people about why developer experience is important. And, uh, one of those reasons is actually sort of saying, you know, promoting good behavior within engineering teams themselves and saying, we only succeed together. We only do that when we make the situation for ourselves that allows us to engineer well. And when we sort of step away from good practice and rush, rush, um, that maybe works for a short period of time. But, uh, in the long term that actually creates a situation where there's a lot of mess and you have to deal with, uh, getting past, we talk about factors like technical debt. There's a lot of things that you have to get past before you can actually get on and do the productive things that you want to do. Um, so teaching organizations and engineers to think that way is, uh, is, uh, I think a big, uh, a big part of the work that has to be done, finding ways to then take that message and put it into a package that is acceptable to people outside of engineering so that they understand why this is a priority and why it should be worked on is, I think, probably the second biggest part of that as well.
Kovid Batra: Makes sense. I think, uh, most of the, so is it like a behavioral challenge, uh, where, uh, developers and team members really don't like the fact that they have to work in cohesion with the teams? Or is it more like the organizational structure that put people into a certain kind of mindset and then they start growing with that and that becomes a problem in the later phase of the organization? What, what you have seen, uh, from your experience?
Geoffrey Teale: Yeah. So I mean, I think growth is a big part of this. So, um, I mean, I've, I've worked with a number of startups. I've also worked in much bigger organizations. And what happens in that transition is that you move from a small tight-knit group of people who sort of inherently have this very good interpersonal communication, they all know what's going on with the company as a whole, and they build trust between them. And that way, this, this early stage organization works very well, and even though you might be working on disparate tasks, you always have some kind of cohesion there. You know what to do. And if something comes up that affects all of you, it's very easy to identify the people that you need to talk to and find a solution for it. Then as you grow, you start to have this situation where you start to take domains and say, okay, this particular part of, of what we do now belongs in a team, it has a leader and this piece over here goes over there. And that still works quite well up into a certain scale, right? But after time in an organization, several things happen. Okay, so your priorities drift apart, right? You no longer have such good understanding of the common goal. You tend to start prioritizing your work within those departments. So you can have some, some tension between those goals. It's not always clear that Department A should be working together with Department B on the same priority. You also have natural staff turnover. So those people who are there at the beginning, they start to leave, some of them, at least, and these trust relationships break down, the communication channels break down. And the third factor is that new people coming into the organization, they haven't got these relationships, they haven't got this experience. They usually don't have, uh, the position to, to have influence over things on such a large scale. So they get an expectation of these people that they're going to be effective across the organization in the way that people who've been there a long time are, and it tends not to happen. And if you haven't set up for that, if you haven't built the support systems for that and the internal processes and tooling for that, then that communication stops happening in the way that it was happening before.
So all of those things create pressure to, to siloes, then you put it on the pressure of growth and customers and, and it just, um, uh, ossifies in that state.
Kovid Batra: Totally. Totally. And I think, um, talking about the customers, uh, last time when we were discussing, uh, you very beautifully put across this point of bringing that product thinking, not just for the products that you're building for the customer, but when you're building it for the teams. And I, what I feel is that, the people who are working on the platform teams have come across this situation more than anyone else in the team as a developer, where they have to put in that thought of product thinking for the people within the team. So what, what, what, uh, from where does this philosophy come? How you have fitted it into, uh, how platform teams should be built? Just tell us something about that.
Geoffrey Teale: Yeah. So this is something I talk about a little bit when I do presentations, uh, about developer experience. And one of the points that I make actually, particularly for platform teams, but any kind of internal team that's serving other internal teams is that you have to think about yourself, not as a mandatory piece that the company will always support and say, "You must use this, this platform that we have." Because I have direct experience, not in my current company, but in previous, uh, in previous employers where a lot of investment has been made into making a platform, but no thought really was given to this kind of developer experience, or actually even the idea of selling the platform internally, right? It was just an assumption that people would have to use it and so they would use it. And that creates a different set of forces than you'll find elsewhere. And, and people start to ignore the fact that, you know, if you've got a cloud platform in this case, um, there is competition, right? Every day as an engineer, you run into people out there working in the wide world, working for, for companies, the Amazons, AWS of this world, as your Google, they're all producing cloud platform tools. They're all promoting their cloud native development environments with their own reasons for doing that. But they expend a lot of money developing those things, developing them to a very high standard and a lot of money promoting and marketing those things. And it doesn't take very much when we talk just now about trust breaking down, the cohesion between teams breaking down. It doesn't take very much for a platform to start looking like less of a solution and more of a problem if it's taking you a long time to get things done, if you can't find out how to do things, if you, um, you have bad experiences with deployment. This all turns that product into an internal problem.
Kovid Batra: In context of an internal problem for the teams.
Geoffrey Teale: Yeah, and in that context, and this is what I, what I've seen, when you then either have someone coming in from outside with experience with another, a product that you could use, or you get this kind of marketing push and sales push from one of these big companies saying, "Hey, look at this, this platform that we've got that you could just buy into." um, it, it puts you in direct competition and you can lose that, that, right? So I have seen whole divisions of a, of a very large company switch away from the internal platform to using cloud native development, right, on, on a particular platform. Now there are downsides for that. There are all sorts of things that they didn't realize they would have to do that they end up having to do. But once they've made the decision, that battle is lost. And I think that's a really key topic to understand that you are in competition, even though you're an internal team, you are in competition with other people, and you have to do some of the things that they do to convince the people in your organization that what you're doing is beneficial, that it's, it's, it's useful, and it's better in some very distinct way than what they would get off the shelf from, from somewhere else.
Kovid Batra: Got it. Got it. So, when, uh, whenever the teams are making this decision, let's, let's take something, build a platform, what are those nitty gritties that one should be taking care of? Like, either people can go with off the shelf solutions, right? And then they start building. What, what should be the mindset, what should be the decision-making mindset, I must say, uh, for, for this kind of a process when they have to go through?
Geoffrey Teale: So I think, um, uh, we within Upvest, follow a very, um, uh, prescribed is not the right word, but we have a, we have a process for how we think about things, and I think that's actually a very useful example of how to think about any technical project, right? So we start with this 'why' question and the 'why' question is really important. We talk about product thinking. Um, this is, you know, who are we doing this for and what are the business outcomes that we want to achieve? And that's where we have to start from, right? So we define that very, very clearly because, and this is a really important part, there's no value, uh, in anybody within the organization saying, "Let's go and build a platform." For example, if that doesn't deliver what the company needs. So you have to have clarity about this. What is the best way to build this? I mean, nobody builds a platform, well not nobody, but very few people build a platform in the cloud starting from scratch. Most people are taking some existing solution, be that a cloud native solution from a big public cloud, or be that Kubernetes or Cloud Foundry. People take these tools and they wrap them up in their own processes, their own software tools around it to package them up as a, uh, a nice application platform for, for development to happen, right? So why do you do that? What, what purpose are you, are you serving in doing this? How will this bring your business forward? And if you can't answer those questions, then you probably should never even start the project, right? That's, that's my, my view. And if you can't continuously keep those, um, ideas in mind and repeat them back, right? Repeat them back in terms of what are we delivering? What do we measure up against to the, to the, to the company? Then again, you're not doing a very good job of, of, of communicating why that product exists. If you can't think of a reason why your platform delivers more to your company and the people working in your company than one of the off the shelf solutions, then what are you for, right? That's the fundamental question.
So we start there, we think about those things well before we even start talking about solution space and, and, um, you know, what kind of technology we're going to use, how we're going to build that. That's the first lesson.
Kovid Batra: Makes sense. A follow-up question on that. Uh, let's say a team is let's say 20-30 folks right now, okay? I'm talking about an engineering team, uh, who are not like super-funded right now or not in a very profit making business. This comes with a cost, right? You will have to deploy resources. You will have to invest time and effort, right? So is it a good idea according to you to have shared resources for such an initiative or it doesn't work out that way? You need to have dedicated resources, uh, working on this project separately or how, how do you contemplate that?
Geoffrey Teale: My experience of early-phase startups is that people have to be multitaskers and they have to work on multiple things to make it work, right? It just doesn't make sense in the early phase of a company to invest so heavily in a single solution. Um, and I think one of the mistakes that I see people making now actually is that they start off with this, this predefined idea of where they're going to be in five years. And so they sort of go away and say, "Okay, well, I want my, my, my system to run on microservices on Kubernetes." And they invest in setting up Kubernetes, right, which has got a lot easier over the last few years, I have to say. Um, you can, to some degree, go and just pick that stuff off the shelf and pay for it. Um, but it's an example of, of a technical decision that, that's putting the cart before the horse, right? So, of course, you want to make architectural decisions. You don't want to make investments on something that isn't going to last, but you also have to remember that you don't know what's going to happen. And actually, getting to a product quickly, uh, is more important than, than, you know, doing everything perfectly the first time around. So, when I talk about these, these things, I think uh, we have to accept that there is a difference between being like the scrappy little startup and then being in growth phase and being a, a mega corporation. These are different environments with different pressures
Kovid Batra: Got it. So, when, when teams start, let's say, work on it, working on it and uh, they have started and taken up this project for let's say, next six months to at least go out with the first phase of it. Uh, what are those challenges which, uh, the platform heads or the people who are working, the engineers who are working on it, should be aware of and how to like dodge those? Something from your experience that you can share.
Geoffrey Teale: Yes. So I mean, in, in, in the, the very earliest phase, I mean, as I just alluded to that keeping it simple is, is a, a, a big benefit. And actually keeping it simple sometimes means, uh, spending money upfront. So what I've, what I've seen is, is, um, many times I've, I've worked at companies, um, but so many, at least three times who've invested in a monitoring platform. So they've bought a off the shelf software as a service monitoring platform, uh, and used that effectively up until a certain point of growth. Now the reason they only use it up into a certain point of growth is because these tools are extremely expensive and those costs tend to scale with your company and your organization. And so, there comes a point in the life of that organization where that no longer makes sense financially. And then you withdraw from that and actually invest in, in specialist resources, either internally or using open source tools or whatever it is. It could just be optimization of the tool that you're using to reduce those costs. But all of those things have a, a time and financial costs associated with them. Whereas at the beginning, when the costs are quite low to use these services, it actually tends to make more sense to just focus on your own project and, and, you know, pick those things up off the shelf because that's easier and quicker. And I think, uh, again, I've seen some companies fail because they tried to do everything themselves from scratch and that, that doesn't work in the beginning. So yeah, I think that's a, it's a big one.
The second one is actually slightly later as you start to grow, getting something up and running at all is a challenge. Um, what tends to happen as you get a little bit bigger is this effect that I was talking about before where people get siloized, um, the communication starts to break down and people aren't aware of the differing concerns. So if you start worrying about things that you might not worry about at first, like system recovery, uh, compliance in some cases, like there's laws around what you do in terms of your platform and your recoverability and data protection and all these things, all of these topics tend to take focus away, um, from what the developers are doing. So on the first hand, that tends to slow down delivery of, of, features that the engineers within your company want in favor of things that they don't really want to know about. Now, all the time you're doing this, you're taking problems away from them and solving them for them. But if you don't talk about that, then you're not, you're not, you may be delivering value, but nobody knows you're delivering value. So that's the first thing.
The other thing is that you then tend to start losing focus on, on the impact that some of these things have. If you stop thinking about the developers as the primary stakeholders and you get obsessed about these other technical and legal factors, um, then you can start putting barriers into place. You can start, um, making the interfaces to the system the way in which it's used, become more complicated. And if you don't really focus then on the developer experience, right, what it is like to use that platform, then you start to turn into the problem, which I mentioned before, because, um, if you're regularly doing something, if you're deploying or testing on a platform and you have to do that over and over again, and it's slowed down by some bureaucracy or some practice or just literally running slowly, um, then that starts to be the thing that irritates you. It starts to be the thing that's in your way, stopping you doing what you're doing. And so, I mean, one thing is, is, is recognizing when this point happens, when your concerns start to deviate and actually explicitly saying, "Okay, yes, we're going to focus on all these things we have to focus on technically, but we're going to make sure that we reserve some technical resource for monitoring our performance and the way in which our customers interact with the system, failure cases, complaints that come up often."
Um, so one thing, again, I saw in much bigger companies, is they migrated to the cloud from, from legacy systems in data centers. And they were used to having turnaround times on, on procedures for deploying software that took at least weeks or having month-long projects because they had to wait for specific training that they had to get sign off. And they thought that by moving to an internal cloud platform, they would solve these things and have this kind of rapid development and deployment cycle. They sort of did in some ways, but they forgot, right? When they were speculating out, they forgot to make the developers a stakeholder and saying, "What do you need to achieve that?" And what they actually need to achieve that is a change in the mindset around the bureaucracy that came around. It's all well and good, like not having to physically put a machine in a rack and order it from a company. But if you still have these rules that say, okay, you need to go in this training course before you can do anything with this, and there's a six month waiting list for that training course, or this has to be approved by five managers who can only be contacted by email before you can do it. These processes are slowing things down. So actually, I mentioned that company that, uh, we lost the whole department from the, from the, uh, platform that we had internally. One of the reasons actually was that just getting started with this platform took months. Whereas if you went to a public cloud service, all you needed was a credit card and you could do it and you wouldn't be breaking any rules in the company in doing that. As long as you had the, the right to spend the money on the credit card, it was fine.
So, you know, that difference of experience, that difference of, uh, of understanding something that starts to grow out as you, as you grow, right? So I think that's a, uh, a thing to look out for as you move from the situation when you're 10, 20 people in the whole company to when you're about, I would say, 100 to 200 people in the whole company. These forces start to become apparent.
Kovid Batra: Got it. So when, when you touch that point of 100-200, uh, then there is definitely a different journey that you have to look up to, right? And there are their own set of challenges. So from that zero to one and then one to X, uh, journey, what, what things have you experienced? Like, this would be my last question for, for today, but yeah, I would be really interested for people who are listening to you heading teams of sizes, a hundred and above. What kind of things they should be looking at when they are, let's say, moving from an off the shelf to an in-house product and then building these teams together?
Geoffrey Teale: Oh, what should they be looking at? I mean, I think we just covered, uh, one of the big ones. I'd say actually that one of the, the biggest things for engineers particularly, um, and managers of engineers is resistance to documentation and, and sort of ideas about documentation that people have. So, um, when you're again, when you're that very small company, it's very easy to just know what's going on. As you grow, what happens, new people come into your team and they have the same questions that have been asked and answered before, or were just known things. So you get this pattern where you repeatedly get the same information being requested by people and it's very nice and normal to have conversations. It builds teams. Um, but there's this kind of key phrase, which is, 'Documentation is automation', right? So engineers understand automation. They understand why automation is required to scale, but they tend to completely discount that when it comes to documentation. So almost every engineer that I've ever met hates writing documentation. Not everyone, but almost everyone. Uh, but if you go and speak to engineers about what they need to start working with a new product, and again, we think about this as a product, um, they'll say, of course, I need some documentation. Uh, and if you dive into that, they don't really want to have fancy YouTube videos. And so, that sometimes that helps people overcome a resistance to learning. Um, but, uh, having anything at all is useful, right? But this is a key, key learning documentation. You need to treat it a little bit like you treat code, right? So it's a very natural, um, observation from, from most engineers. Well, if I write a document about this, that document is just going to sit there and, and rot, and then it will be worse than useless because it will say the wrong thing, which is absolutely true. But the problem there is that someone said it will sit there and rot, right? It shouldn't be the case, right? If you need the documentation to scale out, you need these pieces to, to support new people coming into the company and to actually reduce the overhead of communication because more people, the more different directions of communication you have, the more costly it gets for the organization. Documentation is boring. It's old-fashioned, but it is the solution that works for fixing that.
The only other thing I'm going to say about is mindset, is it's really important to teach engineers what to document, right? Get them away from this mindset that documentation means writing massive, uh, uh, reams and reams of, of text explaining things in, in detail. It's about, you know, documenting the right things in the right place. So at code-level, commenting, um, saying not what the code there does, but more importantly, generally, why it does that. You know, what decision was made that led to that? What customer requirement led to that? What piece of regulation led to that? Linking out to the resources that explain that. And then at slightly higher levels, making things discoverable. So we talk actually in DevEx about things like, um, service catalogs so people can find out what services are running, what APIs are available internally. But also actually documentation has to be structured in a way that meets the use cases. And so, actually not having individual departments dropping little bits of information all over a wiki with an arcane structure, but actually sort of having a centralized resource. Again, that's one thing that I did actually in a bigger company. I came into the platform team and said, "Nobody can find any information about your platform. You actually need like a central website and you need to promote that website and tell people, 'Hey, this is here. This is how you get the information that you need to understand this platform.' And actually including at the very front of that page why this platform is better than just going out somewhere else to come back to the same topic."
Documentation isn't a silver bullet, but it's the closest thing I'm aware of in tech organizations, and it's the thing that we routinely get wrong.
Kovid Batra: Great. I think, uh, just in the interest of time, we'll have to stop here. But, uh, Geoffrey, this was something really, really interesting. I also explored a few things, uh, which were very new to me from the platform perspective. Uh, we would love to, uh, have you for another episode discussing and deep diving more into such topics. But for today, I think this is our time. And, uh, thank you once again for joining in, taking out time for this. Appreciate it.
Geoffrey Teale: Thank you. It's my pleasure.
In this episode of the groCTO Originals podcast, host Kovid Batra engages in an insightful conversation with Christopher Zotter, the Head of Digital Engineering at Sky, Germany. Christopher brings a wealth of experience, including a decade of leading engineering teams and founding a software development agency.
Known for his unique leadership philosophy, Christopher believes in the power of building trust, embracing failures, and fostering a transparent culture. He shares his journey from an apprentice in Germany to a leadership role, emphasizing the importance of hands-on experience and continuous learning. The discussion delves into the challenges and strategies of managing culturally diverse remote teams, effective communication, and transitioning from legacy systems to cutting-edge technologies.
Christopher also highlights the significance of being a role model and integrating community involvement into one’s career. This episode offers a deep dive into the principles and practices that can guide leaders in nurturing successful global development teams.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of groCTO podcast. And today with us, we have a very special guest. Uh, he’s Head of Engineering at Sky, Germany. He is also the founder of a software dev agency, and he has been leading engineering teams from past 10 years now. And today, we are going to talk to him about how to lead those global dev teams because he has been an expert at doing that. So welcome to the show, Christopher. Great to have you here.
Christopher Zotter: Thanks for having me. I’m really excited to be here, part of the great podcast. I get to know this and also the last months and with key insights and hope I can provide some of my learnings from the past experience also to your great audience. So happy, happy to be here.
Kovid Batra: I’m sure you can do that. All right. But before we get started into, um, knowing something about your team and your, uh, areas of expertise of how you lead teams, we would love to know a little bit about you. Like something that LinkedIn doesn’t know, something that is very impactful in your life, from your childhood, from your teenage. Um anything that you would like to share
Christopher Zotter: So first of all, the most important part is not business, it’s my family. So I’m a proud father of two kids and I have a lovely wife. So this is the foundation of everything that I can do, also my job properly to be honest and gives me energy. Um, and also what is not on LinkedIn or it’s on LinkedIn, but it’s worth mentioning is I didn’t study anything. So you see now my title, which is, I also need to reflect, impressive to be honest, also to myself, but I only did a normal apprenticeship in Germany to work as a software developer. So I really start at the core of the things, but now I managed to do so. So I make my, my way through doing the things, getting hats, hands-on, and don’t fear to make mistakes. I learned from things, um, I did, I deployed the hard coded ID and tested it on production while on a software in the past. Yeah, that never happened again. So I really get hands-on and get these kinds of experiences. Um, And what is also, I think, important is to not only focus on, on the software things, but also doing some things for the society, for the community beside the work, which, which gave me the balance. So this is not on LinkedIn. This is something that has also very positive impact on, on my, on my past. So, um, yeah, that’s roughly where, who am I, but I can also continue a bit of my journey to, to becoming that position if you’re interested in too.
Kovid Batra: Sure, why not? Please go ahead.
Christopher Zotter: Um, yeah, then my, my, as I said, I, I did an apprenticeship in Germany, which takes mostly three, three and a half years, and I had the chance to work at the very small company. It’s not, it’s not, the company doesn’t exist anymore, I think, but I got the chance to work in a very small team with great experts, and I got responsibility from day one. So I didn’t develop something for the trash. It was really then something which can go to production, of course, with review process, et cetera. And again, the advice I can already share is try to do as many things as possible. Even if in the younger years, you have the time. I see that now with family, the priority shifts obviously, but use the time you have, do side projects if possible, because getting hands on the things, nothing can beat experience. And this is, I think also the big learning I had over the, uh, over the time is I get all of my, um, promotions all of my way through the career, starting from an apprenticeship, junior developer, senior developer, lead developer, and now Head of Engineering, um, through my experience. I did hands-on and I can prove, showcase what I did starting from code skills, simple HTML page for with the, with the simple contact form, everything. So I get my hands on different things to get, uh, get, get the knowledge, and I think knowledge and experience beats most of the, of the things, but you can’t study it. Um, you need to get hands-on. Yeah, just briefly, and now I’m here.
Kovid Batra: Yeah, no, I think that was a very, very nice intro, and I think we now, we now know you a little more. And one, one thing that I really loved when you said that, uh, it’s not just about work. Uh, there is family, there’s community that you want to do for. So I’m sure this community thing which you are doing, uh, this, this would have helped in shaping up, uh, some level of leadership, some level of giving back. I think leadership is another name for giving back. So from there, it should be coming in. So can you share some of your experience from there that helped you in your career moving from let’s say an IC to an EM and then growing to a leadership position?
Christopher Zotter: I like that you say leadership is giving back. Yes. Um, I didn’t see it that way, but it totally echoes with me. Um, at the end, it’s all about the people. Um, I think we have, we have also on this planet, so many, uh, wars happening, so many people working against it, and I’m, I try to do the opposite because we’re all humans. And I learned also through working for the community in a certain way. So I, I worked for one year to support disabled people, to go with them to school, young people, and there I learned, hey, these are all humans and everybody’s trying their best. Also now, in my position, it’s about people, it’s about getting their feelings, getting their circumstances and getting their perspectives, getting their culture. We will come to the topic later, um, because there are different cultures. We are working together, even in software development, you’re across the globe. Um, and there, you need, always need to, to think about and not act like everybody has the pressure to get it done, get it done. And so, we need to consider that humans behind and let’s find to create a win-win situation for everybody that everybody feels confident, confident and comfortable and respected. And, um, this I learned, I’m a very value-driven person. And my key value is respect because respect is there for everything no matter what you’re doing. Um, it starts going into the office, the cleaning person, greet the same way as you greet the CEO. Um, it’s, it’s, we are all humans, everybody’s putting the bits and pieces together and this sometimes we, we forget in our daily business. So, um, this is what I definitely learned from being there, putting, giving away something for the community or whatever there is. So yeah
Kovid Batra: Perfect. Perfect. And another interesting piece in your career is, uh, no academic background, uh, in engineering and then doing things hands-on. And then, uh, you are working on a side business as well, which you just mentioned where you, you recommend people to do that in the early ages, because that’s where you get the most of your experience and knowledge to do things, how to complete things. How exactly that has contributed in your career growth? Because I also come from a similar experience. I would love for you to explain it if this has contributed in some way
Christopher Zotter: Okay. Yeah, great. Um, that’s yeah. I started my side business also, I think now eight, nine years ago. Um, and by the way, this will now come to an end right now. It’s already more or less ended because my, my daily job requires full attention plus family. There is no time and you need to also to say no to the things. Um, but in that time it was, uh, it was pretty important for me because what I did is the things I learned in my company, in my apprenticeship, um, I tried to do then some projects for first, for my own and then for my inner circle. So for some friends, they had also built up a company, whatever that is, need a home page, need a web application. Um, and I built it on my side business. Then to adapt the things I learned in my, in my daily business and enhance it on a certain way in my environment to test it to work against and enhance the knowledge. Try things out if they’re working there in a smaller, bits of pieces, not in the big company where you’re working on. Um, helps me a lot to grow, trying out, trial and error. Uh, and at least that’s the experience you get and this experience, if you bring it back to your company, if you want it to make career, um, this is where you can benefit from, and yeah, that knowledge beats everything at the end.
Kovid Batra: Sure. I think for me, like I also had a side business and how it has helped me is that I was interacting with the customers directly, right? So that was for me a great experience, which when you are in a larger organization where you have people doing the front end job and then you are getting just the requirements, that relatability with the problem statement with the audience is much lesser So I think that way it has helped me much more from that point of view.
Christopher Zotter: Interesting, because we at Sky we have, our claim is the, the customer or the users in the centric of everything and I have the, the I, I’m a Sky, a soccer fan, and, and, and Sky probably just to name it what we are doing, um, because there is probably a conflict with your audience from India because Sky channel there is known and it’s a bit of a different thing than what Sky Germany is doing. So, um, for, for, for you, we are the major entertainment provider here in Germany called pay tv. We have sports, um, mostly the Bundesliga, so the German soccer football, uh, um, rights we have in place or some, uh, own produced movies. Uh, you can watch Netflix and stuff over our platform, either it’s streaming or it’s our Q receiver. And, um, as I’m a big, Bayern Munich fan, I use Sky or previously it was named Premier, uh, for a long, long time ago. So I’m also the customer on the one hand side to use our product and know what’s going on and know the issues and can bring it then into and learn from it on, on the other side, which is now a great benefit, but I can echo it. It’s, it’s definitely one of the key things to know who’s your audience and what are the users and what are the customers and go out and get to know them, what is their behavior in order to deliver them the best product, the best experience they can, they can have.
Kovid Batra: Sure, sure. Absolutely. All right. I think, uh, that was, outside what you do at Sky, most of it, uh, we discussed. Now moving in from that note into the world of Sky where you are heading teams and, uh, most of them are remotely working from India, from Germany and other parts of the world. So first thing I would like to understand, like, how things have changed in the last four or five years from your perspective? Um, you have grown from a manager to a leadership profile. What were those things that came into, uh, into your role as a responsibility, uh, that you took up with these global teams that help you grow here? How was the experience the last four years?
Christopher Zotter: It was an amazing ride. Um, I think every, every, every step has their challenges in, in a certain way. Um, being a developer, you can then go to either other developers or have your scrum master and feature teams. Um, but coming to be, um, a leader for such, such a, such a big team. So my team is currently, we have five people here in Germany and we have 15–16 right now sitting in Chennai, India. You have to think about different things. You have to think about the team harmony, how the people working together, you have to think about communication. You have to think about values, how everything works then together, and not only getting the code done in a proper way with all of their quality checks in between, but also that I need now to consider there helps me to get the experience in beforehand to know what is technically possible, what we need to do in order to shape, um, the best and the most effective process. We will talk about that, I think, later also, what can be done there. But also, um, yeah, to consider, as I said previously, the different perspectives. Everybody is on a different level, um, has different circumstances. Somebody is now getting it further earlier. So probably not that much focus on work, which is fine. We need to deal with that also to support wherever we can. Somebody is getting sick and all of the things you need to consider. Um, and it’s, it was also a big change for me and I’m still in progress to be honest, because I started my journey as a developer and I love to code also. Um, but so much coding in that position is not possible anymore. And you need to build up your team where you can trust and give them the task and get it back done or get it, getting the right feedback, uh, whatever that is. So this is one of the things to build trust to having a lot of conversations. So having a lot of coffee in the office with the different guys to get to know what’s going on. And of course, um, you are now, or I am now in a position to having, uh, stakeholders, uh, communication with our CTO, COO, uh, different, different areas, which you don’t have normally as a developer that you only get the requirements. So again, I’m a bit next to the customer, right? Because I can also bring my bits and pieces into some of the features and decisions. Um, and this, this is one of the biggest changes to, to go out of the real, getting the hands-on and, and yeah, bringing the layer on top to prepare everything and protect everything that my developers can really focus or my architects can focus on the work without any disruption and make the work as smooth and as fast as possible.
Kovid Batra: But I think in your case, um, as compared to, uh, I would say, a single culture, a uniculture team, um, your case is different. You have people in India, across the globe. This collaboration, uh, I’m sure this becomes a little difficult and it’s a challenge of a lot of companies after COVID, uh, because things have gone remote and people are hiring from across the borders. How, how it has been an experience for you to handle these remote teams who are from different culture? And what, what really worked out, what didn’t work out some of those examples from your journey?
Christopher Zotter: Uh, yes, this is definitely a challenge and I have to say I’m the only German-speaking guy in my team. So we are a German company, but I’m the only German speaking guy. So I, in Germany, we have also some Indian colleagues, some from Russia, uh, sorry, from Ukraine. We have some from, uh, Egypt. So it’s mixed. And as, as you said, a lot of people are coming from, from Chennai, India. And imagine this is about 4, 000 kilometers difference. Um, a lot of, uh, at the end, and we have two different cultures. And this was the biggest learning I got to know is at the beginning, just an example, a yes doesn’t mean a yes. Um, we had some requirements, we talked about that and I got the feedback, “Yes.” Okay, and then I assumed the ticket will be done, but it was only, “Yes. I got to know that I need to do that.” But not, “Yes, I understand it.” So there’s a communication, a learning over the time and which the whole company has to do. So we all need to transform here at Sky and also at Comcast Engineering in India that we are going together, find a way of communication, get to know the, the other, uh, the other culture, the other people, the other behavior, how they’re working.
Um, and of course, I’m also a fan of remote working, but also a fan of getting in touch, uh, getting into, into personal conversations with people, um, not only, uh, not via camera, but in person. So that’s also why we have some mandatory days at Sky where we need to go to the office. But I’ll also be there in India once or twice a year, even if it’s a long travel and, you know, challenge with family, but, um, the investment is, is worth it. Um, I got to know the, the Indian culture very well. Um, and it’s also kind to them to show appreciation. So they recognize, “Hey, they really take care about us and we’re not only there outsource for things, get the things done.” And as I said, I’m taking care of, at least my goal is to take care about the people, to treat them with respect and try to find the way together. And if you’re having the 1-on-1 conversations in person, get to know the culture, go to temples, get to know all of the things we’re running around, what they, what, the food. Oh! It’s amazing in India. Um, everything. Um, then you grow together and then this makes, after my second visit, I can say, um, the communication was a totally different one. So I got to know then, or I feel really the trust of my team then to say, “Hey, Christopher, this doesn’t work.” So they say and you know, this is a cultural topic because in india, it’s normally, uh, it’s they’re not used to saying, “No, it’s not working.” They say yes and try to make it work anyhow, but it doesn’t help in the, in the daily business. So it’s better to say, “Uh, I need help at the first place and then we can get it done as a team.” But coming to that point, that’s one of the biggest challenges I faced. It’s still not perfect yet, but this is where we think always about what is their circumstances? Is that really yes, they got it or do they need some other kind of help, um, that we can provide them to them?
Kovid Batra: I think a very, very good example. Being an Indian, I can totally relate to it. Uh, we go with that mindset and at times it is not, uh, beneficial for the business as such, but there is a natural instinct which says, okay, let’s say yes. Let’s say, “Yeah, we are trying.” And try to fight for it maybe. Not sure what exactly drives that, but yeah, a very, uh, important point to understand and look at.
All right. So I think this is, this is definitely one example, which, uh, our audiences, if they are leading some teams from India, would keep in mind when they’re leading them. Anything else that you, that comes to your mind that you would want to do to ensure good communication or collaboration across these teams?
Christopher Zotter: I think when we stick to the topic is to be the role model. Um, I said it in my introduction. I deployed something hard coded to production with an ID. I bring that always as an example to say “Yes, this was a failure.” But I took a great learning out of it. So to establish these kind of things to acting as a role model, especially as a leader, because then you lead and the people will follow you and you should.. My claim is to act as a leader who is not there. I’m the same. I only have another title, but we are all equal. I can’t do my work without you and the other way around. So we’re one team, no matter who has, which level of a junior or, uh, whoever that is, so working together as a team and be there and support everybody. And I say always, “If they don’t need me anymore, I did my job perfectly.” Um, so this is what I, what I’m aiming for. No, to be really a leader, to be a role model, to, to say, “Hey, this doesn’t work.” “Oh, this was my failure of the week.” That’s what we probably now try to establish failure of the week that everybody, uh, put that failure into learning and share that with the audience. Um, it breaks a bit everything. So they see, “Hey, they are now doing it. So I can do that as well.” And this takes away the fear of if I say too much things I can’t do, I get fired. That’s the most fear, I also get to know why talking to the people. Um, as I know, that’s not the case. I appreciate it more if you say it to me instead of hiding it. So, um, yeah, this is definitely, definitely the thing.
Kovid Batra: True. I think one example that comes to my mind, uh, when I talk to my, um, friends and colleagues who are working across different organizations, like Amazon, Microsoft, world, handling teams from India for US or vice versa. Um, whenever there is huge transitions, let’s say from legacy systems to new architecture, they are like for 6 to 10 to 12 months, I’ve seen they were in a stressed situation where they’re saying like, “The team is not here communicating and managing that stuff is becoming difficult for me.” They were making multiple trips to, to the, uh, to the main home ground and then getting things done. So in your case, you, you guys are remote-first and I’m assuming most of the times you’re dealing with such situations remotely. So has there been a situation where you had to migrate from some legacy systems to new systems, new architecture, and, uh, there were challenges on that journey?
Christopher Zotter: Um, we’re currently in. Uh, so we are in a big transformation phase at Sky. So this is taking off for some years. And, uh, let’s say we in the final steps to be there to create, we started everything, challenged every technology we had, um, a few years back and say, “What can we provide best to our customers? So what technology is cutting edge? What technology is bringing our faster cycles of deployment, faster cycles of changes?” And challenged our content management system up to all completely our CRM system. Um, and that’s, that’s, we’re currently in the middle of it. Um, the challenge is obviously, yes, you always did in the past, something is not documented, some processes are there, and not everybody’s trying to challenge all of the things which happened in the past but it’s exactly the right time to do so, to, to challenge what was there. Do we really need to convert it and migrate it to a new system or not? Um, and get better into doing that. So take the learnings, challenge it and bring it to the new system. And that we’re in the middle of, um, that’s why, why I also started at Sky to, to, to kick-off that journey and at this part of time I was the developer who started it and, um, now i’m happy to say that we are in a very good shape. So we are live with, uh, with most of the things already, the migration is still going on, but um, our sales journey and stuff is already live and going to customers. We have proper monitoring set up. We have good testing in place. So, um, yeah, but again, what I said is, um, I see also now the old worlds, the old systems, um, and we, we all have to be open-minded to getting, getting transferred to new things, um, to always learn every day, especially, I think your audience knows that pretty well. In software development or development is that every day is a new tool, every day is a new change, a new version and new things you need to update it here and there. To always stick to that level is a challenge we face every day, but we’re trying to do our best to always get the latest version and the best features out for our customers.
Kovid Batra: Sure. I think one very good point you highlighted, like as a leader, uh, as a manager, you might still realize that this change is for the good, and this change is going to impact us in much better ways for the business point of view, from our engineering point of view. But when it comes to the people who are actually developing, coding, uh, how do you ensure like such big migrations come handy, people don’t have resistance? Because giving a plan and a strategy, uh, is definitely one thing which you have to craft carefully. But one very important thing goes into the, the innate motivation of people to execute it so that they think of use cases, make it even better than what you have planned for, at least on the paper. So what, what do you do to ensure such kind of, uh, culture shift or such kind of culture being instilled in people to embrace that change?
Christopher Zotter: Um, first of all, I think if you are yourself your own customer, this is the first thing. So you need to consume your own product as well. So dog food it. Um, It’s a bit difficult with India, but we have possibilities to also use Sky at least in the office to play around, to watch the movies to watch the things, um, that we can identify with that. That’s the first thing that we know what we’re doing to know what, how our customers are acting and I always said is I use a lot of data, um, to just, hey, how many visits do we have on these pages? Or check this feature, has this impact on our sales, whatever that is. So using that data to show, hey, the button you’re changing right now is not only a color change. This has a psychologically thing. If you change it to green one to give a positive feedback to our customers that they would click then and buy the things, just stupid example. Um, And you will see when we put that on production or do some user tests, you see directly your impact and it would go to millions of customers. And coming out and bringing that every time, every day to the table, um, opens up, hey, the things they’re doing, they have a real impact and this is everybody can be proud of. And I said always, hey, look, if you show that to your family and your mother, this, you can, and that’s a good thing at that development. You can show the things, uh, if you’re doing an API, it’s also important, but it’s a different thing. That’s why I love that development to say, you can showcase the things. Um, so we’re constantly measuring the things constantly, constantly improving. And this gives also the, the, the developers a sense of, “Hey, this is really important, what I’m doing here and this is the impact.” Um, and in order not to, you know, putting too much pressure on the people. We always have, uh, uh, we are working in a safe environment, so a scaled agile framework where we plan the next three months ahead and the planning is done by the developers and the developers commit to this, um, uh, plan provided by the business and they commit what they can achieve. So they have then the plan and they have an influence on that. And this gives us a balance to first be predictable, but also, uh, make the developers identify with things they’re developing.
Kovid Batra: Got it. Got it. Makes sense. I think it revolves around creating those right incentives, creating those right experiences for the developers to understand and relate to. Uh, so while, while you’re talking about having those right incentives, measuring the impactful areas, uh, I’m sure you must be using some level of metrics, some level of processes to ensure that you continuously improve on these things, you continuously keep working on the impactful areas. So, uh, at, at Sky or at your previous organizations, what kind of frameworks you have deployed? What kind of metrics you look at for different initiatives?
Christopher Zotter: Um, first of all, uh, I got to know that only what you measure, you can improve. That’s the one claim I always get to know. Um, it can be a weight, but, uh, then you see also some improvements. So just an example. Um, I’m, I’m a developer. So, uh, let’s start with the coding part, probably GitHub. Um, yeah, I mean, GitHub, a lot of different cycles, um, starting from creating a pull request, uh, reviewing a pull request, checking if it gets rejected or not, how many comments you get, um, uh, up to, it’s connected to CI/CD where some of our testing frameworks are running against different features we wanted to merge. Um, this is one of the key indicators where we say, um, or in the past also where we, we were looking into and say, “Okay, um, how big is a pull request? How much time does it take that it gets reviewed?” Um, all of these KPIs, um, or there are KPIs behind that, but the, my goal is that I get identified if I need to go deeper into some of the topics to find probably some root cause. Um, the same happened on, on the delivery level. So not on the code level but on the delivery level where we have our tickets, our story points and where we can roughly say a story point is one day more or less, um, and if I see there’s one story point, but the ticket is in development for five days, um, I need to go into, uh, into communication, say, “Hey, are there any challenges?” Um, or, “Do you need some support? Is there a knowledge gap?” Or if a feature has too many bugs after that assigned, um, after it’s merged to our development stage, um, we probably have a lack of quality. It could lead to a lack of, uh, lack of yeah knowledge here and there. So this is my, my measures to not to and this is again coming into a culture topic, um, to use the data the right way and not to say, “I micromanage you. You get fired if you don’t hit the KPIs.” No. Um, the key is we need to have in these KPIs that I get an alert as early as possible that I need to go into communication and find a way to take the people by hand and work together against some strategies. Could be knowledge sharing, could be coachings, could be whatever that is. It could also be that I got identified. We have some issues with one of the product owners, for example, who doesn’t provide all of the details in a ticket beforehand. It comes to development. It can be a lot of things, but if I don’t do that, I don’t have or at least I get to know that by a lot of weeks later, and then it’s too late. So gives me an indicator where I need to get into communication to improve, um, the process, to improve, um, the people, to make them better and, and yeah, to support them.
Kovid Batra: Make sense. I think very rightly said, um, using these metrics always makes sense, but how you’re using it will ultimately be the core thing, whether they are going to help you or they can give back. So yeah, I think great advice there, Christopher. And I think in the interest of time, uh, we’ll have to take a pause here, though I, I really loved the discussion and I would love to deep dive more into how you’re managing your teams, but maybe another episode for that. Uh, and once again, uh, thanks a lot for taking our time, sharing your experience at Sky, telling us about yourself. Thank you so much.
Christopher Zotter: Thanks for having me. Uh, thanks for having me. It was a pleasure to be here. Happy to come a second time to dive deep, uh, deep dive into some of the topics, um, if interested and, uh, also kudos to you. It’s a great podcast. I love to listen to it on my own because I also pick some nuggets out of that each of the time. So keep, keep pushing that. Thanks a lot.
Kovid Batra: Thank you so much, Christopher.
In this episode of the groCTO Originals podcast, host Kovid Batra engages with Vilas, an accomplished engineering leader with significant experience at companies like Walmart, Netflix, and Bill.com.
Vilas discusses the concept of Developer Experience (DevEx) and how it extends beyond simply providing tools. Vilas highlights the importance of enabling developers with frictionless processes and addresses the multidimensional challenges involved. The conversation delves into Vilas’s journey in DevEx, insights from designing platforms and enabling developer productivity, and the necessity of engaging with key opinion leaders for successful adoption. Vilas shares personal anecdotes and learning experiences, stressing the significance of treating developer enablement as a product and encouraging collaboration.
The discussion concludes with advice for those stepping into DevEx roles, underlining the evolving significance of this field in the industry.
Kovid Batra: Hi everyone, this is Kovid, back with a new episode of groCTO podcast. Today with us, we have a very special guest. He’s an accomplished engineering leader, has been building successful teams from last 15 years at Walmart, Netflix, Bill.com, and with his expertise in DevEx and Dev productivity, he’s now very well renowned. So we found Vilas through LinkedIn and, uh, his posts around DevEx and Dev Productivity, and I just like started resonating with it. So, uh, welcome to the show, Vilas, great to have you here.
Vilas Veeraraghavan: Thanks Kovid. I am grateful for getting to meet people like yourself who are interested in this topic and want to talk about it. Um, so yeah, I’m looking forward to having a discussion.
Kovid Batra: Perfect. Perfect. But Vilas, before we get started, um, this is a ritual for groCTO podcast.
Vilas Veeraraghavan: Okay.
Kovid Batra: Uh, we will have to like, uh, know you a little more beyond what LinkedIn tells about you. So tell us about yourself, like your hobbies, how do you unwind your day? Something from your childhood memories that tells who Vilas today is. So, yeah.
Vilas Veeraraghavan: Okay. Okay. That’s, I was not prepared for it, but I’ll, I’ll share it anyway. Um, so I am a, the thing that most people don’t know about me, uh, is that I am a big movie fan. Like I watch movies of all languages, all kinds, and I pride myself on knowing, uh, most of the details around why the movie was made. Um, like, you know, I really want to get into those details. Like I want to get the inspiration of behind the movie. It’s almost like appreciating art. You want to get into like, why did this person do this? Uh, so I’m very passionate about that. Um, so that’s, that’s something that people don’t necessarily know. Um, and apart from that, like, I, I enjoy, uh, running and walking. It sounds weird to say I enjoy walking, but I genuinely do that. Like that’s my, that’s the place where I do most of my thinking, analysing, all of that.
Kovid Batra: Perfect. Which one’s the weirdest movie that you have watched and like found out certain details which were like very surprising for you as well?
Vilas Veeraraghavan: I don’t know if I would say weird, but you know, all of, every director, every film director has one movie that, you know, they have always yearned to make. So they, their entire career goes in sort of trying to get to that movie, right? Because it’s their magnum opus, right? That’s the, that’s the term that people use. Um, I always find that fascinating. So I always try to look for, for every director, what was their magnum opus, right? Uh, so for example, for Raj Kapoor, it was Mera Naam Joker, and that was his magnum opus. Like what went into really making that film? Why did he make it? Like what? And you’ll realize also that their vision, the director’s vision is actually very, um, pure in those, in a sense that they will not listen to anyone else. They will not edit it short. They will not cut off songs or scenes. It’s such a, uh, important thing for them that they will deliver it. So I always chase that. That’s the story I chase.
Kovid Batra: Got it. Perfect. I think that was a very quick, interesting intro about yourself. Good to know that you are a movie buff. And now like, let’s, let’s move on to the main section. So just for the audience, they know, uh, we’re going to talk about DevEx, dev productivity, which is Vilas’s main area of expertise. And his, his quote from my last discussion with him was that DevEx is not just, uh, some tools being brought in, some dev productivity tools being brought in. So I think with that note, uh, let’s get started, Vilas.
Vilas Veeraraghavan: Sure.
Kovid Batra: What according to you defines DevEx? Like let’s start with that first basic question. What is DevEx for you?
Vilas Veeraraghavan: Okay. So before I jump into that, I want to give you, give the context behind that statement I said, right? Um, it’s not about throwing tools at someone and expecting that things will get better. Um, I learnt that over time, right? I was a big fan of automation and creating tools to help people, and I would often be surprised by why people are not using them the way I thought they should. And then I realized it’s about the fact that their process that they are following today does not allow them to include this. There is too much friction that brings that. If they bring in a new tool, it’s too much friction. And then I realized also what the people, about management, all of that stuff. So it’s a very, it’s a, it’s a multidimensional problem. And so that, I just want to set that context because that’s how I defined DevEx, right? DevEx or I, as I like to call it more about dev enablement, is about making sure that your developers have the best possible path through which they can deliver features to production. Right? And so it’s, it’s not about productivity. I think productivity is inherent in the fact that if you enable someone, uh, you are providing them with the shortest paved road kind of thing to get to their destination. They will become productive. Uh, it’s sort of, uh, automatic extrapolation, if you will, from that. So that’s the reason why I, that’s how I defined DevEx. Um, but it’s important because that’s how, that was my journey to learn as well.
Kovid Batra: So I think, uh, before the discussion started, we were talking about how you got into this role and how DevEx came into play. So I think, uh, let audience also hear it from you. Like, we know like DevEx is a very new term. Uh, this is something that has been introduced very lately, but back in the day, when you started working on things, what defined DevEx at that time and how you got involved in it?
Vilas Veeraraghavan: Um, so back in the day when I started working in a software organization, the thing that drew me to, uh, what we would call ‘platform’ back then was the fact that there were a lot of opportunities to see quick wins from doing improvements for other teams. So for example, if I created something, if I improved something at the platform layer, it will not benefit one team. It will benefit all teams, multiple teams. And so the, the impact is actually pretty widespread and it’s immediate. You can see the, um, the joy of making someone happy. Like someone will come to you and say, “Oh, I was spending so much time and now I don’t have to do this.” Uh, so that drew me in, it wasn’t called DevEx. It wasn’t even called Dev Productivity at that time. Um, but this is I’m talking about like 2008, 2007–2008 timeframe. But then what happened over time was that, um, I realized that automation and creating the tools and all of that, uh, I realized how much of a superpower that can be for a company to have, uh, investment in that because it’s a multifold impact on how quickly people can get features. So how quickly you innovate, how efficient your engineering team is, how, um, excellent the, uh, how it says, the practices are within the engineering organization. They can all be defined by providing your engineers something that is, they can use every day and they don’t have to think and reinvent new ways and they don’t have to relitigate the same problem again and again.
Um, so that drew me in. Uh, so over time I’ve seen it evolve from just platform or like there used to be common libraries that people would write, which other companies, other teams would, uh, ingest and then they would release, uh, and we did not have, uh, continuous delivery. Uh, funnily enough, uh, we used to ship CDs, compact discs for those who are new to this process. Uh, so we would actually ship physical media over. So we would burn all the software on it and then we would ship it, um, to the data center and an admin would install it. So there was no concept of that level of continuous delivery, but we did have CI, and we did have a sense of automation within the actual pipeline, the software delivery pipeline. That is still valid.
Kovid Batra: There is one interesting question, like, uh, this is something that I have also felt, uh, coming from an engineering background. People usually don’t have, uh, an interest towards moving into platform teams, DevOps kind of things, right? You say that you are passionate about it. So I just want to hear it from you, like what drives that passion? Like you just mentioned that there is an impact that you’re creating with all the teams who are working there. Um, so is, is that the key thing or is it something else that is driving that passion?
Vilas Veeraraghavan: I mean, I feel like that is the key thing because I, I derive a lot of joy out of that, because I feel that when you make a change and sometimes, uh, the result, the impact of that change is not visible till it’s actually live and then people use it. I mean, for example, if you wanted to, let’s say you’re moving from a GitLab pipeline to, uh, using Argo CD for something or something like that. You’re doing a massive migration. It can be very troubling to look at it when you’re stepping back and looking at it as a big picture. But then when all of the change is done and you see how it has impacted, uh, you see how fast you’re running or you see, something like that, right? So I think it’s that, um, obviously is, which is a big motivator, but here’s the other thing, right? I think, uh, and this is a secret that I hope others also, uh, realize that it was right there all along. They just haven’t seen it. The secret is that by being in a space like DevEx, you actually solve multiple different domain, uh, domain areas, problems, right? So for example, at Walmart, I got deeply, I had a chance to deeply understand supply chain issues, like supply chain teams had issues that were different from maybe, uh, like teams that were doing more payment management. Uh, the problems are different, but when you look at the problem, uh, you have to understand deeply what that technology is. So you end up having a lot of really broad knowledge across multiple domain areas. And when you solve a problem for a domain area, you will be surprised to know, Oh, this actually solves it for five other areas as well. Right? So it’s, it’s a fascinating thing that I think people don’t realize immediately. So it feels less glamorous than something else, um, like a feature team maybe. Um, but in fact, it’s actually, in my opinion, uh, more powerful.
Kovid Batra: Got it. Is this the effect of working with large organizations particularly? Like, uh..
Vilas Veeraraghavan: It’s possible.
Kovid Batra: I’m not making any assumptions here but I’m just asking a question.
Vilas Veeraraghavan: Yeah. It’s possible.
Kovid Batra: Okay.
Vilas Veeraraghavan: Yeah, it is. I, I, yes. Uh, I, I will say that there is definitely a privilege that I’m, I should call out here, is that the privilege for me was to work, uh, in companies which allowed me the ability to like learn this, right? There was a lot of, um, bandwidth that was offered to me to learn all of this. Um, and Netflix was, is, is always good about a lot of transparency across organizations. Uh, so as an engineer, if you are working for a company like Netflix, you absorb a lot of information. And because you, if you’re curious, you can do more, you can do a lot, right? Um, obviously Walmart, fortune one, big, biggest company I’ve ever worked for. I think it’s, it is the biggest company in terms of size as well. Um, again, right, you have the ability to learn, uh, and you work your way out of ambiguity by defining structure yourself. Um, so same thing happens. I think I’ve been lucky in that way as well, um, to learn from all of these folks who worked there and obviously, amazing, talented people work in these places. So something, you keep hearing about it, you keep learning about it and then it makes you better as an engineer as well.
Kovid Batra: Makes sense. So, um, let’s, let’s deep dive into some of these situations where you applied your great brains around designing the platform teams, defining things for, uh, these platforms. So maybe, can you just bring up some examples from your journey at Netflix or Walmart or Bill.com where you had a great challenge in front of you? Uh, and what were the decision-making framework, uh, frameworks you, you, uh, basically deployed at that point of time and how things spanned out during the journey? So this might be a long question, but like, uh, I just wanted to, uh, dive into any one of those journeys if you, if you’re okay.
Vilas Veeraraghavan: Okay. I think we have had in the past, you’ve had Bryan Finster. So this was something that we traversed together along with many other people. Uh, we were all part of the same team, um, when we did this. Uh, so I’ll start with Walmart, uh, as an example. Um, I’ll, I’ll keep, keep it to sort of, I’ll go into generics and not give you specifics, but the challenge, uh, at a company like Walmart is that as a company, a big company, there is a lot of established practices, uh, a lot of established processes, established tools that teams use and businesses rely on, right? So each of these areas within the company is a business by itself. Uh, they are obviously wanting to get the best possible output for their customers. Uh, and they rely on a bunch of processes, tools, people, all of that, right? Um, if you now, going in, say that, “Hey, I’m going to introduce something that’s brand new.” Or if you’re going to change something drastically, you are creating unnecessary churn and unnecessary friction within the system, right? So in order for us to think about how we wanted to do dev enablement within Walmart, it is important to understand that you had to address the friction, right? If you are providing a solution that is replacing existing solution and doing just enough, that’s not going to cut it. It has to be a sea change. It has to be something that significantly changes how the company does software delivery, right? Uh, and so, one thing I’ll say is that I was very lucky to work for someone and for like leaders at Walmart that also understood this at that time. Um, so, for all those who are in the process right now, you cannot do it unless your leadership has that, you have buy in from that leadership, you have sponsorship from your executive teams. Uh, that helped us a lot.
Now, once you have buy in, you still have to produce something that is of value, right? And so that is where I’m saying this thing is important. So initially, uh, in my mind, uh, naively, my expectation was we build some amazing tools, right? And then we provide that to these teams and of course, they’ll be super happy, uh, the word of month will spread and that’s it. Right. All done. Um, what I found was in order to solve a problem where engineers were spending a lot of time doing toil, right? Like they were doing a lot of manual processes or repeated, uh, work throwing a tool at them was actually exacerbating the cognitive load problem, right?
Kovid Batra: Yeah.
Vilas Veeraraghavan: So now, while they maintain existing solutions, they have to now learn something new, migrate it, then convince their leaders and their teams to say, “Yeah, this is how we have to do things.” And then move forward. So you’re making that problem worse, that bandwidth problem, which is I’m a developer. I have certain amount of time to spend on feature delivery. I don’t have time for everything. So now I’m squeezing this into my, like 20 percent time, on my own free time outside of work to learn what this new thing is about. What that meant is that adoption would not succeed. So if adoption doesn’t succeed, then obviously, if your customers are not using you, you’re not, you’re a failed product, right? So what we realized was there are two other aspects to it that we had not thought about. One was process and the other one was people, right? So when I say people, I mean it could be management, it could be a key opinion leader within the space, right? That’s what we attacked. And you can obviously ask Bryan more about it. He is, he’s, he knows all about it. But the way that we attacked it was we created programs which were more grassroots, like more bottoms up view of saying, “Hey, we are starting to use these new tools. Come join us as we learn together. Let’s discuss what problems we have. Let’s talk about successes that we have. Let’s talk about how we want to do this well.” And we were open to feedback. So, inside my organization, uh, which is the dev enablement area, there was also a product organization. Uh, so we had product owners with each of the teams that are building these tools and the product owners had a pulse on the customer’s need.
So that is, that is how we found success over time. We did not obviously succeed at the start, and there was obviously, a lot of challenges we had to work through, but what happened is adoption only kicked up when we saw that we were able to, one, provide a solution that is X times better than where we were, right? So if you were to, if you were maintaining configuration, if you’re meeting five config, uh, different configs, now we just have to meet in one YAML file and that’s checked into GitHub or something like that, right? That’s a big difference productivity-wise. lesser errors. Uh, second thing is how many times do I have to look at the build? Uh, and then security review after the build and all that. So you say, okay, let’s do security scanning before the build. Uh, so even before you build a binary, you know if it’s safe to build it based on your code scan. Uh, things like that we did to improve the process itself. And then we educated our teams about it. All of our teams. We upskilled them. We gave them a chance to upskill themselves by giving them lots to, lots of references. We showed them like what the industry standards are. By showing them what the industry standards are, you created a need inside them say, “Hey, we need to be like that, right? Like, why can’t we do this?” And so that essentially became a motivating factor for most teams and most managers and directors and VPs started saying, “Hey, I want all of my teams to do exactly that.” Right. We need to be that kind of a team. And that introduced a lot of sort of gamification, right? Because when we, when you look at dashboards that look slick, right, and you’re like, “Hey, why can’t I do this? Why can’t my team do this?” It created a very natural tension, a very natural competition within the company, which served adoption well. Once the adoption was starting to grow and beyond a certain threshold, it became a very natural, or we didn’t have to go asking for customers, customers came looking for us. And so, that’s how we got to the point where there was more uniformity in how software is delivered.
Kovid Batra: Perfect. So I think it’s more around defining the right problem for the teams that you’re going to work with, defining a priority on those problems, how you were like very swiftly slide into their existing system so that the adoption is not a barrier in the first place itself. So the basic principles of how you bring in a product into the market. Similarly, you just have to..
Vilas Veeraraghavan: It is the exact same.
Kovid Batra: Yeah.
Vilas Veeraraghavan: Uh, platform, dev enablement, tooling, all of this. These are all products. Your developers are your customers. If your customers are not happy and they don’t use you, um, yeah, you are a failed organization then. That’s how it is. Right. So if you, if you feel like, um, just because you are part of a DevEx team, uh, what you say has to be the law of the land, it doesn’t work that way, right? The customers vote with their, with the time that they give you. Uh, and if that, if you find if, let’s say in an organization, you see that there are some tools that’s been released by the developer productivity or DevEx or enablement or platform engineering organization, but most people are using workarounds to do something. Then I hope the teams understand that there needs to be some serious change in the DevEx organization.
Kovid Batra: Cool. I’ll just go back to the first point itself from where you start. Is there any specific way to identify which teams are dealing with the most impactful problems right now and then you go about tackling that? Or it’s more like you are talking to a lot of engineering leaders around you and then you just think that, “Okay, this is something that we can easily solve and it seems impactful. Let’s pick this up.” How does that work?
Vilas Veeraraghavan: That’s actually a very, um, important thing to think about. And thanks for reminding me of that because I did ignore to say that. I didn’t say this the last time. Uh, you do need some champions and that’s why I said key opinion leaders, right? In the company, you need champions who can help do that early adoption and then find success. That comes from not just impact, which means, let’s say that someone is doing, uh, a hundred million dollars of business every year. Uh, and if they change something that they made to save a significant amount of money, that can be big impact, but it’s also about what their ambition is. So if I am a hundred million dollar business, but my ambition is I want to be a hundred million dollar business next year as well. They may not be able to be the, uh, they may not be the person who’s pushing at the boundaries, right?
Kovid Batra: Got it.
Vilas Veeraraghavan: They may be saying, “Oh yeah, it’s fine. I mean, everything is working just fine. I don’t want to break anything. I don’t want to touch anything. I don’t want to innovate. Let’s keep going.” But on the other hand, you will see, and this is common in many big companies is there’ll always be pockets of rapid innovation, right? And so, these folks who are in that space and their decision makers in those spaces, uh, them having a discussion with it, a really deep discussion, a very open discussion with them, uh, almost like a partnership, right? Saying, “Hey, I’m building this tool. Let’s imagine you have to use this tool. What would you want me to change in this so that it fits you?” And obviously, you’re going to take all of their input and decide which ones will be more useful to others as well. You’re not going to obviously, build something for just one team, but at the same time you get to know, like, you know, what is it that, what is it that is not getting them to adopt this right now? So you do need a set of those key opinion leaders very early in the process because they are also not just going to influence their team; they are going to influence other teams. And that’s how the word of mouth is going to spread. So that’s the first step. So it’s not just impact; its impact with ambition, which is where..
Kovid Batra: There should be some inherent motivation there to actually work on it, only then..
Vilas Veeraraghavan: I will, I will say one other thing, Kovid. Like if there is someone that, if there’s a team that doesn’t necessarily have ambition, but it’s doing more of a top-down, like get this done, right? I have often found that, uh, by leaders saying, get this done, it can sometimes backfire because the team feels like it’s an imposition on them. They may be very happy with their current state of tools, but it’s an imposition. Like now, why do you have to change this? Everything works just fine, right? You always have that inertia, like people, everyone doesn’t want change, and sometimes change might not be needed either. You might actually already be efficient, right? But that top-down approach doesn’t always work, which is why for us, I will say this, that for me, the greatest learning was how and seeing how much the bottoms-up approach worked at Walmart was actually very encouraging because I realized that you have to convince an engineer to see this for themselves. So it is very, that’s why I think opinion leaders are not necessarily VPs or they could be, it could be someone who’s well-respected in an area. It could be someone who is, um, like a distinguished engineer, uh, right, whose word carries a lot of value within an organization. Those are the, those are the people who, who tend to be those key opinion leaders, right? Uh, so top-down also doesn’t work. You can’t just be like, uh, your VP is ambitious, but you are not. That, that, that doesn’t work either.
Kovid Batra: Makes sense. Makes sense. All right. So I think when you have defined the team priority problem that you need to solve, then you start hustling, start building, of course, that phase has to be of a lot of to and fro, patience, transition, MVPs. Anything from that phase of implementation that came out to be a great learning for you that you would like to share?
Vilas Veeraraghavan: I’m thinking there was obviously a lot of learning. Uh, we, it was not, it is never a straight path, right, uh, when, when you’re doing something like this. But I think one thing that I, uh, evolved, uh, during that time was at the start, uh, I was definitely operating in a bit of a, “But this is the best way to do it.” Like I was, we were so convinced that there is no other way, but this to do it. That, uh, slight arrogance sometimes leads you down a path where you’re not listening to what people are saying, right? If people are saying, “Hey, I’m facing this pain.” And you’re hearing that across different organizations, different areas, and you dismiss it as, “Oh, it’s just a small thing. Don’t worry about it.” Right? That small thing can snowball into a very big problem that you cannot avoid, eventually. What I learned over time was I used to go into meetings being very defensive about what we already created and what, because the way I would look at it is, “Oh, well, that team can do it. Why can’t you?” And, uh, that was very naive at that time. But then I realized, uh, one of those meetings I went to, I, for some reason, I basically said, “Okay, fine. Tell me exactly how you would have solved the problem.” Maybe I was annoyed. I don’t know what, but I said, “Okay, how would you solve the problem if you were doing this?” And that person was so happy to hear that. And that person actually sat down with me for the next two hours and designed exactly how things could have been better, all of that. Like they, and I went, I was happy to go into detail, but it made me realize these are actually all allies that I should be adding to my list, right, as opposed to saying, “No, no, you have to use this. Like, what? Go away.” I, I, that was a big mistake I did. I probably did that for like six months. I, I will say that that was a bad idea. Uh, don’t do it. Uh, but after that it was, I, I was able to, the team was able to flourish because everyone saw us as partners in this thing, right?
So then we would go and we would say, “Okay, fine. You have this tool that we built, but don’t think about that. Think about what is the ideal tool that you need and let’s find out how much of this, this satisfies, right. And then whatever it doesn’t, we will accept that as feedback. And then we’ll go back and we’ll see and think about it and all that. And we will share with you what our priorities are. You tell us if this is making sense to you or not, and then we’ll keep this communication going.” That is a big evolution.
Kovid Batra: I totally relate to that. But I haven’t been like being back and forth on this thought of bringing in opinions and then taking a decision rather than just taking a decision and then like pushing it. I think it’s the matter of the kind of people you’re working with. You have to make a wise choice that whom you want to listen to and whom you don’t want to. Both things can backfire. I’ve actually experience both, uh, the same happened.
Vilas Veeraraghavan: Oh yeah. You don’t want to. Yeah, obviously, what, it goes without saying that there is gonna be some people who are, uh, giving you the right advice, right? And some people are just complaining because they are complaining. That’s it.
Kovid Batra: Yeah.
Vilas Veeraraghavan: Right? Uh, oh yeah, you have to separate that. But I’m saying there’s two ways to do this, right? Like when you, when you find that initial adoption starts hitting and all that, you can’t go into your shell and be like, “Okay, that’s it. My job is done. People will keep.” So that is what we, I felt like over a brief amount of time, right? When we said, “No, it’s all working just fine. Like, why do you, what are you complaining about?” And then I realized, I don’t know if maybe other folks in my team realized it earlier, but I realized it as a strategy. We needed to change that. And that put a very different face on our team because our team then started getting welcomed into meetings, which we originally were never a part of. It allowed us to see, uh, into their decision process because they were like, “Oh no, it’s important for you to know this because there is a lot of dependency on tools. We can’t change this process, but maybe we can adjust the tools and the settings to help us with this.” Right? So it was a very different perspective. And that learning, I was able to carry it into like other, uh, other initiatives, projects, companies, all of that. It has definitely served me well. Even now, if I’m listening to someone, I’ll usually say, “What would you do if you were in this space?” Right. And then let’s talk about it. Right. Very open. Um, but it is, it is important to have ego outside.
Kovid Batra: Yeah, totally. So I think it’s a very good point you just mentioned, like, uh, taking that constant feedback in some or the other form. But when you’re dealing with large teams, large systems, uh, I have got a sense that you need to have a system in place along with 1-on-1s and discussions with the people. So I’m sure you are focusing on making the delivery, uh, more efficient, faster, the quality should be better, less of failures, right? At the beginning of a journey, let’s say, any project, there must be something, some metrics that you define that, “Okay, this is what the current scenario is. And during the phase, these are our KPIs which we need to like look at every time, every 15 days or 30 days.” And then finally, when you are putting an accomplishment mark to your change that you have brought in, there is a goal that you must be hitting, right? So during this whole journey, what were your benchmarks? What were your ways of evaluating that system data? So that you are always able to like, most of the time it’s like, it’s for our own benefit. Like we know things are working or not. And at the same time you’re working with so many teams, so many stakeholders, you have some factual things in front of you saying, “Okay, this is what has changed.”
Vilas Veeraraghavan: Sure. Um, I’ll say this, um, we, the team used to do regular road shows, which means we would go around to different teams. We would have weekly and monthly meetings where we would showcase what’s coming, what’s happened, how this is a fit for, and we would try to always do something where you would demo this with the team that you’re talking to. We will demo it with something that they are doing, right, saying, “Hey, look, this is a build that you wanted to run. You want it to slow down all that. So you wanted it to speed up and it’s slow right now. This is how much we sped it up and all that.” So that is a roadshow thing. The reason I’m mentioning that is because that brings me to the metrics, right? Metrics, when we started, um, in the sense of day-to-day metrics, um, evolved over time, uh, till like, when I left, right? In the sense that at the very start, our metric was adoption, obviously, when we started creating the tool and sending it out. So for us, for us, it was an option. The mission statement for us was we wanted to get code into production in less than 60 minutes. So this was, when I say ‘code to production’, it is not just any code. It’s code that is tested. So, uh, which means we, we had to build it fast. We had to run unit tests. We had to run integration tests. We’ve also, uh, intended to run performance evaluation, performance testing, right? And then deploy it without having to go trouble the, the, the team again for details, right? Deploy it or, or at least make it ready to deploy. And then you obviously, have some gate that will say, “Okay, ready to deploy. Check.” Someone checks it and then it goes to product, right? We wanted this process to take 60 minutes or less. So that was the very mission statement kind of thing.
Kovid Batra: Got it, got it, yeah.
Vilas Veeraraghavan: But the metrics evolved over time. So initially, it was adoption, like how many people are using this tool? Um, it was about, uh, some common things, for example, um, a lot of folks within Walmart were using different code repositories, right? All of them, because they’re maintained by different parts of the organization. But because we unified those, we started checking, okay, is everything in one place? What is this amount of code that is maybe not in a secure space? Or something like that. Like that became an open thing to share. And we got a lot of partnership from our sister teams in InfoSec, in, uh, like all of these compliance areas, they started helping us a lot because they established policies that became metrics for us to measure. So just like I said, how secure is the code base? That is a great policy saying, “We need to have secure codebases that do not have high-level and medium-level vulnerabilities.” That meant we could measure those by doing code scans and saying, “Okay, we still have these many to go. We can point out exactly what teams need to do what.” And then we would slide in our tool saying, “Hey, by the way, this tool can do it for you if you just did this.” And so, immediately, it affected adoption, right? So, so that is how we started off with metrics.
Uh, but over time, uh, as we consolidated our, the space, we realized that, uh, I mean, once adoption was at like a 75, 80 percent kind of thing, we realized that we didn’t need to track it. I mean, then it’s like diminishing returns. It’ll take its time. The long tail is long. It’ll take time. Uh, at that time we switched, uh, to looking at more efficiency metrics. So which means we wanted to see how much is the scale costing us as a team. Like, are we scaling well to handle the load of builds that are coming to us, right? Are we, are the builds slowing down week over week for other teams, right? Things like that. So that is how we started seeing it because we wanted to get a sense of how much is the developer spending on things like long builds. So if you’re spent, if you’re like, “Oh, I start this build and I have to go away for an hour and come back.” It is a serious loss of productivity for that person. The context switch penalty is high, right? And when you come back, you’re like, “I forgot what I was even doing.” So we wanted to minimize that. So it became about efficiency metrics and that led to the goals and the strategy that we had to decide for the next year. Okay, we need to fix this one next time. So it was an adoption as much as saying, “Okay, make sure that we are still continuing on the, uh, what is the roadshows and things like that, but we’ll shift our attention to this.” So in the roadshows, we will call out those metrics. So you would start the discussion with saying, “Here is where we are right now.” There were publicly accessible dashboards, which is another thing that we believed truly as a DevEx team or a dev enablement team is every action that we take is very public. In a sense, it should be to all the organizations, public to the organization because that’s our customer, right? So we need to tell them exactly where we do, what we’re doing. The investment in money comes from these people, right? The other VPs or the execs are sponsoring this. So they need to see where their money is going. And so it was like transparency was key, and that’s why metrics were helpful. We showed them all the way from adoption to tuning to efficiency. That’s how sort of the thing went.
Kovid Batra: Cool. I think this was really, really interesting to know this whole journey, the phases that you have had. Just in the interest of time, I think we’ll have to just take a pause here, but, uh, this was amazing, amazing discussion that I’ve had with you. Would you like to share a parting advice or something for people who are maybe stepping into this role or are into this role for some time, anything you want to share with them?
Vilas Veeraraghavan: I want to, first of all, thanks, Kovid. This is, this is great. Uh, I, I really enjoyed this conversation. Um, and I also appreciate the curiosity you had, uh, to have this discussion in the first place. So, thanks for that. Um, message is simple, right? I don’t know how this happens, but DevEx never used to be cool in the past, right? In a sense that DevEx felt like one of those things that people would say, “Hey, you’re doing DevEx. You’re not necessarily releasing features.” But in reality, there were tons of features that, that the feature teams needed to deliver their features that we had to create before they did this. DevEx teams needed to be three to six months ahead of where the feature teams are so that when it comes to delivery, feature teams are not waiting on tools. We have to be giving it ready. So I believed it was cool back then, but I’m very happy to hear that DevEx is actually turning cooler because there is a lot of industry backing about it, right? Like, so there’s a lot of push, a lot of people talking about it, like yourself, uh, and we, like, we are doing right now. My only advice is, for those who are interested in it, I would suggest at least speaking to the right people so you know what the opportunities look like, right, before you say no. That’s all I ask.
Kovid Batra: Perfect. All right, that’s our time. Bye for now. But we would love to have you on another episode talking more about DevOps, DevX, dev productivity. Thanks, Vilas. Thank you for your time.
Vilas Veeraraghavan: Yeah. Thanks, Kovid. I’m happy to return anytime.
In this DORA exclusive webinar, hosted by Kovid from Typo, notable software engineers Dave Farley and Denis Čahuk discuss the profound impact of DORA metrics on engineering productivity.
Dave, co-author of 'Continuous Delivery,' emphasized the transition to continuous delivery (CD) and its significant benefits, involving systematic quality improvements and efficient software release cycles. Denis, a technical coach and TDD/DDD expert, shared insights into overcoming resistance to CD adoption. The discussion covered the challenges associated with measuring productivity, differentiating between continuous delivery and continuous deployment, and the essential role of team dynamics in successful implementation. The session also addressed audience questions about balancing speed and quality, using DORA metrics effectively, and handling burnout and engineering well-being.
Kovid Batra: All right. So time to get started. Uh, thanks for joining in for this DORA exclusive webinar, The Hows and Whats of DORA session three, powered by Typo. I am Kovid, founding member at Typo and your host for today's webinar. With me today, I have two extremely passionate software engineers. Please welcome the DORA expert tonight, Dave Farley. Dave is a co-author of award-winning books, Continuous Delivery, Modern Software Engineering, and a pioneer in DevOps. Along with him, we have the technical coach, Denis Čahuk, who is TDD, DDD expert, and he is a stress-free high-performance development culture provider in the tech teams. Welcome to the show, both of you. Thank you so much for joining in.
Dave Farley: Pleasure. Thank you for having me.
Denis Čahuk: Thank you for having me.
Kovid Batra: Great guys. So I think we will take it one by one. Uh, so let's, let's, let's start with, uh, I think, uh, Dave first. Uh, so Dave, uh, this is a ritual that we follow on this webinar. You have to tell us about yourself, uh, that your LinkedIn profile doesn't tell. So you have to give us a quick, sweet intro about yourself.
Dave Farley: Okay. Um, I'm a long-time software developer who really enjoys problem-solving. I really enjoy that aspect of the job. I, if you want, if you want to get me, get me to come and work at your place, you tell me that the problem's hard to solve. And that's, that's the kind of stuff that I like, and I've spent much of my career doing some of those hard to solve problems and figuring out ways in which to make that easier.
Kovid Batra: Great. All right. So I think, Dave, uh, apart from that, uh, anything that you love beyond software engineering that you enjoy doing?
Dave Farley: Yeah, my wife says that my hobby is collecting hobbies. So, so I'm, I'm a guitarist. I used to, I used to play in rock bands years ago. Um, I, until fairly recently, I was a member of the British aerobatics team, flying competition aerobatics in a 300 horsepower, plus 10, minus 10 G, uh, aerobatic airplane, which, which was awesome, but, uh, I don't do that anymore. I've stopped very recently.
Kovid Batra: That's amazing, man. That's really amazing. Great. Thank you. Thank you so much for that, uh, intro about yourself and, uh, Denis over to you, man.
Denis Čahuk: Um, like Dave, I really like problem solving, but, but I like involving, uh, I spent the beginning of my career in focusing too much on the compiler and I like focusing on the human problems as well. So how, what, what makes the team tick and in particular with TDD, it really, really scratched an itch about what makes teams resistant and what makes teams a little bit more open to change and improvement and dialogue, especially dialogue. Uh, that has become my specialty since. So yes, I brand myself as a TDD, DDD coach, but that's primarily there to drive engagement. I'm, I'm super interested in engineering leadership and specifically what drives trends and what helps people, what helps, uh, engineers, engineering teams overcome their own resistance, sort of, if they're in their own way, you know, why is that there, how to, how to resolve any kind of, um, blockers, let's say, human blockers, not, not, not the compiler kind, uh, in engineering things. I don't plan any planes, but I do have, I do share, uh, Dave's passion for music. So I do have a guitar and, uh, the drum there behind me. So whenever I'm not streaming or coding, I am jamming out as much as I can.
Kovid Batra: Perfect. Perfect, man. All right. So I think it's time we get started and move to the, to move to the main section. Uh, so the first thing that I love to talk to you, uh, Dave first, uh, so you have this, uh, YouTube channel, uh, and it's not in your name, right? It's, it's Continuous Delivery. Uh, what, what makes Continuous Delivery so important to you?
Dave Farley: Somebody else said to, this to me very recently, which, which I agree with, which is that I think that Continuous Delivery, without seeming too immodest, because my name's associated with it, but I think it represents a step change in what we can do as software developers. I think it's a significant step forward in our ability to create better software faster. If you embrace the ideas of continuous delivery, which includes things like test-driven development, in DDD, as Denis was describing, and is very team-centered as well, which Denis was also talking about. If you, if you embrace those ideas and adopt the disciplines of continuous delivery, which fundamentally, all devolve into one idea, which is working software is always in a releasable state, then you get quite dramatically better outcomes. And I think without too much fear of contradiction, continuous delivery represents the state of the art in software development. It's what the best organizations at software development do. And so, I think it's an important idea and it's as I said, although I sound rather immodest because I'm one of the people that helped at least put the language to it, but people were doing these things, but Jez, Jez and my book define the language around which continuous delivery talking is usually structured these days. Um, and so, so I think it's an important idea and I think that software engineering is one of the most important things that we do in our society and it matters a lot and we ought to be better at it as an industry and I think that this is how we get better at it. So, so I get an awful lot of job satisfaction and personal pleasure on trying to help people on their journey towards achieving continuous delivery.
Kovid Batra: And I think you're being just modest here. Your book just didn't define or give a language there. It did way, way more than that. And, uh, kudos to you for that. Uh, I think my next question would be like, what's that main ingredient, uh, that separates a team following CD and a team not following CD? What do you think makes the big difference there?
Dave Farley: There are some easy answers. Let me just tackle the difficult answer first, because I think the difficulty with continuous delivery is that the idea is simple, but it's so challenging to most people that it's very difficult to adopt. It challenges the way in which we think about software. I think it challenges to some degree. I'm a bit of a pop psychologist. I think in many ways it challenges, um, our very understanding of what software is to some extent, and certainly what software development is. And that's difficult. That means that it changes every person's role in undertaking this. It, as I said already, it's a much more team centered approach, I think, uh, to be able to achieve this permanent releasability of our software. But fundamentally, I think if you want to boil it down to more straightforward concepts to think about, I think that what we're talking about here is kind of applying what I think of as a kind of scientific rationalism to solving problems in software. And so the biggest part of that, the two biggest ideas there, from my point of view, are working in small steps and essentially, treating each of those steps as a little experiment and assuming that we're going to be wrong. So it's always one of the big ideas in science is that you start off assuming that your ideas are wrong, and then you try and figure out how and why they're wrong. I think we do the same thing in continuous delivery and software engineering, modern software engineering. We try to figure out how can we detect where our ideas are wrong, and then we try and detect where they're wrong, in those places and find out if they're wrong or not and then correct them. And that's how we build a better software. And so this, I think that goes quite deep and it affects quite a lot about how we undertake our work. But I think that one of the step changes in capability is that I think that previous thinking about software development kind of started off from the assumption that our job is to get everything perfectly right from the start. And that's simply irrational and impossible. And so, instead of taking a more scientific mindset and starting off assuming that we will be wrong, and so we give ourselves the freedom to be wrong and the ability to um, recover from it easily is almost the whole game.
Kovid Batra: Got it. I think Denis has a question. He wants to, yeah, please go ahead.
Denis Čahuk: Sure. I'm going to go off script. I think I like that distinction of psychologist. Sometimes I feel myself, find myself in a similar role. And I think the core disagreement comes from this idea of a lot of engineers, organizational owners, CTOs don't like this idea that their code is an experiment. They want some like certain assurances that it has been inspected and that it's, it's not, it's not something that we expect to fail. So from their perspective, non-CD adopters think that the scientific rationale is hard inspection towards requirements rather than conducting an experiment. And I see that, um, sort of providing a lot of resistance regarding CD adoption cause it is very hard to do, or it's very hard to come from that rationale and say, okay, we're now doing CD, but we're not doing CD right now. We're adopting CD right now. So we're kind of doing it, but not doing it. And it just creates a lot of tension and resistance in companies. Did you find similar situations? How do you, how do you sort of massage this sort of identity shift identity crisis?
Dave Farley: Yeah. Yeah I think, I think absolutely that's a thing and, and that is the challenge. It is that is to try and find ways to help those people to see the light. So I know I sound like an evangelist. Yeah, but, but I guess I see that as part of my role. But..
Denis Čahuk: You did write the book, so..
Dave Farley: Yeah, so, so, so I think this is in everybody's interest. I mean, the data backs me up. The DORA data says that if you adopt the practices of continuous delivery, you spend 44 percent as an organization more time on building new features than if you don't. That's pretty slam dunk in terms of value as far as I'm concerned, and there's lots more to it than that. But, you know, so why wouldn't anybody want to be able to build better software faster? And this is the best way that we know of so far, how to do that. So, so that seems like a reasonably rational way of deciding that this is a good idea, but that's not enough to change people's minds. And you've got to change people's minds in all sorts of different ways. Um, I think it's important to make these sorts of things, but going back to those people that you said that, you know, engineers who think it's their job to get it right first time, they don't understand what engineering is. Managers who want to build the software more quickly, get more features out. They don't understand what building software more quickly really means because if either of those groups knew those things, they'd be shouting out and demanding continuous delivery, because it's the thing that you need. We don't know the right answers first time. Look at any technology. Let alone any product and its history. Look at the aeroplane. In the first aeroplane that could carry a person under power in a controllable way was the Wright Flyer in 1903. And for the first 20 or 30 years, all aeroplanes were death traps. People were, they were such dangerous devices. But engineering as a discipline adopted an incremental approach to learning and discovery to improve the airplane. And by 2017, two thirds of the planet, the equivalent of two thirds of the population of the planet, flew in commercial airliners and nobody was killed. That's what engineering does. It's an incremental process. It doesn't, we don't, we never ever, ever get it right first time. The iPhone, the first iPhone didn't have an app store, didn't have a camera, didn't have Siri, didn't have none of these things, didn't..
Denis Čahuk: Multitasking.
Dave Farley: Didn't have multitasking, all of these things. And now we have these amazing devices in our pockets that can do all sorts of amazing things that the original designers of the iPhone didn't actually predict. I'm sure that they had vague wishes in their minds, but they didn't predict them ahead of time. That's not how engineering works. So the way that engineering works is by exploration and discovery. And we need to, to be good at it, we need to organize to be good at exploration and discovery. And the way that, you know, so if we want to build things more efficiently, then we would, we need to adopt the disciplines that allow us to make these mistakes and accept that we will and look, you know, detect them as quickly as we can and learn from them as quickly as we can. And that's, you know, that's why, to my mind, you know, the results of the DORA thing, so there's no trade-off between speed and quality because you work in these small steps, you get faster feedback on, on whether your ideas are good or bad. So those small steps are important. And then when you find out that they're a bad idea, you correct them. And that's how you get to good.
Kovid Batra: Totally. I think, uh, one very good point, uh, here, we are sure like now CD and other practices like TDD impact engineering in a very positive way, improving the overall productivity and actually delivering value and the slam dunk like 44 percent more value delivered, right? But when it really comes to proving that number to these teams, uh, do you, like, do you use any framework? Do you use like DORA or SPACE to tell whether implementing CD was effective in a way? How do you measure that impact?
Dave Farley: No, most, mostly I recommend that people use the DORA metrics. Um, I, let me just talk momentarily about that because I think that that's important. I think the work of Nicole and the rest of the team in starting off the DORA was close to genius in identifying, as far as I can think of, the only generic measures in software. If you think about what, what the, the DORA metrics of stability and throughput measure, um, it's, um, the quality of the software that we produce and the rate at which we can produce software of that quality. That stability is the quality. Throughput is the efficiency with which we can produce software of that quality. Those are fundamental. They say nothing at all about the nature of the problem we're solving, the technology we're using, or anything else. If you're writing, if you're configuring SAP to do a better job of whatever it is that you're trying to do, that's still a good measure of success, stability and throughput. Um, if I'm writing some low-level code for an operating system, that's still a good measure of success. It doesn't matter. So, so we have these generic measures. Now they aren't enough to measure everything that's important in software. What they do is that they tell us whether we're building software right. They don't tell us whether we're building the right software, for example. So we need different kinds of experiments to understand other aspects of software. But I don't think there's much else. There's nothing else that I can think of that's in the same category. Stability and throughput in terms of the generosity of those measurements. And so, if you want a place to start of what to measure, start with stability and throughput and then figure out how to measure the other things out because they're going to be dependent on your context.
I'm a big fan of Site Reliability Engineering as a model for this. It talks in terms of, um, um, SLOs and SLIs, Service Level Indicators and Service Level Objectives. So the Service Level Indicator is what measure will determine the success of this service. So you identify, for every single feature, you identify what you should measure to know whether it's good or not. And then you set an objective of what score on that scale you want to achieve for this thing. That's a good way of measuring things, but it's kinda difficult. The huge difference is it's completely contextual, not even application by application, but feature by feature. So one feature might improve the latency, another feature might improve the rate at which we recruit new customers. And we've got to figure out, you know, that's how we get experimental with those kinds of things, by being more specific about and targeted with what we measure. I am skeptical of most of the generic measures. Not because I don't want them, it's just that I don't think that most of the others are generic and do what we want them to. Um, I'm not quite sure what I make of the SPACE framework, which is Nicole's new work on measuring developer, developer productivity. She's very smart and very good at the research-driven stuff. Uh, I spoke to her about some of this stuff on my, my podcast and, um, she had interesting things to say about it. I am still nervous of measuring individual developer productivity because as Denis said in his introduction, one of the really important things is how well a team works. So I think modern software development. unless it's building something trivial usually, is a team game. It's a matter of people coming together and organizing themselves in a way to be able to achieve some goal. And that takes an awful lot, and you can have people working with different levels of skill, experience, diligence, who may be still contributing strongly to the team, even if they're not pulling their weight in other respects. So I think it's a complicated thing to measure, a very human thing to measure. So, so I'm a bit suspect of that, but I'm fairly confident that Nicole will have some data that proves me wrong. But I, you know, that's, that's my position so far.
Kovid Batra: Totally makes sense. I think with almost all the frameworks, there have been some level of challenges and so is with DORA, SPACE, but I think in your experience, when, when you have seen, uh, and you have helped teams implement such practices, uh, what do you think have become the major reasons where they get stuck, not implementing these frameworks, not implementing proper engineering metrics? What, what, what stops them from doing it? What stops them from adopting it?
Dave Farley: I think specifically with using DORA, um, there are some complexities. If you, if you, if you are in a, a regular kind of organization that hasn't been working in the ways in which we've been talking about so far, um, then measuring stuff, just, just measuring stuff is hard. You're not used to doing it. The number of organizations that I talked to that couldn't even tell you how much, excuse me, time was spent on a feature, they don't measure it. They don't know. And so just getting the basics in, the thinking in, to be able to start to be a little bit more quantitative on these things is hard. And that's hard for people like us probably to get our heads around a little bit because when you've got a working deployment pipeline, this stuff is actually pretty easy because you just instrument your deployment pipeline and it gives you all the answers pretty much. So I think that there's that kind of practical difficulty, but I don't think that's the big ticket problem. The big ticket problem is just the mindset, my, I am old enough and comfortable enough in my shoes to recognize that I'm a grumpy old man. Um, and part of my grumpy old manness is to look at our industry and think that our industry is largely a fashion industry. It's not a technical industry. And there's an awful lot of mythology that goes on in the software industry. That's simply nothing to do with doing a good job. It's just what everybody thinks everybody else is doing. And I think that's incredibly common. And you've got to overcome that because if you're talking to a team, I'm going to trample on some people's sacred cow right now, but if you're talking to a team that works with feature branching, the evidence is in. Feature branching doesn't work as well as trunk-based development. That's more learning that we got from the DORA metrics, measuring those. Teams that work with feature branches build slightly lower quality code and they do it slightly more slowly than teams working on trunk. Now the problem is, is that it's almost inconceivable how you can do trunk-based development safely to people that buy into the, what I would think of as the mythology of feature branching. The fact that it, it, you can do it safely and you can do it safely at scale with complicated software, they start to deny because they assume that, that, that you can't, because they can't think of how you would do it. And that's the kind of difficulty that, that you face. It's not that it's a rational way of thinking about it, because I, I think it's very easy to defend why trunk-based development and continuous integration are more true, more, more, more accurate. You know, you, you organize things so that there's one point of truth. And in feature branching, you don't have one point of truth, you have multiple points of truth. And so it's clear that it's easier to determine whether the one point of truth is correct than deciding that multiple points of truth, that you don't know how you're going to integrate them together yet, is correct. You can't tell.
So it's, it's, it's tricky. So I think that there are rational ways of thinking that help us to do this, which is why I started, I've started to think about and talk about what we do as engineering more than as craft or just software development. If we do it well, uh, it's engineering and if we do it well and use engineering, we get a better result, which is kind of the definition of what engineering is in another discipline. If we work in certain ways, we do get better results. I think that's important stuff. So it's very, very hard to convince people and to get them away from their, what I would think of as mythologies sometimes. Um, and it's also difficult to be able to have these kinds of conversations and not seem very dogmatic. I get accused of being dogmatic about this stuff all of the time. Being arrogant for a moment. I think there's a big difference between being dogmatic and being right. I, I think that if we talk about, you know, having evidence like the DORA metrics, having a model like the way that I describe how these things stitch together and the reasons why they work and just having a favorite way of doing things, there's a difference between those things. I don't like continuous integration because it's my favorite. I like continuous integration because it works better than anything else. I like TDD not because I think it's my ideal for designing software. It's just that it's a better way of designing software than anything else. That's my belief. And, and so it's difficult to have these kinds of conversations because inevitably, you know, my viewpoints are going to be covered, colored by my experiences and what I've seen. But I try hard to be honest myself as an aspiring engineer and scientific rationalist. I try to be true to myself and try to critique my own ideas to find the holes in them. And I think that's the best that we can do in terms of staying sane on these things.
Kovid Batra: Sure. I think on that note, I think Denis would also resonate with that fact, because last time when Denis and I were talking, he mentioned about how he's helping teams implement TDD and like taking away those roadblocks time to time. So I'm sure Denis has certain questions around that, and he would like to jump in. Denis, uh, do you have any questions?
Denis Čahuk: I have a few, actually, I need your help a little bit to stay on topic. Um, so Dave mentioned something really important that sort of touched me more than the rest, which is this sort of concern for measuring individual performance. And I've been following Nicole's work as well, um, especially with SPACE metrics and what the team topology community is doing now with flow engineering. Um, there, there is a, let's say, strong interest in the community and the engineering intelligence community to measure burnout, to measure.
Dave Farley: Mm-Hmm.
Denis Čahuk: So, so the, so to clarify, do we have a high-performing team that's burnt out or do we have a healthy team that's low-performing? And to really, and to really sort of start course correct in the right areas is very difficult to measure burnout without being individual because of the need for it to be a subjective experience. Um, and I share Dave's concern where the productivity metrics are being put in the same bucket as the psychological safety and burnout research. So, I'm wondering when you're dealing with teams, because I see this with product engineering, I see this with TDD, I see this with engineering leaders who are just resistant to this idea of, you know, are we burned out? Are we just tired and we're following the right process? Or is the process correct, but it's being implemented incorrectly? How do you, how do you navigate this rift? I mean, specifically, do you find any quick, uh, lagging indicators from the DORA metrics to help you a little bit, like to cajole the conversation a little bit more? Um, or do you go to other metrics, like SPACE metrics, et cetera, to sort of, or surveying to help you start some kind of continuous delivery initiative? So a lot of teams who are not doing CD, they do complain about burnout when they're sort of being asked to start just measuring everything, just out of, um, out of, I would say, fatigue.
Dave Farley: Yeah, and, and, uh, and, uh, it gets to the, uh, Matt and Manuel's thing from the team, the Team Topologies guys, you know, uh, uh, description of cognitive load. I know it's not their, their, their idea originally, but, but, but applying it to software teams. It's, it, I, I think burnout is primarily a matter of, a mix of cognitive load and excessive cognitive load and the freedom to direct your own destiny within a team, you know? You need, you need kind of the Daniel Pink thing, autonomy, mastery and purpose. You need freedom to do a good job. You need enough scope to be, and, and that those are the kinds of things that I think are important in terms of measuring high-performance teams. I think that it's a false correlation. Um, I know that recent versions of the, the DORA reports have thrown up some, what seemed to me to be, um, counterintuitive findings. So people saying things like working with continuous integration has, is correlated with increased levels of burnout. That makes no sense to me. I put this to, to Nicole when I spoke to her as well, and she was a little skeptical of that too, in terms of the methodology for collecting the data. That's no, it's no aspersion on the people. We all get these things wrong from time to time, but I'm distrustful of that result. But if that is the result, you know, I've got to change my views on things. But my experience, and that's in the absence of, of hard data, except that previous versions of DORA gave us hard data and now the finding seems to have changed. But my experience has been that teams that are good at continuous delivery don't burn out, because it's, it's sustainable. It's long-term sustainable. The LMAX team that, that I led in the beginning of that team have been going, how long is it now? Uh, about 15 years. And those, those people weren't burning, people weren't burning out, you know, and they're producing high-quality software still, um, and their process is working still. Um, so I I'm not, I, I think that mostly burnout is a symptom of something being wrong. Um, and something being wrong in terms of too much cognitive load and not enough control of your own destiny within the team. Now, that's complicated stuff to do well, and it gets into some of the, for want of a better term, softer things, the less technical aspects of organizing teams and leading teams and so on. So we need leaders that are inspirational, that can kind of set a vision and a direction, and also demonstrating the, the right behavior. So going home on time, not, not working all hours and, you know, not telling people off if things go wrong, if it's not their fault, and all these kinds of things. So we need.. The best teams in my experience, take a lot of personal responsibility for their work, but that's, that's doing it themselves. That's not externally forced on them, and that's a good thing because that makes you both be prouder of the things that you do and more committed to doing a good job, which is in everybody's interest.
So, so I think there's, I think there's quite a lot to this. And again, it's, none of it's easy, but I think that shaping to be able to keep our software in a releasable state and working in small steps, gathering feedback, focusing on learning all of those techniques, the kind of things that I talk about all the time are some of the tools that help us to at least have a better chance of reducing burnout. Now that, there are always going to be some individuals in any system that get burnt out for other reasons. You get burnt out because of pressures from home or because your dog died or whatever it might be. Um, but, you know, we need, we need to treat this stuff seriously because we need to take care of people even if that's only for pragmatic commercial reasons, that we don't want to burn people because that's not going to be good for us long term as an industry. I, I, I, that's not more the primary reason why I would do it. But if I'm talking to a hard-nosed commercial person, I still think it's in their interest to treat people well. And so, and so we need to be cautious of people and more caring of people in the workplace. It's one of the things that I think that ensemble programming, whether it's pairing or mobbing, are significantly better for, and probably that's counterintuitive to many people, because there's a degree to which pair programming in particular applies a bit of extra pressure. You're a bit more on your game. You get a bit more, more tired at the end of each day's work, but you also build better friendships amongst your, your, your team workers and you learn from one another more effectively and you can depend on one another. If you're having a bad day, your, your, your pair might pick up the pace and be, you know, sustaining productivity or whatever else. There are all these kinds of subtle complex interactions that go on to producing a healthy workspace where, where people can keep at it for a long, you know, a long time, years at a time. And I, I think that's really important.
I worked at a company called ThoughtWorks in, in the early 2000s, and during that period, ThoughtWorks and ThoughtWorks in London in particular where I worked, where I think some of the thought leaders in agile thinking, we were pushing the boundaries of agile projects at that time and doing all sorts of interesting things. So we experimented a lot. We tried out lots of different, you know, leading edge, bleeding edge, often ideas in, in development. One of those, I worked on one of the early teams in London that was doing full-blown lean and applying that to software development. Um, and one of the things that we found was that that tended to, to, to burn us out a little bit over months because it just started to feel a bit like a treadmill. There was no kind of cadence to it because you just pick up a feature off the Kanban board, you'd work on that feature, you'd deliver the feature, you'd showcase the feature, you'd pick the next feature and you'd, and so on and so on and so on, and that was it. And you did that for months on end. And we were, we were, we were building good software. We were mostly having a good time, but over, over time it made us tired. So we started to think about how to make more social variants in the way in which we could do things. And we ended up doing the same thing, but also having iterations or most people would call them 'sprints' these days, of two weeks so that we could have a party at the end and celebrate the things that we did release, even though we weren't committing to what we'd release in the next two weeks. And, you know, we'd have some cake and stuff like that at the end, and all of those sorts of human things that just made it feel a little bit more different. We could celebrate our success and forget about our losses. Software development is a human endeavor. Let's not forget that and not try and talk, turn us into cogs in a machine. Let's treat us like human beings. Sorry. I'm off-road. I'm not sure if I answered your question.
Denis Čahuk: This is great. This is great, Dave. No need to apologize. We're enjoying this and I think our audiences as well.
Kovid Batra: I'm sure. All right. So, Denis, uh, do you have any other question?
Denis Čahuk: Well, I would like to follow up with what the story with the, with the ThoughtWorks story that Dave just mentioned You know, you mentioned you had evidence of high performance in that team. You know, we tend to forget that lean is primarily a product concern, not an engineering concern. So it sort of has to go through the ringer and to make sure, you know, does it apply to software engineering as well? And I have similar findings with things like lean, things like Kanban, particularly Scrum or the bad ways of doing Scrum is that it is, it can, it can show evidence of high performance, but not sustainably due to its lack of social component. And the retrospectives are a lame excuse at social components. It's just forcing people to judge each other and usually produces negative results rather than positive ones. So I'm wondering, you just mentioned this two-week iteration cycle for increments, but also you're leaning towards small batches. Are you still adamant on like this two-week barrier for social engagement? So, so, so what we There does seem to be a difference.
Dave Farley: Yeah, so, so, so what we did is that we retained the lean kind of Kanban style planning. We just kept that as it was, but we kind of overlaid a two-week schedule where we would have a kickoff meeting at the start of an iteration, and we would have a little retrospective at the end of an iteration and we, you know, we would talk about the work that we did over that period. So, so we had this, this kind of different cycle and that was purely human stuff. It wasn't even visible really outside of the team. It was just the way that we organized our work so that we could just look ahead for, for, for what's coming downstream as far as our Kanban board said today, and look back at what, what, what we'd, you know, what we delivered over the pre, you know, the previous iteration. It was just that kind of thing. And that was enough to give us this more human cycle, you know, because we could be, we could be looking forward to, so I'm releasing this feature, we're nearly at the end, you know, we'll talk about that tomorrow or whatever else it is, you know, and it was just nice to kind of reconnect with the rest of the team in that way. And it just, we used it essentially, I suppose you could pragmatically look at it as just as a meeting schedule for, for, for the team-level stuff. I suppose you could look at it like that, but it was, it felt like a bit more, more than that to us. But I've, by default, if I'm in a position to control these things, that's how I've organized teams ever since. And that, that's how, that's how we worked at LMAX where we built our financial exchange. That's the organization that's been going for 15 odd years, um, doing this real high-performance version of continuous delivery.
Denis Čahuk: But to pick your brain, uh, Dave, sorry to interject. When you said, you separated out the work cycles from the social cycles, that does involve daily deployments, right? Like daily pairing, daily deployments. So the releases were separate from the meeting, uh, routine.
Dave Farley: Yes. Yeah, so, so, so we, we were, we were doing the, we were doing the, the, the, the Kanban continuous delivery kind of thing of when a feature was finished, it was ready to go. So, so we were working that way. Um, there was some limitations on that sometimes, but, but, but pretty much that, that's a very close approximation have been an accurate statement, at least. Um, so, so we, we were working that way. Yeah. So we'd really, we'd essentially release on demand. We'd, we'd release when, you know, at every point when we were ready. And that was more often, usually, than once every two weeks. So the releases weren't, weren't forced to be aligned with those two week schedules. So it wasn't a technical thing at all. It was, uh, it was primarily a team social thing, but, but it worked. It worked very well.
Denis Čahuk: I really liked the brief mention about SPACE and Nicole's other work. Kovid and I are very active in the Google community. It's sort of organizing DORA-related events. And Google does have a very heavy interest in measuring well-being, measuring burnout, or just, you know, trying to figure out whether engineers and managers are actually really contributing or whether they're just slowing things down. And it's very hard to just judge from DORA metrics alone, or at least to get a clearer picture. Um, is there anything else you use for situational awareness? What would you recommend for either evidence of micromanagement, or maybe the team wants to do TDD, but there's sort of an anti-pairing stigma, if you have to, how would you approach, um, the sort of more survey-oriented, SPACE-oriented?
Dave Farley: From my experience, and I'm saying that with reservations, not with not, not, not boasting. I'm not saying because I've got great experience, but, but from my experience, I, I'm a little bit wary of trying to find quantity of ways of evaluating those things. These are very human things. So stuff like some of the examples that you mentioned, I, I've spent a significant proportion of my career as a leader of technical teams and I've always thought that it was a failure on my part as a leader of a technical team if I don't know, notice that somebody's struggling or that somebody's not pulling their weight or, or I haven't got the kind of relation, relationship where the team, if I, if I don't, if I don't know something, the team doesn't come and tell me and then I can help. I'm kind of in a weird position, for example, I'm in a slightly weird position in terms of career reviews. I think that as a manager or a leader, if you don't know the stuff that you find out in a review, you're not doing your job. You should be knowing that stuff all of the time. And it's kind of the Gemba thing. It's kind of walking around and being with the team. It's it's spending time and understanding the team as a member of the team because that's what you are. You're not outside it. You're not different. You're a member of the team, so you should feel part of that and you should be there to help, help people guide their careers and steer them in the right direction of doing better and doing, doing good things from their point of view and from the organization's point of view. But to do that, you've got, you've got to understand a little bit about what's going on. And that feels like one of those very, very human things. It's about empathy, and it's about understanding. It's about communication, and it's about trust between, between the people. And I'm not quite sure how well you can quantify that stuff.
Denis Čahuk: I coach teams primarily through this kind of engagement, to rebuild trust.
Dave Farley: Yes.
Denis Čahuk: So I have found I have zero success rate in adopting TDD if the team isn't prepared to pair on it.
Dave Farley: Yeah.
Denis Čahuk: Once the team is pairing, once the team is assembling, TDD, continuous delivery, trunk-based\ development, no problem. Once they're prepared to sort of invest time into each other, just form friendships or if nothing else, cordial acquaintances, sort of, we can sort of, bridge that gap of, well, I want you to write a test so that he can go home and spend time with his kids without worrying about deployment. So that, that is the ulterior motive, not that there is some like, you know, fairytale fashion metric to tick a box on.
Dave Farley: Yeah.
Denis Čahuk: Um, since you mentioned quantitative metrics, to sort of backtrack a little bit on that and tie it together with TDD, did you find any lagging indicators of a team that, that did adopt TDD after you came in that, you know, what, what are the key metrics that are getting better, different after TDD adoption, or maybe leading indicators or perhaps leading indicators that say, hey, this more than anything else needs attention?
Dave Farley: So, so, so, so I think, I think, I think mostly, uh, stability. So, so it's a lagging indicator, but I, I think that's the measure that, you know, tells us whether you're doing a good enough job on quality. And if you're not doing TDD, mostly the data says you're not doing a good enough job on quality. There's a lot of other measures that kind of reinforce that picture, but fundamentally in terms of monitoring our performance day-to-day, I think stability is the best tool for that. Um, and, you know, so, so some, you know, so there's, I, I, I'm interested as a technologist from a technical point of view in some of the work that, um, Adam Thornhill, uh, uh, and code scene are doing in terms of red code and things like that. So patterns of use in code, the stuff that changes a lot and monitoring the stuff that changes a lot versus this stuff that, you know, where, where defects happen and all that kind of stuff. And so, you know, the crossover between sort of cyclomatic complexity and other measures of complexity in code and the need to change it a lot and all that kind of stuff. I think that's all interesting and kind of, but I see that as reinforcing this view of how important quality is. And fundamentally, we need to find ways of doing less work, managing our cognitive load to achieve higher quality, and that's what TDD does. So TDD isn't the end in itself. It's, it's a tool that gives us, that pushes us in the direction of the end that matters, which is building high-quality software and maintaining our ability to change it. And that's, again, that's what TDD does. So, so, so I think that TDD influences software in some deep ways that people that don't practice TDD miss all of the time.
And it's linked to lots of other practices. Like you said, um, you know, pairing is a great way of helping to introduce TDD, uh, particularly for our people that already know how to do TDD in the team. That's, that's the way that you spread it, certainly, but it's, I can't, I can't think of many things that, that, as I say, I'm wary of measures. I tend to either use tactical measures that just seem right in the context of what we're doing now, sort of treating each thing as an experiment and trying to figure out how to experiment on this thing and what do I need to measure to, to do that, or I use stability and throughput primarily.
Kovid Batra: Uh, I'll just, uh, take a pause here for all of us because, uh, we have a QnA lined up for the audience. And, uh, we will try to take like 30, 30 seconds of a break here and, uh, audience, you can get started, posting your questions. Uh, we are ready to take them.
Denis Čahuk: We already have a few comments and we had, uh,
Kovid Batra: Okay. I think, uh, we can start with the questions.
Denis Čahuk: Before we go into Paul's question. Paul has a great question. I just want to preface that by saying that not this one, the DORA-related one.
Kovid Batra: But I like this one more.
Denis Čahuk: Yes.
Kovid Batra: Dave, I think you have to answer this one. Uh, where do you get your array of t-shirts?
Dave Farley: So, so, so mostly I buy my t-shirts off a company based in Ireland called QWERTEE. "QWERTEE". And if you go to, if you go to any of my videos, there's usually a link underneath them where you can get a discount off the t-shirts because we did a deal with QWERTEE because, because so many people commented on my t-shirts.
Denis Čahuk: Great t-shirts. Well done.
Kovid Batra: Yeah. Denis.
Denis Čahuk: I just wanted to, I just wanted to preface Paul's other question regarding how to measure that, you know, Kovid and I are very active in the DORA communities on the Google, Google group, and by far the most asked questions are, how do I precisely measure X? How do I correctly measure this? My team does not follow continuous delivery. We have feature branches. How do I correctly measure this metric, that metric? Before we go into too much detail, I just wanna emphasize that if you're not measuring, if you're not doing continuous delivery, then the metrics will tell you that you should probably be doing continuous delivery. And..
Dave Farley: Yeah.
Denis Čahuk: The ulterior motive is how can we get to continuous delivery sooner? Not how can we correctly measure DORA metrics and continue doing feature branching. Yeah, that's that is generally the most trending conversation topic on these groups. And I just want to take a lot of time to sort of nail, like the, it's about the business. It's about continuous delivery, running experiments quickly, smoother, safely, sustainably, rather than directly measuring any kind of dysfunctional workflow. Or even if you can judge that your workflow is bad because the metrics don't track properly, which is usually where people turn towards DORA metrics.
Dave Farley: Yeah, I would add to that as well is that even if you, even if you get the measures and you use the measures, you're still not going to convince people it's the measures enough alone aren't enough. You need, you need to approach this from a variety of different directions to start convincing people to change their minds over things, and that's without being disrespectful from those, of those people that differ in terms of their viewpoints, because it's hard to change your mind about something if you've, if you've made a career working in a certain way, it's hard to change the things that from the things that you've learned. Um, so this is challenging, and that's the downside of continuous delivery. It works better than anything else. It's the most fun way of organizing our work. It does tend to eliminate, in my experience, burnout in teams, all of these good things. You build better software more quickly working this way. But it's hard to adopt when you're not, when you've not done it before. Everybody that I know that's tried likes it better, but it's hard to make the change.
Denis Čahuk: It's a worthwhile change that manages a lot of stress and burnout, but that doesn't mean there aren't difficult conversations along the way.
Dave Farley: Sure.
Kovid Batra: All right, uh, moving on to the next one. Uh, how do you find the right balance between speed and quality while delivering software?
Dave Farley: The DORA metrics answer this question. There is no trade off, so there is no need to balance. If you want more speed, you need to build with higher quality. If you want more quality, you need to build faster. So let's just, let's just explain that a little bit because I think it's useful to just have this idea in mind because, because we have to defend ourselves because it seems, it seems like a reasonable idea that there's a trade off between speed and quality. It's just not true. But it seems like a reasonable idea. So, so if I build bad software this week and then next week, I've got a load more pressure on me to build next week's work, next week, I'm going to have all of that pressure plus all of the cost of the bad software that I wrote this week. So it's obviously more efficient if I build good software this week and then I don't have that work next week and then I could build good software next week as well. And what that plays out to is that that's where the 44 percent comes from. That's where the increase in productivity comes from. If we concentrate and organize our work to build higher quality software, we save time. We don't, we don't waste, we don't, it doesn't cost time.
Now there's a transition period. If you're busy working in a poor software development environment, that's building crap software, then, you know, it's going to take you a while to learn some of these things. So there's, there's an activation energy to get better at building software. But once you do, you will be going faster and building higher quality software at the same time because they come together. So what do we mean by fast when we talk about going fast if you want high quality software? Fundamentally, that's about working in smaller steps. So we want to organize our work into much smaller steps so that after each small step, we can evaluate where we are and whether what, whether that step that we took was, was a good one. And that's in all kinds of ways. Does my software do what I think it does? Does it do what the customer wants it to do? Is it making money in production or whatever else it is? So, so all of these things, you know, these are learning points and we need to build that more experimental mindset into the, in deep, into the way that we work.
And the smart thing to do. To optimize all of this is to make it easy to do the right things. It makes it, make it easy for us to carry out these small steps in these experiments. And that's what continuous delivery does. That's what the deployment pipeline fundamentally is for. It's an experimental platform that will give us a definitive statement on the releasability of our software multiple times per day. And that makes it easier then to, to work, to work in these small steps and do that quickly and, and get high quality results back.
Kovid Batra: Totally makes sense. Moving on, uh, Agustin, uh, why is it so, why is it so important in your opinion to differentiate between continuous delivery, continuous deployment, and how that affects the delivery process performance, also known as the DORA metrics?
Dave Farley: So, so, so, so let me first differentiate between them and then explain why I think it matters. So, so continuous delivery is working so that our software is always in a releasable state. Continuous deployment is built on top of continuous delivery. And if all of your tests pass, you just push the change out automatically into production. And that's a really, really good thing. If you can get, if you can get to that point where you can release all of the time small changes, that's probably the best way of getting this, optimising to get this really fast feedback, all the way out to your end users. Now the problem is, is that there are some kinds of software where that doesn't make any sense. There are some kinds of software for a variety of different kinds of reasons, depending on the technology, the regulation, um, real practical limitations for some reason, why we can't do that. So, Tesla are a continuous delivery company. But part of what they are continuously, continuously delivering is software embodied as silicon burnt into devices in the car. There's physics involved in burning the silicon. So you can't always release every change immediately that the software is, the software is done. That's not practical. So you have to manage that slightly differently. Uh, one of my clients, um, Siemens build medical devices and so, within the regulatory framework for medical devices that can kill people, you're not allowed to release them all of the time into production. And so, continuous delivery is the foundational idea but continuous deployment is kind of the, the limit, I suppose of where you can get to. If you're Amazon, continuous, continuous deployment makes a huge amount of sense. Amazon are pushing out changes. I think it's currently 1. 5 changes per second. It might be more than that. It might be five changes per second. Something like that. Something ridiculous like that. But that's what they're doing. And so they're able to move ridiculously fast and learn ridiculously quickly. And so build better software. I think you can think of it from a more internally focused viewpoint as that they each optimize for slightly different things.
Continuous delivery gives us feedback on whether we are, um, building things right and continuous deployment gives us feedback on whether we're building the right things. So we learn more about our product from continuous deployment by getting it into the hands of real users, monitoring that and understanding their impact. We get, and we can't get that kind of feedback any other way really than getting out to real users. We don't learn those lessons until real users are really using it. Continuous delivery though, gives us feedback on, does this do what we think it's doing? Um, is it good quality? Is it fast enough? Is it resilient enough? All of those kinds of things. We can measure those things. And we can know those before we release. So, they are slightly different things. And they do, they do balance off in different ways. They give us different levels of value. There's an excellent book that's recently been released on continuous deployment. Um, I've forgotten the name of the author. Valentina, somebody, I think. Um, but I wrote the foreword, so I should remember the name of the author. I'm very embarrassed, but it's, it's, it's a really good book, and it goes into lots of detail about continuous deployment as distinct from continuous delivery. I think, but I suppose I would say this, wouldn't I? I think that continuous delivery is the more foundational practice here, and I think that depending on your viewpoint, I think this is one of the very, very few ideas where, where Jez Humble and I would, would come at this from slightly different perspectives. I tended, I've tended to spend the latter part of my career working in environments where continuous deployment wasn't practical. I couldn't, I was never going to get my clients to, to, to do it in, in, in the environments in which they were building things. And sometimes they couldn't even if they wanted to. Um, I think Jez has worked in environments where continuous deployment was a little easier. And so that seems more natural. And so I think that kind of is why, um, some of the DORA metrics, for example, measure the efficiency based on assumptions, really, of continuous deployment.
Um, so I think, I think continuous deployment is the right target to aim for. You want to be able to release as frequently as is practicable, given the constraints on you, and you want to kind of push at the boundaries of those constraints where you can. So, for example, working with Siemens, we weren't allowed to release software into production of medical systems in clinical settings, but we could release much more frequently to non-clinical settings. So we did that, so we identified some non-clinical settings, and we released frequently to those places, in university hospitals, for example, and so on.
Kovid Batra: So I think it's almost time. Uh, and, uh, we do have more questions, but just because the stream is for an hour, uh, it's going to end. So we'll take those questions offline. Uh, I'll email the answers to you. Uh, audience, please don't be disappointed here. It's just in the interest of time that we'll have to stop here. Thank you so much, Dave, Denis, for this amazing, amazing session. It was nice talking to you and learning so much about CD, TDD, engineering metrics from you. Thank you so much once again.
Dave Farley: It's a pleasure. Thank you. Bye-bye. Thanks everyone.
Denis Čahuk: Thanks!
In this episode of the groCTO Originals podcast, host Kovid Batra is joined by Carlos Neves, the Head of Engineering at Vitality, as they explore the often challenging transition from an individual contributor (IC) to an Engineering Manager (EM).
With over 15 years of experience in engineering and leadership, Carlos shares his journey from Portugal to the UK, his initial interest in computer science influenced by a cousin, and his passion for salsa dancing. The discussion delves into the importance of gaining horizontal exposure within an organization, understanding the nuances of management beyond technical skills, and building confidence to overcome imposter syndrome. Carlos emphasizes the significance of proactive communication, trusting the team through delegation, and seeking mentorship. He shares insights into making a conscious decision to transition into management, highlighting the need for self-assessment regarding technical passions and people management skills.
The episode concludes with advice for those considering this career path and the introduction of groCTO Connect, a mentoring initiative aimed at helping technical leaders advance.
Kovid Batra: Hi everyone. This is Kovid, back with another episode of groCTO podcast. And today with us, we have our special guest, Carlos. He is Head of Engineering at Vitality, having more than 15 plus years of engineering and leadership experience. Welcome to the show, Carlos. Happy to have you here.
Carlos Neves: Thank you. It’s a pleasure to be here and share my experience with you today.
Kovid Batra: Of course, we are looking forward to a lot of learning. And before we get started on our today’s topic, which is the ‘Not-so-easy transition from an IC to an EM role’, uh, we would love to know a little bit more about you. Uh, I, I, I had a very brief intro here, but I would love to know more about you, uh, your hobbies, uh, your childhood, your teenage and how you transitioned into who you are today. So, over to you. Uh, tell us about yourself, something that probably social media doesn’t know.
Carlos Neves: Well, there’s a lot of that, but, um, so first of all, actually I’m Portuguese, um, moved to the UK about eight years ago. Um, it was a, an interesting transition, a new culture, a new way of living, but very happy with that move, um, so far, at least. Uh, in terms of how I got to this, um, to what I got to today, I guess it was mainly influenced by one of my cousins. Uh, I saw him as a little bit of a mentor. When I was a teenager, he was very much keen into computers and computer science and programming. And I was like, “Oh, that looks interesting. So, uh, it’s just something that I will actually enjoy doing.” I remember that I was a little bit on the fence between, uh, following a computer science degree or, uh, going into, um, physical education at the time. So being a PE teacher, but, uh, yeah, in the end, computer science won, um, and I never looked back and it’s been so far a very rewarding journey, if I may say so. And something personal that no one, my friends know about it, uh, but social media doesn’t know is that I’m a very avid salsa dancer. Uh..
Kovid Batra: Oh, nice!
Carlos Neves: Yeah, sort of my, my hobbies outside of work.
Kovid Batra: Perfect. So you have a partner with you?
Carlos Neves: Uh, well, usually when, whenever you go to these social events, you tend to find multiple partners there, but yeah, sometimes I do go with, uh, with friends and, uh, not necessarily, uh, a set partner. So you get to swap, uh, partners during, during the event and it’s a lot of fun. It’s a good way to actually interact and socialize with people. I do recommend for anyone that hasn’t tried before.
Kovid Batra: Perfect. Perfect. I think that was really interesting. But you mentioned about, uh, it was between physical education and, uh, computer science, right? So like from childhood, teenage, like you had any sport that you were really interested in, you were playing something or it was just, uh, out of curiosity or you like physical education in general?
Carlos Neves: No, I was very active as a kid. Um, so when I was, uh, six, seven, my, my parents put me into swimming. So I’m, until I was 15, did some competition, then transitioned to, uh, athletics. I did athletics from the age of 12 until I was 18. Again, did competition and I really did enjoy the competition side of it. Again, the training with colleagues and, um, that was also a lot of fun. And because I did enjoy that, like that, that part, and it made me feel really, really well about myself, so I did think that maybe this is something that I actually want to do full time. But then, uh, looking at all the options and all the alternatives, I guess that’s, computer science just won in the end. Uh, I can, I’m still very physically active. I do try to hit the gym, uh, multiple times a week. I’m not saying that I’m a hundred percent, a hundred percent successful at that, but I did try my best. Uh, but, um, yeah, I still like to keep myself like fit and healthy as much as possible.
Kovid Batra: No, I think that’s, that’s really great. I think, um, childhood, uh, then when you are, uh, as a kid involved in sports and, uh, I’ve, I’ve seen a lot of my, my peers also who have been there, uh, played state-level, national-level competitions. Ultimately, in their careers, professionally also, came out to be very good leaders in general somehow and I am sure there is some linkage to that where you are more motivated, you’re more, uh, like a fighter spirit is there basically. So I think maybe that really impacts, uh on overall journey as, professionally also, if you see. So yeah, cool. I think that’s, that’s really interesting. So I think, uh, from there, moving into present as a Head of Engineering for Vitality, right? Tell us something about the company. What’s your role here? What do you do as a head of engineering? What kind of responsibilities you have? And, uh, of course we would love to know when you transitioned from the point where you were into engineering and then moving into, uh, you’re at an IC and you are moving into a management role. How did that transition happen?
Carlos Neves: Sure. So currently, as you said, I’m Head of Engineering for Vitality, uh, for those that don’t know Vitality is an insurance company that operates within the health and life space, uh, I’m responsible for the systems that support our members in their both health and life claims journey. Uh, there’s a big focus right now for us in terms of increasing our digital capability, so allowing the members to service themselves mostly digitally. Of course, there’s going to be the need to, uh, sometimes reaching by email or call, uh, but trying to minimize that as much as possible. Um, there’s also been a lot of focus in terms of, uh, after you get, uh, treatment or consultation to allow you, to allow you, the member to, uh, continue that, uh, continuous care, like online, as I said, as much as possible. I did a lot of modernization in terms of our systems that comes as part of the data engineering role, a lot of engagement with a lot of other departments, like the product department, um, eventually sales, um, it’s, I think it’s one of the things that I do enjoy the most as part of my role is that I tend to talk to a lot of different people that do a lot of different things. Uh, there’s a lot of forward-looking in terms of what we want to do in the future. What’s the plan for the next two, three years, where do we want to take our products? Um, and this is something that we’ll get into more detail after, but it’s one of the big differences that I put that I see in the role that you have as an IC versus, uh, an EM or a head of specifically where the, the vision that you have, it’s more shorter term as an IC versus a medium to long term vision for someone that operates at, uh, at this level, to be more specific.
Um, specifically about my, my transition. So, let me think. This was a while back. Uh, so, uh, before as a individual contributor, uh, so I started with Microsoft technologies doing C sharp, uh, messing with SQL databases, uh, mainly full stack at the time, which was actually a very good learning opportunity because you do get the opportunity to, uh, learn how the, how an application works full stack, messed a little bit with the back end, a little bit with the front end, a little bit with the, uh, your data store. And that allows you to understand the effort that goes into each of the different components to have an application up and running. This was still in the times where monoliths were the, the trend, not, uh, as it is today where everything is, well, microservices, not everything, but it’s, it seems that that’s the, the trend right now, even if I’ve seen that some, uh, corporations are, uh, depending the, going back to monoliths, which is, uh, something that, that’s, that’s, that would be a completely different podcast, and, uh, we would spend enough time just discussing that, but that’s, yeah, that’s a different conversation. But in terms of transitioning to, um, an EM or a people, uh, team leader, to be more specific, it happened where my manager at the time actually had to leave the business for personal reasons and I was invited to replace him. Um, it was a surprise, a good surprise, because it’s something that I really, really wanted to do, but still a surprise. It was, um, interesting because when I transitioned, I was told that I could choose the, some of the team members that I would want to work with, which in my opinion, actually helped quite a lot because having people that you can trust with you, people that you actually have worked with before, also does, does help in that transition. But I did feel at the time that I did have a little bit of, uh, an imposter syndrome and said, “Well, why am I doing this? And why isn’t, uh, someone else doing this?” Or, “Why was I invited when there’s people that have been here maybe for longer than I have, uh, and are as good or even better than I am?” But then, after going through that process, I said, “Well, if they chose me, there must be a reason why. So let’s trust the process.” And then I tried to use that to build my confidence, um, because it is, it is, it is a shift, it is a change, and it is something that, um, you need to start thinking differently. So for example, when I was working as a software engineer, it was very much focused on my tasks. What do I need to do today? Uh, I, I did have to interact with colleagues and understand what they were doing, but it was very much, um, not siloed, but focused on, on what I had to do, whilst when I went through this transition, it became, okay, what does my team need to do? What do they need to, uh, to perform their tasks? How can I help them? How can I support them to achieve their goals, their objectives, our common goals are common objectives? And that was one of the, the shifts and one of the changes that I, that I had to face. Um, the fact that you were no longer as close to the detail as before was something that I actually struggled with quite a lot, uh, in the beginning, and I remember a situation where I went to my manager at the time. I said, “ How do you know everything that’s going on around you? Because I’m struggling to provide support to my team and knowing what they need to do, but knowing everything that the other teams are working on.” And he said, “Well, sometimes you just have to trust the people that you work with, trust the process and wait for them to come to you with problems. So if no news, so the premise of no news is good news, try to apply that as much as possible. Only focus on what you really need to focus on.” And with that, with that, uh, example, actually it did help quite a lot because you do, if you do trust the people that you work with, I’m using the word ‘trust’ a lot because that’s one of the core values that I believe that I need to have when working, uh, with a team or with multiple teams, as it is my case today. Um, but going back to what I was saying, by doing that, by just focusing on the problems, you allow them to operate how they need to operate and you say, “Okay, I’m here to help you. I’m here to support you. I’m here for what you need, and if what you need is actually just to go out for coffee, for example, let’s do that. Let’s let’s talk.” And sometimes it’s not necessarily just about work.
Kovid Batra: Yeah. I think for you, um, it happened coincidentally that the manager left and you got the opportunity to move into this role.
Carlos Neves: Um, yeah.
Kovid Batra: Uh, I think, uh, now when you are here into this journey for maybe more than a few years, uh, let’s say, if there is someone, uh, who is actually at the point where they can consciously make a choice of transitioning, uh, into a technical role then a management role or a management role then a technical role, uh, what do you think are the core, uh, beliefs that that person should have, uh, to be doing great, uh, in this management side of, uh, the technical vertical, I would say? And what all it takes, the change, I think you have already highlighted a few points that the change, changes are really, really drastic because initially you are just not siloed exactly, but you are working on specific things that are bound to be with you and the impact is like here in front of you and you, you do things and you see changes. So, the changes are there, but at the core, I think when you’re making a conscious choice, you need to know who you are, right? And what are those things one should identify in themselves to do good in this journey?
Carlos Neves: Um, the first thing that I would say is how much do you love being a technical-minded person?
Kovid Batra: Okay.
Carlos Neves: To me, that’s the, the, the fundamental thing. Um, if you love, so talking about engineering specifically, if you love coding, if you love being part of the technical discussions, if you, if it’s something that you know that you’re going to miss, maybe being an engineering manager or a team leader is not for you because the higher up you go, the less opportunity you’re going to have to, to do that. Uh, there are some, some exceptions, of course, where there are some, um, Head of Engineering roles or even, uh, CTO roles that are hands-on, but that’s in my, in my experience, that’s the exception. So if you do really enjoy, um, that aspect of the, of the job, so being technical, being hands-on, maybe moving into that, uh, Engineering Manager role is not necessarily for you. Also, how much do you enjoy managing people? And this is also something that is very, very important because you are no longer focusing just on, on you, on yourself as an individual, you’re supposed to, uh, nurture, guide, mentor, find the opportunity for the people that, uh, you’re responsible for to, to grow. So if you don’t like that aspect of the job, then again, maybe it’s not for you.
Um, so, but if you do, and if you do enjoy talking to other people, if you do enjoy learning more about the, the wider aspect of the, of the business that you’re trying to, uh, to support and you work for, if you’re, if you do enjoy, um, guiding, showing, giving people direction, tell them, uh, show them how their day-to-day work is influencing positively the goals of the company, then yes, by all means go for it. Um, be intentional about it. Try to find within your, your team opportunities to take some of the tasks that your current team leader does. So one of the things that I always tried to do, uh, was to identify within my teams if there were people that actually wanted to take in that step, uh, in the near future and try to expose them to some of the activities that were delegated, that were my responsibility. So I would delegate to them, uh, let’s say, uh, talking to, uh, architects or talking to, uh, some of the, the people from, from the, from the product, uh, teams and by doing that, you can actually assess, “Okay, do I enjoy doing this or is it something that I actually I had in my mind, but it’s not something that I actually do, uh, see myself doing every single day?” Because that’s the thing, uh, doing it every single day, it’s different from doing it every now and then.
Kovid Batra: Yes.
Carlos Neves: The good thing is you can also try it for a while and if it doesn’t work out, you can always refer back to the, the, the, the role that you had before. And I think that’s the, one of the things that people sometimes need to consider is that a choice that you make today is not necessarily a choice for life.
Kovid Batra: Yeah. I think that’s a very good advice and I feel, uh, if someone wants to even try that, uh, one can actually get the taste of it at a technical leader role, right? A team lead role, basically, where you are involved technically, and I have seen most of the team leaders, tech leaders are coding also, and at the same time coding their teams in every possible way. So, I think for anyone who wants to see how things would look like, can get a taste of it as soon as they step into a team lead kind of a role. But the thing is like, uh, most of the people, uh, are driven by two primary reasons to make those career moves. One is, of course, uh, what you like to do, what aligns with your character, your identity, your personality. And the second is, of course, uh, how it is going to progress financially also, right? That, that also becomes a concern for people. So in, in your opinion, how do you think, uh, in, in a futuristic way, uh, things can impact someone financially, they’re taking the technical route or, uh, a management route in, in any company, for say? Maybe you can’t generalize it, but I am asking a general question. You can, of course, answer it the way you feel about this.
Carlos Neves: Well, I guess it all depends where you want to get to. So, um, when you get to that, um, Senior Software Engineer, Principal Software Engineer role or Principal Test Engineer role, so where you are considered to be a specialist that people can look for with any guidance, right? Someone that’s going to help shape a technical decision. Someone that’s going to help define the best technical standards for software engineering and test engineering. Um, from there, eventually the part can become of, of being an architect, solutions architect, enterprise architect, uh, chief enterprise architect. So I think there are ways to progress where you can actually keep being, um, very close to what you enjoy and also seeing that financial benefit. But if you, uh, would rather be a people, people manager, where you go through the Engineering Manager, Head of, CTO, uh, role, then again, there are, there’s different, there are different parts, but you can still get the benefits, the financial benefits that you were talking about. It’s just making sure that at the end of the day, that you still enjoy what you’re doing. Um, in my case, one of the things that actually made me, uh, make this shift wasn’t necessarily, well, of course, the financial, the financial gains are important, but it was actually the fact that I, I enjoy working with people and enjoy working as part of a team and try to expand my, uh, my remit in terms of, uh, who I was interacting with day-to-day. Um, I like to understand or get a better understanding of what I’m doing, how it’s impacting the wider business, and I think that’s where this, uh, want, want came from. It wasn’t necessarily just the, the financial benefits.
But just going back to what I was saying, try to understand, uh, which part makes more sense to you, but I wouldn’t say necessarily that one would be, uh, detrimental in terms of the financial benefit or not. And there’s been, there’s plenty of situations where even software engineers are quite well paid if the skills that they have are quite uncommon in the market. So if that’s the case, if you’re a specialist in an area that there’s not a lot of offer, then you also get that benefit of being, well, financially rewarded and still doing what you love.
Kovid Batra: Makes sense. So let’s, let’s talk about, uh, the point where let’s say, I have taken the decision to move from an IC to a management role. Uh, now what should I start doing today? Let’s say, today I’m a Senior Software Engineer, or let’s say I’m a, I’m a Tech Lead. What should I start doing to get to the next step? Uh, what kind of, uh, uh, impact should I be, uh, reflecting on the team on the things that I’m doing so that the managers, the leaders of the teams are feeling that, okay, I am the right person to be pulled up to this particular, uh, profile? So it happened for you coincidentally, but I’m sure in retrospect, you tell what they saw in you and how, how it turned out. So what do you think, uh, one should start doing today?
Carlos Neves: So I think the first thing is look at the people that, uh, you report into and let them know that that’s something that you do want to do. First thing that’s, that should be the first, the first step. Second is if you feel that the person that you report into is not given the opportunities to, um, get exposed to some of the activities that normally would be given to, to them, then again, ask them, “Is it okay if next time I do this presentation?”, “Is it okay if next time I get the data for this report?” For example, one of the things that an engineer manager has to do is to look at their team metrics, uh, to understand how they’re progressing, if things are going according to plan. Okay, “Is that something that I can do on my own even if my Engineering Manager or my, my Team Lead is actually doing it?” I have access to the information so I can actually go and have a look and understand how is my team performing, if there’s something that is not necessarily right, how, what can I do to, um, to change things? I guess all this summarizes into being intentional. Identify the areas where you, you know, that your Team Lead needs to operate in and try to go in, have a look at what you need to do. Um, but again, it all comes on to being supported by, by that person that it’s, uh, that you’re reporting to. So your, your Line Manager. Uh, if that’s not really an option, then sometimes you need to look for that opportunity elsewhere, even though it’s more difficult because people don’t tend to hire based on the belief that you can do a job. You need to prove that you can do the job itself. So it’s usually easier to find that opportunity, um, within the organization that you’re already working with. But I guess it’s just trying to find that opportunity, if not in your team, within the business, but in a different team. Don’t be afraid of moving horizontally because that can bring benefits. It’s also going to actually give you exposure to other parts of the business that, uh, is going to give you more knowledge, become well-rounded across the, the business, and that’s something that is really valued, uh, when you go and do higher, more, in more senior roles, I would say.
Kovid Batra: Makes sense. I think, um, this is one, uh, very good way, like going out and explicitly mentioning, uh, it to your manager that you want to move into that role. Of course, that really, really helps in terms of highlighting. Okay. For the manager also, it becomes easier to align people, make sure that they stick because their role is to keep people happy, right? And when they know what they are wanting, it’s much easier for them to deliver that. But let’s say, there are situations where the opportunity is not being given by the manager. What else can someone do on their own? What they can do in their day-to-day routine, uh, to actually reflect those traits? And maybe the manager themselves come asking for it, or maybe, let’s say, you are working with a cross-functional team, the other people appreciate that trait of yours, uh, and they start looking at you from that point of view that, oh, yeah, this person could be, uh, moved into a management role or a Tech Lead role and, uh, moving forward. So what, what, what are those kinds of things that probably a Senior Software Engineer or a Tech Lead should start doing from today on their own?
Carlos Neves: Uh, so one of the things that you mentioned that is very, very important is being, uh, someone that is good technically, that a team can rely on and support for guidance, but it’s also trying to be a leader underneath your leader, if it makes sense. So what do I mean by that? Someone that, uh, your team can go to and trust if they feel that they need some, some support. It’s someone that people from outside your team can go to if they have any questions, you need to be seen as someone that knows what they’re doing, that understands, uh, the, the benefit that the team brings, that understands other parts of the business, someone that is seen as an expert in their field, I think that would be the first thing. But it’s also putting yourself out there, and what I said before, in terms of putting yourself out there and telling, telling your manager that you have this, this want and this objective, but talk to other people about it. One, one thing that actually I did indirectly that I think also helped when people thought about me at the time was looking for guidance and mentors outside of my most immediate circle, because when you do that, people, they do realize that you do want, you’re doing more, that you’re ambitious, that you’re trying to, uh, get outside of what you do now and you want to step into a more senior role. And not only that, people get to know you, and that’s one very important thing that is, if people don’t know you, they’re not going to think about you, uh, when an opportunity comes because there’s going to be someone else they’re going to think of first. So put yourself out there.
Kovid Batra: Makes sense. Totally makes sense. So moving on from, uh, what one should be doing at this point of time when they’re wanting to be there, uh, next step is like foreseeing the challenges that are coming on them. I, you briefly talked about it already, but I think, uh, I want to deep dive into what are those experiences? Like, if you could just give me some examples that as soon as you moved into that role, what was the first experience which made you realize where am I, what should I be doing now? Something of that sort, so that people who are really looking up to that should know, okay, what’s on their way now.
Carlos Neves: Well, I guess it depends on the team that you’re going to be looking after. But one thing that, well, two things actually that I think might, might happen, uh, in a way that kind of happened to me. Uh, one is trust yourself, otherwise that imposter syndrome that I mentioned before, it might consume you and then you’re going to be so focused in trying to prove to others that you can actually do it, that you’re going to forget how you should actually be focusing on the job itself. Um, I’ll explain a little bit more on that. So there’s two things that you actually, uh, that I faced, actually. One was the, that imposter syndrome that, uh, in the beginning kind of affected my, my confidence and I got so concerned about what others were thinking that I forgot about doing the, the, the job itself. I was so concerned about, but what if they think that I’m not good enough? What if they, uh, think that I’m not the best person for the job? Don’t, don’t, don’t fall into that trap. As I said before, if you’re appointed to do something, trust that you’re the right person for the job, focus on your skills, focus on the benefits that you believe that you can bring to the team because we’re all different. Different people will manage differently. There’s not necessarily one, uh, size fits all when it comes to management.
And then, I guess the other thing is the fact that some people will, again, try and question. So it’s the same thing, but in coming from others, actually, you get to experience people coming to you and not necessarily asking, “Why are you my manager now when two weeks ago we were peers?”
Kovid Batra: Yeah.
Carlos Neves: But there are some things that you can pick up where actually you can sense that people are almost trying to test you and don’t fall into the trap again of trying to convince them that you’re the right person for the job. So focus on what you think the job is. Look upwards for guidance. Look, not necessarily your Line Manager, but other people that are, uh, that you tend to work with, as long as they have, they have more experience than you, it might be another Team Lead or another Engineering Manager that has done, has done it for a lot longer than you, and you can look at them for guidance and say, “Well, I’m doing this. Do you think this is something that is working or do you have any advice for me to do something slightly differently?” So, try to use that as a, as a sounding board, but don’t fall into the trap of trying to convince others that you’re the right person for the job. So, focus on you.
Kovid Batra: And, um, just to add to it, I think, uh, I have a few friends who have moved into this role and they’re mostly, uh, uh, being troubled, uh, with the fact that now they are not actually doing something related to engineering. They’re mostly managing people, right? And you also mentioned in the beginning that it becomes more about that. And, uh, of course, it doesn’t come, uh, very naturally to a lot of people, uh, who have been into the tech space for, let’s say, a good 5 to 8 to 10 years. And, uh, And then, uh, they’re moving into this role. So now in that situation, I think, uh, what, what would be that right piece of advice for people to change that core belief system? Because it, you become like that, right? You, you tend to be more, I wouldn’t say introvert, introvert could be a wrong word here, but something of that sort where, uh, right communication, uh, handling things proactively so that they don’t end up messed up, end up getting messed up. So things like that happen and, and I think the core thing lies within the frame of having the right communication style, right communication. So how, how one should learn to do that? Because that’s very evident that one needs to do that. How, how should one be doing that in that role?
Carlos Neves: So just, just a few things on that, that is in terms of letting go, I think the best thing that you can do is actually just delegate. And by delegating, I don’t mean delegating your new tasks into your team. Delegate the tasks that you believe that you still, that you should still be doing, to your team, because in the first few months, what’s going to happen is your mindset is going to be, “Oh, I need to go and look at the code.”, “I need to go and check that, that pull request to make sure that it’s following the standards.” No, I’m not saying let it go completely, but if you know the people that you’re working with, you know that you can trust them, just delegate it to them. Don’t, try not to think about it. Again, tell them that if there’s anything that is wrong, if there’s a problem, come to me. Leave that to the side and focus on what does my team need? How are they performing? What does my team require to perform this task? Are they blocked by something? Are they, is there something that I can do differently that would benefit them? I think that’s when things start to, uh, settle down from, from that shift from, uh, an Engineering Manager role, when you start thinking about the team first.
Kovid Batra: Got it.
Carlos Neves: And in terms of communication, one of the things that I do even today is talk to everyone individually, of course, make time to talk to your team individually. Try to understand what their motivations are. Try to understand what drives them. Try to understand how things are going even outside of work, because we’re, we don’t, we’re not just employees. We have a life outside of work.
Kovid Batra: Yeah.
Carlos Neves: That is more important, I would say, at least for me, it’s more important than going into the office nine to five and then that’s, that’s, that’s all of your life. So, and that has a big influence on how you perform at work. So, if there’s anything that is happening, try to be available if they want to talk to you. Um, and finding that space where people start to trust you and they, they come to you for problems, they come to you for good things, and that, that’s when you actually, the communication is flowing. The communication is good between us. They trust me. They feel like I’m here to help them. They feel like I’m here to guide them and do what’s best for them. And it takes, it takes a lot of time to get to that point, but the main thing is stop thinking about what you can do, how, uh, how your own individual work is going to impact you, but try to think more about this is what my team needs. This is what the group of people that I’m responsible for can drive and can succeed because your success comes from their success.
Kovid Batra: Cool. I think, uh, the last line you said is the most impactful one for this role probably, like their success is my success and that’s how one should be progressing, and that’s the mind shift one would need when they’re moving from the role, from the IC role to an EM kind of a role. So cool, Carlos. I think, uh, there is a lot more to talk about this topic, but I am sorry, we can’t cover it in one, one session that we’re having with you. We’d love to have you for another session, maybe seeing how you progress from an EM role to a Head of Engineering role. That could be another discussion totally. And, uh, happy to have you again, uh, anytime, whenever you, you, you think you have time to discuss about it.
And, uh, talking about the mentoring piece, uh, just for our audience to, uh, let them know, uh, groCTO has come up with the, uh, groCTO Connect, uh, initiative where we are helping these EMs, ICs, technical leaders connect with leadership people for their mentorship to grow to the next level. So it’s groCTO Connect. Uh, we’d be happy if people want to send in requests. I’ll share the link of our groCTO Connect page in the comments. And with that, Carlos, thank you so much for your time. Loved having you here, really insightful talk. See you soon.
Carlos Neves: Thank you very much for the opportunity again. It was a pleasure. And reach out, I’ll be always available.
Kovid Batra: Thank you. Thank you so much, Carlos.
In this episode of the groCTO Originals Podcast, Kovid Batra talks with Jagannath Kintali, former Head of Engineering at Dojo and ex-startup co-founder, about building impactful engineering teams focused on customer delight.
Jagannath shares his extensive experience of over 18+ years in engineering, discussing the importance of building what is needed rather than overshooting with extravagant systems. He emphasises creating high-performance teams through trust, purpose, and customer empathy. Jagannath highlights his journey, the learnings from his startup, and how he implemented these insights at Dojo, including stories about curtain ordering systems and observability projects. This episode provides valuable insights on leadership, team building, and aligning engineering efforts towards solving real customer problems.
Kovid Batra: Hi everyone. This is Kovid, back with another episode of groCTO Podcast. And today with us, we have a very special guest. He’s Ex-Head of Engineering, Dojo. He has been an ex startup co-founder. Welcome to the show, Jag.
Jagannath Kintali: Thank you very much, Kovid. It’s, uh, it’s been a pleasure and thank you for having me on your show.
Kovid Batra: Great. So for the audience, uh, Jag is short for Jagannath and on this show, I think we’ll be calling you Jag. Is that okay with you?
Jagannath Kintali: Oh, that’s absolutely fine. Thank you. Yes, uh, Jagannath, it’s usually not the most common name in the Western world. So short form is Jag.
Kovid Batra: Yeah, that’s, that’s really cool. I think, uh, be a Roman when you are in Rome. So, that works. Yeah.
Cool. So, uh, on that note, like for the audience, um, today’s topic is. How to build impactful engineering teams that really build for the customer delight and I think Jag has, uh, really good hands-on experience with nurturing such teams. But before we dive deep into that part, I think we would love to know more about you, Jag. You have been a startup co-founder and I think it’s been a long journey of 18 years in the engineering world. Tell us something about yourself so that audience, audience, gets, gets to know you a little more. Um, your personal life, your hobbies, what you have been doing, uh, maybe about your startup.
Jagannath Kintali: Oh, absolutely. Uh, I am, my name is Jagannath. Uh, I actually do come from Orissa where Jagannath Puri, uh, Lord Jagannath Puri hails from. So after, uh, being there in Orissa, I’ve done my engineering, uh, I decided to come for a master’s degree in the UK and that’s where I started my software engineering career, uh, so to say, started as a, a software engineer, but once you come from, uh, this background of engineering and add a world to explore, but obviously the Western world was, uh, and especially UK was completely new to me, and the opportunities that you see over here was, uh, so many, I always wanted to go into building something of my own and having something of my own and to start something which will serve the community and, and a certain customers segment in general. And so, I ended up doing after several years of doing software engineering roles and especially my expertise is in solution architecture. But after several years, I decided to take the plunge, like everybody else wants to do that. But yes, I got to warn everybody and the audience that my startup does belong to the 9 failures out of 10 that all the startup happens. But I’ve done that and I have no regrets in giving it a try and doing that, but it is the most, uh, beautiful experience I had during the startup time, and we tried to do it for just over two years. Um, but yes, it was all about, uh, hyper local services, providing services to, um, customers within a certain community. But yes, ever since then, um, I’m still very much passionate about engineering and what I’m very passionate about is building or engineering beautiful products for customers who, you know, have a need for it, a particular challenge that it solves. Solving the customer problems is my main aim in life, and I’ve grown up in a, um, you know, I’ve grown up with the ethos or the principle is that, uh, to service, you know, uh, godliness. That’s where all it comes from. But yes, learning to be a, a pilot, which has been a dream of mine for a very long time. So let’s see how that goes. So hopefully I will get that license in this lifetime.
Kovid Batra: All the best to you for that.
Jagannath Kintali: Thank you.
Kovid Batra: Uh, you, like you said that, uh, you had this beautiful experience of, uh, being a co-founder and having that startup experience particularly. Um, what, what was your major learning from it? Like if I have to say like when you came out of it, I’m sure, uh, it’s never a failure, obviously. I mean, I have been..
Jagannath Kintali: Absolutely.
Kovid Batra: So what you learn out of it is something which is very different from what you do in a job. You get such a holistic experience of solving problems and building solutions when you are doing things as a co-founder or probably as in the leadership of a startup also, for that matter. So what was your learning from that journey? If you could, uh, like highlight that for us.
Jagannath Kintali: My total learning, as you said, it’s never a failure, and actually based on the learnings from the startup, I’ve had many successful jobs based on the learning from, uh, from the startup and, uh, I’ve had many, uh, many times, uh, uh, tried to think about and summarize what, what were the things that I could have completely done, uh, differently, and that’s what I keep on using in my future roles. And I boiled it down to basically three, uh, different learnings. First of all, it was the product. Then second comes the, uh, people aspect of it and how you execute it. Those were the three areas that I, I think, uh, were the three main learnings. First, it was the product, that service that we were trying to provide. It was a very simple concept. It was a matchmaking process where somebody as a service holder can provide the service to a person who is in need of that service and a very hyper local at that point. So within, um, 15, uh, 20 minutes, you get your service, uh, sorted, whether it is, uh, looking for a cleaner, whether you’re looking for a locksmith, or whether you want to, uh, wanted somebody to get some, uh, grocery from the store, uh, to you. Now, nowadays, it sounds like it’s so common. It wasn’t that common in 2012, 2013 when we, uh, started this. But, uh, the first learning was we, the opportunity was so big, we got a little lost, in my opinion, as to which area we should concentrate on. So there were just so many avenues we wanted to go down on. We should have, uh, probably own down in a, kind of set of services and tried to build that platform and repeatedly perfected or make it much more efficient, the process of end-to-end, somebody requesting for a service and somebody getting a service and the feedback loop going back and forth and repeatedly doing that through our systems, through customer feedback and through the service, services that we provided, particularly one or two. We tried to widen it straight away with 10 to 12 different services. And what happens is every service type has, uh, different kinds of needs that the need of a, uh, a cleaner or a maid, uh, you’re looking for a maid is completely different than looking for a locksmith, or, uh, you know, looking for, uh, a nanny’s, uh, completely different and trying to, uh, funnel all of those requirements and make it efficient into one single channel was the most difficult thing. What we should have done is just pick one particular vertical, try to get some traction on it and then you will realize and you will have your learning and then use that learning in other services. Slowly added that.
So being in a particular and it is very behavioral because this is not a Uber, uh, type concept where you have the service being provided outside your house. The service we were trying to provide was within the house. So there’s a big trust factor that needed to come in. And every country that you go to, we were trying to do it in the Middle East, where, uh, it’s a service Mecca. Um, and we want to get some traction over there, but I was in London at that time. I did not spend enough time, uh, I’ve been there quite often, but I do not spend enough time. Be there, be emerged into the local community and try to figure that out by yourself. Going back to the first principles of totally immersing yourself into finding out where the needs are, what the actual requirements are, where the actual inefficiencies are and how to join the dots. Trying to sit completely away and trying to, uh, uh, totally imagine the inefficiencies and, and not looking at the reality was probably one of the, uh, challenges, uh, uh, we faced and the biggest learning, uh, I’ve had in, in, in doing that. And second, uh, on the people side. That was on the product side. People side, it brings me, uh, uh, to the, it’s very related to the topic that we’ll be talking about. It’s building that very strong team.
When you are a startup, it is very difficult to get the right set of people and, uh, you’re looking for funding, you’re looking for finances, you don’t, uh, uh, you are not going to get, uh, you know, the star players that, uh, you wanted on your team from day one, it is very difficult to do that and also trying to build a, uh, build a team, which is totally dedicated for the purpose. What we did was, okay, let’s go out and find a team, whether it is a third-party software provider, uh, or software consultancy, a small outfit somewhere, and try to bring them in. What we didn’t do, that would have also worked, but what we didn’t fail to do, in my opinion, is, is, uh, giving them that purpose. So they always worked as a consultant. They were not integrating. They were not, uh, bought into the product that they were trying to build or the company. Uh, company had a mission, company was trying to solve a particular customer challenge. We did not expose that particular team to that area, and they were just literally taking instructions and building a software system. They didn’t have the direct interaction with the customers or trying to understand the customer problem that we were trying to solve. Uh, that, that, that was the biggest gap, and this is where the impactful engineering comes into play. I’m a true believer in building teams which are totally exposed to the customer challenges. That doesn’t mean that you have to go and talk to the customer every single day, but you’ve got to understand the customer problem that you’re trying to solve on a single, every single day. Find out why, why it is that you are doing and everything that you’re building, how it is impacting the challenge you are trying to solve. If you don’t have that, if you don’t have that purpose, if you don’t have that, uh, you know, the belief that you are actually doing something, which solves a customer problem, you have lost the interest, the engagement of a particular team, and that’s where it goes downhill.
We’ll talk about many different things, and, uh, I’m sure we’ll go in-depth into it. But, uh, those were the biggest learnings and the execution of it. Obviously, being in 3 different geographical locations, we were trying to coordinate and do that. If you want to do a startup, be there, be in the location, be amongst your customers, understand the problem, even be the person who is even delivering that service and, uh, and try to understand the entire life cycle of a product. It’s not about building a software system, which you think will be very useful. It is, uh, if there are no customers who are using it and customers are not willing to pay for it, it’s not going to work out for you. It’s always going to end up in a, uh, well, 9 out of the 10, uh, do fail as starters because of that reason. So, you know, those were my biggest learnings from doing a startup, but I wouldn’t change, uh, this experience, uh, ever. I mean, it was, it was probably the hardest two and a half years of, of my life, we lost a lot of money also, uh, but wouldn’t change the experience for, uh, for any amount of money, for sure.
Kovid Batra: Perfect. I think, uh, the best part about such journeys, uh, are that in those hardships, in those times, you actually see a significant change in your mindset, how you think about things. It’s more like reality coming to you. Uh, it’s, it’s more like reality slapping you, saying that, okay, this is how things should be working, right?
Jagannath Kintali: Yeah, absolutely.
Kovid Batra: So, uh, I think that’s when you, you evolve the most. I mean, according to my understanding of how one should be, um, leading life in this universe is understanding more of world concepts, how reality works, the more you become empathetic and compassionate towards people, nature, how things are working around you, the better decision-making you bring into your, yeah. So I think startup has done that to me at least, and I feel the same when you are talking about, uh, realizing that it’s about building great teams also who focus on customer empathy, like customer delight, so that they can bring out those solutions which really solve the problem. You just don’t become a feature factory delivering features, taking instructions, delivering features. You actually deliver value. That’s how the mindset changes. And on that note, I think, uh, which is, of course, the topic for today, now when you are like four or five years ahead in that journey, you have been leading an engineering team for Dojo, I’m sure you would have incorporated some level of, uh, framework or some level of practices which inculcate this customer empathy or, uh, teams that are fundamentally aligned towards solving problems rather than just building features. So can you tell us about some of your experiences in your journey, how things worked out for you after that, and how you implemented this learning in your, in your teams?
Jagannath Kintali: I’ll start with the story this, uh, while having this conversation, it just came to my mind, previous to Dojo, I worked for it, uh, I was working for a software consultancy and I was working for it, uh, one of the biggest retailers in, uh, in the UK, and, uh, uh, I’ll tell you my first, uh, foray into, or the first time I ever was so delighted, uh, with the work I was doing. So the story goes as if that, so this biggest retailer, they, so it’s a super, um, what is it called? A superstore. They sell from food to clothing to anything, you name it, and they sell it, and they also sell curtains. So this is early into my career, and I’m in this, and I’ve been given this responsibility to design a curtain ordering system. Like, I have no knowledge about curtains. I didn’t even know that there were so many types of curtains that existed in this world, there’s so many textures, the type of cloths, and how the look will be, how to hang it, and all of those, but again, never interacted with any of the actual users. It was a consultancy. So, you know, you went into a dark room, you designed a system, and, and you deliver it to this, uh, retailer. It took my time trying to understand that the business, how the curtain, curtain ordering system works and how it goes from A to B, and when customer orders and it goes to the manufacturer, it comes back, uh, to the retailer and how they deliver it. Everything was beautifully fine, and, and went in, you designed to the best of your ability, right? Uh, trying to understand what the customer might need or, or the shop, the shop assistant who’s using your system to provide this service to the, uh, customer, but somehow we managed, we had a conversation, the system was delivered on, well on time and, and so. But, uh, I never felt like I, uh, so proud of, uh, this project, you know, it’s, it’s, I always used it as a job, okay? I went to work, I did some coding, I built some systems, it’s running absolutely fine, it is delivering what it’s supposed to deliver, you input A and the output B comes out, and those were the right input and output everybody was looking for. Job done. But then I was, in my off day, I visited one of these retailers and I went to one of the stores and I was with my partner at that time. So we were both visiting the store and I was trying to figure out how could I use this system that I built. I wanted to show, okay, I built a system, but I actually went and ordered some curtains at, at this store and the lady who was, uh, uh, serving us in, in the store, she pulls out, uh, an, an, the device, that were hand-held devices that they were doing, and she pulls out the system that the UI that, uh, was built by me and, uh, and two other engineers. And as soon as I saw that, uh, a UI and the ways she was using it, the satisfaction I got and the joy, that the happiness that I got just looking at, uh, and you know, your, uh, hard work is being utilized by somebody, and, and it is being very useful to somebody. On that day forward, onwards, I’m telling that something completely changed in the way I think and the way I approach and, uh, approach my work and the way I try to find that delight every single time I do something in my professional career, it completely changed.
And the best learning, uh, we were talking about in the introduction is the best learning from my 19 or 18, 19 years of engineering, uh, leadership, one thing that I have learned from, uh, uh, some of my senior engineers, I was in a project, one sentence that sums up all of it, ‘Build what you need, not what you want’, because there is this thing that we always overshoot. It’s, it feels like we should be building this, uh, uh, wonderful system, the most efficient, the most effective and do that. But no, you just need to build something which you need and the customer needs, that’s the most delightful thing that you can do for a customer and providing that talent. So that’s one of the best things that has ever happened. And from that moment onwards, this is what, how it has changed my, my perspective on software engineering in general, and how even in engineering leadership.
So coming back to the, I know it’s a roundabout way, but then coming back to the original question about how I’ve done this in my, uh, you know, my, my stint or my, uh, my work at, at Dojo, I tried to find the purpose or, or even build this purpose within a team. Building a high-performance team, in my opinion, it’s nothing to do with tech. It’s nothing to do with what you are trying to achieve. It’s about building that trust and finding that purpose every single, you will find, uh, a star, uh, engineers. You will find all the, uh, uh, right people in the, uh, uh, right places. But if they don’t have a purpose, if they don’t have a goal, they don’t have a direction to go towards, none of this works. And bringing that trust factor is the clue that will bind the team together in moving towards that goal, moving towards that ultimate aim of delivering that customer delight or the impact, customer impact that I keep going back to. And my way of doing it, there was no framework. There is, I know this might be very controversial and there’s nothing to do with frameworks or there’s nothing to do with, you know, reading books or, uh, uh, engineering leadership, it was pure and simple, uh, people’s relationship and building relationship and understanding each and every person within your team that you have. And the more you do it, the more it trickles. I started with a simple team of five when I started, I ended up, uh, when I finished with Dojo, finished at Dojo, I was looking more than 60, 70 engineers at a time. But once you build this environment where you build relationships, you build, you play the long game, not, never a short game for, for the purpose, you build relationships, try and understand each and every person who is within your team, what is that purpose and give them that purpose, give them that direction, give them the, uh, validation and recognition, which is the most undervalued aspect of software engineering. You provide them the right scenarios and the right environment, you will have a high-performing team every single time. I can guarantee you that.
That’s, that has been my mantra. It’s about personal relationships and building relationships and understanding people and going back to the first principles, and why we are doing it, give them the same input. Usually, I mean, it’s almost like if anybody replaces you as well, every team member within a particular team should be able to reiterate the same purpose within the team. So that’s how I always see it. Everybody having the same mentality and, uh, you know, the collective high mentality and trying to achieve that same goal, does a lot of good in a longer run. Uh, you might not see that in a shorter term, but for a longer run, it is the most, uh, the best thing you can do.
Kovid Batra: I think I absolutely agree with you. And in fact, uh, you said there is no framework as such. This is what you do and how you achieve things to build better teams. But I think this is the framework, according to me. Like on your behalf, I would just say that if you really want to build a team that cares for the customer and you are the one who is leading the teams, you build that relation, you build that trust with your team members, and every discussion, every sprint or every procedure that you are following to build something, if you’re putting that out in your thoughts, putting that out in your documents, maybe even if there are some PRDs where you are mentioning why we are solving this along with what needs to be built, I think that’s when you crack the things, because every day, if there is a discussion in the room where we are talking about solving the problems for the customer, automatically everyone starts thinking like that. Of course, there has to be a first-level trust built to be, uh, to be there where everyone looks up to that mindset which you are adopting or if you are preaching that. So this is the key, I believe. Like in every team, whether big or small, you just need to make sure that whatever you are following as a philosophy while building products for the, for the customers, that needs to propagate in every discussion, every document that’s going out from you and people would automatically start following it, and I think that’s how things over a long term would, uh, get imbibed fundamentally, uh..
Jagannath Kintali: Fundamentally. It’s the basic fundamentals that you, uh, uh, that you target and everything, uh, everything falls in place afterwards. And one of the things I’ll tell you for sure, like once you have this, your work becomes a side effect because you are building that, uh, mentality. Are you building that mindset across? The team, you move like a single unit and move and try to target, you know, what you were aiming for. The one thing I actually forgot to mention, or I wanted to bring up is that, you know, people talk about resolving conflict. How do you resolve conflict if there are two competing ideas and which is having, you know, you are having heated arguments or discussions about what is the best way to move it forward? I ask simply the question, which one, which solution will have the biggest impact? For our customer, the problem we are trying to solve, can it, which one does have, and there is always a single solution, there is never a multiple solution which says, okay, this will have, whether you count that as a, uh, how beneficial it will be for the customer, the cost impact of it, or how long-term effect it will have, how it will even have, uh, reduced tech debt, also in the longer run, you will find that asking that question, which one will have the better impact or most, most impact for the challenge that we are trying to solve, then you will, in terms there, there is a resolution always, most of the time.
Kovid Batra: Okay. Yeah, yeah, yeah. I totally get it.
Jagannath Kintali: And every sprint, what we used to do, uh, we do use the uh, uh, you know, the sprinting method as well, in every sprint, we will reiterate. We follow this OKR process, the, you know, and the key results and objectives and key results. Every sprint, we will try and make sure that the objectives and key results are pretty aligned to the needs of the company. First of all, you have your customer, then you also have your company goals to meet as well. So you have to keep this in balance in trying to go through. Make sure that it is still very much valid. It’s still very much aligned to what we are trying to move towards. It’s, it’s, it’s a pyramid kind of structure, if we were to talk about frameworks that we are doing, each and every team needs to do, set their own objectives and key results that they want to try and achieve. But those objectives and key results, need to also come from top-down. So we meet in the middle. So you have very strategic goals set by the founders of the company, Execs, right from the beginning, and then they will say, these are the different areas that we will be targeting on. And, you know, the squads and basically the teams will set their objectives accordingly from an engineering perspective, from the product perspective, and they meet at the middle. That’s how we have always looked into doing that. So it is very aligned. It is very, very much towards the company and the customer aims, uh, or the customer challenges that we are aiming for. And that’s how, uh, in my opinion, that’s, it is not, it is never going to be perfect, but the best results we have got so far is by this OKR framework.
Kovid Batra: Got it. Got it. I think, um, one more thing that I realized, like setting up these objectives and key results definitely brings that structural angle to solving the problems and doing something as a team. But going back to the first point from where you started with a story, I really loved that. And as a, as a, let’s say, as a team member, let’s say, you have been a, an, a leader for the team, if this is something how you would explain something to the, uh, the team members, the developers that how one should be thinking about things, I think that can also go a very long way, right?
Jagannath Kintali: Long way. Absolutely.
Kovid Batra: So basically, getting those team meetings sometimes around, uh, sharing such stories where they actually, uh, experienced what customers feel like, getting into their shoes and experiencing something, and then going back to your desktop or laptop and coding, I think that also is a big, uh, big-time need for, at least for the developer space, because it’s most of the time they’re coding in their own zones and there is a very big disconnect, but if, if we propagate this thought and we incentivize this thought, I think that can also go, as I said, long-term, in terms of building teams that are able to think with empathy, compassion for the customers.
Jagannath Kintali: There’s another story I would like to, uh, tell you. It’s, uh, in, in Dojo, we wanted to, um, introduce, uh, a particular engineering paradigm regarding, uh, observability, right? So the whole idea is that every single system that is, that exists in, in Dojo, we should be, uh, it should be totally observable. Uh, we should know about how it is performing, where it is, how, how much traffic it is coming through, how much CPU or memory, the whole shebang. But it, it was a very, uh, nice, a niche, a concept that we were trying to introduce in Dojo. Dojo was in, in, in its journey to, in its scale of journey. So how do we do that, uh, impact? How do we even, uh, build this, talk about this story, how to, how useful this is going to be, right? So what we did is that we did a very small project and we put it out regarding observability and we called it the ‘architectural pane of glass’. We used to, well, Dojo has a massive, uh, TV screens within the engineering floor, where we are displaying numbers and Grafana dashboards and, uh, you know, all stats flying around. What we did is we took a complete product and every component of that product, we devised it. So it was basically a Grafana dashboard, and every, we broke it down to different parts of the, all the components that builds that system and the system basically builds the product. And we showed everything pictorially on this Grafana dashboard, and every time any problem that would happen within these particular components or systems, it flashes, right? It’s saying, hey, there’s an error, uh, and there’s a metric failure or all the, uh, SLAs and SLIs that you have set, which is dropping down. You have the variants and all of that. It’ll start flashing. What happened, uh, by doing that is, is that every person who passed that, uh, screen, uh, and we have multiple products in Dojo, so any other product members who were passing that, including our CTO and founders, so every time they will pass this screen, they would stop by this screen, right? And they would say, Oh, what’s this about? This is something that we haven’t seen. And this is and ‘red, green’ is a, you know, universal language. You know, if it is showing red, that there’s a problem. It is green, then it is all going well. Oh, why is there a problem? And it became a conversation starter.
Kovid Batra: Got it.
Jagannath Kintali: And what we were trying to push for is, is, is the effective way of operation, uh, of all the different systems. And what we did is building that team who would say, and it was right next to where the team was sitting down, right? So every time somebody came around and talked about, uh, this big screen, the team would really feel, uh, very good about what they have built. They can see the usefulness of this product that we were trying to push for. And what that resulted in, we got the funding to build a team, we got the funding to afford and take that even further and spread it across entire Dojo Engineering. And I, last time I checked, I haven’t been to Dojo in a while, but, uh, the observability system that we have built is uh, I can put my hand on heart and say, probably one of the best in the UK market or in, in, in the FinTechs. I’d go even further in the world, but I haven’t seen many of the other systems, but it’s one of the best systems that we have built. It’s been a journey of two years.
So what I was trying to get to is that even doing small little things and having that customer delight, in this case, it was an internal community of engineers that we were trying to do. But you can see how you can capture the imagination of the customer and uses that you are trying to solve the problem for and get them engaged. And it’s a two-way street. Because the customers are getting engaged, the team is now getting engaged, and they are finding that, oh, uh, you know, that people are talking about this particular product. I was meeting with this person from that particular team and they were saying, hey, how can we, get that system built for us? And it becomes a starting point and starting conversation point, and it spreads all by itself. What about there was no company direction or a top-down approach in doing that? This is doing things very organically and trying to capture the imagination and showing that, hey, this is also possible, this is something that can be done. And, and of course, the product was very useful. We didn’t have as much observability into our systems as, you know, previously, this allowed us to observe our systems even better. So it worked out beautifully and it’s a story that I will probably never forget for as long as I am in this profession. It’s how all of the observability team started from there.
Kovid Batra: Got it. Got it. Amazing. Amazing. I think, uh, this is really a good example where not just thinking about customers who are business customers, but these developers, these people are your internal customers who you have to cater. And as a leader, if you become compassionate and empathetic about how you can actually make them, uh, push towards success metrics and think, think about things which they would align with and bringing this at such large scale, ultimately, would impact your customers also. So I think a very good example shared here and it was a really, really good session.
As we are moving out of time, now I would like to take this to a close end. Thanks a lot, Jag, for bringing such beautiful, beautiful insights on how you can actually build great engineering teams and sharing your experiences at Dojo. It was a lovely, lovely experience for sure.
Jagannath Kintali: Thank you very much for having me on. And it’s always nice to go back to, we, we as engineers, as professional, we don’t usually do this enough where we, uh, stop and, uh, take a pause and look back in our previous experiences, and, and it brings me great joy to even talk about all the different experiences and it, it brings a smile to my face as well. So it was very delightful and, uh, delightful for me as well. Thank you very much for the opportunity.
Kovid Batra: Great. Um, we would definitely love to have you back sometime again, uh, talking about more such engineering challenges and how things work out in the engineering world.
Jagannath Kintali: 100%.
Kovid Batra: Thank you for today. Thank you, Jag.
Jagannath Kintali: Thank you. Have a good day. Bye.
Kovid Batra: Thank you. Bye.
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.
.png)
Typo hosted an exclusive live webinar titled 'The Hows and Whats of DORA', featuring Bryan Finster and Richard Pangborn. With over 150+ attendees, we explored how DORA can be misused and learnt practical tips for turning engineering metrics into dev team success.
Bryan Finster, Value Stream Architect at Defense Unicorns and co-author of 'How to Misuse and Abuse DORA Metrics’, and Richard Pangborn, Software Development Manager at Method and advocate for Typo, brought valuable perspectives to the table.
The discussion covered DORA metrics' implementation and challenges, highlighting the critical role of continuous delivery and value stream management. Bryan provided insights from his experience at Walmart and Defense Unicorns, explaining the pitfalls of misusing DORA metrics. Meanwhile, Richard shared his hands-on experience with implementation challenges, including data collection difficulties and the crucial need for accurate observability. They also reinforced the idea that DORA metrics should serve as health indicators rather than direct targets. Bryan and Richard offered parting advice on using observability effectively and ensuring that metrics lead to meaningful improvements rather than superficial compliance. They both emphasized the importance of a supportive culture that sees metrics as tools for improvement rather than instruments of pressure.
The event concluded with an interactive Q&A session, allowing attendees to ask questions and gain deeper insights.
P.S.: Our next live webinar is on September 25, featuring DORA expert Dave Farley. We hope to see you there!
Kovid Batra: Hi, everyone. Thanks for joining in for our DORA exclusive webinar, The Hows and Whats of DORA, powered by Typo. I'm Kovid, founding member at Typo and your host for today's webinar. With me, we have two special people. Please welcome the DORA expert for tonight, Bryan Finster, who is an exceptional Value Stream Architect at Defense Unicorns and the co-author of the ebook, 'How to Misuse and Abuse DORA Metrics', and one of our product mentors, and Typo advocates, Richard Pangborn, who is a Software Development Manager at Method. Thanks, Bryan. Thanks, Rich, for joining in.
Bryan Finster: Thanks for having me.
Richard Pangborn: Yeah, no problem.
Kovid Batra: Great. So, like, before we, uh, get started and discuss about how to implement DORA, how to misuse DORA, uh, Rich, you have some questions to ask, uh, we would love to know a little bit about you both. So if you could just spare a minute and tell us about yourself. So I think we can get started with you, Rich. Uh, and then we can come back to Bryan.
Richard Pangborn: Sure. Yeah, sounds good. Uh, my name is Richard Pangborn. I'm the Software Developer Manager here at Method. Uh, I've been a manager for about three years now. Um, but I do come from a Tech Lead role of five or more years. Um, I started here as a junior developer when we were just in the startup phase. Um, went through the series funding, the investments, the exponential growth. Today we're, you know, over a 100-person company with six software development teams. Um, and yeah, Typo is definitely something that we've been using to help us measure ourselves and succeed. Um, some interesting things about myself, I guess, is I was part of the company and team that succeeded when we did a Intuit hackathon. Um, it was pretty impactful to me. Um, We brought this giant check, uh, back with us from Cali all the way to Toronto, where we're located. Uh, we got to celebrate with, uh, all of the company, everyone who put in all the hard and hard work to, to help us succeed. Um, that's, that's sort of what pushed me into sort of a management path to sort of mentor and help those, um, that are junior or intermediate, uh, have that same sort of career path, uh, and set them up for success.
Kovid Batra: Perfect. Perfect. Thanks, Richard. And something apart from your professional life, anything that you want to share with the audience about yourself?
Richard Pangborn: Uh, myself, um, I'm a gamer, um, I do like to golf, I do like to, um, exercise, uh, something interesting also is, um, I met my, uh, wife here at the company who I still work with today.
Kovid Batra: Great. Thank you so much, Rich. Bryan, over to you.
Bryan Finster: Oh, yes. I'm Bryan Finster. I've been a software developer for, oh, well, since 1996. So I'll let you do the math. I'm mostly doing enterprise development. I worked for Walmart for 19 of those years, um, in logistics for most of that time and, uh, helped pilot continuous delivery at Walmart inside logistics. I've got scars to show for it. Um, and then later moved to platform at Walmart, where I was originally in charge of the delivery metrics we were gathering to help teams understand how to do continuous delivery so they can compare themselves to what good continuous delivery looked like. And then later was asked to start a dojo at Walmart to directly pair with teams to help them solve the problem of how do we do CD. And then about a little over three years ago, I was, I joined Defense Unicorns as employee number three of three, uh, and we're, we're now, um, over 150 people. We're focused on how do we help the Department of Defense deliver, um, you know, do continuous delivery and secure environments. So it's a fun path.
Kovid Batra: Great, great. Perfect. And the same question to you. Something that LinkedIn doesn't tell about you, you would like to share with the audience.
Bryan Finster: Um, computers aren't my hobby. Uh, I, you know, it's a lot better than roofing. My dad had a construction company, so I know what that's like. Um, but I, I very much enjoy photography, uh, collecting watches, ride motorcycles, and build plastic models. So that's where I spend my time.
Kovid Batra: Nice. Great to know that. All right. So now I think, uh, we are good to go and start with the main section of, of our webinar. So I think first, uh, let's, let's start with you, Bryan. Um, I think you have been a long-time advocate of value streams, continuous delivery, DORA metrics. You just briefly told us about how this journey started, but let's, let's deep dive a little bit more into this. Uh, tell us about how value stream management, continuous delivery, all this as a concept started appealing to you from the point of Walmart and then how it has evolved over time for you in your life.
Bryan Finster: Sure. Uh, no, at Walmart, um, continuous delivery was the answer to a problem. It wasn't, it was, we had a business problem, you know, our lead time for change in logistics was a year. We were delivering every quarter with massive explosions. Every time we piloted, I mean, it was really stressful. Um, any, anytime we did a big change of recorder, we had planned 24 by 7 support for at least a week and sometimes longer, um, And it was just a complete nightmare. And our SVP, instead of hiring in a bunch of consultants, cause we've been through a whole bunch of agile transformations over the years, asked the senior engineers in the area to figure out how we can deliver every two weeks. Now, if you can imagine these giant explosions happening every two weeks instead of every quarter, we didn't want that. And so we started digging in, how do we get that done? And my partner in crime bought a copy of continuous delivery. We started reading that book cover to cover, pulling out everything we could, uh, started building Jenkins pipelines with templates, so the teams didn't have to go and build their own pipeline. They can just extend the base template which was a pattern we took forward later. And, and, uh, we built a global platform. I started trying to figure out how do we actually do the workflow that enables continuous delivery. I mean, we weren't testing at all. Think how scary that is. Uh, other than, you know, handing it off to QA and say, "Hey, test this for us.
And so I had to really dig into how do we do continuous integration. And then that led into what's the communication problems that are stopping us from getting information so we can test before we commit code. Um, and then once you start doing that at the team level, what's preventing us from getting all the other information that we need outside the team? How do we get the connection? You know that, all the, all the roadblocks that are preventing us from doing continuous delivery, how do we fix those? Which kind of let me fall backwards in the value stream management because now you're looking at the broader value stream. It's beyond just what your team can do. Um, and so it's, uh, it's, it's been just a journey of solving that problem of how do we allow every team to independently deploy from any other team as frequently as they can.
Kovid Batra: Great. And, and how do, uh, DORA metrics and engineering metrics, while you are implementing these projects, taking up these initiatives, play a role in it?
Bryan Finster: Well, so, you know, all this effort that we went on predated Accelerate coming out, but I was going to DevOps Enterprise Summit and learning as much as I could starting in 2015 and talking to people about how do we measure things, cause I was actually sent to DevOps Enterprise Summit the first time to figure out how do we measure if we're doing it well, and then started pulling together, you know, some metrics to show that we're progressing on this path to CD, you know, how frequently integrating code, how many defects are being generated over time, you know, and how, how often can individuals on the team deploy as like, you know, deploys per day per developer was a metric that Jim proposed back in 2015 as just a health metric. How are we doing? And then later in the, and when we started the dojo in platform at Walmart, we were using a metrics-based approach to help teams. Continuous delivery was the method we were using to improve engineering excellence in the organization. We, you know, we weren't doing any Agile frameworks. It was just, why can't we deliver change daily? Um, and early on when we started building the platform, the first tool was the CI tool. Second tool was how do we measure. And we brought in CapitalOne's Hygieia, and then we gamified delivery metrics so we can show teams with a star rating how they were doing on integration frequency, build time, build success rate, deploy frequency, you know, and code complexity, that sort of thing, to show them, you know, this is what good looks like, and here's where you are. That's it. Now, I learned a lot from that, and there's some things I would still game today, and some things I would absolutely not gamify. Um, but that's where I, you know, I spent a long time running that as the game master about how do we, how do we run the game to get teams to want to, want to move and have shown where to go.
And then later, Accelerate came out, and the big thing that Accelerate did was it validated everything we thought was true. All the experiences we had, because the reason I'm so passionate about it is that first, first experience with CD was such a morale improvement on the team that I, nobody ever wanted to work any other way, and when things later changed, they were forced to not work that way by new leadership, everyone who could left. And that's just the reality of it. And, but accelerate came out and said these exact things that we were seeing. And it wasn't just a one-off. It wasn't just this, you know, just localized to. What we were saying, it was everywhere.
Kovid Batra: Yeah, totally makes sense. I think, uh, it's been a burning topic now, and a lot of, uh, talks have been around it. In fact, like, these things are at team-level, system-level. In fact, uh, I'm, uh, the McKinsey article that came out, uh, talking about dev productivity also. So I, I have actually a question there. So, uh.
Bryan Finster: Oh, I shouldn't have read the article. Yeah, go ahead.
Kovid Batra: I mean, it's basically, it's basically talking about individual, uh, dev productivity, right? People say that it can be measured. So yeah. What's your take on that?
Bryan Finster: That's, that's really dumb. If you want to absolutely kill outcomes, uh, focus on HR metrics instead of outcome metrics, you know. And, and so, I want to touch a little bit on the DORA metrics I think. You know, I've, having worked to apply those metrics on top of the metrics we're already using, there's some of them that are useful, but you have to understand those came from surveys, and there's some of them that are, that if you try to measure them directly, you won't get the results you want, you won't get useful data from measuring directly. Um, you know, and they don't tell you things are going well, they only tell you things are going poorly and you can't use those as your, your, the thing that tells you whether, whether you're delivering value well, you know? It's just something that you, cause you to ask questions about what might be going wrong or not, but it's not, it's not something you use like a dashboard.
Kovid Batra: Makes sense. And I think, uh, the book that you have written, uh, 'How to Misuse and Abuse DORA Metrics', I think, let's, let's talk, talk about that a little bit. Like you have summarized a lot of things there, how DORA metrics should not be used, or Engineering metrics for that matter should not be used. So like, when do you think, how do you think teams should be using it? When do the teams actually feel the need of using these metrics and in which areas?
Bryan Finster: Well, I think observability in general is something people don't pay enough attention to. And not just, you know, not just production observability, but how are we working as a team. And, and really what we're trying to do is you have to think of it first from what are we trying to do with product development. Um, a big mistake people make is assuming that their idea is correct, and all we have to do is build something according to spec, make sure it tests according to spec and deliver it when we're done. When fundamentally, the idea is probably wrong. And so the question is, how big of a chunk of wrong idea do I want to deliver to the end user and which money do I want to spend doing that? So what we're trying to do is we're trying to become much more efficient about how we make change so we can make smaller change at lower costs so that we can be more effective about delivering value and deliver less wrong stuff. And so what you're really trying to do is you're trying to measure the, the, the way that we work, the way we test, to find areas where we can improve that workflow, so that we can reduce the cost and increase the velocity, which we can deliver change. So we can deliver smaller units of work more frequently, get faster feedback and adjust our idea, right? And so if you're not, if you're just looking at, "Oh, we just need to deliver faster." But you're not looking at why do we want to deliver faster is to get faster feedback on the idea. And also from my perspective, after 20 years of carrying a pager, fix production very, very quickly and safely, I think those are both key things.
And so what we're trying to do with the metrics is we're trying to identify where those problems are. And so in the paper I wrote for IT revolution, which was about twice as long as they asked me for on, on how to misuse and abuse DORA metrics, I went into the details of how we apply those metrics in real life. At Walmart, when we were working with teams to help them improve and also, you know, using them on ourselves, I think if a team really wants to focus on improving, the first thing they should measure is how well they're doing at continuous integration, you know, how frequently are we integrating code, how long does it take us to finish whatever a unit of work is, and what's our, uh, how many defects we're generating, uh, over time as a trend. And measure trends and improve all those trends at the same time.
Kovid Batra: How do we measure this piece where we are talking about measuring the continuous integration?
Bryan Finster: So, as an average on the team, how frequently are we integrating code? And you really want to be at least daily, right? And that's integrated to the trunk, not to some develop branch. And then also, you know, people generally work on a task or a story or whatever it is. How long does it take to go from when we start that work until it's delivered? What's that time frame? And there's, there's other times within that we can measure and that was when we get into value stream mapping. We can talk about that later, but, uh, we want small units of work because you get higher quality information if you get smaller units work and you're more predictable on delivery of that unit of work, which takes a lot of pressure off, it eliminates story points. But then you also have to balance those with the quality of what we did, and you can't measure that quality until it's in production, because test to spec doesn't mean it's good. 'Fit for purpose' means the user finds it good.
Kovid Batra: Right. Can you give us some examples of where you have seen implementing these metrics went completely south instead of working positively? Like how exactly were they abused and misused in a scenario?
Bryan Finster: Yeah, every single time somebody builds a dashboard without really understanding what the problems you're trying to solve are, I see, I've seen lots of people over the years since Accelerate was published, building dashboards to sell, but they don't understand the core problem they're trying to solve. But also, you know, when you have management who reads a book and says, Oh, look, here's an end, you know, I helped cause this problems, which is why I work so hard to fix it by saying, "Hey, look at these four key metrics." Aren't you? You know, this, this can tell you some things, but then they start using them as goals instead of health indicators that are contextual to individual teams. And when you start saying, "Hey, all teams must have this, this level of delivery frequency." Well, maybe, but everybody has their own delivery context. You're not going to deliver to an air-gapped environment as frequently as you are to, you know, AWS, right? And so, you have to understand what it is you're actually trying to do. What, what decisions are you going to make with any metric? What questions are you trying to answer before you go and measure it? You have to define what the problem is before you try to measure that you're successful at correcting the problem.
Kovid Batra: Right. Makes sense. There are challenges that I've seen in teams. Uh, so of course, Typo is getting implemented in various organizations here. What we have commonly come across is teams tend to start using it, but sometimes it happens that when there are certain indicators highlighted from those metrics, they're not sure of what to do next.
Bryan Finster: Right.
Kovid Batra: So I'm sure you must.
Bryan Finster: Well, but the reason why is because they didn't know why they were measuring it in the first place, right? And so, like I said, you know, DORA metrics in specific, they tell you something, but they're very much trailing metrics, which is why I point to CI because CI is really the, the CI workflow is really the engine that starts driving improvement. And then, you know, once you get better at that, you say, "Well, why can't I deliver today's work today?" And you start finding other things in the value stream that are broken, but then you have to identify, okay, well, We see this issue here with code review. We see this issue here. We have this handoff to another team downstream of development before we can deploy. How do we improve those? And how can we measure that we are improving? So you have to ask the question first. And then come up with the metrics that you're using to evaluate success.
And so, people are saying, well, I don't know what to do with this number. It's because they don't, they didn't, they started with a metric and then tried to figure out what to do with it because someone told him it was a good metric. No metric is a good metric unless you know what you're doing with it. I mean, if I put a tachometer on a car and you think that more is better but you don't understand what the tachometer is telling you, then you'll just blow up your engine.
Kovid Batra: But don't you think like there is a possible way to actually not know what to measure, but to identify what to measure also from these metrics itself? For example, like, uh, we have certain benchmarks for, uh, different industries for each metric, right? And let's say I start looking at the lead time, I start looking at the deployment frequency, mean time to restore, there are various other metrics. And from there, I try to identify where my engineering efficiency or productivity is, productivity is getting impacted. So can, can it not be a top-down approach where we find out what we need to actually measure and improve upon from those metrics itself?
Bryan Finster: Only if you start with a question you're trying to answer. But I wouldn't compare. So one of the other problems I have with the DORA metrics specifically is that the, and I've talked to DORA at Google about this as well, it's, it's like some of the questions are nonspecific. So for your, the system you work on most of the time, how frequently you deliver. Well, are you talking about a thousand developers, a hundred developers, a team of eight, right? And so, your delivery frequency is going to be very much relative to the number of people working on it, plus other constraints outside of it. And so you, yes, high performers deliver, you know, multiple times a day with, uh, you know, lead times of less than an hour, except that what's the definition of lead time? Well, there's two inside Accelerate, and they're different depending on how you read it. And, but that doesn't mean that you should just copy what it says. You should look at that and say, "Okay, now what, what am I trying to accomplish? And how can I apply these ideas? Not necessarily the metrics directly, but how can I apply these ideas to measure what I'm trying to measure to find out where my problems are?" So you have to deep dive into where your problems are. And so just like, "Hey, measure these things and here's your benchmarks.
Kovid Batra: Makes sense. Makes sense. Richard, do you have a point that I think we have been talking for a long, if you have any question, uh, I think let's, let's hear from Richard also. Um, he has used Typo, uh, has been using it for a while now, and I'm sure, uh, in this journey of implementing engineering metrics, DORA metrics in his team, he would have seen certain challenges. Richard, I think the stage is yours.
Richard Pangborn: Yeah, sure. Um, so my research into using DORA metrics stem from, um, building high-performing teams. So, um, we always, we're looking for continuous improvement, but we're really looking for ways to measure ourselves that, that makes sense, that can't be totally gamed, that, um, that are like standards. Uh, what I liked about DORA was it had some counterbalancing metrics like throughput versus quality, time to repair versus time to build, speed for stability. That's, it's a, it's a nice counterbalancing, um, effect. Um, and high-performing teams, they care about stuff like continuous improvement, they want to do better than they did last quarter or, or last month, they want to, um, they want help with decision-making. So better data to drive some of the guesswork about, you know, what, what area needs, um, The most improvement or what area is, uh, broken in our pipeline, maybe for like continuous delivery for quality. Um, I want to make sure that they're making a difference, that they're moving a needle, um, ladders up. So a lot of times, a lot of companies, uh, have different measurements at different levels, like company level, department level, team level, individual level. So DORA, we were able to identify some that do ladder up, which is great.
Some of the there are some challenges with implementing DORA, like when we first started. Um, so I think part of the challenge, one of the first ones was the complexity around data collection. Um, so, you know, accurately tracking and measuring DORA metrics. So deployment frequency, lead time for changes, failure rate, recovery, um, they all come from different sources. So CI/CD pipelines, version control systems, incident management tools. So integrating these data sources and ensuring they provide consistent results can be a little time consuming. Um, it can be a little difficult to understand. Yeah, so that was, that was definitely one part of it. Uh, we haven't rolled out all four yet. We're still in the process, just ensuring that, you know, what we are measuring is accurate.
Bryan Finster: Yeah, and I'm glad you touched on the accuracy thing. Um, When we would go and work with teams and start collecting data, so number one, we had data from the pipeline because it was embedded into the platform, but we also knew that when we worked with teams that the Git data was accurate, but the workload was going to be garbage unless the teams actually cared about using Jira correctly. And so, education step number one was while we were cleaning up the, the data in Jira, educating them on why Jira actually should matter to them, instead of just as a, it's not, it's not a time-tracking tool, it's a communication tool. You know, and educating them so that they would actually take it seriously so that the workflow data would be accurate so that they could then use that to help them identify where the improvements could happen because we're going to try to teach them how to improve, we weren't just trying to teach them to do what we said. Um, and yeah, I built a few data collection tools since we started this, and yeah, the collecting the data and showing where, um, accuracy problems happen as part of the dashboard is something that needs to be understood because people will just say, "Oh, the data's right." But yeah, I mean, especially with workflow data, one of the things we really did on the last one I built was show where, where the, you know, where we're out of bounds, very high or very low, you know. I talked to management. I was like, "Well, look, we're doing really good. I've got stuff closing here really fast." I'm like, you're telling me it took 30 seconds to do that, give it a work. Yeah, the accuracy issues. And MTTR is something that DORA's talked about ditching entirely because it's a far too noisy metric if you're trying to collect it automatically.
Richard Pangborn: Yeah, we haven't started tracking MTTR yet. Um, we're more concerned with the throughput versus stability that would have the biggest, um, change at the department level, at the team level. Um, I think, I think that's made the difference so far. Also, we have a challenge with, um, yeah, just doing a lot of stuff manually. So lack of tooling and automation. Um, there's a lot of manual measurements that are taking place. So like you said, error-prone for data collection, inconsistent processes. Um, once we get to a more automated state, I feel like it will be a bit more successful.
Bryan Finster: Yeah. There's a dashboard I built for the, for the Air Force. I'll send you a link later. It might, it might be useful, I'm not sure. But also the other thing is change failure rate is something that people misunderstand a lot, uh, and I've, I've combed through Accelerate multiple times. Uh, uh, Walmart has actually asked to reverse engineer the survey for the book, so I've gone back in depth. Change failure rate is any defect. It's not an incident. If you go and read what it says about change failure rate, it's any defect, which it should be because also the idea is wrong. If the user's reporting it's defective, and you say, "Well, that's a new feature." No, the idea was defective. We're not, it's not fit for purpose in most, you know, unless it's some edge case, but we should track that as well, because that's part of our quality process and change failure rate's trying to track our quality process.
Richard Pangborn: Another problem we had is, um, mean, uh, meantime to recovery. So because we track our bugs or defects differently, they have different priorities. So, um, P0s here has to be done, has to be fixed in less than 24 hours. Um, P, priority 1 means, you know, five days, priority two, you have two weeks. So trying to come up with a, an algorithm to accurately identify, um, time to fix, I guess you'd have like three, three or four different ones instead of one.
Bryan Finster: I've tried to solve that problem too, and especially on distributed systems, it becomes very difficult. So who's getting measured on MTTR? I mean, I'm sorry. Yes, yes. Who's getting measured, right? It's going to be because MTTR, by definition, is when the user sees impact. And so really, that's whoever has the user interface owns that metric. If you're trying to help a team improve their processes for recovery. So it's, it's, it's just a really difficult metric to try to do anything with unless, um, well, you can't, it's, I've, I've, I've tried to measure it directly. I've talked to Verizon, CapitalOne, uh, you know, other people in the dojo consortium, they've tried to make, nobody's been successful at measuring it. But yeah. I think better metrics are out there for how fast we can resolve defects.
Richard Pangborn: Um, one of the things we were concerned about at the beginning was like a resistance to measurement. Um, some people don't want to be measured.
Bryan Finster: That's because they have management meeting over the head and using it as, as the reason why it's a massive fear thing. And it's part of the, it's a cultural thing. I mean, as long as you, it's, you have to have a generative culture to make these metrics effective. One of the things we would do when we start working with teams is number one, we'd explain to them, we're not trying to judge you. We're like your doctor. We're working with you. We're in the trenches with you. These are all of our metrics. They're not yours. And here's how to use them to help you improve. And if a manager comes and starts trying to beat you up with them, just, you know, stop making the data valid.
Richard Pangborn: Yeah. Well, some developers do want to know am I doing well, how do I measure myself? Um, So this gives them a way to do it a little bit, but we told them, um, you know, you set your own goals. Improve yourself. Don't measure yourself next to a developer, another developer on your team or, or someone else where you're looking for your own improvement.
Bryan Finster: Well, I think it's also really important that the smallest unit that's measured with delivery metrics is team and not person. If, if, if individuals are being measured, they're going to optimize for themselves instead of optimizing for team goals. And this is something I've seen, uh, frequently, uh, there was one, uh, with, you know, on, on our, on the dojo team, we can walk into your team and see that if there was filters by individual developer, your team was seriously broken. Uh, and I've seen managers who measured team members by how many Jira issues they closed, which meant that code review is going to be delayed, uh, mentoring was not going to happen, um, uh, you'd have senior engineers focusing on easy tasks to get their numbers up instead of focusing on solving the hard problems, design was not going to happen well because it wasn't a ticket, you know, and so you focus on team outcomes and measure team goals and individual performance because everybody has different roles on the teams. People know that from an HR perspective, coaching by walking around is how you find out who's struggling. You go to the gimbal, you find out who's struggling, you can't measure people directly, that way it'll impact team goals, business goals.
Richard Pangborn: Yeah, I don't think we measure it as a, um, whether they're not successful, it's just something for them to, to watch themselves.
Bryan Finster: As long as somebody else can see it. I mean.
Richard Pangborn: Yeah, it's just for them, isn't it? Not for anyone else.
Bryan Finster: Yeah.
Richard Pangborn: Um, cool. Yeah. Yeah. That's, that's about it for me. I think at the moment.
Kovid Batra: Perfect, perfect. I think, uh, Rich, if, if you are done with your questions, we have already started seeing questions from the audience.
Bryan Finster: There's one other thing I'd like to mention real quick before we go there.
Kovid Batra: Sure.
Bryan Finster: I also gave a talk about how to misuse and abuse DORA metrics, and the fact that people think there's, yes, there's four key metrics they focus on, but read Accelerate. There's a lot more in that book for things that you should measure, including culture. Uh, it's, it's important that you look at this as a holistic thing and not just focus on these metrics to show how well we're doing at CD. Cool, but the most valuable thing in Accelerate is Appendix A and not the four key metrics. So that's number one. But number two, value stream maps, they're manual, but they give you far deeper insights into what's going wrong than the 4 key metrics will. So learn how to do value stream maps and learn how to use them to identify problems and fix those problems.
Kovid Batra: And how exactly, uh, so just an example, I'm expecting an example here, like when, when you are dealing with value stream maps, you're collecting data from system, you're collecting data from people through surveys and what exactly are you creating here?
Bryan Finster: No, I don't collect any data from the system initially. So if I'm doing a value stream map, it'll be bringing a team together. We're not doing it at the, at the organization level. We're doing it at the team level. So you bring a team together and then you talk about the process, starting from delivery and working backwards to initiation of how we deliver change. Uh, you get a consensus from the team about how long things take, how long things are waiting to start. And then you start seeing things like, Oh, we do asynchronous code review, and so I'm ready for code review to start. Four to eight hours later, somebody picks it up and they review it. And then I find out later that they've done and there's changes being made, you know, maybe the next day. And then I go make those changes, resubmit it, and like four to eight hours later, somebody would go re-review it. And, and you see things like, Oh, well, what if we just sat down and discuss the change together and just fix it on the fly, um, and remove all that wait time? How much, you know, that would encourage smaller pieces of work? And we can deliver more frequently and get faster feedback and see, you can see just immediate improvements from things like that, just by doing a value stream map. But bringing the team together will give you much higher quality data than trying to instrument that because not all of those things are, there's data being collected anywhere.
Kovid Batra: Makes sense. All right. We'll take a minute break and we'll start with the Q and A after that. So audience, uh, please shoot out all your questions that you have.
All right. Uh, we have the first question.
Bryan Finster: Yeah. So MTTR is a metric measuring customer impact. So the moment from when a customer is impacted or user impact until they are no longer impacted. And that doesn't mean you fix the defect. It means that you are no, they are no longer being impacted. So roll back, roll forward, doesn't matter. That's what MTTR has mentioned.
Kovid Batra: Perfect. Let's, let's move on to the next one.
Bryan Finster: Yeah. So, um, there's some things where I can set hard targets on as, as ways to know that we're doing well. Integration frequency is one of those, you know, if, if we're integrating once per day or better into the trunk, then we're doing a really good job of breaking down our work. We're doing a good job of testing, or as long as we keep our defects from blowing up, you know, we should be testing. But you can set targets for that. You can also set targets as a team, not something you impose on a team. This is something we as a team do that we want to keep a story size of two days or less. Paul Hammett would say one day or less. Uh, but I think two days is, is a good time limit, that if we, if it takes us more than two days, we'll start running into other dysfunctions that cause quality impact and, and issues with delivery. So I've built dashboards where I have a line on those two graphs that say "this is what good looks like", so the teams can compare themselves to good. Other things that you don't want to gamify, you don't ever want to measure test coverage and say, "Hey, this is what good test coverage looks like." Because test coverage doesn't measure quality. It just measures how much code is executed by code that says it's a test whether it's a test or not. So don't want to do that. That's a fail. I learned that the hard way. Delivery frequency, of course, it's, that's relative to their delivery problem. Uh, you may be delivering every day, every hour, every week, and that all could be good. It just depends. Um, but you can make objective measurements on integration frequency and how long a unit of work takes to do.
Kovid Batra: Cool. Moving on to the next one. Uh, any recommendations where you learn, uh, where we can learn value stream maps?
Bryan Finster: Yeah, so Steve Pereira and Andrew Davis released 'Flow Engineering', which is basically, because there's lots of books on value stream mapping, but it's, from the past, but they're mostly focused on manufacturing and Steve and Andrew released the Flow Engineering book where they talk about using value stream maps to identify problems and how to go about fixing those things. So it was just released earlier this year.
Kovid Batra: Cool. Moving on to the next one. When would you start and how to convince upper management? They want KPI now and we are trying to get a VSM expert to come in and help. It's a hard sell.
Bryan Finster: Yeah, yeah. We want easy numbers. Okay. Well, you know, I would, I would start with having a conversation about what problems we're trying to solve. It's very much like the conversation you have when you're trying to convince management that we want to do continuous delivery. They don't care about continuous delivery unless that they're, they're deep into the topic. But they do care about, uh, you know, delivering better about business value. So you talk about the business value. When you're talking about performance indicators, well, what performance are we trying to measure? And we really need to have that hard conversation about, are we trying to measure how much, how many lines of code are getting dumped onto the end user? How much value are we delivering? Are we trying to, you know, reduce the size and cost of delivering change so we can be more effective about this, or are we just trying to make sure people are busy? And so if you have management that just wants to make sure people are productive, uh, and they're not opening to listening to why they're wrong, I'd quit.
Kovid Batra: All right. Can we move on to the next one then?
Bryan Finster: Where's the next one?
Kovid Batra: Yeah.
Bryan Finster: Oh, okay.
Kovid Batra: Is there any scientific evidence we can use to point out that working on small steps iteratively is better than working in larger batches? The goal is to avoid anecdotal evidence while discussing what can improve the development process.
Bryan Finster: You know, the hard thing about software, uh, in an industry is that people don't like sharing their information, uh, the real information because it can be stock impacting. And so we're, we're going to get a scientific study from a private company. Um, but we have a, you know, a few centuries worth of, of knowledge about knowing that if you build a whole bunch of the wrong thing, that you're not going to sell it. Um, there's, you don't have to do a scientific study because we have knowledge from manufacturing. Uh, you know, the, the, the Simpsons, the documentary The Simpsons, where they talk about the Homer car, where they build the entirely wrong car and put the company out of business without, because there was no feedback loop on that car at all until it was unveiled. Right? That's, that's really the problem. We're doing product development. And if you go off and say, I have this brilliant, well, you know, like, uh, uh, what was the, uh, Silicon Valley, they spent so much money building something nobody wanted and they kept iterating and trying to find the right thing, but they kept building the complete thing and building the wrong thing and just burning money. And this, this is the problem we're trying to solve. And so you're, you're trying to get faster feedback about when we're wrong, because we're inventing something new. Edison didn't build a million wrong light bulbs and see if any, I see if they worked.
Kovid Batra: All right. I think we can move on to the next one. Uh, what strategies do you recommend for setting realistic yet ambitious goals based on our current DORA metrics?
Bryan Finster: Uh, I would start with why can't we deliver today's work today? Well, I'd do that right after why can't we integrate today's work today? And then start finding out what those problems are and solving them. Uh, as far as ambitious goals, I mean, I think it's ambitious to be doing continuous delivery. Why can't we do continuous delivery? Uh, you know, one of the reasons why we put minimumcd. org together several years ago was because it's a list of problems to solve, and if you solve those problems, you can't solve those problems with an organization that's not a great place to work. You just can't. And the goal is to make it a better place to work. So solve those problems. That's an ambitious goal. Do CD.
Kovid Batra: Richard, do you have a question?
Richard Pangborn: Uh, myself? No?
Kovid Batra: Yup.
Richard Pangborn: Nope.
Kovid Batra: Okay. One last one we'll take here. Uh, yeah.
Bryan Finster: Yeah, so common pitfalls, and I think we touched on some of these before, is trying to instrument all but two of them. You could instrument two of them mostly, I think that, uh, you know, and change fail rate is not named well because of the description. It's really defect arrival rate. But even then, that depends on being able to collect data from defects and whether or not that's being collected in a disciplined manner. Um, delivery frequency, you know, people frequently measure that at the organization level, but that doesn't really tell you anything. You really need to get down to where the work is happening and try to measure that there. But then setting targets around delivery frequency, instead of identifying how do we improve, right? And it's, it's, it's all it is, is how do we, how do we get better, um, using them as goals? They're absolutely not goals. They're health indicators. You know, like I talked about the tachometer before, I don't have a goal of, we're going to run at 5, 000 RPM. I mean, number one, it depends on the engine, right? I mean, that would be really terrible for a sport bike, would blow up a diesel. So we, we need to, using them naively without understanding what they mean and what it is we're trying to do. I see it constantly. Uh, I and others who were early adopters of these met out, screaming about this for several years, and that's why I'm on here today is please, please don't use them incorrectly because it just hurts things.
Kovid Batra: Perfect. Uh, Bryan, I have one question. Uh, uh, like when, when teams are setting these benchmarks for different metrics that they have identified to be measured, what should be the ideal strategy, ideal way of setting those benchmarks? Because that's a question I get asked a lot.
Bryan Finster: Let's say, they were never benchmarks in Accelerate either. What they said was is that we're seeing a correlation between companies with these outcomes and metrics that look like this. So those aren't industry benchmarks, that's a correlation they're making. And correlation is not equal causation. I will tell you that being really good at continuous delivery means that you can, if you have good ideas, deliver good ideas well, but being good at CD doesn't mean you're going to be good at, at, at, you know, meeting your business goals because it depends, you know, garbage in, garbage out. Um, and so, you don't set them as benchmarks. They're not benchmarks. They're health indicators. Use them as health indicators. How do we make this better? Use them as, as things to cause you to ask questions. Why can't we deliver more than once a month?
Kovid Batra: So basically, if we are, let's say, for a lack of a better term, we use 'benchmarks'. There should, those should be set on the basis of the cadence of our own team, how they are working, how they are designed to deliver. That's how we should be doing. Is that what you mean?
Bryan Finster: No, I would absolutely use them as health indicators, you know, track trends. Are we trending up? Are we trending down? And then use that as the basis of starting an investigation into why are we trending up? Why are we trending down? I mean, are we trending up because people think it's a goal? And were there some other metric that's going south that we're not aware of while we're, while we're focusing on this one thing getting better? I mean, this is Richard, I mean, you pointed out exactly. It's a good balance set of metrics if they're measured correctly unlike if it's collected correctly. And you can't, you know, another problem I see is people focusing on 1. I remember a director telling his area, "Hey, we're going to start using DORA metrics. But for change management purposes, we're only going to start by focusing on MTTR instead of anything else." They're a set, they go together, you know? You can't just peel one out. Um, so.
Kovid Batra: Got it, got it. Yeah, that absolutely answers my question. All right. I think with that, we come to the end of this session. Uh, before we part, uh, any parting advice from you, Bryan, Rich?
Richard Pangborn: Um, just what we found successful in our own journey. Every, every company is different. They all have their own different processes, their own way of doing things, their own way of building things. So, there's not exactly one right way to do it. It's usually by trial and error for each, probably each company, uh, I would say. Depending on the tooling that you want to choose, the way you want to break down tasks and deliver stories. Like for us, we chose one day tasks in Jira. Um, we didn't choose, uh, long-lived branches. Um, we're not trunk-based explicitly, but we're, our PRs last no longer than a day. Um, so this is what we find works well for us. We're delivering daily. We haven't gotten yet to the, um, you know, delivering multiple times a day, but that's, that's somewhere in the future that we're going to get to, but you have to balance that with business goals. You need to get buy-in from stakeholders before you can get, um, development time to sort of build out that, that structure. So, um, it's a process. Um, everyone's different. Um, but I think bringing in some of these KPIs or, or sorry, benchmarks or health metrics, whatever you want to call them, um, has worked for us in the way where we have more observability into how we operate as engineers than we've ever had in the past. Um, so it's been pretty beneficial for us.
Bryan Finster: Yeah. I'd say that the observability is critical. Um, you know, I've, I've built a few dashboards for showing these things. And for people, for development teams who were, uh, focusing on "we want to improve", they always found value in those things. Um, but I, one, one caution I have is that if you are showing metrics on a dashboard, understand that the user experience of that will change people's behaviors. It's so important people understand. And whenever I'm building a dashboard, I'm showing offsetting metrics together in a way that they can't be separated, um, because you, otherwise you'll just focus on one. I want you to focus on those offsetting metrics as a group, make them all better. Um, but it only matters if people are looking at it. And if it's not a constant topic of conversation, um, it, it, it won't help at all. And I know, uh, Abi Noda and I have a difference of opinion on how, on data collection. You know, I'm big on, I want real-time data because I'm trying to improve quickly. Uh, he's big on surveys, but for me, and I don't get feedback fast enough on, um, with a survey to be able to correct the course correctly if I'm trying to do, if I'm trying to improve CI and CD. It's good for other stuff. Good for culture. So that's the difference. Um, but make sure that you're not just going out and buying a tool to measure these things that shows data in a way or has, you know, that causes bad behavior, um, or shows, or collects data in a way where it's not collecting it correctly. Really understand what you're doing before you go and implement a tool.
Kovid Batra: Cool. Thanks for that piece of advice, Bryan, Rich. Uh, with that, I think that's our time. Just a quick announcement about the next webinar session, which is with the pioneer of CD, the co-author of the book 'Continuous Delivery', Dave Farley. That will be on 25th of September. So audience, stay tuned. I'll be sharing the link with you guys, sending you emails. Thank you so much. That's it for today.
Bryan Finster: Thanks so much.
Richard Pangborn: I appreciate it.
Kovid Batra: Thanks, Rich. Thanks, Bryan.
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.
Typo recently hosted an engaging live webinar titled “The Hows and Whats of DORA,” featuring DORA expert Nathen Harvey and special guest Ido Shveki. With over 170 attendees, we explored DORA and other crucial engineering metrics in depth.
Nathen, the DORA Lead & Developer Advocate at Google Cloud, and Ido, the VP of R&D at BeeHero, one of our valued customers, brought their unique insights to the discussion.
The session explored why only 5-10% of engineering teams actively use DORA metrics and examined the current state of data-driven metrics like DORA and SPACE. It also highlighted the organizational and cultural elements essential for successfully implementing these metrics.
Further, Nathen explained how advanced frameworks such as DORA become critical based on team size and DevOps maturity, and offered practical guidance on choosing the most relevant metrics and benchmarks for the organization.
The event concluded with an engaging Q&A session, allowing attendees to ask questions and gain valuable insights.
P.S.: Our next live webinar is on August 28, featuring DORA expert Bryan Finster. We hope to see you there!
Want to Implement DORA Metrics for Improving Dev Visibility and Performance?
Kovid Batra: All right. Hi, everyone. Thanks for joining in for our DORA Exclusive webinar- The Hows & Whats of DORA, powered by Typo. This is Kovid, founding member at Typo and your host for today's webinar. And with me, I have two special co-hosts. Please welcome the DORA expert tonight, Nathen Harvey. He's the Lead and Dev Advocate at Google Cloud. And we have with us one of our product mentors, Typo Advocates, Ido Shveki, who is VP of R&D at BeeHero. Thanks, Nathen. Thanks, Ido, for joining in.
Nathen Harvey: Oh, thanks for having us. I'm really excited to be here today. Thanks, Kovid.
Ido Shveki: Me too. Thanks, Kovid.
Kovid Batra: Guys, um, honestly, like before we get started, uh, I have to share this with the, with our audience today. Uh, both of you have been really nice. It was just one message and you were so positive in the first response itself to join this event. And honestly, uh, I feel that this, these kinds of events are really helpful for the engineering community because we are picking up a topic which is growing, people want to learn more, and, uh, Nathen, Ido,, once again, thanks a lot for, for joining in on this event.
Nathen Harvey: Oh yeah, it really is my pleasure and I totally agree that these events are so important. Um, I often say that, you know, you can't improve alone. Uh, and that's true that each individual, we can't improve our entire organization or even our entire team on our own. It requires the entire team, but even an entire team within one organization, there's so much that we can learn from each other when we look into other organizations around the world and other challenges that people are running into, how they've overcome them. And I truly believe that each and every one of us has something to share with the community, uh, even if you were just getting started, uh, maybe you found a new pitfall that others should avoid. Uh, so you can bring along those cautionary tales and share those with, with the global community. I think it's so important that we continue to learn from and, and be inspired by one another.
Kovid Batra: Totally. I totally agree with that. All right. So I think, we'll just get started with you, Nathen. Uh, so I think the first thing that I want to talk about is very fundamental to the implementation of DORA, right? We know lately we had a Gartner report saying there were only 5 to 10 percent of teams who actually implement such frameworks through tools or through processes in their, in their organizations. Whereas, I mean, I have grown up in my professional career hearing that if we are measuring something, only then we can improve it. So if you go to any department or any, uh, business unit for that matter, everyone follows some sophisticated processes or tooling to measure those KPIs, right? Uh, why is it, why this number is so low in our engineering teams? And if let's say, they are following something only through What's the current landscape according to you? I mean, you have been such a great believer of all this data-driven DORA metrics, engineering metrics, SPACE. So what's, what's your thought around it?
Nathen Harvey: Yeah, it's a, it's a good question. And I think it's really interesting to think about. I think when you look at the practice of software engineering or development, or even operations like reliability engineering and things along those lines, these all tend to be, um, one creative work, right? When you're writing software, you're probably writing things that have never been written before. You're trying to solve a new problem that's very specific to your context. Um, it can be very difficult to measure, what does that look like? I mean, we've, we've used hundreds of different measures over the years. Some are terrible. You know, I think back to a while ago, and hopefully no one watching is under this measurement today. But how many lines of code did you commit to the repository? That's, that's a measure that has certainly been used in the past to figure out, is this a develop, is this developer being productive or not? Uh, we all know, hopefully by now that that's a, it's a terrible way to measure whether or not you're delivering value, whether or not you're actually being productive. So, I think that that's, that's part of it.
I also think, frankly, that, uh, until a few years ago, the world was working in a, in a way in which finances were easy to get. We were kind of living in this zero interest rate, uh, world. Um, and engineers, you know, we're, we're special. We do work that is, that can't be understood by anyone else because we have this depth of knowledge in exactly what we're doing. That's kind of a lie. Uh, those salespeople, those marketing people, they have a depth of knowledge that we don't understand, that we couldn't do their job in the same way that they couldn't do our job. And that's, that's not to say that one is better than the other, or one is more special than the other, but we absolutely need different ways to measure. And even ways that we have to measure other sort of disciplines, uh, don't actually give us the whole picture. Take sales, for example, right? You might look at well, uh, how much, uh, how much revenue is this particular salesperson bringing in to the organization? That is certainly one measure of the productivity of that salesperson, but it doesn't really give you the whole picture, right? How is that salesperson's experience? How are the people that are interacting with that salesperson? How is their experience? So I think that it is really difficult to agree on a good set of measures to understand what those measures are. And frankly, and this, this might be a little bit shocking, Kovid, but look, I, I, I am a big proponent of DORA and the research and everything that we've done here. But between you and me, I don't want you to do DORA metrics. I don't want you to. I don't care about the DORA metrics. What I care about is that you and your team are improving, improving the practices and the processes that you have to deliver and operate software, improving the well-being of the members of your team, improving the value that you're creating for your business, and improving the experience that you're creating for your customers.
Now, none of those are the DORA metrics. Of course, Measuring the DORA metrics helps us assess some of those things and what we've been able to show through the research is that improving things like software delivery performance have positive outcomes or positive predictive nature of better organizational success, better customer satisfaction, better well-being for your teams. And so, I think there's there's this point where, you know, there's, uh, maybe this challenge, right, do you want, do you want me to spend as an engineer? Do you want me to spend time measuring the work that I'm doing, measuring how much value am I delivering, or do you want me delivering more value? Right? And it's not really an either or trade-off, but this is kind of some of the mindsets I have. And I think that this is some of the, the blockers that come in place when people want to try to bring in a measurement framework or a metrics framework. And then finally, Uh, you know, between you and me, nobody really likes their work to be measured. I want to feel like I'm providing valuable work and, and know that that's the case, but if you ask me to measure it, I start to get really worried about why are you asking that question. Are you asking that question because you want to give me a raise and a promotion and more money? Great. I'm gonna make sure that these numbers look really good. If you're asking that question to figure out if you need to keep me on board, or maybe you can let me go, now I'm getting really nervous about the questions that you're asking.
And so I think there's a lot of like human nature in the prevention of adopting these sorts of frameworks. And it really gets back to, like, who are these frameworks for? And again, I'll just go back to what I said sort of towards the beginning. I don't want you to do DORA metrics. I want you to improve. I want you to get better. And so, if we think about it in that perspective, really the DORA metrics are for me and my teammates. They aren't necessarily for my leaders. Because it's me and my teammates that are going to make those improvement efforts.
Kovid Batra: Totally. I think, um, very wise words there. One thing that I just picked up from what you just said, uh, from the narrative, like there is a huge organizational cultural play in this, right? People are at the center of how things get implemented. So, you have been experiencing this with a lot of teams. You have implemented this. What's the difference that you have seen? What are those mindsets which make these things implement actually? What are those organizational factors that make these things implement?
Nathen Harvey: Yeah, that's a, that's a good question. I would say, first it starts with, uh, the team that you're going to start measuring, or the application, the group of people and the technology that you want to start measuring. First, these people have to want to change, because if we're, if we're going to make a measure on something, presumably we're making that measure so that we understand how we are, so that we can improve. And to improve, we have to change something. So it starts with the people wanting to change. Oh, except I have to be honest, that's not enough. Wanting to change actually isn't enough. We all want to change. We all want to get better. Actually, maybe we all just want to get better, but we don't want to have to change anything. Like I'm very comfortable in the way that I work. So can it, can it just produce better results? The truth is, I think we have to find teams that need to change. There has to be some. Motivating factor that's really pushing them to change because after we look at the dashboard, after we see some numbers, if we're not truly motivated, if there isn't a need for us to change, we're probably not going to change our behavior. So I think that's the first critical component is this need to improve, this fundamental desire that goes beyond just the desire. It's, it's a motivating factor. You have to do this. You have to get better because the competition is coming after you, because you're feeling burnt out, because for a myriad of reasons. So I think that that's a big first step in it.
Kovid Batra: A lot of times, what I have seen while talking to a lot of my Typo clients also, uh, is, uh, they feel that there is a stage when this needs to be implemented, right? So people use Git metrics, Jira metrics to make sure things are running fine. And I kind of agree to them, like very small teams can, can rely on that. Like maybe under 10 size teams are good. But, what do you think, uh, what, what's the DevOps maturity? What's the team size that impacts this, where you need to get into a sophisticated framework or a process like DORA to make sure things are, uh, in, in the right visibility?
Nathen Harvey: Yeah, that's, that's, that's a really good question. And I think unfortunately, of course, the answer is it, it depends, right? It is pretty context-specific. I do think it matters that, uh, it matters the level at which you're measuring these things. You know, the DORA metrics have always been meant, and if you look at our survey, we always sort of prepend our questions with, for the primary application or service that you're working on. So when we think about those DORA metrics, those software delivery metrics in particular, we aren't talking about an organization. What is the, you know, we don't ask, for example, what is the deployment frequency at Typo? But instead, we ask about specific applications within Typo, and we expect that you're going to have variation across the applications within your team. And so, when you have to get into this sort of more formal measurement program, I think that really is context-specific. It really depends on the business and even what are you measuring? In fact, if if your team has, uh, more of a challenge with developing code than they do with shipping code, then maybe the DORA metrics aren't the right metrics to start with. You want to sort of find your constraint within your organization, and DORA is very much focused on software delivery and operational performance. So on the software delivery piece, it's really about are we able to take this code that was written and get it out the door, put it in front of customers. Of course, there's a lot of things on the development side that enable that. There's a lot of things on the operational side that benefit from that. It all kind of comes together, but it is really looking at finding that particular pain point or friction point within your organization.
And then, I think one other thing that I'll just comment on really quickly here is that as teams start to adopt these frameworks, there's often an overfitting for precision. We need precise data when it comes to this. And honestly, again, if you go back to the methods that DORA uses, each year we run an annual survey. We ask people, what is your average time or your typical time from code committed to code in production? We're not hooking into your Git systems or your software delivery pipelines or your, uh, task backlog management systems. We're not hooking into any of those things. We're asking about your experience. Now, we have to do that given that we're asking the entire world. We can't simply integrate with all of those systems. But this level of precision is very helpful at some point. But it doesn't necessarily need to be where you start. Right? Um, I always find it's best to start with a conversation. Kind of like what we're having today.
Kovid Batra: But yeah, I think, uh, the toolings that are coming into the, into the picture now are solving that piece also. So I think both the things are getting, uh, balanced there because I feel the survey part is also very critical to really understand what's going on. And on top of that, you have some data coming from the systems without any effort that reduces your pain and trust on what you are looking at. So yeah, that makes sense.
Nathen Harvey: Yeah, absolutely. And, and, and there is a cautionary tale built in there. I've seen, I've seen too many teams go off and try to integrate all of these systems together to get all of the precise data and beautiful dashboards. Sometimes that effort ends up taking months. Sometimes that effort ends up taking years. But what those teams fail to do over those months or years is actually try to improve anything. All they're trying to improve is the precision of the data that they have. And so, at the end of that process, they have more precise, a more precise understanding of what they knew at the beginning of that process.
And they haven't made any improvements. So that's where a tool like Typo, uh, or others of this nature like really come in because now I don't have to think about as much, all of that integration, I can, I can take something off the shelf, uh, and run it in my systems and immediately start to get value from that.
Kovid Batra: Totally. I think, uh, when it comes to using the product, uh, Ido has been, uh, one of the people who has connected with me almost thrice in the last few days, giving me some feedback around how to do things. And I would let Ido have some of his, uh, questions here. And, uh, I have, uh, my demo dashboard also ready. So if there is anything that you want to refer back to Ido or Nathen, to like highlight some metrics that they can look at, I, I'll be happy to share my screen also. Uh, over to you, Ido. I'll, I'll put you on the main screen so that the audience sees you well.
Ido Shveki: Oh, thanks, Kovid. And hi again, Nathen. Uh, first of all, very interesting, uh, and you speaking about it. I also find this topic, uh, close to my heart. So I, uh, I, it's a fascinating to hear you talk about it. I wanted to know, uh, if you have any, you mentioned before that among the different, like you said, it may be inside the Typo as a company, there are like different benchmarks, different, uh, so how can you identify this, uh, benchmark? Maybe my questions are a bit practical, but let me know if that's the case, but yeah, I just want to know how to identify this benchmark because as you mentioned, and also at BeeHero, we have like, uh, uh, different teams, different sizes, different maturity, uh, different, uh, I mean, uh, seniority level. So how can I start with these benchmarks?
Nathen Harvey: Yeah, yeah. That's a, that's a really great question. So, um, one of the things that I like to do when I get together with a new team is we first kind of, or a new organization first, let's, let's pick an application or two. So at, BeeHero, uh, I, I, I know very little about what BeeHero does, you know, tell us a little bit about BeeHero. Give us, give us like a 30-second pitch on BeeHero. What do you do there?
Ido Shveki: Cool. So we are an Israeli startup where we deal with agriculture. What we do is we place, uh, sensors inside beehives as the, as the name might, uh, you know, give you a hint. Uh, we put sensors inside beehives and this way we can give a lot of, uh, we, we collect metrics and we give great, uh, like, uh, good insights, interesting insights to beekeepers, uh, so that they can know what to do with their bee colony, how to treat it, and how to maintain the bee colony. So, this is, you know, basically, and if, if I'm, uh, to your question, so we have, yeah, uh, different platforms. We have the infra platforms, we have the firmware guys, we have mobile app, et cetera. So. But I assume that like every company has this, different angles of a product.
Nathen Harvey: Yeah. Yeah. Yeah. Of course. Every company has hundreds, maybe thousands of different products that they're maintaining. Yeah, for sure. Um, not, well that's first, that's super cool. Um, keeping the farmers and the bees happy. Now, so what I like to do with, with a new team or organization that I'm working with is we start with an application on our service. So maybe, maybe we take the mobile application that BeeHero has and what we want to do is bring together, in the perfect world, we bring together into a physical room, everyone that's responsible for prioritizing work for that application, designing that work, writing the software, shipping the software, running the service, answering customer requests, all of that stuff. Uh, perhaps we'd let the bees stay in the hives. We don't bring them into the room with us. Um, software engineers aren't, aren't known for being good with bees, I guess. So, but..
Ido Shveki: They do affect the metrics though. Yeah, I don't want, I don't want that.
Nathen Harvey: Absolutely. Absolutely. So, so we'll bring these people together. And I like to just start with a conversation, uh, at dora.dev, we have a quick check, that allows you to quickly answer those for software development or software delivery performance metrics. You know, the deployment frequency, change lead time, your change failure rate and your failed deployment recovery time. But even before we get to those metrics, I like to start with a simpler question. Okay, so together as a team, a developer has just committed a change to the version control system. As a team, let's go to the board and let's map out every step in the process, every handoff that has to happen between that code commit and that code landing in production, right, so that the users can use it. And the reason we bring together a cross-functional team is because in many organizations, I don't know how big BeeHero is, but in many organizations, there are handoffs that happen from one team to the next, sort of that chain of custody, if you will, to get to production. Unfortunately, every single one of those handoffs is an opportunity for introducing friction, for hiding information, you know. I've, I've worked with teams as an example where the development team is responsible for building a package, testing that package and then they hand it off to the test team. Well, the test team does, takes that package and they discard it. They go back to the Git repo. They actually clone the Git repo and then they build another package and then start testing that. So now, the developers have built a package that gets discarded. Now the testers build another package that they test against that probably gets discarded and then someone else builds a third package for production. So there's, as you can imagine, there's lots of ways for that handoff and those three different packages to be different from one another. This is, it's, it's mind boggling. But until we put all those people in the room together, you might not even see that friction and that waste in the process. So I start there to really identify where are those friction points? Where are those pain points? And oftentimes you have immediate sort of low hanging fruit, if you will, immediate improvement opportunities.
And the most exhilarating part of that process as a facilitator is to see those aha moments. "Oh my gosh! I didn't realize that you did that." "Oh, I thought I packaged it this way so that you could do this thing that you're not even doing. You're just rubber stamping and passing it on." Or whatever it is. Right? So you find those things, but once you've done that map, then you go back to those four questions. How's my, what are my, you know, we used a quick check in that process. What does my software delivery performance look like? This gives us a baseline. This is how we're doing today. But in this process, we've already started to identify some of those areas for improvement that we want to set next. Now I do this from one team to the next or encourage the teams to do this on their own. And this way we aren't really comparing, you know, what is your mobile app look like versus the front end website, right? Should they have the same deployment frequency? I don't know. They have different customers. They have different needs. They have different teams that are working on them. So you expect them to be different. And the thing that I don't really care about over time is that everyone gets to the top level or a consistent performance across all of the teams. What I'd much rather see is that everyone is improving over time, right? So in other words, I'd rather reward the most improved team than the team that has the highest performance. Does that make sense?
Ido Shveki: Yeah, a lot actually.
Nathen Harvey: All right.
Ido Shveki: Thanks.
Nathen Harvey: Awesome. Yeah.
Ido Shveki: Kovid, do we have another, time for another question?
Kovid Batra: Yeah, I do. I mean, uh, you can go ahead, please. Uh, we have another three minutes. Yeah.
Ido Shveki: Oh, cool. I'll make it quick. I'm actually interested in how do you aligned the business to DORA metrics? Because I usually I find myself talking to the management, CEO, CTO, trying to explain to them what's, what's happening under the hood in the developer team and it's not always that easy. Do you have some tips there?
Nathen Harvey: Yeah, you know, as your CEO come to you and said, You know, you know, last year you did 250 deploys. If you do 500 this year, I'm going to double your salary. They probably never said that to you. Did that?
Ido Shveki: No, no.
Nathen Harvey: No, no. Primarily because your CEO probably doesn't care how many deploys you delivered. Your CEO.
Ido Shveki: And I think that's, I mean, I wouldn't want them to.
Nathen Harvey: You don't want them to. You're, you're exactly right. But they do care about other things, right? They care about, I don't, I don't know, I'm going to make up some metrics. They care about how many, uh, like the health of the hives that each farmer has, right? Like, that's what they care about. They care about how many new farmers have signed up or how many new beekeepers have signed up, what is their experience like with BeeHero. And, and so really, as you go to get your executives and your management and, and the business tied into these metrics, it's probably best not to talk about these metrics, but better to talk in terms of the value that they care about, the measures that they care about. So, you know, our onboarding experience has left some room for improvement. If we ship software faster, we can improve that onboarding experience. And really it's a hypothesis. We believe that by improving our software delivery performance, we'll be able to respond faster to the market needs, and we'll be able to therefore improve our onboarding process as an example, right? And so now you can talk to your CEO or other business counterparts about look, as we've improved these engineering capacities and capabilities, we've seen this direct impact on our customers, on the business value that we care about. DORA shows, through our data collection, that software delivery performance is predictive of better organizational performance.
But it's up to you to prove that, right? It's up to you, essentially, we encourage you to replicate our study. We see this when we look across teams. Do you see this on your team? Do you see that improving? And that's really, I think, how you should talk about it with your business counterparts. And frankly, um, you, you are the business as well. So it also encourages you and the rest of the engineers on your team to remember, we aren't creating this application because we want to use the new, uh, serverless technology, or we want to play with the latest, greatest AI. We're building this application to help with the health of bees, right? And so, keeping that connection back to the business, I think is really important.
Kovid Batra: Okay. On your behalf, can I ask one question?
Yeah. So I think, uh, there are certain things that we also struggle with, with not just Ido, but, uh, various other clients also that, which metrics to pick up. So can we just run through a quick example from your, uh, history of clients where you have, uh, probably highlighted for, uh, let's say, a 100-member dev team. What metrics make sense in what scenario? I, I'll quickly share my screen. Uh, I have some metrics highlighted for, for DORA and more than that on Typo.
Nathen Harvey: Oh, great!
Kovid Batra: You can tell me which metrics one should look at and how one should navigate through it.
Nathen Harvey: Yeah, for sure. That, that'd be awesome. That'd be awesome. So I think as you're pulling up your screen, I'll just start with, you know, the, the reason that the DORA software delivery metrics are nice, is kind of multifold, right? First, there's only four of them. So you can, you can count them on one hand. That's, that's a good thing. Uh, you aren't over, like over, have too many metrics that you just don't know. How many, which lever should we pull? There's too many in front of me, right? Second. Um, they, they represent both lagging and leading indicators. In other words, they're lagging indicators for what does your engineering process look like? What's engineering excellence or delivery excellence look like within your organization? These DORA metrics can tell you. Those are the lagging indicators. You have to change things over here to make them improve. But they're leading indicators for those business KPIs, right? Organizational performance, well-being for the people on your team. So as we improve these, we expect those things to improve as well. And so, the nice thing about starting with those four metrics is that it gives you a good sense of where you are. Gives you a nice baseline.
And so, I'm just going to make my screen a little bit bigger so I can see your, uh, yeah, that's much better. I can see your dashboard now. All right. So you've got, uh, you've got those, uh, looks like those four, uh, a couple of those delivery metrics you got, uh, oh, actually tell me what, what do you have here, Kovid?
Kovid Batra: Yeah. So we have these four DORA metrics for us, the cycle time, deployment frequency, change failure rate, and mean time to restore. So we also believe in the same thing where we start off with these fundamental metrics. And then, um, we, we have more to deep dive into, like, uh, you can see things at team level, so there are different teams in one single view where you can see each team on high level, how their velocity, quality, and throughput looks like. And when you deep dive, you find out those specific metrics that basically contribute to velocity, quality, and throughput of the teams. And these are driven from DORA and various other metrics that we realized were important and critical for people to actually measure what's going on.
Nathen Harvey: Yeah. Yep, that's great. And so I really like that you can see the trend over time because honestly, the, the single number doesn't really mean anything to you. It's like getting on the scale in the morning. There's a number on the scale. I don't know if that's good or bad. It depends on what it was yesterday and what it will be tomorrow. So seeing that trend is the really important thing here because then you can start to make decisions and commitments as a team on experiments that you want to run, right? And so in this particular case, you see your cycle time going up. So now what I want to do is kind of dig in. Well, what's, what's behind the cycle time, what's causing this? And that's where the things like the, that map and, and you see here, we've got a little map that shows you exactly sort of what happens along that flow. So let's take a look at those. We have coding, pick up, review and merge, right? Okay, yup. And so the, nice thing there is that the pickup seems like it's going pretty well, right? One of the things that we found last year in our survey was that teams with faster code reviews have 50 percent better software delivery performance. And so it looks like this team is doing pretty good job. I imagine that pickup is you're reviewing that code, right?
Kovid Batra: Yeah. Yeah. Yeah.
Nathen Harvey: Mm hmm. Yeah. So, so that's good. It's good to see that. But what's the review? Oh, I see. So pickup must be when you first grab the PR and then review maybe incorporates all the sort of back and forth feedback time.
Kovid Batra: Yes, yes. And finally, when you're merging it to your main branch, so the time frame between that is your review time.
Nathen Harvey: Ah, gotcha, gotcha, gotcha. Okay, so for me, this would be a good place to dig in. What's, what's happening there? Because if you look between that pickup and review, that's about 8 hours of your 5, 10, 15, uh, 18 hours. So it's a significant portion there is, sort of in that code review cycle. This is something I'd want to look at.
Kovid Batra: Perfect.
Nathen Harvey: Yeah. Yeah. And we see this, we see this a lot. Um, one, one organization I worked with, um, the, the challenge that they had was not necessarily in code review, but in approvals, they were in a regulated industry and they sent all changes off to a change approval board that had to approve them, that change approval board only met so frequently, as you can imagine, that really slowed down their cycle time. Uh, it also did not help with their stability, right? Um, changes were just as likely to fail when they went to production as not, uh, regardless of whether or not they went through that change approval board. So we really looked at that change approval process and worked to help them automate that. The net result is I think they're deploying about 600 times more frequently today than they were before we started the process, which is pretty incredible.
Kovid Batra: Cool. That's really helpful, Nathen. And thanks for those examples that fit into the context of a lot of our audience here. In fact, this question, I just realized was asked by Benny Doan also. So I think he would be happy to hear you. And, uh, I think now it's time. I feel the audience can ask their questions. So, um, we'll start with a 15 minute Q&A round where all the audience, you are free to comment in the comment sections with all the questions that you have. And, uh, Nathen, Ido, uh, would be happy to listen out to you on those particular questions.
Ido Shveki: Kovid, should we just start answering these questions?
Kovid Batra: Yeah.
Nathen Harvey: Yeah, I'm having trouble switching to the comments tab. So maybe you could read some of the questions. I can't see them.
Ido Shveki: Um, I can see a question that was also asked by Benny, which I worked in the past. Oh, hi, Benny. Nice that you're here. Um, about how to, like, uh it was by Nitish and Benny as well, asking about how does the, the dev people, the developers won't feel micromanaged when we are using, um, uh, the DORA metrics with them. Um, I can begin, I'll let you Nathen, uh, uh, elaborate on it in a second. I can begin with my experience thing that first of all, it is a slippery slope. I mean, I do find it not trivial to, to, um, like if you would just show them that I'm looking at the times from this PR to the improvement and line of codes, et cetera, like Nathan said in the beginning. Yeah. I mean, they would feel micromanage. Um, I, uh, first of all, I, I usually talk about it on a, on a team level or an organization level. And when I do want to raise this, uh, questions or maybe like address them as a growth opportunities for a certain developer. Uh, personally, I don't look at it as a, like criticism. I, it's like a, it's a beginning of a conversation. It's not like I don't know. I didn't make up my mind before. Uh, and because of this metric looks like this, then I'm not pleased with how you perform. It's just like, All right. I've seen that there is a decrease here. Uh, is there a reason? Let's talk about, let's discuss it. I'm easily convinced if there are like, uh, ways to be convinced. And, but, but yeah, I do look at it as a growth. Um, I try to, to, to convince and I do look at it as a, like a, growth opportunity for the developer to, to look at, uh, yeah, that's, that's at least my take over this.
Nathen Harvey: Yeah, I definitely agree with that, you know, because I think that this question really gets to a question of trust. Um, and how do you build trust with your teammates? And I think the way that you build trust is through your actions. Right? And so if you start measuring and then start like taking punitive action against individual developers or even teams, that's going to, your actions are going to tell people, you should be afraid of these metrics. You should do whatever you can to not be measured by these metrics, right? But instead, if and DORA talks a lot about culture, if you lean in and use this as an opportunity to improve, an opportunity to learn more about how the team is going. And, and I like your approach there where you're taking sort of an inquisitive approach. Hey, as an example, you know, Hey, I see that the PRs, uh, that you started to submit fewer PRs than you have in the past, what's going on? It may be that that person has, for the time being, prioritized code reviews. So they're doing less PRs. It may be that they're working on some new architectural thing. They're doing less PRs. It may be that, uh, they've had a family emergency and they've been out of the office more. That's going to lower their PRs. That's the, the, the fact that they have fewer PRs is not enough information for you to go on. It is a good place to start a conversation.
And then, I think the other thing that really helps is that you use these metrics at the team level. So if you as a team start reviewing them, maybe during your regular retrospectives or planning sessions, and then, importantly, it comes back to what are you going to change? Is the team going to try something different based on what they've learned from these metrics? Oh, we see that our lead time is going up, maybe our continuous integration practices, we need to put some more effort into those or some more automated testing. So over the next sprint or time block, we're going to add, you know, 20 percent more capacity for automated testing. And let's see how that impacts things. So seeing that these metrics are being used to inform improvements, that's how you prevent that slippery slope, I think.
Kovid Batra: Totally. Okay. I think we can move on to this next question. Uh, this is Nitish. Uh, how can DORA and data-driven approach be implemented in a way that devs don't feel micromanaged? Yeah, I think.
Nathen Harvey: Yeah, I think, I think we've covered a little bit of this in the previous question here, Nitish. And I think that it really comes back to remembering that these are not measures that should be at the individual level. We're not asking, Kovid, what's your deployment frequency? You know, what's yours? Oh, one of you is better than the other. Something's going to change. No, no, no. That's not how we, that's not how we use these measures. They're really meant for that application or service level. When it comes to developing, delivering, operating software or any technology, that's a team sport. It's not an individual sport.
Kovid Batra: All right. Then we have from Abderrahmane, uh, how are the market segments details used for benchmark collected?
Nathen Harvey: Yeah, this is a really good question. Thanks for that. So, uh, as you know, we run a survey each year and we ask about what industry are you in? Um, and what we found surprisingly, maybe, maybe not surprisingly is that over the years, industry is not really a determinant of how your software delivery performance is going to be. In other words, what we see across every industry, whether it's technology or retail or government or finance, we see teams that have really good software delivery performance. We also see in all of those industries, teams that have route rather poor software, but lots of opportunities to improve their software delivery performance, I should say. Yeah.
So we see that, uh, the market segments are there and, and honestly, we, we publish that data so that people can see that, look, this can happen in our industry too. Um, I always worry that, you know, someone might use their industry as a reason not to question the status quo. Oh, we're in a regulated industry, so we can't do any better. It doesn't matter what industry you're in. You can always do better. You can always do worse as well. So just be careful, like focus on that improvement.
Kovid Batra: Cool. Uh, next question is from Thomas. Uh, how do you plan the ritual with engineers and stakeholders when you're looking at this metric? Yeah, this is a very, uh, important question. I think Nathen, would you like to take this up?
Nathen Harvey: Yeah, I'll take this. I'd love to hear how Ido is doing this as well, sort of incorporating the metrics into their daily work. But I think it's, it's, it's just that as you go into your planning or retrospective cycle, maybe as a team, you think about the last period and you pull up maybe the DORA quick check, or if you're using Typo or something like it, you pull up the dashboard and say, "Look, over the last two weeks over the last month, here's where we're trending. What are we going to do about that? Is there something that we'd like to change about that? What can we learn about that?" Start just with those questions. Start thinking about that. So I think really just using it as a, as a discussion point in those retrospectives, maybe an agenda item in those retrospectives is a really powerful thing that you can do.
Ido, what's your experience?
Ido Shveki: Yeah. So, um, I totally agree. And I think in most parts, this is what I, what I also do, we're also doing at BeeHero, in their perspectives, maybe not on, bi-weekly basis, like every two weeks because sometimes they find it too often and not too much to, to, you know, to, uh, I want it to be, uh, tell them something new, let's say. Um, but also I do find it in what we, when we are doing some rituals for some incident that happened and we're discussing this issue, I really put emphasis, and I think this is the cultural part that you mentioned before. Uh, in this rituals of, uh, incident, uh, rituals. I really try to point out and look at, uh, uh, how long did it take us to mitigate it? Um, when, like how, how long, uh, until the, the customer didn't see the issue. And from these, uh, points, you can, I mean, I hope the team understands the culture that I'm pushing towards. And from that point, they will also want to implement DORA metrics without even knowing the name DORA. We don't really care about the name. I mean, we don't really, it doesn't really matter if they know how to call it. Just like to, as you mentioned before, I don't want you to know about DORA. Just get better or just be better at this. So yeah, that's basically it.
Nathen Harvey: Thanks. Awesome.
Kovid Batra: All right. I think there is one thing that I wanted to ask from this. It's good with the engineers, probably, and you can just pull in every time. But when it comes to other stakeholders in the business, what I have seen and experienced with my clients is they find it hard to explain these DORA metrics in terms of the business language. I think Nathen, you touched upon this in the beginning. I would like to just highlight this again for the audiences' sake.
Nathen Harvey: Yeah, I think that, I think that's really important. And I think that when it comes to dashboards, uh, it, it would be really good to put your delivery performance metrics right next to your organizational performance metrics, right? Are we seeing better customer, like, are we seeing the same trend? As software delivery improves, so do customer signups, so do, uh, revenue that we get per customer or something along those lines. That's, you know, if you think about it, we're really just trying to validate an experiment. We think that by shipping this feature, we're going to improve revenue. Let's test that. Let's look at that side-by-side.
Kovid Batra: Totally. All right. Uh, we have a lot of questions coming in. Uh, so sorry, audience, I'm not able to pick all of those because we are running short on time. We'll pick one last question. Uh, okay. That's from Julia. Uh, are there any variations of DORA metrics you have found in customer deployed or installed software? Example, deployment frequency may not be directly relevant. A very relevant question. So yeah.
Nathen Harvey: Yeah, absolutely. Uh, I think, I think the beauty of the four key metrics is that they are very simple, except they're not, they are very simple on the surface, right? If, and if you take just, let's just take one of them, change lead time. In DORA's language, that starts at like change is committed and it ends when that changes in production. Okay. What does committed mean? Is it committed to a branch? Is it committed to the main line? Is that branch, has that branch been merged into the main line? Who knows? Um, I have a perspective, but it doesn't really matter what my perspective is. When it comes to production. What does it mean to be in production? If we're doing, um, progressive deploys, does it mean the first user in production has it or only when 100 percent of users have it? Is that when it's in production? Or somewhere in between? Or we're running mobile applications where we ship it off to the app store and we have to wait for it to get approved, or installed software where we package it up and we shrink wrap it into a box and we ship out a CD. Is that deployed? I mean, I don't, I don't know that anyone does that any, well, I'm sure it happens. I know in the Navy they put software on helicopters and they fly it out to ships. So that's, you know, all of these things happen. Here's the thing. For your application, what you need to do is think about those four metrics and write down for, for this application, commit, change, change lead time starts here at this event ends here at that event. We're going to write that down probably in maybe something like an architectural decision record and ADR, put it into the code base. And as you write it down, make sure that it's clear, make sure that everyone agrees to it, and probably just as importantly, make sure that when you write it down, you also write down the date at which we will revisit this decision, right? Because it doesn't have to be set in stone. Maybe this is how we're going to measure things starting today, and we'll come back to this in six months. And some of the things that drive that might be the mechanics of how you deliver software. Some of the things that drive that might be the data that you have access to, right? And over time, you may have access to more precise data, additional data that you can then start to use in that. So the important thing is that you take these metrics and you contextualize them for your team. You write down what those metrics are, what their definitions are for your team and you revisit those decisions over time.
Kovid Batra: Perfect. Perfect. All right. I think, uh, it's already time. Nathen, would you like to take one more question?
Nathen Harvey: Uh, I'm happy to take one more question. Yes.
Kovid Batra: All right. All right. So this is going to be the last one. Sorry if someone's question is not being asked here. But let's, let's take this up. Uh, this is Jimmy. Uh, do you ever try to map a change in behavior/automation/process to a change in, in the macro-DORA performance? Or should we have faith that our good practices is what is driving positive DORA trends?
Nathen Harvey: Um, I think that, uh, having faith is a good thing to do. Uh, but validating your experiments is an even better thing to do. So, uh, as an example, uh, let's see, trying to change a behavior automation process to a change in the macro performance. Okay. Uh, I'll, I'll, I'll pick a change that you might have or an automation that you might have. Let's say that, uh, today, your deployment process is a manual process, uh, and you're doing, and there's lots of steps that are manual, uh, and you want to automate that process. Uh, so, we can figure out what are our, what's our software delivery performance look like today, you can use a Typo dashboard, you could use the DORA quick check. Write that number down. Now make some investments in automation, deployment automation, you've deployed, instead of having 50 manual steps, you now have 10 manual steps that you take and 40 that have been automated. Now let's go back and remeasure those DORA performance metrics. Did they improve? One would think and one would have faith that they will have improved. You may find for some reason that they didn't. But, validating an experiment and invalidating an experiment are kind of the same thing. In either case, it's really about the approach that you take next. Are you using this as an opportunity to learn and decide how are we going to respond to the, the new information that we have? It really is about a process of continuous learning, And hopefully continuous improvement, but with every improvement, there may be setbacks along the way.
Kovid Batra: Great. All right. On that note, I think that's our time. We tried to answer all the questions, but of course we couldn't. So we'll have more sessions like this, uh, to help all the audience over here. So thanks a lot. Uh, thank you for being such a great audience. Uh, we hope this session helped you build some great confidence around how to implement DORA metrics in your teams.
And in the end, a heartfelt thanks to my cohosts, Nathen and Ido, and to my Typo team who made this event possible. Thanks a lot, guys. Thank you.
Nathen Harvey: Thank you so much. Bye bye.
Ido Shveki: Thanks for having us. Bye.
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.
Sign up now and you’ll be up and running on Typo in just minutes
