In today's fast-paced and rapidly evolving software development landscape, effective project management is crucial for engineering teams striving to meet deadlines, deliver quality products, and maintain customer satisfaction. Project management not only ensures that tasks are completed on time but also optimizes resource allocation enhances team collaboration, and improves communication across all stakeholders. A key tool that has gained prominence in this domain is JIRA, which is widely recognized for its robust features tailored for agile project management.
However, while JIRA offers numerous advantages, such as customizable workflows, detailed reporting, and integration capabilities with other tools, it also comes with limitations that can hinder its effectiveness. For instance, teams relying solely on JIRA dashboard gadget may find themselves missing critical contextual data from the development process. They may obtain a snapshot of project statuses but fail to appreciate the underlying issues impacting progress. Understanding both the strengths and weaknesses of JIRA dashboard gadget is vital for engineering managers to make informed decisions about their project management strategies.
JIRA dashboard gadgets primarily focus on issue tracking and project management, often missing critical contextual data from the development process. While JIRA can show the status of tasks and issues, it does not provide insights into the actual code changes, commits, or branch activities that contribute to those tasks. This lack of context can lead to misunderstandings about project progress and team performance. For example, a task may be marked as "in progress," but without visibility into the associated Git commits, managers may not know if the team is encountering blockers or if significant progress has been made. This disconnect can result in misaligned expectations and hinder effective decision-making.
JIRA dashboards having road map gadget or sprint burndown gadget can sometimes present a static view of project progress, which may not reflect real-time changes in the development process. For instance, while a JIRA road map gadget or sprint burndown gadget may indicate that a task is "done," it does not account for any recent changes or updates made in the codebase. This static nature can hinder proactive decision-making, as managers may not have access to the most current information about the project's health. Additionally, relying on historical data can create a lag in response to emerging issues in issue statistics gadget. In a rapidly changing development environment, the ability to react quickly to new information is crucial for maintaining project momentum hence we need to move beyond default chart gadget like road map gadget or burndown chart gadget.
Collaboration is essential in software development, yet JIRA dashboards often do not capture the collaborative efforts of the team. Metrics such as code reviews, pull requests, and team discussions are crucial for understanding how well the team is working together. Without this information, managers may overlook opportunities for improvement in team dynamics and communication. For example, if a team is actively engaged in code reviews but this activity is not reflected in JIRA gadgets or sprint burndown gadget, managers may mistakenly assume that collaboration is lacking. This oversight can lead to missed opportunities to foster a more cohesive team environment and improve overall productivity.
JIRA dashboard or other copy dashboard can sometimes encourage a focus on individual performance metrics rather than team outcomes. This can foster an environment of unhealthy competition, where developers prioritize personal achievements over collaborative success. Such an approach can undermine team cohesion and lead to burnout. When individual metrics are emphasized, developers may feel pressured to complete tasks quickly, potentially sacrificing code quality and collaboration. This focus on personal performance can create a culture where teamwork and knowledge sharing are undervalued, ultimately hindering project success.
JIRA dashboard layout often rely on predefined metrics and reports, which may not align with the unique needs of every project or team. This inflexibility can result in a lack of relevant insights that are critical for effective project management. For example, a team working on a highly innovative project may require different metrics than a team maintaining legacy software. The inability to customize reports can lead to frustration and a sense of disconnect from the data being presented.
Integrating Git data with JIRA provides a more holistic view of project performance and developer productivity. Here’s how this integration can enhance insights:
By connecting Git repositories with JIRA, engineering managers can gain real-time visibility into commits, branches, and pull requests associated with JIRA issues & issue statistics. This integration allows teams to see the actual development work being done, providing context to the status of tasks on the JIRA dashboard gadet. For instance, if a developer submits a pull request that relates to a specific JIRA ticket, the project manager instantly knows that work is ongoing, fostering transparency. Additionally, automated notifications for changes in the codebase linked to JIRA issues keep everyone updated without having to dig through multiple tools. This integrated approach ensures that management has a clear understanding of actual progress rather than relying on static task statuses.
Integrating Git data with JIRA facilitates better collaboration among team members. Developers can reference JIRA issues in their commit messages, making it easier for the team to track changes related to specific tasks. This transparency fosters a culture of collaboration, as everyone can see how their work contributes to the overall project goals. Moreover, by having a clear link between code changes and JIRA issues, team members can engage in more meaningful discussions during stand-ups and retrospectives. This enhanced communication can lead to improved problem-solving and a stronger sense of shared ownership over the project.
With integrated Git and JIRA data, engineering managers can identify potential risks more effectively. By monitoring commit activity and pull requests alongside JIRA issue statuses, managers can spot trends and anomalies that may indicate project delays or technical challenges. For example, if there is a sudden decrease in commit activity for a specific task, it may signal that the team is facing challenges or blockers. This proactive approach allows teams to address issues before they escalate, ultimately improving project outcomes and reducing the likelihood of last-minute crises.
The combination of JIRA and Git data enables more comprehensive reporting and analytics. Engineering managers can analyze not only task completion rates but also the underlying development activity that drives those metrics. This deeper understanding can inform better decision-making and strategic planning for future projects. For instance, by analyzing commit patterns and pull request activity, managers can identify trends in team performance and areas for improvement. This data-driven approach allows for more informed resource allocation and project planning, ultimately leading to more successful outcomes.
To maximize the benefits of integrating Git data with JIRA, engineering managers should consider the following best practices:
Choose integration tools that fit your team's specific needs. Tools like Typo can facilitate the connection between Git and JIRA smoothly. Additionally, JIRA integrates directly with several source control systems, allowing for automatic updates and real-time visibility.
Encourage your team to adopt consistent commit message guidelines. Including JIRA issue keys in commit messages will create a direct link between the code change and the JIRA issue. This practice not only enhances traceability but also aids in generating meaningful reports and insights. For example, a commit message like 'JIRA-123: Fixed the login issue' can help managers quickly identify relevant commits related to specific tasks.
Leverage automation features available in both JIRA and Git platforms to streamline the integration process. For instance, set up automated triggers that update JIRA issues based on events in Git, such as moving a JIRA issue to 'In Review' once a pull request is submitted in Git. This reduces manual updates and alleviates the administrative burden on the team.
Providing adequate training to your team ensures everyone understands the integration process and how to effectively use both tools together. Conduct workshops or create user guides that outline the key benefits of integrating Git and JIRA, along with tips on how to leverage their combined functionalities for improved workflows.
Implement regular check-ins to assess the effectiveness of the integration. Gather feedback from team members on how well the integration is functioning and identify any pain points. This ongoing feedback loop allows you to make incremental improvements, ensuring the integration continues to meet the needs of the team.
Create comprehensive dashboards that visually represent combined metrics from both Git and JIRA. Tools like JIRA dashboards, Confluence, or custom-built data visualization platforms can provide a clearer picture of project health. Metrics can include the number of active pull requests, average time in code review, or commit activity relevant to JIRA task completion.
With the changes being reflected in JIRA, create a culture around regular code reviews linked to specific JIRA tasks. This practice encourages collaboration among team members, ensures code quality, and keeps everyone aligned with project objectives. Regular code reviews also lead to knowledge sharing, which strengthens the team's overall skill set.
To illustrate the benefits of integrating Git data with JIRA, let’s consider a hypothetical case study of a software development team at a company called Trackso.
Trackso was developing a new SaaS platform that consisted of a diverse team of developers, designers, and project managers. The team relied heavily on JIRA for tracking project statuses, but they found their productivity hampered by several issues:
In 2022, Trackso's engineering manager decided to integrate Git data with JIRA. They chose GitHub for version control, given its robust collaborative features. The team set up automatic links between their JIRA tickets and corresponding GitHub pull requests and standardized their commit messages to include JIRA issue keys.
After implementing the integration, Trackso experienced significant improvements within three months:
Despite these successes, Trackso faced challenges during the integration process:
To further illustrate the benefits of integrating Git data with JIRA, let's examine a real-world case study involving Eazer, a company that successfully utilized GitHub and JIRA integration to enhance collaboration and project management.
Eazer supports different projects hosted on GitHub while managing their feature development and bug fixes through JIRA. The internal project teams required a seamless way to synchronize issues raised in GitHub with their JIRA project. They needed visibility into both internal and external issues to plan their work effectively and they were looking for new dashboard that reduced their dependence on multiple dashboards.
The team implemented Typo, which enables seamless integration between JIRA project dashboard and GitHub. This allowed issues raised in GitHub to be automatically synced with JIRA, ensuring that internal developers could plan their work based on external user feedback.
The integration led to several positive outcomes:
While JIRA dashboards are valuable tools for project management, they are insufficient on their own for engineering managers seeking to improve project delivery speed and predictability. By integrating Git data with JIRA, teams can gain richer insights into development activity, enhance collaboration, and manage risks more effectively. This holistic approach empowers engineering leaders to make informed decisions and drive continuous improvement in their software development processes. Embracing this integration will ultimately lead to better project outcomes and a more productive engineering culture. As the software development landscape continues to evolve, leveraging the power of both JIRA and Git data will be essential for teams looking to stay competitive and deliver high-quality products efficiently.
Developer productivity is the new buzzword across the industry. Suddenly, measuring developer productivity has started going mainstream after the remote work culture, and companies like McKinsey are publishing articles titled - ”Yes, you can measure software developer productivity” causing a stir in the software development community, So we thought we should share our take on- Developer Productivity.
We will be covering the following Whats, Whys & Hows about Developer Productivity in this piece-
Developer productivity refers to the effectiveness and efficiency with which software developers create high-quality software that meets business goals. It encompasses various dimensions, including code quality, development speed, team collaboration, and adherence to best practices. For engineering managers and leaders, understanding developer productivity is essential for driving continuous improvement and achieving successful project outcomes.
Quality of Output: Developer productivity is not just about the quantity of code or code changes produced; it also involves the quality of that code. High-quality code is maintainable, readable, and free of significant bugs, which ultimately contributes to the overall success of a project.
Development Speed: This aspect measures how quickly developers (usually referred as developer velocity) can deliver features, fixes, and updates. While developer velocity is important, it should not come at the expense of code quality. Effective engineering teams strike a balance between delivering quickly and maintaining high standards.
Collaboration and Team Dynamics: Successful software development relies heavily on effective teamwork. Collaboration tools and practices that foster communication and knowledge sharing can significantly enhance developer productivity. Engineering managers should prioritize creating a collaborative environment that encourages teamwork.
Adherence to Best Practices for Outcomes: Following coding standards, conducting code review, and implementing testing protocols are essential for maintaining development productivity. These practices ensure that developers produce high-quality work consistently, which can lead to improved project outcomes.
We all know that no love to be measured but the CEOs & CFOs have an undying love for measuring the ROI of their teams, which we can't ignore. The more the development productivity, the more the RoI. However, measuring developer productivity is essential for engineering managers and leaders too who want to optimize their teams' performance- We can't improve something that we don't measure.
Understanding how effectively developers work can lead to improved project outcomes, better resource allocation, and enhanced team morale. In this section, we will explore the key reasons why measuring developer productivity is crucial for engineering management.
Measuring developer productivity allows engineering managers to identify strengths and weaknesses within their teams. By analyzing developer productivity metrics, leaders can pinpoint areas where new developer excel and where they may need additional support or resources. This insight enables managers to tailor training programs, allocate tasks more effectively, and foster a culture of continuous improvement.
Developer productivity is directly linked to business success. By measuring development team productivity, managers can assess how effectively their teams deliver features, fix bugs, and contribute to overall project goals. Understanding productivity levels helps align development efforts with business objectives, ensuring that the team is focused on delivering value that meets customer needs.
Effective measurement of developer productivity enables better resource allocation. By understanding how much time and effort are required for various tasks, managers can make informed decisions about staffing, project timelines, and budget allocation. This ensures that resources are utilized efficiently, minimizing waste and maximizing output.
Measuring developer productivity can also contribute to a positive work environment. By recognizing high-performing teams and individuals, managers can boost morale and motivation. Additionally, understanding productivity trends can help identify burnout or dissatisfaction, allowing leaders to address issues proactively and create a healthier workplace culture.
In today’s fast-paced software development landscape, data-driven decision-making is essential. Measuring developer productivity provides concrete data that can inform strategic decisions. Whether it's choosing new tools, adopting agile methodologies, or implementing process changes, having reliable developer productivity metrics allows managers to make informed choices that enhance team performance.
Regularly measuring productivity can highlight the importance of collaboration and communication within teams. By assessing metrics related to teamwork, such as code reviews and pair programming sessions, managers can encourage practices that foster collaboration. This not only improves productivity but overall developer experience by strengthening team dynamics and knowledge sharing.
Ultimately, understanding developer experience and measuring developer productivity leads to better outcomes for both the team and the organization as a whole.
Measuring developer productivity is essential for engineering managers and leaders who want to optimize their teams' performance. It involves assessing both team and individual contributions to understand how effectively developers are delivering value through their development processes. Here’s how to approach measuring productivity at both levels:
Measuring productivity at the team level provides a more comprehensive view of how collaborative efforts contribute to project success. Here are some effective metrics:
The DevOps Research and Assessment (DORA) metrics are widely recognized for evaluating team performance. Key metrics include:
This metric measures the time taken from the start of work on a task to its completion, providing insights into the efficiency of the software development process.
Surveys and feedback mechanisms can gauge team morale and satisfaction, which are critical for long-term productivity.
Assessing the frequency and quality of code reviews, pair programming sessions, and communication can provide insights into how well the software engineering team collaborates.
While team-level metrics are crucial, individual developer ****productivity also matters, particularly for performance evaluations and personal development. Here are some metrics to consider:
Measuring developer productivity metrics presents unique challenges compared to more straightforward metrics used in sales or hiring. Here are some reasons why:
By employing a balanced approach that considers both quantitative and qualitative factors, with a few developer productivity tools, engineering leaders can gain valuable insights into their teams' productivity and foster an environment of continuous improvement & better developer experience.
Measuring developer productivity is a critical task for engineering managers and leaders, yet it comes with its own set of challenges and potential pitfalls. Understanding these challenges is essential to avoid the dangers of misinterpretation and to ensure that developer productivity metrics genuinely reflect the contributions of developers. In this section, we will explore the challenges of measuring developer productivity and highlight what not to measure.
Measuring developer productivity is fraught with challenges and dangers that engineering managers must navigate carefully. By understanding these complexities and avoiding outdated or superficial metrics, leaders can foster a more accurate and supportive environment for their development team productivity.
Developer productivity is a critical factor in the success of software development projects. As an engineering manager or leader, measuring and optimizing developer productivity is essential for driving development team productivity and delivering successful outcomes. However, measuring development productivity can have a significant impact on engineering culture & software engineering talent, which must be carefully navigated. In this article, we'll explore strategies for measuring developer productivity while maintaining a healthy and productive engineering culture.
Measuring developer productivity presents unique challenges compared to other fields. The complexity of software development, inadequate traditional metrics, team dynamics, and lack of context can all lead to misguided incentives and decreased morale. It's crucial for engineering managers to understand these challenges to avoid the pitfalls of misinterpretation and ensure that developer productivity metrics genuinely reflect the contributions of developers.
Remember, the goal is not to maximize metrics but to create an development environment where software engineers can thrive and deliver maximum value to the organization.
Development teams using Typo experience a 30% improvement in Developer Productivity. Want to Try Typo?
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 today's competitive tech landscape, engineering teams need robust and actionable metrics to measure and improve their performance. The DORA (DevOps Research and Assessment) metrics have emerged as a standard for assessing software delivery performance. In this blog, we'll explore what DORA metrics are, why they're important, and how to master their implementation to drive business success.
DORA metrics, developed by the DORA team, are key performance indicators that measure the performance of DevOps and engineering teams. They are the standard framework to track the effectiveness and efficiency of software development and delivery processes. Optimizing DORA Metrics helps achieve optimal speed, quality, and stability and provides a data-driven approach to evaluating the operational practices' impact on software delivery performance.
The four key DORA metrics are:
In 2021, the DORA Team added Reliability as a fifth metric. It is based upon how well the user’s expectations are met, such as availability and performance, and measures modern operational practices.
These metrics offer a comprehensive view of the software delivery process, highlighting areas for improvement and enabling software teams to enhance their delivery speed, reliability, and overall quality, leading to better business outcomes.
DORA metrics provide an objective way to measure the performance of software delivery processes. By focusing on these key indicators, dev teams gain a clear and quantifiable understanding of their tech practices.
DORA metrics enable organizations to benchmark their performance against industry standards. The DORA State of DevOps reports provide insights into what high-performing teams look like, offering a target for other organizations to aim for. By comparing your metrics against these benchmarks, you can set realistic goals and understand where your team stands to others in the industry.
DORA metrics promote better collaboration and communication within and across teams. By providing a common language and set of goals, these metrics align development, operations, and business teams around shared objectives. This alignment helps in breaking down silos and fostering a culture of collaboration and transparency.
The ultimate goal of tracking DORA metrics is to improve business outcomes. High-performing teams, as measured by DORA metrics, are correlated with faster delivery times, higher quality software, and improved stability. These improvements lead to greater customer satisfaction, increased market competitiveness, and higher revenue growth.
Analyzing DORA metrics helps DevOps teams identify performance trends and pinpoint bottlenecks in their software delivery lifecycle (SDLC). This allows them to address issues proactively, and improve developer experiences and overall workflow efficiency.
Integrating DORA metrics into value stream management practices enables organizations to optimize their software delivery processes. Analyzing DORA metrics allows teams to identify inefficiencies and bottlenecks in their value streams and inform teams where to focus their improvement efforts in the context of VSM.
Firstly, engineering leaders must identify what they want to achieve by tracking DORA metrics. Objectives might include increasing deployment frequency, reducing lead time, decreasing change failure rates, or minimizing MTTR.
Ensure your tools are properly configured to collect the necessary data for each metric:
Use dashboards and reports to visualize the metrics. There are many DORA metrics trackers available in the market. Do research and select a tool that can help you create clear and actionable visualizations.
Establish benchmarks based on industry standards or your historical data. Set realistic targets for improvement and use these as a guide for your DevOps practices.
Use the insights gained from your DORA metrics to identify bottlenecks and areas for improvement. Ensure to implement changes and continuously monitor their impact on your metrics. This iterative approach helps in gradually enhancing your DevOps performance.
Train software development teams on DORA metrics and promote a culture that values data-driven decision-making and learning from metrics. Also, encourage teams to discuss DORA metrics in retrospectives and planning meetings.
Regularly review metrics and adjust your practices as needed. The objectives and targets must evolve with the organization’s growth and changes in the industry. Typo is an intelligent engineering management platform for gaining visibility, removing blockers, and maximizing developer effectiveness. Its user-friendly interface and cutting-edge capabilities set it apart in the competitive landscape.
Understanding DORA metrics and effectively implementing and analyzing them can significantly enhance your software delivery performance and overall DevOps practices. These key metrics are vital for benchmarking against industry standards, enhancing collaboration and communication, and improving business outcomes.
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 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.
Sign up now and you’ll be up and running on Typo in just minutes
