And we've got a lot of product leaders, we've got a lot of product people watching this right now, and I think we've all probably experienced the really tight deadline, right? The really tight product deadline and then the engineer or the tech specs that's like hey we need to write better code or more higher quality code or look at these technical specs a little bit closer. EJ, I'd love to ask you and this is kind of a -- I think I'm going to put you on the side of the product person, right, as you are. And what are some of any examples or experiences you've had of engineering folks coming to you and making a great case as to why you might need to shift a product timeline? >> Yeah, so the best examples of this I can think of are when the engineers cover my blind spots. As far as what are the consequences of rushing something out or doing it in a less than optimal engineering way. So as a product manager, I might be really just focused on the end feature, the end result, the end UX to the customer. But the engineer who is writing the code often might think long term about the technical debt we might include by building a feature in this way. And so usually a good case example be when the engineer comes in and says I can do it on this timeline in this tacky way, but it means that our feature development over the next six months is going to slow down dramatically because we have to deal with this. It means that the feature might be a lot less stable and is going to require a lot less maintenance. And so it's going to have these second and third order effects down the road on our road map that I'm not thinking about when I'm just focused on delivering the product feature itself. >> Similar to what Nancy shared earlier around when you're building a product and you start to think about hey like does what we're doing and the way we're doing something now, is that going to force us to maybe have a duplicate of effort in trying to maintain the product? Or V1 or V2 of that product? Stephanie, if I can kind of come to you with this question, how do you factor that in to your decision making process? Are there other times where you have to make some tradeoffs, knowing that like hey this might be what's best right now, and I actually know it's maybe not optimal for V2 let's say. >> Yeah, no, definitely. I think I mean things like tech debt, feature debt, experience debt, like these are all things that you just naturally accrue, like moving quickly, making decisions, shipping product to get data. So these are things you're going to have to confront at some point. So I think it's all about, as your shipping product thinking about what's the right mix of feature, what's the right mix of focus that you're shipping with each version, with each iteration. Are you fixing a bit of tech debt here, a bit of feature debt there, as well as shipping new features that you're going to start getting more data on? So I think it's about finding balance and making sure that you're obviously listening to your engineering partners when they're telling you what their needs are in order to make themselves and as a result the entire team more efficient and ultimately increase velocity. >> And again, you all will realize how much I love community. And one part of community is culture and so companies, you think about whether it's engineering culture or product culture. George let me start with you I'd actually love to get maybe one or two other takes on this. How do you set that culture in approach and problem solving? And approach to product building for your teams? >> I think in many cases as a leader, both of the product and engineering leader is a lot about how you yourself behave and think about things. And how do you serve as that to your team. And, in the context of what we're talking about, maintainability and long-term thinking, I think the concept of a culture of ownership is super important. So when you repeatedly signal to your team that important questions, important solutions are long-term solutions. Then you instill that culture in the team, both by making such decisions and signaling them yourself, but also making sure that you very explicitly award certain decisions that are more long-term thinking versus short term thinking, right? So if you constantly as a product leader or as a team leader, or as any form of leader, if you constantly reward time to market, the team will be trained to cut scope, not think about long term maintability. Not think about ops, but think only about that [time to market]. However, if you do reward yourself, so the importance of that longer term thinking and how do we keep our engineering velocity high in the longer term. So you reward behaviors over two years or three years, then you instill that culture of ownership. So I think it's a lot about personal behavior and also setting the right rewards and incentives in the team. >> Thanks for that George. I'd love to kind of get the take of Nancy and EJ on this from the perspective of the two of you have experience at large enterprise as well as startups. So Nancy starting with you and then going to EJ, what has been that dynamic? Have you seen a difference in terms of that trade off between long-term thinking and short-term? >> Wahab as you mentioned right, you and I had worked together in the startup, although it wasn't necessarily a small startup. Right, by the time I think we had joined, it already had raised Series D [venture capital] and there was roughly around 300 engineers and the PM team was around 10 in size by the time I joined. At that point, right, it's almost like you are a microcosm where you have that ability to really impact culture at that point. Now compare and contrast that to Amazon, where ensure there is tens of thousands of PMS and engineers, you have the ability as leader of let's say a team like George for example. Or Sharmeen to change or to create culture that you want on your team. Whether it's, let's say, process driven or being engineering driven or being customer obsessed, those are all leavers within your control. So going back to the topic here, which is how do you develop effective working relationships. That's something totally within your scope of influence as a leader. And so from day one it's really thinking about how can these two separate functions work together in a way that we not only satisfy what customers are looking to get out of us, but at the same time maintaining the speed of innovation. Thanks Nancy. EJ, your thoughts on this. >> Yeah, so I'll bring the perspective of like the super small startup of like the 5, 10, 15 person. I think at that stage it becomes even more important with your engineers to realize that the lines of responsibility really become blurred because with so few people any one of you really has the fate of the company in your hands. If you can overperform and deliver for customers, that can really affect the trajectory of your road map, the customers you can get, and how successful you'll ultimately be. And so at that stage it's really important to realize that even though regardless of your job title, even though some people obviously engineering or product focused, everybody's opinion really has the chance to make a big impact. And so it's less about thinking about your individual responsibilities and more about thinking how can you advance this small company as a whole.
