Debugging Product vs Engineering: Breaking down silos and building trust (LCPS01E09)
Listen on all Podcast Platforms, like Spotify, Overcast, Apple Podcasts, iHeartRadio, Amazon Music.
Episode Summary
"This collaboration and making it work really well is such a critical factor to delivering great software for your clients."
Product teams and engineering teams tend to have rocky relationships. Why is this? They’re working toward the same goal, at least they are in theory, so what is the reason for their misalignment? In organizations with product and engineering teams that work together in harmony, what is their secret to success?
In this episode, Lena and her guest, Reina, explore the challenges and dynamics of the collaboration between product and engineering teams.
They diagnose problems in this relationship, such as finger-pointing, lack of communication, and conflicting incentives. They also provide advice on how to improve the relationship, including how to set clear expectations, communicate better, and align goals between each team. Reina shares her insights from working in multiple organizations as a product manager. Sometimes, Reina had a fantastic relationship with her engineering counterparts. Other times, things didn’t go so smoothly. Her experience at both ends of the spectrum brings a wealth of information on how to navigate this complicated relationship between product and engineerings teams.
Resources
Chapters
00:00 Introduction
02:45 The Importance of Product and Engineering Collaboration
11:17 Building Trust and Mutual Respect
19:18 Addressing Misaligned Incentives
22:30 Investing in Discovery and Planning
27:40 Balancing Feature Work and Technical Excellence
31:29 The Role of Leadership in Fostering Collaboration
32:22 Challenges in the Product-Engineering Relationship
34:19 Collaborating Closely and Establishing a Relationship
40:30 Responsibilities and Accountability in Product and Engineering
49:32 More Issues in the Product-Engineering Relationship
52:27 Improving the Relationship: Communication and Collaboration
58:32 Bonus Advice: Regulating Emotions and Mindful Thinking
***
We want to hear from you! Email us with feedback, questions, or topic ideas; I can't promise we'll always respond, but I can promise we read every email! At pod@lenareinhard.com.
Full Episode Transcript
Lena: So yeah, honestly, what I thought you - really fun to talk about is the whole product and engineering collaboration debacle.
Reina: Yeah.
Lena: Fun or adventure.
Reina: It doesn't have to be a debacle, but it can be!
Lena: Yes!
Reina: And I've had both.
Lena: For the majority of my 20 year career, I've been in leadership roles like VP engineering, startup co -founder, and CEO. And now I coach and mentor technical people leaders.
And every day I speak to leaders in the technology space who are dealing with the good and the hard parts around leadership. And now I'm inviting you into these conversations.
This is Leadership Confidential with Lena Reinhard. Real talk on more than two hard things in technology, finding community, and becoming the engineering leader you can be.
Today, we're debugging the relationship between product and engineering teams.
And today, again, I have my wonderful producer and overall fantastic person, Sly Stark, with me again. Hi, Sly.
Sly: Hi, Lena. And hi, everyone who's listening. My name is Sly Stark, and I'm an assistant to neurodivergent business owners. But more importantly, I'm Lena's assistant and the production assistant for Leadership Confidential.
I do not have 20-plus years of leadership experience, but I do have an extremely hard-earned business degree and experience working with people across multiple industries in varying roles as an assistant.
And hopefully, that will prove useful today and you'll get some good advice from me at the end of the show too.
Lena: I hope so. It better be good advice.
Sly: We'll see about that.
Lena: Well, be your own judge, dear listener. I'm really excited to have you again. We mentioned this last time, we're trying out a new format. So Sly, shall we talk about today's episode?
Sly: We shall. So Lena, what makes you excited about today's guest in conversation?
Lena: I'm really passionate about how to make the collaboration with product management teams work. I have for the majority of my career run teams that were client-facing and with that have worked really closely with product teams. And I've really appreciated working with great product teams. But on the flip side, I also know how frustrating it can be for all parties involved when that collaboration is not working.
Like, I'm not prone to emotional outbreaks, but I've rarely in my life used as much caps lock or honestly swear words at work as in some of those instances when that didn't work. And I know that my product partners often felt the same.
I know several engineering leaders who've really struggled in making the collaboration with product work. And that's why I wanted to speak with someone who's seen this from the other side and who has never in her life and I’m sure complained about the engineering leaders that she's working with because she's been able to make this work really well.
Because there is an idealized version that we're all taught of how this partnership between product and engineering is supposed to work. Like product owns the why and then maybe a part of the what, as in they own the business case, the input from internal stakeholders, from clients and customers, and a first idea at least of what we're supposed to build to make the business case a reality and realize ultimately the business impact that we're all looking for. And then there's the idea that engineering owns the how and maybe also a portion of the what.
Like how well things be implemented, how long will it take, what capacity will we need for it, and what will those things look like on the architectural side, for example, and how exactly is the feature going to be built? And that split sounds simple enough, even though the ambiguity in it already suggests that it's often not quite as simple. But I also know that even just how responsibilities are split is often a fighting point in a lot of organizations. And the reality of many companies is that this collaboration and making it work really well is such a critical factor to delivering great software for your clients. But in reality, it's just often really hard to make it work.
Sly: Lena, what are you and your guest talking about today?
Lena: So I wanted to understand from her, and my guest is a very fantastic product leader and she knows what she's talking about. So she helped me understand how do I as an engineer leader know if a product manager is good? How can I help them help me?
What does a good accountability split look like between product and engineering? What are differences in between roles and how do you manage those? And then also, how can you look at an organization to see if maybe misaligned incentives are causing people to behave in ways that are not helpful?
Talking about our fantastic guest, Sly, would you do the honors and share who our guest is today?
Sly: Yes, our guest today is Reina. That's not her real name, but that's what we're going to call her for this episode, and we've changed her voice.
Reina is a versatile product manager with a rich background in healthcare and health policy, bringing over a decade of experience from a sector known for its slow pace and regulatory challenges to the fast moving tech world. Her journey into product management began somewhat serendipitously when she stepped up to lead a critical project to fill a leadership vacuum.
Leveraging collaboration, trust, and mutual respect, Reina has mastered the art of bridging the gap between technical teams and business needs, even making herself a beloved quote unquote engineers product manager. Today, she continues to apply her strategic vision and inclusive leadership style to create software as a service products that are relevant to customers now and in the future.
And by the way, Reina is open to new roles as a product manager. She's based in the US. And if you're interested in connecting with her, email us at pod@lenareinhard.com and we'll forward your message to her.
Lena: I was really excited to talk to Reina and here's real talk on more than two hard things in technology with Reina.
Reina: I’ve had a really great experience for the most part.
There's only one or two that actively stick out in my mind is like working challenges, not just personality-based, right? And so I think I was fortunate enough to learn product management and learn the job in a company that had really great people.
And so that really helped me find my footing and find what it means to be like a partner to an engineering person, a design person, so really function as one group of people, like making decisions that a team is gonna carry out and do that well. And that strong foundation helped me, because when you get to places where like that's not the case, or you're in a relationship where that's not the case, you can at least find your footing and find your way to something about this.
I'm ready to dive in if you've got a question or how you want to do it.
Lena: I'm honestly still figuring that part out, but we can figure it out together. So I would love to start with a couple of things about you, whatever you're comfortable sharing, like your background, how you got into this work, what you're doing now.
Reina: Absolutely. My background is not in tech at all. I had a whole career in healthcare and health policy, primarily focused on military health care for 10 years. And I spent some time living abroad and I came back to America and in the city I was living, it's a transient place that's driven by politics. There was a big shift in our politics and all of my friends were leaving and they were all getting these jobs with these cool tech companies, the Facebooks back then, the Googles and they were moving fast and breaking things and it sounded so exciting.
That I wanted, I was like, wanna move fast, I wanna break things. Like the area I'm working in, healthcare for the government essentially is really slow. And their idea of innovation is catching up to something that the private sector has done five years ago. It just wasn't fun to chase. And so I started interviewing with these big companies and they were like, we don't understand what you think you're gonna do at a Facebook or a Google, you're a healthcare girl. It doesn't make sense.
So I pivoted a little bit. I ended up taking a job at a healthcare startup. And I went in as a program manager. They didn't know healthcare, the system, they didn't know providers in the way that I did. They had a tech product, a couple tech products. They were very early, so still figuring out, throwing stuff at the wall, seeing what sticks. And they knew they wanted to build some integration with healthcare systems.
They didn't know what they were asking for. They thought it was all technical. And I was like, nope, you're trying to drive behavior change of providers. That's a whole nother ball game. And I joined that team to do that work. And then all of a sudden I'm there for like two months. There's four product managers, two of them quit. So they're down to a team with 2 PMs.
The co -founders have a great idea of a value proposition they want to present to our customers. And they need it like put on the website within two weeks, right before everyone goes on holiday break for Christmas. And they were just like, is there someone that can lead this?
And I was like, Oh, you just need to get something done. Like, I could execute on anything. I can get folks to do it. Fine. Not a problem.
Lena: I can wrangle people.
Reina: I can wrangle people. Not a problem. So I get the folks in the room and I'm like, we've got to put up this two tier pricing model and give people an option of what they want to pay. And they're the restriction. If you pay less, you have to go to a specific place to pick up the thing you want, but it's just two prices. Right, like we can do that in two weeks. They want it in two weeks, we can do it in two weeks.
And I sat down with a group of really smart engineers and really great designers and they were like, that's not gonna work. To support the thing that they're asking for, we need to redo our checkout model. That's not the thing that we're gonna rebuild in two weeks. Here's why.
And I worked with a really smart engineer who pulled me over, this non -technical girl, who pulled me over to their computers and would show me things. Almost too much to tell sometimes. I was like, as long as you can make it work, it's fine. But they really helped me explore, like understand how our systems work and what I was asking for of them and why it was impossible.
They didn't automatically say no. And really were interested in getting to a place of yes, but they needed me to understand. And I have a person who helped me understand what I'm asking for. I will ask you to fly me to the moon, and I'll ask you to do it today. You have to tell me if I'm being crazy because your job is to know what's possible and how we can do that.
And so that was my first foray into product. I hold those skills in my second role when I actually got a job with like as full product manager, but that foundation of working with really caring and kind engineers and being able to partner with them in a way that they could push back on me because I'm - Right? My directive comes from the business. We need to go do a thing. And I needed the right people to ground me and say, yes, but not that way. Not that quickly. Here is what this really means. Here's what you're asking for.
And I found that leaning into people's expertise formed the best partnerships for me. And I've carried that throughout my career as a product manager.
When I walk into a new team, the first thing I tell everybody is that I start off trusting you to do your job. And I trust you to tell me when something that I'm asking for doesn't track your understanding of it or how it actually works.
I'm a person who talks about the what and the why. Trust that I got that and I'll do that part. Design is going to talk about what it should feel like and what it should look like. I don't know pixel. I trust them to do that. Or my engineering partner tell me how are we going to build it? How are we going to execute it? I'm not gonna tell you what software or what language you should be using. That's what you do really well.
So even when we're like developing, doing discovery work, thinking about what we wanna work on as product, I like to have all of those voices in the room because we all have different blind spots. And I trust you inherently that you're good at your thing, your thing really well, and I know my thing really well, and come together, then we'll get to something that hopefully is really good for me.
Lena: I mean, that honestly, that sounds wonderful. also makes me immediately want to work with you.
Reina: This is anonymous, right? I'm looking for a job.
Lena: Perfect. I'm happy to forward any, you know, inquiries, anyone looking for a great product manager in the US. I can send your way. It's not a problem. Because I honestly like I thought that description of the collaboration and really relying on people's expertise like that sounds so great.
And I also, you mentioned it doesn't have to be horrible, but I also want to just get a little bit into some of the horrible parts because I found that we all have these great ideals and ideas of how this can work. And it sounds like you've really experienced that and I'm so happy for you. At the same time, yeah, that's probably it. Cause at the same time, I've, I also found F1 product engineering teams a lot.
I’ve had engineering counterparts that were more focused on platform. My job was really a lot of collaboration with product. And so I'm listening to this. I'm also like remembering a lot of pain points. And so I also don't want to just dwell in all the sad.
Reina: But it's a part of it. It's a part of it.
Lena: So like how's that looked for you? What are the things that have made this hard or what are some experiences you've had?
Reina: So a couple things. I think one thing that really makes all of our jobs hard in that we all have different motivations. So as product, as I mentioned, like I am beholden, I ultimately accountable to the business for what we did and why we did it and if it wasn't actful. And so my motivation is to like get a thing done, get it out and let's measure it. We've got technical leadership who want a stable platform, who want to make sure that we're not making mistakes, that we're not exposing ourselves to critical breaks or bugs or anything like that, which generally slows down the process.
Then even within their ranks, that is true of engineering, but they also want you to hurry up and get something done. Once you move up the ladder in leadership, like lower level team leadership, they're like, yeah, let's do it right. Once you get up their ranks, once you get to the C-level, they're like, how fast can we get it done?
Which usually means let's cut some corners. So now we're all focused on delivering not the quality of the thing that we wanted sometimes. And that creates an inherent conflict because we are all being pulled in different directions to do a thing when I think genuinely at our core, we all want to do it right. And that's just not how business works. Business says we need to beat someone else to the market or we need to be able to offer this to our customers. Or we need to be able to retain customers, so we have to hurry up and get this done. And then there's all this misalignment at different levels that just makes it very hard to move forward in the same way. Sometimes the pressures are different. As I mentioned, in that first role, they were like, we need this done in two weeks. I was new to this type of role, so I was like, sure, until I got the explanation and like from that moment on, I've never commuted to a timeline ever, because it's not real. They have their own motivations, but that's not how it worked.
I think more recently, I've had a more difficult working relationship with my engineer in my recent team. And I didn't hear this from him. I heard the feedback from my boss who said, how's it going with your EM, I hear things aren't going well. And I was like, okay, that's interesting.
I said, my response was, we're not as close as I'm used to working with an EM. But I don't think anything is necessarily going wrong. We just don't have the relationship established in the way that I'm used to being the right hand, having a triad that really does focus in, think about the team altogether. We're not just talking about the work and asking you, how is the team feeling? Do we need to like think about how we're planning work so we don't burn people out? I really am used to being a partner to my EM.
And this person I just didn't have that natural relationship with. I couldn't get them to set one-on-ones with me like regularly. They did not want to meet with me, which was like super hard. I'm trying to like make our team be good.
So we didn't have that close relationship. And when I asked him, hey, I heard things weren't going well in our relationship. What's going on? I'd love to hear that directly from you. ‘Cause feedback is best received directly from the person.
And he goes, no, I didn't say that. I just said, like, I don't get requirements from you. And I was like, well, that's interesting. That is true. You have not gotten requirements from me because for the last three months, I've been tied up in getting leadership approvals for what we're doing. You've also been in every single one of those meetings. So you understand why we're not moving forward. The misalignment that he had from his leadership to hurry up and go get something done didn't gel with the reality of like product and design, leadership are not aligned. So we can't move forward because everything we're putting forward, nobody can agree on.
So it's not that I'm not getting him requirements. The bigger picture is that we can't do our job because there's a whole other set of alignment that's like a blocker. And instead of being empathetic or like understanding or paying attention to the meetings that you're in and reading the room both happening. The conversation went to like, I don't get anything from this PM. And I just felt, I think in that moment, I was frustrated because I was like, I brought you along, I've let every decision or in past that we've been at and why we're not moving. It's very odd to hear that you don't look at me as a good PM because I can't get your requirements for something that I can't get passed.
And that was really tough. so again, it came back to the differences and motivations and the different directives that we have and different functional, like, teams.
Yeah, that was a hard one. But it really dated with like your leadership is telling you to move forward, but I can't understand what they want you to move forward with is we don't on this side, we're not ready. And all of you are in the same meeting then can see that. Yeah.
Lena: I mean, it even sounds like in this situation, if you had given this EM requirements, you actually wouldn't have done your job because you would have had to make something up or that no one was agreed on.
Reina: That's another thing that I think sometimes can pose a difference or a challenge in the relationships is nobody says they work in waterfall method out loud, right? Everyone swears in their adult, right? yeah. No one is though. Yeah, of course.
But in certain environments, and I think that this is actually the nature of the environment that I work in, just I'm looking at the relationships. I've been able to step back and look across after working on many teams and just understand like the nature of products-engineering relationship in this particular environment is a little different than what I'm used to.
And so there's a lot of times, engineers don't want to move forward on what I would call discovery work. That I like to do early on together, they aren't willing to move on any of that without some level of requirements. And it's very hard to give you a requirement when we're in discover mode. And so the challenge there is, my job isn't to have everything figured out and buttoned up and then hand it off to you. That's not how we say we want to work.
I have rough ideas. I really want your partnership in helping me figure out like how do we bring it to life versus product and design go figure it out and then we'll come and look at the technical side of it later. I think the track there is we get that far down the line and we've designed something that we can't technically make work in any reasonable amount of time. I want to have like, bring you along in that conversation and have that input early so we can build the right thing.
And I think sometimes we get stuck on, I need all of these things before we can dedicate a single engineering resource into looking into it. And that just, that makes our product take a lot longer to get to where we need to go. And it reinforces the thing that we say we don't want to do in terms of how we work together.
Lena: Yeah, and the examples you're sharing resonate so deeply with me, feeling that in my core. Because I, even in the last bit you shared, I feel like there's always this tension between, yes, at an abstract level, we want everyone to collaborate really early on and make sure that all perspectives are represented and that we're even thinking in the right direction and we can actually, we'll be able to implement those things and whatnot. But then at the same time, capacity is super limited. And every time that, like every hour that we have, say a developer, like brainstorming on things with product is going to cost us and it's taking away from the things that we're trying to actually push out.
And so I think even in that, we're like, in theory for the sort of long-term gain, it would be really great to dedicate some time early on. It's in practicality, it's often really hard to actually do.
Reina: That's a false choice though.
Lena: Oh, yeah, I think it is.
Reina: We think that we're sacrificing time upfront.
If you give me someone for discovery. If you do, if you lead me to go do the discovery on my own, I feel like we're just gonna pay for it on the back end when we have to spend more time to either figure it out or I write a bunch of requirements that weren't right or weren't fully fleshed out. You start working on them and then I go and change the requirements.
And that I think is something that I try very often not to do because I understand that it's incredibly frustrating to go down a path of building something only to have to scrap it. And it happens a lot by nature of the business. There are enough interruptions on the business side when priorities change, we ditch a product, we put something on hold indefinitely that folks have been pouring their time into. That's already very frustrating. I don't want to add to that if I can help it by giving you requirements that are not fully fleshed out and then you go down a path and we need to pivot.
It evokes the same feeling for you as an engineer, as an engineering team of being like doing throwaway work, right, which people don't like to do. We have to find that balance. And I don't think it's the sacrifice here. And then like you're going to sacrifice on either end. And I think you just have to decide which end you're more comfortable with. I would rather a little bit of sacrifice on the front end. I'm not asking this person to pair with me for my entire day for every meeting that I go to, but there are some sessions where it would be great to just have that perspective because I don't know what I don't know. And I don't spend my day in the code. So there's a lot that I literally don't know.
Lena: Absolutely. I would a hundred percent like subscribe to that, I think the issue is that what I see a lot in delivery is just that what I like to call it, lack of discipline.
Of course, like when you're in a really, like really early stage and whatnot, you're throwing spaghetti at the wall, whatever short, but once you're at a point where you have a couple of teams, actually need to somewhat coordinate what you're working on and whatnot. It's still really easy, I think for everyone, especially with like high business pressure, to fall into kind of what feels like near-term rewards. Or it's like the whole thing with, we're just going to get this one thing out and then we'll do discovery or then we'll do the planning.
Or even like when you're doing work breakdown for sprints or however thick whatever cadence you're working on say, oh you know, we'll just get started on this, we'll figure it out as we go. Which is like, I'm pretty sure we've all done it. It's not great. But I think often, you know, there's sort of how processes work in in the ideal setting. And then there's also the reality of where basically the, for example, the pressure to deliver something is just much more strongly felt than the longer-term reward effect. Hey let's actually think this through, plan this out, not just move fast and break things to pick up your quote from earlier. And that part I find it's just sometimes really hard to do and to get people to actually wrap their heads around that, you know, these investments and the work together is really worth it.
Reina: I think part of what makes it successful when it does work is that there's buy-in and collaboration from the top down. And that means that the message you're getting from your engineering leadership is not different from the message that I'm getting as a product person. And even when I work in a few organizations where the CTO is over both product and engineering, even in those settings, same head can give two different messages to the different functions, right?
And so where I've seen this work well, or where we have more of an appetite for that partnership and making space for things is where there was better alignment at the top that trickled down.
So a good example is my first actual product role at another fast communications company on a platform that we probably all use, but it was just like really good. And I know no company is perfect, but it was a really good place.
I heard someone say like, is it like an engineer's PM? Because I care about the things that engineers have to care about. I know that engineering leadership thinks that we need to like do some technical excellence work. We need to be doing bug batches regularly. I also know that my leadership says we need to be putting new products out and we need to be driving customer impact. And to some people, those things are inherently in conflict because if you're spending time on one, you're not spending time on the other.
And maybe in my current environment, it feels that way. We can't get to a bunch of the stuff because we've got all of these customer facing things that we need to go put out. I don't have time to go like outside of escalations. We're not actively reducing our backlog. We're not actively making technical investments that we don't have to make because it is blocking something else. What I found by a company where I had my first PM roll is that there was an alignment between product and engineering to say, we're going to take time every sprint, for every team, to do some technical investment stuff and some like customer focus and bug bashing.
And so when we planned our quarters, I didn't plan by quarter and plan my engineers time to 200%, which is already ridiculous. We plan to 70% because 30% of that time is like overhead stuff. It's being on call. It's going on vacation because please go take your vacation, right? So with 70% of your time, I have to say let's go focus on the work we need to do. 70% is not all my product work. Actually, we're probably gonna do something like 45% is gonna be my product stuff. And then we're gonna do a portion that's like on technical fixes.
And I need, when we go into planning, I need my partner, my engineering manager to say, these are the big ticket things that we need to do to make infrastructure changes, to like clean up some code, like it's stuff that's been hanging out for six months and it's a risk, we should clean that up. Let's identify those things. We're going to actually plan that work and block it off in our calendar. And we're going to go do that work. Same thing we're going to do for our, we call it customer love, which was like a sprint where you did things that were like little nits, small bugs.
If we had the time and people weren't focused on having to get this product out the door, it would be an easy fix. How do we spend time focusing on just those things? Let's pick up a few of those. Everything is confined into a sprint, so we're really not like, gonna let it bleed over, but we got to get that stuff done so everybody feels like their agenda is being accomplished.
Because at the top, we said, let's make room for all the things that are important to us. And just the feature work is not the only thing that's important to us. We need to make sure we have great infrastructure and that we don't have buggy systems. Let's make sure we're balancing that. And I feel like when you have that message from the top, it sets the tone so that everybody has some understanding and we can work together to make better decisions about what we work on, but also how we build our product and how we make a better product for our users.
Lena: Well, there is, I, you and I have talked about this before, there is this question in there of basically our product is not just the quote unquote features that we're pushing out, but there is even at the top leadership and what I just heard from you, there is a very kind of balanced and nuanced understanding that our product is everything that our customers experience. And that includes, of course, things that are buggy for them.
It also includes maybe stability issues and we need to invest into all of those and then being committed as a leadership team to those things and to making all of this a great product.
Reina: That's exactly it.
It is easy to think about the product being a thing that people see and interact with, but the product is also the underlying platform and the underlying infrastructure.
And if those things are left alone, we will pay for it later and you'll spend years - I came into a theme earlier this year that needed to decouple some of their work from our old back end and put it into the new front-end system. The estimate I was given was three engineering years to get it done. It needs to be done, needed to be done by the end of last year. But the amount of work that was needed was three dev years.
Lena: Oh, that's terrible.
Reina: Do you torch it? Or what do do here? Another, here’s a quick tip for any product manager that may be listening. You want to gain favor with your engineering teams, do the legwork to get them by-in to torch the bug backlog. I have walked into teams that had a backlog with bugs from four years, five years ago. And it's just sitting there and it's hanging over everyone's head and no one's like actively paying attention to it, but there is someone that's like this team has this bug. Come up with a plan to like triage those and get rid of the stuff that doesn't matter. And you win favor with your team. That's a free nugget for any product manager who's like looking to get a better relationship with their engineering team.
Torch the bug backlog. If it's truly important, it will have been reported again and more recently and have, it will matter and you will know what matters and you will know what doesn't. And it's a mood lifter to see that you no longer have 500 items in your bug backlog.
Lena: Yeah, that's a looming like danger. Yeah. I love that. That is an excellent tip that I think I might actually steal.
Reina: Listen, I went on the road show. I like looked at the stuff with the team when I walked into the scene, this long backlog. Wasn't sure if these things were really even valid, but I went and did the road show with engineering leadership to say like, these things have been sitting back here. It's a weight on our team that we're never going to get to. But I would like for us to be able to make impact here and on the right thing.
It's easy to get focused on the wrong thing when there's too many options there. Half of them, you pare this down. And then I went to my IT team and I was like, go in Jira and close out all of these things. You have approval? Absolutely, I have approval here, right here. We're closing like 300 of these things.
Lena: Oh my God. That is genius.
Reina: If they’re truly important then they will have appeared somewhere else in the list. They will have to report it again. Or they will be reported again. But our technology moves so quickly anyway. Why are we holding onto things that may not even be relevant in our product anymore? But we're all so busy that no one's had the chance to keep an eye on that backlog and actually go through and see what’s relevant and what’s was not. That's the way to gain favor and have a better working relationship for sure.
Lena: The bug baggage is really not the stuff that anyone needs. And as you said, if it's important, if it loves you, it will come back. Also, if it's, if it actually is truly haunting you then too.
Reina: Then we will also come back. Yeah, for sure.
Lena: I do honestly, in the things that you've talked about so far, I think there was so much wisdom in there and I wrote down a couple of points on the side that I want to ask you to like, basically honestly help me and maybe help other engineering folks and just debug these relationships with product or make them better.
It sounds like one thing that has been really important for you is just like collaborating really closely. Like when that collaboration works the way that you've seen it work, what do you spend time on with your engineering peer especially or your design folks? Like what does that look like in the day to day basically? What are the things you work on together, the things you talk about maybe, you for people who are interested in trying that out?
Reina: Yeah, so I think one part is to establish a relationship with your triad.
Or if you don't have a full-time design partner with your engineering person, like as a human, and also as the leaders of this team. As I mentioned, my 101 was by EMs. I'm not just checking in on like, when it's the progress, the ball, the stuff. How is the team feeling? How are you thinking about like, I have a sprint planning meeting as soon as I get out of here. We're going to talk about who's best suited to do what next, given what they've been working on, given what their interests are like.
Take a genuine interest in the health of your team so that you guys can do your best work together. And so we meet weekly. We have a one-on-one and then we have all these other meetings that we're in together, but we're spending time talking about what are the things that we need to be focused on. Where can I leverage? Because my team is so busy and working actually on something completely disparate from what I'm working on for the future for us. I do need some end support.
So right now, he and I are the partners for the discovery of how we're gonna go build out this new experience, along with design. And what it works really well is the three of us have meetings together. It's not weekly, bi-weekly, where design can come and talk about the things that they're thinking about. And engineering can provide feedback on that very directly, but in such a low stakes place, not in some product review or UX review, where there's a bunch of people with a bunch of opinions.
But it helps us go in like, form a unified front on what it is that we think we're presenting and how we're thinking about approaching it. So that when you go in the rooms for your reviews, your tech reviews, your UX reviews, your product reviews, you're not alone. You've at least got your other, you've got your triad with you and you guys are united in how you're thinking about something going forward.
Or if you disagree, you can at least get the other folks opinions, but you've seen it before, you're versed on it. You can answer the questions that may come up about a thing. I think that in some of the best places I've been I've seen designers be able to answer questions about engineering I've been able to answer a question about the volume not with full detail, but be able to give me the gist. So I think that works really well together. I think also understanding what, and this depends on how the teams work, where you are, but what are the things that the EMs see as their role and what is the PMs see as their role?
There's been times where I've been like the product manager, but also the scrum master. And so I see my job as making sure we've done backlog refinement, making sure we've got things teed up for the sprint, that everything is pointed and that's my role. And the engineering manager sees their role as something very different. I think understanding kind of what's ideal for both parties is a good thing to establish early on so that you can play to each other's strengths, but also have a plan for managing the team.
And then keeping each other in the loop. It may sound like a little bit of gossiping between you and your EM, but often we're in different meetings. He goes to a lot of engineering-led meetings and engineering-focus meetings where somebody may say something like, Oh we're going to have this thing ready - that somebody will throw out a date. And I need him a go back and tell me that because I didn't know that. Or I'll hear a date somewhere and be like- A really great example, my team was working on building a component for a product that we're putting out, someone in the products channel just put out a document about redoing that same component for our entire product.
And I sent him this and I was like, yo, have you seen this? Cause I know you guys are working on about to go build a 16th version of this thing. Cause we have 16 of them in our product that are not unified. Are you aware that they're doing a unified one? And he was like, no. I wasn't aware, I'm gonna go read that. I think we're still gonna have to build our thing because we need it quickly. But I wasn't aware that there was this whole other set of work to make this make sense beyond us.
So there's a lot of conversations that we are really just keeping each other apprised of like, hey, did you hear? Hey, did you hear? How does that affect us? Do we need to think about that? Do we need to communicate into the team together? There's lots of rumors and things that we hear and like some stuff we need to give our team a heads up about so they're not blindsided.
So I think it really does come down to having communication, that trust that like you're doing your job and you're going to bring me feedback. And you're also going to be the person to lend your expertise and I'm going to be the same. That I think is really key to helping like getting a good footing of that relationship and being able to like, let it grow for now.
Lena: These are such good examples and it's so practical, honesty, because it, to me, so much of what comes through there is really, we have each other's backs. That doesn't mean we don't challenge each other or I criticize things, but it means we're watching out because we all care about this team and about the work that needs to get done and that we're trying to make sure that we're doing this together as even like a small core team between that sort of triad or the two people who are working together.
Another question that came up for me was, because you just mentioned the responsibilities may shift sometimes, I know that's something a lot of people struggle with because often there's like really ambiguous role documents and then who owns exactly what and what not to figure it out.
I think I heard you earlier say that you take accountability for ultimately, for delivery. How do you actually handle kind of accountability split between like you and an engineering counterpart?
Reina: Yeah, I'm - Let me rephrase that.
I am the one who's ultimately responsible to the business. That said, my engineering counterpart is ultimately responsible for the delivering and things like, did he get this done and how and in what amount of time.
And I know that his leadership cares about that and they measure it and they talk about it. They look at points, they sit in meetings that I have uninvited myself to quite frankly, because I don't need to know.
Lena: Good for you.
Reina: Looking at burn down, looking at how quickly things are moving, looking at how things are pointed and if they're broken down in the right way. They are responsible for delivering as close to on time as they can and with the right quality are. I'm responsible for the impact of that thing. In some ways for delivery, like what is slowing us down were the requirements not clear, where there's something else that we needed to think about to include.
Did we have all the right information going in to know what we were going to build? And then once it's launched, did it do anything. That responsibility falls on me. But the actual, did we get to all these points in a sprint? Did this thing get built in the time that we said it was going to be built or were our estimates wildly off? Like that accountability is on my engineering counterpart. And I think that's very, that's driven by the way our functions are defined in the company.
I think that's something you don't necessarily know walking into a job. You don't know it until you get in and see how the company functions. And again, it's a communication thing. Like ask, what do you see as your job? And what do you see as my job? This is how I view my job. This is how I view your job. What things like overlap and what things were we wildly apart on? Like how do we, what do we need to address? May not be a big deal, but if it is, what do we need to address there?
Lena: There's a lot in being super explicit about the expectations and what you want and need from one another. I think that's really great. In a sort of, how do I know that a product manager is good at what they're doing?
Reina: That is a subjective answer.
Lena: That is fair.
Reina: And so I'm not going to say that there is any right or wrong. I think it is situation dependent, company dependent. All of those things.
I will tell you that what I think makes me a good product manager is that I strive for alignment and clarity on what we're doing and why. And the why matters somewhat, I think, to the team, but sometimes it doesn’t. But being able to, but making sure that like across and up for sure they understand the why and get the clarity all the way around and make sure that the like clarity is something that I can deliver down to my team is really important.
I think valuing engineering perspective, I can't imagine PMs who don't value that. And I know that they exist, but I know they exist, but I can't imagine what work looks like for them. And I don't want to.
I had a very vulnerable moment with someone on my team. They built some stuff for me in the data table. And I was like, Hey, okay, now I have to go time to set it to a dashboard.
Here's full-transparency. This is where my imposter syndrome shows up. I don't feel, I worked in research for a very long time. You give me an Excel file, I can do whatever I want to do with data. You've given me something in SQL, I'm not super comfortable. And I'm telling you that like, I may have a lot of questions, because I need to go build this thing. But I'm like already nervous about it. And he goes, thank you for sharing that with me. Also, the imposter syndrome part I had was building it. So I know the other part and we can work together. We can figure it out.
But there is this level of just being open and honest and vulnerable where you're comfortable. That to me, I think makes me not just a good product manager, but a good colleague. And no, that's not what gives you PM jobs necessarily, but I think that's important. Yes, I've been able to ship and have an impact, but like those things are the things that I think make me a good PM. And a desire to on some level understand what that thing.
I don't want to be technical, I don't desire that, but I do want to be able to understand and have a conversation and show you that I'm open to you explaining things to me. And I think that goes back to my very first experience where I had these great engineers who would like stick me at their computer and be like, this is what this means, or this is how this would work. Being open to that and not just being like, you go figure it out because my job is to spend my whole day and meetings and I don't have time for that. Like we'd have to be open.
And I think that that curiosity, also, is a hallmark of what makes me a great PM. I'm just saying that because I think you could get a million answers to that question.
Lena: Yeah, that is fair. It was a mean question. I think you answered it brilliantly. Also, I think that is why people should hire you as their PM because you are open to a new job. So keep putting the word out.
Reina: Thanks so much.
Lena: Of course.
What can engineering leaders do to make your job easier? And by extension make things better for everyone involved and the team and all that.
Reina: Yep. Provided at level of the input and expertise, the discovery process is not like fine- It's not finite. It's not clear. It is messy. And I think that a personality trait of people who write code could be that they need something that like is very clear and you can do the thing and it does the thing. And discovery just isn't that.
And so having the patience and understanding for like all that discovery might bring, it's something that I'm even learning myself. I am a more get to the point person and discovery does definitely lend itself to that. So there is a level of patience that has to be exercised. I think the other thing that I appreciate about a good EM is understanding the team, how they work and their capacity like where they are what level they are. Title doesn’t necessarily mean anything about speed or proficiency.
Ultimately me and this EM are on the line for delivering something by a date whenever we have to commit to that date. Being very clear about being able to provide clear expectations around the scope and estimates is probably one of the biggest things I value in a good EM.
It is great when we under promise and over deliver, but I don't want it to be a habit that all of our estimates are so big because we don't really know how to do that well. We don't, we're not good at that practice. And so we always deliver quickly. It does, it actually makes it very hard to plan, but it doesn't, that doesn't bode well. The first couple of times, wow, you guys like deliver before time. That's great. But then when it becomes a pattern, everyone was like, wait, you guys.
Lena: Your buffers are too big.
Reina: Yeah. Yeah, the other side of that is also not challenging the team to go deep enough to understand what gotchas there might be. So you underestimate work and then we're driving on and on. There is, I'm on a new team. There's something that they released internally six months ago. I think we're just now getting to GA, but my boss was like, we've been working on this for the last year and a half that I've been on this team and it was supposed to be done a year ago.
I've watched my principal engineers come alongside and actually pair with engineers on the team and see, okay, I understand how they estimate now and now I need to push back. But there is the level of engagement you have to do with engineers to get them good at that and get them to think about all the right things to get something that's really accurate. That helps immensely. And when my EM is really good at that and I can trust that we have a good sense of what it's going to take, it makes me more confident in the dates that we put out.
And also, I'm happy to go to bat when we need to ask more time because I know that you got me, right? It instills more confidence there. So I think, yeah, that's- Be willing to get in the messy part of the discovery with me and get the team really good at estimates. That's what I wish for all EMs to provide to products.
Lena: Love that.
Sly: All right, Lena, let's talk about it. What stood out to you about this episode?
Lena: I can't emphasize enough and how much that stood out to me as well from what Reina shared with us, like how much the relationship between product and engineering can make or break an organization at all levels. And we've heard some things that break this relationship. And I want to summarize a bit and add a few from my own experience.
Like one big piece of things that ruins this relationship between product and engineering is finger-pointing.
Like the whole who done it or product is waiting for engineering, engineering is waiting for product. I've seen that so often. And it's always just, it's terrible for all parties involved because not only does it kill morale, but it also doesn't really treat the whole group working on these things as a team. And that was one of the things that really stood out in what Reina shared, like how important it is to work this way.
I've also often experienced triangulating feedback, which then often becomes a bit of a like the parents are fighting situation with like people coming to me saying, you know, product is doing this or that I try and work things out with my product counterparts who then are telling me a different story. And at some point, like untangling this becomes really, really difficult. Because once people like stop talking to each other directly, things just go downhill from there, no matter who's involved.
What also often is really tricky is when things are misaligned at a higher level. I've often experienced that teams are actually doing fine and the collaboration between product engineering is going okay, but at higher levels there is unclarity about goals or that leaders in, for example, even C-level positions aren't entirely on the same page in terms of what needs to be prioritized, which can then still backfire at the team level as well.
And I think another big killer is often when investments are treated as like product work versus engineering work so that some initiatives are prepared by product and others are kind led or prepared by engineering. Which in theory could be fine, but often what it leads to is, because capacity is limited in any organization, it often leads to a lot of either fighting or in the end, oftentimes engineering initiatives get deprioritized because engineering may not be able to present an as-clear business case as the product side.
And those kinds of fights just don't really go well either. Another piece I did want to call out was that when motivations and incentives are misaligned, I think Reina spoke really well to that as well. And in my experience, it's a really subtle but important piece. That if product has its own goals and engineering has its own goals, you already have a setup where everyone working towards the same goal is by default not given.
Like product and engineering having distinct goals may not be the problem, but it often is the starting point for, again, discussions about capacity and prioritization and whatnot. And so looking at, are we actually all pursuing like literally the same goal or do we have different incentives? Do we have different things that we're going after can already resolve a lot of the infighting.
Sly: Okay, so what's your advice on how to create a better relationship between a product manager and an engineering manager?
Lena: I want to highlight several of the points that Reina mentioned and again, add a couple of my own. I think the biggest piece that she emphasized so often and that I think is so critical is that product managers are part of teams. There is no product versus engineering and whatnot. Yes, that may exist in your hierarchy or in your org chart and that's fine. But this is one team and it's one team that's pursuing one goal, which is ultimately impact for the company.
That also means make it an explicit collaboration with your product manager. If there have been issues or misunderstandings in the past, that's okay, that happens. It's also kind of part of how things set up. Because again, we've talked about the sort of idealistic world in which there is a lot of tension already built in between product and engineering. And it's important to acknowledge that as well. But talk to your product manager and talk about, how do we want to work together in the future? What's been working well for us? What hasn't? How can we improve things and how can we actually function as a team?
I also think it's really helpful to speak about what you expect from one another and as part of that, talk about how things are going on a regular basis. I know there's a lot of delivery pressure on a lot of teams, but still, even if it's just three minutes at the end of your meeting with your PM or at the last five minutes of your planning meeting together with your team, spend a little time about how is our work together going and talk about just things that are going well that you appreciate about each other and things that you want to improve in.
That kind of conversation ongoing is one of the biggest things you can do to make this go well. And I think a lot of the points that Reina highlighted go in that direction as well.
I also want to add for anyone who is in a more senior leadership position, you may really benefit from setting some clear guidance for your teams about how your teams should be investing. That can, for example, mean that there is a strategy. And even if that strategy is just two paragraphs or a couple bullet points, that I give them something to orient themselves around. Similarly, make a clear strategy around how you want engineering investments to be done and how you want your teams to prioritize between more customer-facing things or engineering legwork, which may also have a customer impact. Ideally, it should.
Where the impact may be a bit more long-term than with, for example, some feature work that your teams can build. You can also use investment guidelines that you give your team, like for example, say, OK, out of our capacity, you want 60% to go toward features, 30% to work tech debt and maintenance and bugs, and 10% as a buffer for escalations. Those numbers can also look different depending on if your organization is a bit earlier stage. It may be more feature heavy. If it's later stage, you may need a bit more maintenance buffer.
Clarifying a little bit how work is prioritized and how you want your teams to invest and clarifying that for your entire organization can take away a lot of the escalations and of the issues that your teams then have to deal with as they're prioritizing their day-to-day work.
It also really helps if you do some sort of annual or even quarterly goal setting. It doesn't have to be OKRs. I honestly don't care. Even if you just make it a smart goal or you have some sort of priority that you want your teams to go after. But again, having a bit of higher level guidance on what's important for your company will go a really long way to help your teams be able to honestly make decisions that are quote unquote smarter because they understand what they're supposed to go after.
And be clear on who's accountable for what.
I think the setup that Reina described where everyone owns the part that they contribute to is really good. Your setup may be different. That doesn't matter, but as long as it's clear. I think that's in the really important part.
The last bit that I want to recommend is if you have disagreement with your product manager or you see issues that keep coming up, one exercise that I like to do is basically tracing back to finding the breaking points. Essentially tracing back to the last point where you were in agreement with each other and then taking small steps onward from there.
So as an example, just a few months ago, I worked with a company where product engineer leaders had really bad conflicts about every freaking thing. And what we did eventually was we realized, one, they didn't really have an up-to-date strategy anymore. The roadmaps weren't really clear to everyone either. But what we were able to do was we pulled out the most recent version of their strategy, which wasn't super accurate anymore but it was still a starting point that everyone could work from.
So we used that strategy document. We looked at it. We realized, okay, everyone is still at least in agreement on that. And then we had small working groups that we broke out to discuss how can the team move onward from there? Like, what are the next steps going to be? How do they want to prioritize? And that kind of back-ttracing exercise can be really useful because oftentimes, conflicts or misunderstandings don't happen because people have bad intentions or they really want to get into fights. Like no one enjoys that stuff. We all just want to do good work. And so tracing back to basically what's the last point where we were all on the same page and how can we then move on from there and building on that together is like, it's kind of simple, but it's a really powerful way to fix those kinds of difficulties in relationships.
Sly: Beautifully said.
Lena: Thank you. If you just said, Lena I just hated everything about this, then I also would have taken that.
Sly: Well, luckily for you, it was, yeah, no, luckily for you, it was great.
Lena: Thank you. So as promised, we also have bonus advice from Sly.
Sly: After listening to Reina's episode, it sounds like the relationship between engineering and product management can be very humbling, a very humbling experience.
Cross-team conflict and cross-department conflict is always really difficult to deal with. Coincidentally enough, that's something I had lots of trouble with when I worked in a very large nonprofit. People in other departments could not get aligned and there was tons of finger pointing. And so when I was experiencing that while I worked in a corporate setting, three things that I found most helpful that I had to learn, by the way, because I started corporate as like a little baby. I was like 22. And so I had, I didn't have any of these. I know I didn't have any of these skills. And sometimes it's just nice to be reminded of them.
So, listener, if you're in the midst of conflict between another team or another department, or even with someone at a different level than you, like upper management, the best thing you can do for yourself personally is to, one, learn how to regulate your own emotions so you can keep your cool and keep your cortisol levels from exploding because that will just make things worse.
The only thing that we can sometimes control, truly, is the way we respond to a situation. And if everything else is out of our control, let's do the best that we can to keep ourselves in a good mental state.
The second thing you could do is to consciously communicate effectively and kindly, even when it's hard. In situations where you want to send the other person an email saying, what is wrong with you?
Lena: All caps.
Sly: All caps, all caps. Exactly.
Instead, you really need to swing it the other direction and opt for an empathetic response with non-confrontational language. Because most people are always in their own brains. It could be at the other person doesn’t even know how they're coming off, you know? And it's hard to receive those kind of like conversational signals over messages versus like talking face-to-face, right?
That's something we are all pretty much aware of at this point. So when you're expressing your thoughts and your perspective, let's do it without escalating tension. It'll make your life easier. It'll keep your coworkers, the people from other teams from having problems with you because those things stick around. You could say four nice things. You say to somebody, they're going to remember the one bad like experience or the bad thing you said or like the sass you've given them.
Just do your best to be kind, even when it's really hard.
And then the third thing is be mindful of how you're thinking about yourself and the people that you're interacting with. Pay attention to your thoughts to make sure you're not falling into negative thought patterns like self-doubt or viewing others as adversaries. And please just remember this, just because you're thinking something doesn't mean it's true.
Your brain is literally designed just to spit a bunch of things out to get your attention. And sometimes that output is wildly unhelpful. So make sure you're aware of your thoughts that way those unhelpful negative thought patterns aren't causing you more trouble than you're already experiencing in the conflict with these other teams, with these other departments.
Lena: Negativity bias is very real. Yeah. especially in like, when things have already been bad, it can make it really hard to like, get out of that spiral.
Sly: Make it hard to rein it back in, which is wonderful pun, unintentionally, to your guest's name.
Lena: I will also say on your second point, a personal recommendation. If you need to change your all caps message into something that's more corporate appropriate and doesn't violate the code of conduct of your company, I highly recommend Goblin Tools. It's a collection of small, simple single task tools. They're not sponsoring us or anything. It's mostly designed to help neurodivergent people with tasks that they find overwhelming or difficult. Like for example, turning your all caps yelling email into something that is corporate appropriate.
Sly: That is amazing. Is that like an AI thing? Goblin Tools.
Lena: It is an AI thing and I use a couple other things and it's free and it's a wonderful tool collection. I'll put it into the show notes.
Sly: Okay. That's a great idea. The beauty of AI. Taking your wildly unprofessional and inappropriate message and turning it into something that is good to send. Yep. An underrated use.
Lena: And thank you for those lovely bonus tips, Sly.
Sly: Of course. Thanks for asking.
Lena: A good reminder to take care of oneself and one's own feelings. I think much appreciated here.
Sly: Yeah, yeah. The best path to talking with other people is to first, just like center yourself to make sure your own self is doing okay. That way you have the best outcome whenever you're actually ready to tackle that conflict.
Lena: Well, thanks again to Reina for her honest and honestly beautiful advice for working with product. I really appreciate it. And again, if you want to hire Reina, please email us the emails in the show notes.
And that was today's episode about debugging the relationship with product.
Next time, we'll get real on having a micromanager boss and how to deal with that. And we'll also have an episode about neurodivergency in leadership coming up.
Leadership Confidential was created, produced, and presented by me, Lena Reinhard. Our guest's voice was digitally modified.
Our theme, original composition, and mixing are by Esteban Del Pino.
Production assistance, production, guest support, and social media by Sly Stark.
Thank you for listening and we'll hear you next time.
Sly: The beauty of media is that everyone's going to hear the finished product, because they're not going to know that you had to redo it. They're not going to know that you're feeling unsure about it. They’re going be like, wow, Lena sounds confident. And like they know exactly what they want to say.
Lena: It's because we have a script. That's why.
