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.
Implement DORA metrics, gain dev visibility & drive success in your teams.
Try Live Demo
