Las Vegas 2020
Alleviating Product-Engineering Angst
Great products are the result of smart plans, alignment, and collaboration across product and engineering teams.
With 79% of business leaders believing that the customer experience would benefit if the product, marketing, and IT/engineering teams worked together more closely, it’s incredibly important that these teams collaborate effectively. However, with different goals and management structures, how can product and engineering teams ensure they work well together, and flawlessly deliver for their customers?
As Chief Product Officer and Chief Technology Officer, we’ve each experienced firsthand the challenges that can arise when our teams aren’t aligned. If your product and engineering teams aren’t tightly coupled and embedded during the development process, things can start to go off the rails quickly. And when your teams aren’t aligned on how to best serve your customers, neither can be effective.
In this session, we’ll outline the steps we took to solve this problem, including the structural and cultural changes we implemented to ensure our teams are aligned—and how we ensure they stay aligned—both on business goals and objectives as well as on delivering better products quickly and safely. Attendees will learn how to establish a culture of collaboration, from harnessing shared goals and objectives, to realigning strategies and objectives to avoid traditional product and engineering angst.
Attendees will leave armed with proven methods and insights to alleviate the angst between their product and engineering teams.
LB
Lawrence Bruhmuller
Chief Technology Officer, Optimizely
CV
Claire Vo
Chief Product Officer, Optimizely
Transcript
Welcome. And thank you for joining us on a discussion about reducing friction between product and engineering teams. I'm Clairvaux and I'm the chief product officer at optimized Lilly, which is the world's best progressive delivery and experimentation platform. And I've been at Optimizely running product now for three and a half years. And I joined optimized when they acquired a company. I was CEO and co-founder of called experiment engine that was focused on helping teams scale experimentation. I am a rumor to be obsessed with experimentation, have, uh, loved the concepts of AB testing and feature flagging for a really long time. And I am joined today by Lawrence who will introduce himself.
Hi folks, I'm Lawrence and I'm the CTO here at Optimizely. Uh, I've been in the head of engineering roles for about 10 years now, previously, a companies like we work ClearSlide and Symantec. I joined Optimizely this past February, and I've been closely partnering with Claire and the team since then. I'm very passionate about, uh, releasing software quickly, um, and incrementally. So I've had a big background in feature flagging and, um, really was excited about optimize these direction, this area, and now happy to be part of the team driving it.
Awesome.
So yeah, so product engineering teams, you know, have a very symbiotic relationship and in today's modern development processes make these as intertwined as ever before. So Claire and I are going to talk about that from our different perspectives. So during the session, we're going to, you know, talk about each of our perspectives on product and engineering, where we come from, discuss where and give examples of where there's actually friction that pops up, uh, and how we've worked together to analyze, iterate and improve as an integrated team.
And still a little bit about optimized Lee. So Optimizely, we say we help teams move fast with confidence and what combination of product and engineering team doesn't want that I'm always running around saying, Hey, could we go, could we go faster, but can we also get it exactly right the first time? And the way we add optimized, we help teams do this is by bringing together the concepts of progressive delivery and the idea of releasing your software incrementally and targeted against customer segments with the concept of experimentation, which is all about hypothesis thinking AB testing and being really data-driven. And we're really proud of the platform that we built in the progressive delivery and experimentation space. Um, but we, we're also really proud at Optimizly at our pace of delivery. So, uh, Lawrence and I worked together, our teams worked together to ship a lot of ship, uh, as well as I'll say. And this is really about, uh, and this is only made available or possible these 50 things, the big things that we ship every year, in addition to all the little stuff is only made possible with a functioning product and engineering relationship. And that's what we're here to talk about today.
So just, uh, a little bit of context about our jobs and responsibilities and how we approach those at Optimizely. So I lead the entire technology organization here at Optimizely, which includes all of our engineering teams as well as specialized teams, dedicated to SRE security, privacy, and compliance quality and program management, as well as our business and data systems teams and our it team. Our core engineering team is divided into product teams directly focusing on product functionality and platform teams working on underlying infrastructure and tools. Our product teams are organized by business domains or each team owns that domain, whether it's an old system or a new system, these teams are highly agile and work very closely with a dedicated product manager and designer to deliver the most important, highest value items in their area.
Yeah, and then our product teams optimize lead are really responsible for setting our overall vision and strategy, deeply understanding customer problems and prioritizing how we'll solve them. And then working closely with design and engineering to make everything a reality. Uh, we're also the ones that are ultimately responsible for a product or future success or failure. So we do a lot of work across the company to ensure that every launch is a success or at the very least that we measure things and learn from customer feedback. I also oversee the design team, which we consider a peer to product and engineering, but you know how we work together. It doesn't tell you what really works. Um, and so there's more to working together than just the structure or chart and roles and responsibilities. We really believe that each team must understand the other team, their goals, their KPIs, their processes, their challenges, their culture, their priorities.
Yeah. And in fact, many of these goals and KPIs really need to be shared across engineering and product and not just at the leadership level, which is very important, but also down to the team level. And this is critical to enable your team to be self-organizing and self-managing, which is actually how you get high velocity and scale and organization. Uh, but you know, we, it is important to note that we have, you know, different roles and responsibilities to play different positions to play. So let's take a few minutes to better understand product and engineering teams and how we run them.
Yep. And we're going to be really cute. So Morris is going to interview me about products and then I'm going to interview him about engineering. So I'm ready. Loris.
All right. So Claire, question one, how has your role as a product leader evolved over the last few years and how does that affect collaboration with the engineering team?
Yeah. So when I came in, it was part of an acquisition, as I said. So it was much more, hands-on doing product execution for a specific domain area. I thought that was really great too, as a foundation for my role as a product leader at Optimizely, because it allowed me not only to understand our more deeply, but actually understand our code and some of the challenges that come with building new products at Optimizely. And as I developed into our overall product leader, I'm now much more focused on broader company strategy, collaborating with my peers in engineering, sales, and marketing, uh, hitting our goals and developing a thriving team. But I never, I never forget those days where y'all still would let me do poll requests and, and code. Um, because I think just having that empathy for what it means to be an engineer at Optimizely is really important.
So our engineering team attendees will be really curious about this. So how is your product team measured?
Yeah, so it's really important to me that product teams are measured on outcomes, not outputs. And that means you can ship a lot of features. You can, you know, have a lot of code written, a lot of new things for your customers, but if they don't drive the outcomes that you want, either from a user experience perspective or from a business perspective, uh, shipping really isn't a measure of success. And one of the examples of the way that are driven, focus on outcomes, not outputs is we sort of have, we have a wall of work and, uh, it has different lanes from, you know, dreaming to deciding, to designing, to developing. And then we had delivered as our last column. And that was just really, uh, a threshold that said we made this generally available. It passed all of our quality standards in this, in the hands of customers, but that's really not the end of a life cycle for products. So, uh, we added a column which is delighting, which means that it's actually making our customers happy. They're actually using it and it's driving value for the business. And that's just one way we oriented product around measuring outcomes, not outputs.
Cool. Yeah. I love that like column a so well, so what direction do you provide your team on aligning with engineering?
Yeah, so at the, at first we did this at a very basic level, which is organization structure. So we have stable counterparts across engineering product and design from the very top. So between Lawrence and I, um, all the way down through our direct reports and our first line managers and even individual teams, we just want to make sure that there's stability and partnership through those three functions, uh, throughout the organization. And then we really take the idea that it's not just PMs who decide what's on the roadmap teams decide, which means that we really do as a product team, try to invest in technical debt and other work that helps our overall code and engineering team healthy. Um, the addition of platform teams, which I think Lawrence is gonna talk about a little later, only helps with, uh, this kind of prioritization. And then it's really about shared goals, you know, Lawrence and I share all of our goals at the top. We take full ownership of our shared teams. I mean, rarely do we talk about the product team, this and the engineering team that it's really, we call it adept our design engineering and product team, uh, and Lawrence and I are, uh, you know, co-parents, so we're we're leaders of this team and we think about how it works, what we work on, what the culture is like together.
So what's most common reason you see it for when product engineering aren't on the same page.
Yeah. It's typically to me, two things, it's misaligned goals, uh, or an unhealthy culture. So if engineering is measured on one thing and product on another, and then these teams can be consistently at odds. Um, an example of this is sometimes engineering's measured on quality and PM's are measured on something like velocity or revenue or something that just has much more to do with how much you get out the door, as opposed to the quality of things that you get out the door. And when you had those kinds of, you know, there are lots of examples of these times with conflicting goals and when leaders like boards, and I don't share as a shared destination, uh, everyone cascading down from us can get really misaligned. And then I think that only gets worse. If you lack a culture of trust, accountability, and transparency, when there's a culture of us versus them, you know, we're product and just engineering's too slow or we're engineering and product never like gives us room in the roadmap to fix things. Um, and that's how leaders talk. That's how individual employees talk. It only exacerbates a misalignment. So I think it's really important to truly operate as a team. And that means you win together and you lose together.
So how do you manage and prioritize the product roadmap alongside the engineering priorities? How do you, how do you mix those?
Yeah, so we tend to take a portfolio approach to our products. We have a broad set of products in our product line, plus all the infrastructure and core pro platform work we want to do plus security, privacy clients. And at the beginning of any planning cycle, whether that's an annual planning cycle or even something like a quarterly planning cycle, we really look at everywhere. We could invest in a product. We look at our strategy and then we say kind of what percentage are we going to allocate towards this or that? And some years it's, Hey, uh, we're really, you know, struggling with developer velocity and an application performance and some core things. And so we need to do 50% investment in our platform work, and it's kind of a, we're going to go slow to go fast year. And so we'll make that decision pretty intentionally at the beginning of the year and then allocate resources and projects against that. Um, some years it's like things are humming and we just have tons of opportunity if we can get features in the hands of customers. And then we go 80% feature work, 80% new products. Um, and we do sort of the maintenance and bare minimum on the platform piece. So it's really a percentage allocation and that's a decision that's made between Lawrence and I and our teams collectively.
Great. All right. I think we're going to switch it around now. Huh?
All right. Lawrence, it's your term to talk about the role of engineering. So how has your role as an engineering leader evolved over the past few years and how do you think that affects collaboration with the product team?
Yes. I used to be a bit more focused on the actual mechanics of how products and engineering work together and shipped features and enhancements. So how to make your teams truly agile backlogs are teams can execute smoothly high velocity. I still care about that a lot. Don't get me wrong, but I find that others can also take a lot of this burden and I don't have to focus on it as much directly. So I've ended up focusing more on these big strategic projects that are really necessary for future success, but they're big and risky and they could be building a new data platform or decomposing a big monolith or a major investment, a new type of tool across the group. And if we pull these off, we weren't big as an organization. Um, but if we do this right, you need to understand the product and the business strategy of your company really well, kind of see it, you know, see ahead in the future a little bit. So I work closely with the product team, uh, as ever before, but at a more strategic level than I used to.
Yeah. And so how do modern software development techniques like agile and CICB affect this dynamic between product and engineering?
Yeah, so they definitely definitely affected, I think they drive just the right behavior. So, you know, the days of a waterfall release planning cycle and a 50 page functional spec are long gone, thankfully teams break down, work into smaller chunks to get them out the door with minimal delay. They see what works and they iterate. So it's all about velocity and, uh, and speed of iteration. So the implication is that prior to engineering, you had to work very closely together, really as one team with a single set of goals and processes like we've talked about. And the old days it was more of a handoff from one function to another. And I used to say that, you know, I think handoff is kind of a dirty word in product development. You have like a, you know, a spec handed off from product to dev, you have code handed off from dev to QA. You have to build handed off to the ops team. And then it's, you know, the support team and, and all those handoffs actually really, um, don't have the teams operate as a single team. And so the speed of modern practices, agile CIC D drive the right behavior because you can't get away with having different processes.
Yeah. Uh, so likewise, I think you asked me this, our products team attendees may mesh what may benefit from hearing how your engineering team is measured.
Yeah. So, you know, there in as many ways as possible, we focus on the same goals, the same business and product level KPIs and how whatever one team is doing, whether it's feature, work, bugs, quality, stability platform, and whatever it is that that actually accrues towards the product and business goals. But there are a, you know, kind of cross checking engineering centric goals that we do use quality, reliability, how we respond to incidents, uh it's tensive velocity. So we do measure all of these. It's mostly to look at trend lines to see how we're doing relative to how we were doing and, and allow teams to course. Correct. Uh, and again, then we focus again, most declares in my time on really like these overall outcomes for the pride in the business and how we've tracking on those.
Yeah. So what direction do you give your team a tool to align with my team and product?
Yeah. I mean, it's, you know, this sounds, uh, this sounds redundant, but really it's, that it's critical to be lied in the first place and not just at the leadership level and not just at the individual level, but all the way up and down the org, you know, these are two teams I need to really, you know, mesh perfectly together. And, uh, so that's one just really highlighting the importance of that. And then I also emphasize that, you know, we do play different roles. The role of engineer or engineering manager is, is, is different than a product manager. And we're not, we're at different perspectives and we're not always going to agree. So let's have a culture of teamwork, transparency, also some well-managed, you know, productive conflict, um, where everything's really out there on the table and you can get aligned.
Yeah. And I'm just going to interject here because I think a lot of people sometimes think, oh, we'll align product and engineering by making them all report to one, one person, whether it's the CTO like a chief digital officer. And I actually think that healthy conflict and tensions between product and engineering is really healthy. It helps keep both of us honest. Um, it allows us for a little push and pull and I think ultimately it's, it's better for the team, so That's my preference. Okay. So what part, what traits do you value most in a product leader?
Yeah, so above, above, uh, everything, I would say a customer centricity and this doesn't mean just focusing on one big customer. It doesn't mean just being like a proxy or a pass through for sales. It really means truly understanding customer use cases and depth and not just the customer use cases of today, but where they're going tomorrow and doing. And then so not just understanding them, but doing all the hard work to measure the outcomes. You know, we shipped this new capability and it's, we think it's our customers or our future customers want it, but how are we actually measuring that uptake, whether it's product adoption, whether it's retention, increased revenue, whatever it is. It's a really, really hard to measure that. Um, but you start with the customer and the best part people live there. Um, the other things I would say are empathy.
You know, it's a big part of teamwork and collaboration is understanding how the other person with a different perspective and a different team is viewing the situation. And then last but not least, uh, again, it might sound simple, but you know, clear prioritization. And again, you know, this isn't, uh, all that product management is about, but a lot of it also, the hard things are really prioritizing things above the other. And, um, a lot of times I ask for a stack rank, so things, and they're really, really hard to build, and I appreciate that, but I really value product leaders who can, um, figure out a way to make clear priorities like that.
I do love my, my stack rank spreadsheet. So I'm living up to the, to the bar there. All right. So, uh, that's a little bit about Lawrence and I are, um, our functions and, you know, I want to talk about what this looks like in an ideal world. So like in an ideal world, you know, product and engineering are aligned on the strategy, a roadmap clearly articulated and regularly updated. We ship everything on time. Um, everybody loves their phone, their partner in engineering and product. There's just like a love match there. Every single release is a smashing success. Customers love it. And then before they know it we've shipped something new. Um, that's the ideal world. That's, that's how it always works. Right. Is Very talented.
And my humorous virtual background for this one. Yes, it definitely closed. That's not the way it, uh, it ends up in the real world. So let's talk about some common areas of friction, just throwing some out there that hopefully resonate with, uh, with folks in the audience, you know, a product might, might think, or other people in the company might think engineering's just not shipping fast enough. Like why, you know, just please go faster. Um, engineering might be thinking that product hasn't figured it out, all the details. There's still these open questions while I'm in the middle of coding. Um, you know, engineers might wonder, or other people in general might wonder this stuff I've worked so hard on, is it really making a real difference? We shipped it, we celebrated it, but is it really making a big difference to the business and our goals as a company?
What about innovation? You know, is it always just these things that people ask for? And what about the new things that people aren't asking for? What about technical debt? Are we, you know, doing enough of that, what's the right amount, what's the right balance. So these are, these are things that we've all seen many times and they pop up anywhere and they pop up, but optimize it. There's just, no, you know, we're not a, some perfect universe. So it's all about how we actually resolve those issues. So let's give an example. And so it Optimizely, I'll try to make this brief. Um, we have surprise, surprise a legacy monolithic app at the heart of our product. That's been around for a while. Uh, and despite some good efforts, it's still a slows down develop over the last city and it still slows down, you know, some decisions about new architecture.
So the tension arises when no one team, one of these self-managed teams feels like they have enough bandwidth to make the big investments needed, to do some really needle moving, you know, uh, impact in this area. So everyone across engineering is frustrated. They're slower as things clunky, but no one seems to have enough of a remit to actually take it on. So then enter, you know, a platform team or an infrastructure team, a separate set of engineers with this explicit goal of improving architecture and infrastructure for the benefit of everyone. But staffing a team, Mike this, uh, require it directly takes away from your product development team's capacity. Meanwhile, these rearchitecture projects typically have a low rate of success. You'd probably know a couple on your own experience that have failed. So if you're going to bite the bullet and actually staff up a team like this, how can you be confident? That's actually going to provide value back to the business soon enough and then build confidence in this kind of approach.
Yeah. And from a product perspective, most PMs understand the need to invest in a project like this, but, you know, we're stressed because we're ultimately accountable for the outcomes of the roadmap. And so, you know, we want to be sympathetic and we're trying to help staff this, but we're also trying to figure out like, how can we do this work and also make progress against customer problems. And, you know, we tend to be the, the role that gets a lot of pressure from non product engineering, from other parts of the organization, other executives to push more on customer facing work, you know, sales wants more to sell and marketing. What's more to market, um, customer success or customer support once bugs fixed. And, um, and it's just an easier investment to understand when you're outside of product and engineering. So these, these are very common problems we solve. And I think, um, Lawrence, I think about him a lot. Lawrence, how do you think about, you know, fixing this when, when we were, we're faced with a challenge like this?
Yeah. So in this case, I think it's, uh, it's really important that a big like architectural or re-platforming project, even if it's engineering driven, even if it's very technical, even if, you know, the, uh, the ROI might take a little longer to see results, you has to have full visibility and alignment with the product team and actually beyond to the company, depending on the size, there should be no hidden work. And there needs to be accountability that the right impact is delivered. You know, sometimes I do see the tendency to try to, you know, shut off resources and do this stuff in the background. Um, and I feel like I really does a disservice to, you know, the value of that work and the importance of that work. And it really should be able to stand on its own and be justified. So, um, to that point, they need strong advocacy from the various very highest levels of engineering leadership.
Uh, and you just gotta, you just have to decide you're going to do it. So to quote, you know, Yoda, there is no try for these big bets. You're either going to do them and, or you're not. And if you do them, you have to have a leadership, focus on them, put your best engineers on them, clear space and be comfortable with the risk and the reward. Um, so more generally back to what we're talking earlier, collaboration and alignment at the highest levels of leadership, so that we can send a unified message to our teams. So if there's a big project like this, it's really important for me, that Claire really, really understands how it works, why we're doing it, what the risks are, how are we going to stay on track? And that unified message can go all the way down. And we can model that behavior to the individual team with an engineering manager and a product manager.
Yeah. And then I think that's really also comes down to culture and reinforcing the culture that you want and, you know, figuring out like, is there distrust here, do PMs distrust, that engineering is making the right decision? Where does that come from? Um, does there need to be a bigger sense of ownership in one part of the organization or the other? Um, as Lawrence said, if you're going to do it, you're gonna do it and you're gonna be accountable to the results. And so how do you drive that in the culture? How can we cultivate more transparency? You know, no hidden work, uh, why are we hiding work in the first place? What about our culture is saying, we do that. And then how can we have a higher tolerance for failure and higher cadence for learning? And this is something that we care really passionately about at Optimizely, but I think makes sense for a lot of product and engineering teams, which is, you know, sometimes you're going to get it right.
And sometimes you're going to get it wrong and product gets it right and gets it wrong all the time engineering is going to get it right and get it wrong all the time. How can you cultivate a tolerance and even a willingness to fail because it's only by being willing to fail that you're going to be doing really, really great things. And, you know, the last thing that I think Lawrence and I want to convey to all of you is as amazing as we are at being product and engineering leaders, you know, reducing friction is, is an iterative process. It's our teams are made of people, people in code, both of which are finicky. And so I just think it's really important to know that things change, uh, 2020 is proof that that things change and what you've learned today, or what you've learned yesterday might not apply tomorrow. And so culture really matters, especially in times when it's hard to connect and do things that bring you together. So that's my recommendation. I think the three big takeaways from us are aligned at the organization level, align at the goal level, uh, focus on culture. And as, as more it says, there is no try. So get along and thank you so much for the time. I think we're here to answer questions and, uh, we will continue to do our best to be a wholly aligned prompt and engineering team.
That's right. Thanks everybody. Hope it was useful.