Ani Mishra: Effective Cross-functional Collaboration

Speaker A: Welcome to the Effective Engineering Manager podcast. Today we have a great guest, Ani Mishra. Ani is an engineering manager at Doordash. Ani joined Doordash during its early stages in San Francisco. He currently heads the new verticals, logistics engineering at Doordash. Ani, welcome. So what would you like to talk about today?

Speaker B: Thank you so much, Slava, for having me on the show. Thank you. Today I would like to talk about effective cross functional collaboration.

Speaker A: So why is effective, uh, cross functional collaboration so important?

Speaker B: Yeah, so this is a topic that is like really close to my heart. And why I think it is so important for EMS to effectively collaborate with cross functional partners is because at the very core, em's job is to ship products. And to ship products to millions of people. It requires skills beyond software development and beyond coding. That is why it's very important for EMS to hone this skill set.

Speaker A: Nice. Makes sense. All right, so let's dive in.

Speaker B: Yeah. So as I mentioned, Saba, that as an em, your job is to deliver high quality software to millions of customers. And doing this requires a lot more than writing code and building great software. And I'll give you some examples on how and why. First, for any business that is actually going to be building products and software, there has to be a business problem that can be solved by building a product. And there are people in companies like business strategists and product strategists that specialize in understanding the business model and understanding where a product can come in and solve a business problem. Right. There is also like a lot of knowledge that is needed on, um, what do customers actually need and what should a product look and feel like for the customers? And there are specialists like product managers and UX designers who are really good at this. Similarly, let's say you build a product and our feature for your customers. How do you know that it is actually solving a problem for them? How do you know that they are engaging with the feature? They're able to do what they want by using the feature that your team has built. That is where data scientists come into the picture. They can give you insights about the product, uh, that your team is building. So as an engineering manager, I think it's really important for you to understand that all of these skills that are available to you are equally important as the skill set that is available in your engineering team. It's uh, like a very similar kind of situation where you're tapping these different functions with the specializations to help you ship a product that is actually useful for your customers. And I'm m not saying that you cannot train engineers to do all of these jobs, you definitely can. But when you have these experts available in different disciplines, as an engineering manager you should leverage their skill set and help and take the available help to ship the products that a lot of customers will love. What do you think, Slava?

Speaker A: Yeah, I think you're absolutely right and you uh, nailed it on the head. Because modern software development and modern systems are complex. Knowing uh, what needs to be built, how it needs to be built requires really broad skill set which is most likely a single team of software developers. You know, five, six people won't have. We really need to have this cross functional, fully aligned team to work on solving and delivering um, um, on customer needs. I do remember like let's say 25 years ago we had extreme programming where the idea was that we can put three, five people, maybe three to six people, software developers connect to a customer and build something. But that time has gone and now we have such a complex systems which do require a lot of collaboration. So tell me more, what does it take to collaborate, cross function and what does it take to deliver when you have so many tight important dependencies?

Speaker B: Yes. So like what, what I've seen is that while it is very important for EMS to be effective at being able to leverage the skill set from a product manager or from a designer, from an analyst, what happens in reality is there's a lot of friction that EMS face when they collaborate with these functions. And I think a lot of it comes from lack of understanding what is, what are the common grounds that you have as an EM with your partners as well as what are the differences that you have with your partners and ems, um, should try to understand what are these common grounds with the partners, for example ems as well as anybody any other functions that are working with them, all of them have the same goal that the customer and the business should win. And usually like at a lot of companies there is a model that there is a team made up of engineering manager as well as a product manager, a designer, a data scientist that work towards a shared goal. Obviously engineering manager also brings developers to the table, uh, and the shared goal is often easily quantified as well. It could be like reduce 5% of defects rate uh, for a logistics system or it could be like improve the conversion rate uh, for the checkout, something like that. So usually you as an EM have this common goal with all the XFM partners which is a very easy way for you to bond with them and connect with them. One thing I will caution all the EMS is to also understand what are the other goals that your partners have because those often lead to friction and conflicts. Uh, in many situations identify what are the common, uh, goals between you and your partners as well as what are the differences between you and your partners. And I've also noticed that a lot of friction or differences come from how all of these functions want to achieve those shared goals. So even though you have shared goals with your partners, your partners might want to achieve them through different ways. For example, your product manager might want to build a new amazing feature and new amazing user interface to delight all the customers and hopefully help customers check out and convert more easily. Your analyst might see friction for a small cohort of customers and they might propose you to do a more data driven approach and improve the existing product. Your business folks might be thinking about different business, uh, model. They might be thinking about pricing the product differently. So all of these functions come up with different ways to achieve the same goals that you have shared with them. As an em, you might have a different idea of how to achieve these goals. You might want to build another service or in the microservice to improve the reliability of the systems and thus achieve these goals. So it is very common for all these functions to have a different approach to achieving these goals. And I think as an em, it's very important for you to understand what is common and what is different between you and your closest partners because this information will help you always to navigate when a conflict happens. Uh, you'll be able to more strategically, uh, decide what to push forward versus what is something that you should probably hold back on. So as an em, make sure that you have a good understanding of what are the goals for you and your cross functional partners. Where do they overlap as well as where are the differences, what are the things where things do not overlap between you and your partners. What do you think, Slava?

Speaker A: Yeah, good stuff. And uh, I think I have this sort of a visual uh, image of what you are describing where the engineering team with an engineering manager responsible for the work, sort of sits in the center of this, sits in the center. And um, the partnering functions, using it as a confluence and feeding into it. Right. Whereas product management defines what the customers are going to like, data science helps to understand how to make it work on a large scale. And using, uh, quantifiable methods, operations are bringing operational excellence. I mean, okay, well we'll assume that they have operations here because some teams run what they build. So essentially it's Just a central role. And indeed it is important to, uh, align on what are we building and how are we building it, but also being able to understand, um, what other things which our partners are bringing to the table and how we can fulfill them to a degree. Because in the end of the day we have to ship a working product that customers love, right? And then what else can we do to make it happen? And I think it's critical to a know or what are the extra things on top of building the core product? And like you are saying, uh, conflicting goals. I don't think these are conflicts. Uh, the goals are conflicting, but these are not like real conflicts because it just. Everyone wants to build, to bring more and a lot. And these are the engineering managers who are going to be implementing that, the main part, and then the more of it. And I think it's knowing, um, knowing and documenting and making it explicit is super important. And um, so. And I do, I do feel that this central role is important and maybe you could dive a bit deeper. What does it mean to be in the center of all of it?

Speaker B: Yeah, I agree, Slav, a great point. And now I visualize this as an orchestra. I see this as a mental model. It's like it's a product management, uh, it's a product engineering orchestra where you as a EM are the conductor and you have your engineers, you have your excellent partners playing together in unison to achieve a goal, solve a customer problem, solve a business problem. And I think EM should really see their role as somebody that empowers not just their engineering team, not just the people that report to them, but also your XF1 partners. And why it is important for EMS to do that is because EMS are relying on these partners to provide their skill set, just like ems rely on their engineers to provide their skill set. So EM should really see their role as a force multiplier, as somebody that has empowering effect on not just their team, but also on their XM partners. And I think it all pretty much boils down to understanding the needs of your partner. It's like any other relationship in life. Like, you gotta understand what are the needs of your partner to have a healthy partnership. And some of the needs are very well understood. And I think a lot of EMs do a great job at managing those. For example, EMs are expected to have predictability of the outcomes, uh, to provide predictability of the outcomes and to have consistency of deliverables. Your XFM partners and everybody's looking at you to be able to ship the product on the Timeline that the business needs it. So it's a no brainer. And all the ems, um, spend all of their energy in trying to make that happen. It's a no brainer that high productivity is an expectation for ems. Uh, ems have to make sure that all their engineers are deeply engaged using their skill set, uh, in the right way. And the productivity is high, like the team is building feature, the team is shipping. Right. So these are very well understood and I think ems do a good job and spend a lot of energy in trying to meet these expectations. But there's a lot of other things which are less obvious and which I think EMS can benefit from focusing more, more on. And that will truly make them a uh, force multiplier for their X7 partners. And how I like to think about this is that EM should think about what are the unique engineering insights that only they can bring to the table and focus on how to bring those to the XM partners. And some of the examples I like to give for that is like em should think about like how can they launch 10x the number of experiments or the features that are, that are launched by the team, like are the barriers number of people in the team or are the barriers that tools available for experimentation. So the EM should bring a point of view on like how to 10x the number of features or experiments that the team can run. And that is an insight that only EM or somebody deeply technical can bring. Right? Similarly, I feel EMS can bring a lot of value by just keeping their XFN partners informed on what are the low hanging fruits, what are some of the things that can be done on the product that can be done with very little investment so that your X1 partners know what are some of the things that can be easily changed and transformed for the customers. And on the flip side, EM should also keep their partners informed on what are some of the things that look trivial are actually really high effort or really hard to do. And I think with that ems create a mental model for their excellent partners, uh, so that they know what is low effort work, what is high effort work, uh, and by doing that they proactively prepare their partners to represent engineering in looms. EMs are not present and they kind of also prevent their partners to not promise things which are huge efforts, uh, to deliver in like within a quarter. Similarly, another thing that I think EM should really think about is how to remove engineering as a bottleneck from building a feature or from achieving a goal. Because engineering is usually the long pole in everything. Because engineering is the team that is actually building this stuff. And it takes a long time to build a reliable product. It takes a long time, it takes a lot of effort to build it. So EM should actively think about how can they prevent their team to be the bottleneck in the entire process. So some ways to think about this is like what are the internal tools that the engineering managers can build so that the operational load on the engineering team is reduced? Uh, similarly, what are some of the process improvements that EMS can make that will help their team to not be in every change that your product partners want to make. So EM, uh, should actually think about how to remove the engineering team as a bottleneck from various processes and various feature development cycles. In addition, I think EM, since like EM and product manager kind of like partner on building a roadmap for the team, EM should own the responsibility of having a balanced roadmap. So the roadmap should not only have new features or uh, new products that the team is building, but also a good balance of internal tools that the team is building to improve the operational excellence for the team as well as the investments in reducing the tech debt for the team. So EM should really make sure that all voices are represented in the roadmap. It is not really skewed towards just building new products or it's not skewed towards just removing tech debt and make sure that there is a balance in the roadmap. What do you think, Slava?

Speaker A: Yeah, good stuff. And I really like this image of an orchestra, uh, because I think it describes it well how we build working high quality systems for our customers and our users. And in fact there's even a strategic thinking tool which is called Sheet of Music, believe uh, it or not. And so I like what you're saying in terms of, I think I see there are two components here. One is understanding. You said um, that engineering team needs to understand their cross functional partners and the engineering managers must understand their cross functional partners. And I'm also liking that. Uh, what you are saying is that there's also a, this is a two way road where engineering also brings something to communicate and share back to the cross functional partners. Right. The improving the engineering processes, communicating low hanging fruits which a product team might not be seeing, communicating back things which are looking to you from the product side but maybe quite heavy on the engineering side that need to be discussed. I really like this, um, sort of like a bidirectional communication style orchestra. Ah, where not only engineering teams and engineering managers are uh, talked into but also it's a shared Joint effort between cross functional partners with the engineering managers being in the center of it. Not necessarily the most important part because everyone brings, I think the whole system is important because imagine that you remove all the data science, all the product managers, all the operations and what are we going to have, what are we going to do with our code? So especially in large scale systems, maybe if it's uh, a product with a few users, maybe it doesn't matter. But systems that make money and serve customers, this is super important. So, and this sort of brings us to the next question. It's great when everyone is communicating, collaborating and uh, understanding, but it's not always going this way. And sometimes things do not go well or don't well as planned. How do we handle, how do we as engineering managers handle day to day work which is not always perfect?

Speaker B: That's a great topic. So I mean the EM and PM friction is like well known, well understood and there are some things that ems can do to uh, be really good at navigating this friction and produce outcomes that are good for everybody, even in situations which are difficult. Previously I just mentioned that it's very important for EMS to proactively communicate a lot of things to their partners. I think the key word there was proactive. A lot of ems are reactive to that. Like a PM will come up with, hey, can you build this feature? And EM reacts. Oh, this is a lot of work. So that is why it's very important for AAM M to be proactive in doing a lot of the communication about what are the low hanging fruits, what are the areas that are hard to move. But regardless of that, conflicts happen. And EM, um, should have a framework to navigate these conflicts and my approach to a lot of these conflicts. And I'll share what my framework is and then uh, we can discuss some situations of where we can apply this framework is to whenever there is a conflict on what should we build or what should we prioritize. My suggestion is to always do what is good for the customers. And as an em, um, you should know what is good for the customers. If not, it's never too late to learn it, but you should know what is good for the customers, what your customers want. The second priority is what's good for the business. And the obvious question is that what is good for the customer should be good for the business also. So they're usually not in conflict with each other. But sometimes there are decisions where what is good for the business might not be good for the customer directly because let's say Price of software increased. It is necessary for the business to sustain, to serve the customers. But it's not directly the customers will not love it. So but it is the second priority. The first priority is like think what is good for the customer, then what is good for the business. Third priority is what is good for your team and your excellent partner. So don't make decisions that just help your team, but not the excellent partners. They are equal. And then finally the fourth one is yourself, like what is good for you as an individual, what is good for your career growth? So I like to use this for these four pillars in the prioritization. You know, customer comes first, then the business, then your team and the XFN partners and then you yourself. And the common problems that arise, common conflicts that happen is sometimes the requirements change, um, you know, your team and you will be executing and the requirements change. And ems usually are in a tough spot when that happens. Because ems do not want to move the date of the project, they want to keep the date and they want to deliver what was promised. But the requirements has changed. How I suggest EMS to navigate this is like make a first principles argument on like is this good for the customer? Should we change the requirement? Changing the requirement might push the date delivery date by a month, for example, like is that a good decision for the customer or should we rather optimize for speed and go as is and not change the requirement? So as an em, um, you can apply this framework and have some talking points that you can use with your X7 partners to make a decision here. I also think that at the end of the day, EMS and TLS and the engineering team should really embrace when the requirements change because it usually happens when we have learned something new about the customer or the business. So EM should see this as something as uh, learning and should react to that and should welcome things like that. Now there might be situations where there are other tools that EMS might have to use which we should definitely discuss also. But I think in general engineering teams and engineers should embrace when we learn something new about the customer and we are able to change the product and ship the right product for the customer as a result of that. Another common conflict that happens is unchanging priorities. Uh, EM might want to prioritize reducing the tech debt, while PM might want to uh, prioritize trying out a new exciting feature. There can be uh, conflict with each other. And here also I think em, um can apply the same framework is like what is the right thing to do for the customer? Uh, one practical Problem that EMS um, face is like how to convey tech debt or removal of tech debt as something that is good for the business and the customer. And I think if EM M can nail that down, it takes some effort but it's definitely possible. Then you can have a conversation about what is good for the customer and what is good for the business and you can have a principled argument or principal discussion with your X7 partners on what should we prioritize. So I think while conflicts happen, I think EMS can use this way of prioritizing and this way of making an argument to navigate these more smoothly. Slava, what are your thoughts?

Speaker A: I mean we cannot go wrong with uh, putting uh, customer first because everything else flows from it and changes the norm. I think when I was a young engineer, engineering manager, I took it personally and seriously and uh, tried to defend not uh, changing anything. But the reality is that doing what customer wants means that learning and uh, doing what they want. And this means change. So yeah, I absolutely agree with you. Change needs to be embraced. And uh, this is something that all engineering managers must learn and accept and also agree that communication is still needed. It cannot be one way street from product to engineering because uh, we're in this together and we should be able to communicate to the product team and product managers, if it's a separate team, what it takes to build uh, what they want. And it's not only the new features, it's also the infrastructure, technical data which is always there. So 100% and that's good stuff. So let's talk about situations when we did our best. Uh, we collaborated, we communicated, we had a dialogue and still things are not going 100% and things getting escalated. How do we handle this as engineering uh, managers?

Speaker B: I love the point that you made about not taking it personally. I think it is really critical for EMS to not get emotional in making these decisions. I think EM M should be objectively making decisions based on what is more important. And I think you had a really great point on like don't take anything personally if the requirements change, the priorities change and you know, rather solve that objectively. And as you mentioned, like there's always going to be situations where you cannot reach an agreement no matter how many frameworks you apply. There are various things that could lead to you not reaching an agreement with your cross functional partners. And I think in that case your biggest tool is escalation. And escalation is something that is really underused by ems. I think ems, um, kind of frown from escalating things because that could be perceived as lack of ownership or lack of being able to get things done. But I think isolation can be a real powerful tool for EMS M if you use the right way. My suggestion is if you have a conflict based on product, uh, priorities or requirements, if you cannot reach a decision, uh, as an EM with your pm, do a joint escalation. Instead of just escalating directly to your manager or your PM's manager. You and your PM should agree on something and you should present the trade offs transparently to your leadership. And it is very important for you to actually either disagree and commit or your PM partner to disagree and commit. One of you have to do it, uh, but it's very important for you to present a united perspective because that shows that you can navigate differences with your partner. But I think how you present this to your leadership is that, uh, you share the trade offs. Like as a result of, for example, as a result of we are going to build this feature instead of improving this tech debt. And as a result of that, we are going to have lesser reliability for this XYZ service that will reduce the checkout rate for 1% of customers that are located in this part of the world. So by articulating these, I think you really help the decision makers understand, like how you made a decision and what trade offs you considered. And as an em, um, you should really choose the battles wisely because there's going to be a lot of conflicts. And as a EM M, you can only manage a limited number of conflicts. So pick your battles wisely and then be open to like, disagreeing and committing where you cannot make a decision. And I guarantee you your partner will also reciprocate. And sometimes they will disagree and commit, sometimes you will disagree and commit. But, uh, it's very important for you to present a united perspective to your leadership. However, there might be situations where there are personal issues, like there are just bad behaviors or things that you cannot work around for issues like that. My suggestion is that is where you escalate to your manager directly and that is where you don't do the United States, uh, perspective because it is impossible to reach a united perspective in that case. And that is where you actually escalate to your manager and ask them to like, take action or you are the PM's manager or whoever is your excellent partner, whoever their manager is, if you run into something where it's, uh, more of a personal issue and you're not able to make any progress there. Slav, what are your thoughts?

Speaker A: Yeah, good stuff. I agree 100% that, that it is important to treat disagreements or even conflicts professionally. It means that if there's a disagreement, uh, this means that most of the times it's misunderstanding or misalignment of priorities. There are a lot of things but uh, uh these things are not happening because someone doesn't like you. So and I really like what you said about having a united perspective and I think having regular stable standing one on ones with your partners, especially the ones that you continue to work directly like with product teams, ops and um, data teams. It is super important to have stable one on ones I would say once a week because that is the platform where we can have a safe environment to present challenges where our world challenges whatever is not 100% agreed. And I really like that your idea of. I don't think it's really an idea. I think it's just a solid advice to form an agreement or form understanding of what we agreed upon or what we agree with on this united perspective and then tease out uh, things which we are not agreeing and then agreeing that hey, this is what you think. This is what I think. This is the gigantic body of things that you and I agree upon. How about we take and because we talked about it, nothing is happening. How about we take it together to the folks upstairs and let them decide. And I think it's really important to, for both, for engineering managers, for product managers and for other teams to know that it's not always go their way. Sometimes the folks who are going to be breaking the tie won't agree on doing things the way you want them to be done. So this sort of agree uh, um, disagree and commit is very important. So that's really good stuff and a very solid guidance on uh, cross functional collaboration. I really have a very good question for you. So we within last two years we moved from living uh, in the one world to now living in a new world. And this world is becoming newer and newer by every hour and every day. We live in the world of AI now from your point of view, what is changing and how is it changing? How's the um, effective cross functional collaboration changing in the AI world?

Speaker B: That's an excellent question, very timely as well because the world around us is changing and um, it is inevitable that we will live in a different world anytime from one year to five years because uh, the pace of how AI is changing everyday life is so fast. And I think my point of view is that in future your non engineers so your cross trainer partners will be able to actually do A lot of things that engineers are doing today, they'll be able to try a lot of variations of the product themselves without involving engineers or em. And I think as a result of that EMS will transition to building more of the product platforms than actually building the products directly. And as a result of that your X7 partners will become your direct customers. And that is why I think EM should think about really multiplying, be a force multiplier for your cross functional partners because they are your customers for tomorrow. And I think it's inevitable that EMS as well as engineering teams will focus more on building product platforms that can be easily extended and iterated upon by your non engineering friends, by your product managers, by your project manager, data engineers and whatnot. And EM should really focus on like how to like treat your XFN partners as your customers from today to actually adjust for the word that is coming up very soon. What are your thoughts Slava?

Speaker A: I think this is good stuff because and it's really a fresh take because we've heard a lot of uh, engineers are going to disappear and also people who cannot code are going to wipe code into the production. I don't see it happening next minimum I'll say five to ten years. Uh, maybe we'll get to the point where you just describe what you want as it just automatically materializes in production. Being able to handle millions of users possible. But who's going to be building this? And this is why I really agree with you that I can really see engineers and engineering team led by engineering managers becoming a provider of tools that take this uh, works on my computer wipe coded product. Most likely an excellent product because product team will be able to describe and have a detailed conversation with the code and see this code evolve and morph into doing something useful. And then engineering teams would bridge this gap between wipe coded product and production by bringing those tools very close to the product uh, visionaries. Mhm. And then it's going to be just like these days we as engineering teams uh use LLM tools or now we're using MCP model context protocol. I think those platforms are going to be that MCP for the product teams. I can totally agree with this. I like it. So anyway Ani, that was a great discussion and uh, could you please share checklist with our listeners that they can start using tomorrow to collaborate cross functionally effectively.

Speaker B: Yeah, of course Lava. So uh, some of the uh suggestions I have for EMS that they can readily implement and be more successful collaborating with their X7 partners. One is really obvious. Have a regular one on one with your PM, your data scientist, your analyst, your business folks, whoever you work with regularly make sure you have a regular check in with them so that you are building alignment proactively and you can smell the conflicts coming up. Because it's always easier if you know about something that is coming up than being reacting to something when it comes up. Right. Secondly, I suggest all the ems to have a prioritized list of everything that they're working on, which means all the new features, all the internal tools, all the tech debt, to have one list of prioritized initiatives. This also goes in the same direction of being more proactive. And if you have this, your partners will know very transparently like what are you prioritizing? And if there's ever a decision to think about like should we change the priorities? I think people will really understand very clearly that you know what will have to drop if we were to prioritize project A over project B. And I think that could potentially reduce a lot of conflicts that happen. Number three, I think this is a tricky one, uh, which is for ems to actually start communicating tech debt differently. So I suggest all the ems to think about. How can you articulate the impact of reducing the tech debt in terms of how it changes life for your customers or how it changes life for your business? And you might think about hey, uh, if the tech debt improves developer velocity, it is not really helping your customers, but it is you can think about like how can you go to market faster with improved developer velocity so you can connect everything and anything that you work on with the customer. It's just about changing the mindset and thinking more a customer first. And also avoid the perception that you know engineering for the engineering sake. You'll be more seen as a more customer, uh, centric leader if you implement this. Number four, whatever the planning cycle in your company looks like, maybe it's quarterly, maybe it's half yearly, maybe it's annual. Make sure you do a plan review. After the planning is done, make sure you invite all your cross functional partners as well as all your engineers. This is more of a structured checkpoint and you and your team validates the priorities as well as folks have chance to uh, object to the priorities and be able to see what is coming up. And then last but not the least make sure you are actually Talking to your X1 partners in non formal settings also. So I suggest is to join the retracer off sites or organize them where you invite your cross functional partners, uh, as well as your engineering team and this gives you an opportunity to build trust and learn about things beyond just a roadmap. Learn more about your excellent partners, build more of a personal connection with folks, and build more trust. Because eventually trust is all that matters. And if you have trust and relationship with people, you can work with them more smoothly. So, yeah, those are the, uh, suggestions I have for the EMS Anja thank you.

Speaker A: This was good stuff to our listeners. Uh, if you like this episode, I, uh, encourage you to share it with other engineering managers. As always, the, uh, complete set of episodes of the Effective Engineering Manager Podcast can be found@www. Effectiveam.com and you are welcome to reach us with a feedback and suggestions@contactiveam.com.