Effective Cross-functional Collaboration

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? Thank you so much Slava for having me on the show. Today I would like to talk about effective cross-functional collaboration. So why is effective cross-functional collaboration so important? Yeah, so this is a topic that is like really close to my heart and why I think it is so important for EM's 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 EM's to hone this skill set. Nice. Makes sense. All right, so let's dive in. Yeah, so as I mentioned, Slava, 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 gonna 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 a lot of knowledge that is needed on 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. And that is where a data scientist come into the picture. They can give you insights about the product 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 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 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? Yeah, I think you're absolutely right and you nailed it on the head because modern software development and modern systems are complex and knowing 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 selling and delivering 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, six, three to six people, software developers, network 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 how, what does it take to deliver when you have so many tight, important dependencies? Yes, Slava. So, like what I've seen is that while it is very important for EMs to be effective at, you know, being able to leverage the skill set from a product manager or from a designer or 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, you know, 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 works towards a shared goal. Obviously, the engineering manager also brings developers to the table. And the shared goal is often easily quantified as well. It could be like reduce 5% of defects rate, you know, for a logistics system or it could be like improve the conversion rate for the checkout, something like that. So usually, like you as an EM have this common goal with all the acceptance partners, which is like 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 are often, those often lead to friction and conflicts in many situations. So, you know, identify what are the common 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, a lot of friction or differences come from how all of these functions want to achieve those shared goals. So even, 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, you know, help customers check out and convert more easily. Your analyst might, you know, see friction for a small cohort of customers and they might propose you to do a more data-driven approach and, you know, improve the existing product. Your business folks might, you know, be thinking about different business model. They might be thinking about pricing the product differently. So all of these functions come up with, you know, 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. 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. You will be able to more strategically decide like what to push for versus what is something that you should probably like 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 between 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? Yeah, good stuff. And I think I have this sort of a visual image of what you are describing where the engineering team with an engineering manager is responsible for the work sort of sits in the center of this sits in the center and the other of the the partnering functions using it as a conference and feeding into it, right? Whereas public management defines what the customers are gonna like. Data science helps to understand how to make it work on a large scale and using quantifiable methods. Operations are bringing operational excellence. I mean, okay, we'll assume that they have operations here because sometimes run what they build. So essentially it's just a central role and indeed it is important to align on what are we building and how we're building it. But also being able to understand 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 of what are the extra things on top of building the core product and like you are saying conflicting goals. I don't think that these are conflicts. The goals are conflicting, but these are not like a real conflict because it just everyone wants to bring more and a lot. And these are the engineering managers who are gonna be implementing that the main part and then the more of it. And I think it's knowing and documenting and making it explicit is super important. And I do feel that the 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? Yeah, a great point. I visualize this as an orchestra. I see this as a mental model. It's like it's a product engineering orchestra where you as EM are the conductor and you have your engineers, you have X7 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 X7 partners. And why it is important for EM's to do that is because EM's are relying on these partners to provide their skills that just like EM's rely on their engineers to provide their skillset. 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 X7 partners. And I think it all pretty much boils down to understanding the needs of a partner. It's like any other relationship in life. Like you've got to 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 EM's do a great job at managing those. For example, you know, EM's are expected to have predictability of the outcomes or to provide predictability of the outcomes and to have consistency of deliverables. Your X7 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 EM's spend all of their energy in trying to make that happen. And it's a no-brainer that high productivity is an expectation for EM's. You know, EM's have to make sure that all their engineers are like deeply engaged using their skillset in the right way. And the productivity is high. Like the team is building features, the team is shipping, right? So, you know, these are very well understood. And I think EM's do a good job and spend a lot of energy in, you know, trying to meet these expectations. But there's a lot of like other things which are less obvious, and which I think EM's can benefit from, you know, focusing more on and that will truly make them a 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 like how to like bring those to the X7 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 do 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 EM's 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 like what are some of the things that can be like easily changed and transformed for the for the customers. And on the flip side, EM should also like 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 EM's create a mental model for their XFN partners so that they know like what is what is low effort work what is high effort work. And by doing that they proactively like prepare their partner should represent engineering in Loom's EM's are not present. And they kind of also prevent their partners to like not promise things which are which are huge efforts 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 like you know achieving a goal. Because engineering is usually the long pole in everything because engineering is a team that is actually building this stuff. And it takes a long time to build you know 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. Similarly, what are some of the process improvements that EM's can make that will help their team to not be in every change that you know that your product partners want to make. So EM should actually think about like how to remove the engineering team as a bottleneck from various processes and various you know feature development cycles. And 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 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 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's a balance in the roadmap. What do you think, Slava? Yeah good stuff and I really like this image of a of an orchestra and 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 it or not. And so I like what you are saying in terms of I think I see that there are two components here. One is understanding. You said that the engineering team needs to understand their cross-functional partners and that the engineering managers must understand their cross-functional partners. And I'm also liking that 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. Improving the engineering processes, communicating low hanging fruits which a product team may not be seeing, communicating back things which are looking through from the product side but may be quite quite heavy on the engineering side that need to be discussed. I really like this sort of like a bi-directional communication style orchestra where not only engineering teams and engineering managers are 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 try to imagine that you remove all the data science, all the product managers, all the iterations 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 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 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? That's a great topic. So I mean that the EM and PM friction is like well-known, well-understood and there are some things that EM's can do to buy to be really good at navigating this friction and produce outcomes that are good for everybody even in situations which are difficult. You know I just previously I just mentioned that it's very important for EM's to proactively communicate a lot of things to their partners. I think the key word there was proactive a lot of EM's 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 like it's very important for EM to be proactive in doing a lot of you know a lot of the communication about what are the low-hanging fruits, what are the areas that are hard to move and but regardless of that you know conflicts happen and EM 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 we can discuss some situations of where you know 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 you should know what is good for the customers if not it's never too late to 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 you know 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 you know software increased you know that's you know it is necessary to for the business to sustain but to serve the customers right but it's not directly the customers will not love it so but it is a 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 ex-fn partner so don't make decisions that just help your team but not the ex-fn 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 like use this you know for these you know four pillars in the prioritization you know customer comes first then the business then your team and ex-fn partners and then you yourself and the common common problems that arise common conflicts that happen is sometimes the requirements change you know you your team and you will be executing and the requirements change and EM's usually are in a tough spot when that happens because EM's 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 EM's to navigate this is like make a first principles argument on like is this good for the customer should we change the requirement change the requirement might push the date delivery date by a month for example like is that a good decision for that for the customer or should we rather optimize for speed and go as is and not change the requirement so as an EM you can apply this framework and you know have some talking points that you can use with your ex-fn partners to make a decision here I also think that at the end of the day EM's and TL's 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 should you know see this as something as a learning and should react to that and should welcome things like that now there might be situations where you know there are other tools that EM's might have to use where which we should definitely discuss also learning in general engineering teams and engineers should embrace when we learn something new about the customer and we are able to like change the product and ship the right product for the customer as a result of that another common conflict that happens is on changing priorities right you know even EM might want to prioritize reducing the tech debt while you know PM might want to prioritize trying out a feature I mean a new exciting feature right there they can be you know conflict with each other and here also I think EM can apply the same framework like what is the right thing to do for the customer one practical problem that EM's 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 can nail that down it takes an effort but it's definitely possible and 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 principle discussion with your X7 partners on what should we prioritize so I think while conflicts happen I think EM's can use you know this way of prioritizing and this way of like making an argument to navigate these more smoothly so what are your thoughts I mean we cannot go wrong with the putting our 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 tried to defend not changing anything but the reality is that doing what customer wants means that learning and doing what they want and that this means change so yeah I absolutely agree with you change needs to be embraced and this is something that all engineering managers must learn and accept and also I agree that communication is still needed it cannot be one way street from product to engineering because 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 what they want and it's not only their new features it's also the infrastructure technical data which is always there so hundred percent so and that's good stuff so let's talk about situations when we we did our best we collaborated we communicated we had a dialogue and still things are not a not going hundred percent and things getting escalated how do we handle this as engineering managers now I love the point that you made about not taking it personally I think it is really critical for e-m's to not get emotional in making these decisions I think e-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 and as you mentioned like there's always gonna be situations where you cannot reach an agreement no matter how many frameworks you apply there are various things that will lead to you not reaching an agreement with your trust and partners and I think in that case is your biggest tool is escalation and escalation is something that is like really underused by e-m's I think e-m's kind of like frown from escalating things because that could be perceived as you know lack of ownership or lack of like being able to get things done but I think escalation can be a real powerful tool for e-m's if you use the right way my suggestion is if you have a conflict based on product priorities or requirements if you cannot reach a decision with your e-m with your p-m do it do a joint escalation instead of just escalating directly to your manager or your p-m's manager you and your p-m 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 p-m partner to disagree and commit one of you have to do it 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 you share the trade-offs like as a result of for example as a result of you know we are gonna build this feature instead of improving this tech debt and a result as a result of that we are gonna have less reliability for this XYZ service that will reduce the checkout rate for you know one percent 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 consider and as a EM you should really choose the battles wisely because there's gonna be a lot of conflicts and as a EM you can only manage a limited number of conflicts so pick your battles wisely and then be open to you like disagreeing and committing where you cannot make a decision and I guarantee you your partner will also reciprocate and in some times they will disagree and commit sometimes you will disagree and commit but 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 right 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 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 more of a personal issue and you're not able to make any progress there so what are your thoughts yeah good stuff I agree 100% that that it is important to treat disagreements or even conflicts professionally it means that if there's an disagreement this means that most of the times it's misunderstanding or misalignment of priorities there are a lot of things but there's an these are not things 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 will continue to work directly like with product teams and ops and data teams it is super important to have stable one-on-ones I would say one once a week because that that is the platform where we can have a safe environment to present challenges where our work changes 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 or what we agreed upon or what we agree on this united perspective and then tease out things which are 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 we 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 there a way sometimes the folks who are gonna be breaking the tie won't agree on doing things the way you wanted them to be done so this sort of a agree disagree and commit is is very important so that's that's really good stuff and a very solid guidance on cross-functional collaboration really have a very good question for you so we within last two years removed from living in the one world to now living in a new world and that this world is becoming newer and newer by 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 effective cross-functional collaboration changing in the AI world that's a that's an excellent question very timely as well because the world around us is changing and it is inevitable that we will live in a different word in like from any time from one year to five years because the pace of how AI is you know changing a real life is so fast and I think my point of view is that in future your non-engineering part your non-engineers so your cross-functional 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 product directly and as a result of that your excellent partners will become a 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 the 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 product manager data engineers and whatnot and EM should really focus on like how to how to make your how to like treat your excellent partners as your customers from today to actually adjust for the world that is you know coming up very soon. What are your thoughts Lava? I think this is good stuff because and it's really a fresh take because we've heard a lot of you know engineers are gonna disappear and that's also you know people who cannot code are gonna wipe code into the production. I don't see it happening next minimum I'll say five to ten years maybe we'll get to the point where you just describe what you wanted is just automatically materializes in production being able to handle you know millions of users possible but who's gonna be building this right and 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 works on my computer wipe-coded product most likely an excellent product because product product team will be able to describe I have a detailed conversation with the 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 visionaries and and and then then it's gonna be just like these days and we as engineering teams use LLM tools or now we're using MCP model context protocol I think those platforms are going to be that MCP for for the product teams I can totally agree with this I like it so anyway honey that was a great discussion and could you please share checklist with our listeners that they can start using tomorrow to collaborate cross-functionally effectively yeah of course lava so some of the suggestions I have for EM that they can like 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 your analysts 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's coming up than you know being than being the acting 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 you know goes in the same direction of like have been more proactive and if you have this your partners will know very transparently like what are you prioritizing and if there was 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 which is for EMS to actually start communicating the 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 if the 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 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 planned review after the planning is done make sure you invite all your cross-sectional partners as well as all your engineers this is more of a structured checkpoint and you and your team validate the priorities as well as folks have chance to object to the priorities and you know be able to like see what is coming up and then last but not the least make sure you are actually talking to your excellent partners in like non-formal settings also so I suggest is to join the resource or organize them where you invite your cross-sectional partners as well as your engineering team and this gives you an opportunity to like 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 matter all that matters and if you have trust at relationship with people you can you work with them more smoothly so yeah those are the stations I have for the EMS honey thank you this was good stuff to our listeners if you like this episode I've encouraged you to share it with other engineering managers as always the complete set of episodes of the effective engineering manager podcast can be found at www.effectiveam.com and you are welcome to reach us with a feedback and suggestions at a contact at effectiveam.com