Claire Vo

Welcome, and thank you for joining us for a discussion about reducing friction between product and engineering teams. I'm Claire Vo, the Chief Product Officer at Optimizely, which is the world's best progressive delivery and experimentation platform. I've been running product at Optimizely for three and a half years.

I joined Optimizely when they acquired Experiment Engine, a company I was CEO and co-founder of that focused on helping teams scale experimentation. I am rumored to be obsessed with experimentation, and I have loved A/B testing and feature flagging for a long time. I'm joined today by Lawrence, who will introduce himself.

Lawrence Bruhmuller

Hi, folks. I'm Lawrence, and I'm the CTO here at Optimizely. I've been in head-of-engineering roles for about ten years, previously at companies like WeWork, ClearSlide, and Symantec. I joined Optimizely this past February and have been closely partnering with Claire and the team since then. I'm very passionate about releasing software quickly and incrementally, so I've had a big background in feature flagging and was excited about Optimizely's direction in this area. I'm happy to be part of the team driving it.

Claire and I are going to talk about the symbiotic relationship between product and engineering. Modern development processes make these teams intertwined as ever. During the session, we'll discuss each of our perspectives on product and engineering, where we come from, examples of friction that pop up, and how we've worked together to analyze, iterate, and improve as an integrated team.

Claire Vo

Optimizely says we help teams move fast with confidence. What product and engineering team doesn't want that? I'm always asking, "Could we go faster, but can we also get it exactly right the first time?" We help teams do this by bringing together progressive delivery -- releasing software incrementally and targeting customer segments -- with experimentation, which is about hypothesis thinking, A/B testing, and being data-driven. We're proud of the platform we've built in progressive delivery and experimentation.

We're also proud of our pace of delivery. Lawrence and I and our teams work together to ship a lot of ship, as I'll say. The 50 big things we ship every year, plus all the little things, are only possible with a functioning product and engineering relationship. That's what we're here to talk about.

Lawrence Bruhmuller

For context on our responsibilities: I lead the entire technology organization at Optimizely, which includes all engineering teams plus specialized teams dedicated to SRE, security, privacy and compliance, quality and program management, business and data systems, and IT.

Our core engineering team is divided into product teams focused directly on product functionality and platform teams working on underlying infrastructure and tools. Product teams are organized by business domains, where each team owns that domain, whether it is in 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.

Claire Vo

Our product teams at Optimizely are responsible for setting our overall vision and strategy, deeply understanding customer problems, prioritizing how we'll solve them, and working closely with design and engineering to make everything a reality. We're ultimately responsible for a product or feature's success or failure, so we do a lot across the company to make every launch a success, or at least to measure things and learn from customer feedback. I also oversee the design team, which we consider a peer to product and engineering.

But how we work together does not tell you what really works. There is more to working together than structure, org charts, roles, and responsibilities. We believe each team must understand the other team's goals, KPIs, processes, challenges, culture, and priorities.

Lawrence Bruhmuller

Many of these goals and KPIs need to be shared across engineering and product, not just at the leadership level, but also down to the team level. This is critical to enable teams to be self-organizing and self-managing, which is how you get high velocity and scale in an organization.

It is also important to note that product and engineering have different roles and responsibilities to play. Let's take a few minutes to better understand product and engineering teams and how we run them. Lawrence is going to interview Claire about product, and then Claire will interview me about engineering.

Claire, how has your role as a product leader evolved over the last few years, and how does that affect collaboration with engineering?

Claire Vo

When I came in, it was part of an acquisition, so I was much more hands-on doing product execution for a specific domain area. That was a great foundation for my role as a product leader at Optimizely because it allowed me not only to understand the product more deeply, but also to understand the code and some of the challenges that come with building new products at Optimizely.

As I developed into the overall product leader, I'm now more focused on broader company strategy, collaborating with peers in engineering, sales, and marketing, hitting our goals, and developing a thriving team. But I never forget the days where you all still let me do pull requests and code, because having empathy for what it means to be an engineer at Optimizely is really important.

Lawrence Bruhmuller

Our engineering attendees will be curious about this: how is your product team measured?

Claire Vo

It's important to me that product teams are measured on outcomes, not outputs. You can ship a lot of features, write a lot of code, and create a lot of new things for customers, but if they don't drive the outcomes you want from a user-experience or business perspective, shipping is not a measure of success.

One example is our wall of work. It had lanes from dreaming, to deciding, to designing, to developing, and then our last column was delivered. Delivered meant the work was generally available, passed quality standards, and was in customers' hands. But that's not the end of a product life cycle, so we added a column called delighting. That means customers are happy, they're using it, and it's driving business value. That's one way we orient product around outcomes, not outputs.

Lawrence Bruhmuller

I love the delight column. What direction do you provide your team on aligning with engineering?

Claire Vo

At a basic level, we start with organization structure. We have stable counterparts across engineering, product, and design from the very top, between Lawrence and me, down through our direct reports, first-line managers, and individual teams. We want stability and partnership across those three functions throughout the organization.

We also take seriously the idea that PMs don't decide alone what's on the roadmap. Teams decide. That means product invests in technical debt and other work that helps keep our code and engineering teams healthy. The addition of platform teams helps with that prioritization.

Then it's about shared goals. Lawrence and I share all of our goals at the top and take full ownership of our shared teams. We rarely talk about "the product team" this and "the engineering team" that. We call it ADEPT: a design, engineering, and product team. Lawrence and I are co-leaders of this team, and we think together about how it works, what we work on, and what the culture is like.

Lawrence Bruhmuller

What's the most common reason you've seen for product and engineering not being on the same page?

Claire Vo

Typically, it is two things: misaligned goals or an unhealthy culture. If engineering is measured on one thing and product on another, the teams can consistently be at odds. Sometimes engineering is measured on quality while PMs are measured on velocity, revenue, or something tied to how much gets out the door instead of the quality of what gets out the door.

When leaders like Lawrence and me don't share a destination, everyone cascading down from us can get misaligned. That only gets worse if you lack a culture of trust, accountability, and transparency. When there is an us-versus-them culture -- product saying engineering is too slow, or engineering saying product never gives us room in the roadmap to fix things -- and leaders and employees talk that way, it exacerbates misalignment. It is important to truly operate as a team, which means you win together and lose together.

Lawrence Bruhmuller

How do you manage and prioritize the product roadmap alongside engineering priorities?

Claire Vo

We take a portfolio approach to our products. We have a broad product line, plus infrastructure and core platform work, plus security, privacy, and compliance. At the beginning of a planning cycle, whether annual or quarterly, we look everywhere we could invest in a product, look at our strategy, and decide what percentage to allocate to each area.

Some years we may be struggling with developer velocity, application performance, and core platform issues, so we need to put 50% investment into platform work. That becomes a "go slow to go fast" year, and we make that decision intentionally at the beginning of the year and allocate resources and projects against it.

Other years, things are humming and there are many opportunities to get features into customers' hands, so we may go 80% feature work or 80% new products and do maintenance and the bare minimum on platform. It is a percentage allocation decision made collectively between Lawrence and me and our teams.

Claire Vo

Now it's Lawrence's turn to talk about engineering. How has your role as an engineering leader evolved over the past few years, and how does that affect collaboration with product?

Lawrence Bruhmuller

I used to be more focused on the mechanics of how product and engineering work together and ship features and enhancements: making teams truly agile, keeping backlogs clean, enabling teams to execute smoothly, and getting high velocity. I still care about that a lot, but others can take on much of that burden, so I don't have to focus on it directly as much.

I've ended up focusing more on big strategic projects that are necessary for future success but are large and risky. That could be building a new data platform, decomposing a big monolith, or making a major investment in a new type of tool across the group. If we pull these off, we win big as an organization. But to do this right, you need to understand the product and business strategy really well and see ahead into the future a little bit. I work as closely with product as ever, but at a more strategic level than I used to.

Claire Vo

How do modern software development techniques like Agile and CI/CD affect this dynamic between product and engineering?

Lawrence Bruhmuller

They definitely affect it, and they drive the right behavior. The days of waterfall release planning and a 50-page functional spec are long gone, thankfully. Teams break work into smaller chunks, get it out the door with minimal delay, see what works, and iterate. It's about velocity and speed of iteration.

The implication is that product and engineering need to work very closely together, as one team with a single set of goals and processes. In the old days, it was more of a handoff from one function to another. I used to say handoff is a dirty word in product development: spec handed from product to dev, code handed from dev to QA, a build handed to ops, then to support. Those handoffs prevent teams from operating as a single team. The speed of modern practices like Agile and CI/CD drives the right behavior because you can't get away with having different processes.

Claire Vo

Our product attendees may benefit from hearing how your engineering team is measured.

Lawrence Bruhmuller

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 -- feature work, bugs, quality, stability, platform, or anything else -- accrues toward product and business goals.

We also use cross-checking, engineering-centric goals: quality, reliability, incident response, and sense of velocity. We measure these mostly to look at trend lines, see how we're doing relative to how we were doing, and allow teams to course-correct. Claire and I spend most of our time on overall outcomes for the product and business and how we're tracking against those.

Claire Vo

What direction do you give your team to align with product?

Lawrence Bruhmuller

It sounds redundant, but it is critical to be aligned in the first place, not just at the leadership level or the individual level, but all the way up and down the org. These two teams need to mesh together.

I also emphasize that we play different roles. The role of an engineer or engineering manager is different from a product manager. We have different perspectives, and we're not always going to agree. So we need a culture of teamwork, transparency, and well-managed productive conflict where everything is on the table and we can get aligned.

Claire Vo

I want to interject because some people think product and engineering can be aligned by making them all report to one person, whether a CTO or chief digital officer. I think healthy conflict and tension between product and engineering is healthy. It keeps both of us honest, allows some push and pull, and is ultimately better for the team.

Lawrence, what traits do you value most in a product leader?

Lawrence Bruhmuller

Above everything, customer centricity. That does not mean focusing on one big customer or being a proxy or pass-through for sales. It means truly understanding customer use cases in depth -- not just today's use cases, but where they are going tomorrow.

It also means doing the hard work to measure outcomes. We ship a capability and think it is what customers or future customers wanted, but how are we measuring uptake, whether through product adoption, retention, increased revenue, or something else? That is really hard to measure, but you start with the customer, and the best product people live there.

The other traits are empathy -- understanding how someone with a different perspective and team sees the situation -- and clear prioritization. Product management includes many things, but the hard work is prioritizing some things above others. I often ask for stack ranks, and they are hard to build, but I value product leaders who can make clear priorities like that.

Claire Vo

I do love my stack-rank spreadsheet. That's a little bit about Lawrence and me and our functions. I want to talk about what this looks like in an ideal world. In the ideal world, product and engineering are aligned on strategy, the roadmap is clearly articulated and regularly updated, we ship everything on time, everyone loves their partner in engineering and product, every release is a smashing success, customers love it, and before they know it, we've shipped something new.

That's the ideal world. That's how it always works, right, Lawrence?

Lawrence Bruhmuller

Yes, that's the world we live in.

Claire Vo

And we're very talented. Use my humorous virtual background for this one. Clearly, that is not how it ends up in the real world.

Let's talk about common areas of friction. Product or other people in the company might think engineering is not shipping fast enough and ask them to go faster. Engineering might think product has not figured out all the details and that there are still open questions while they are in the middle of coding. Engineers, or people in general, might wonder whether the work they shipped and celebrated is really making a difference to the business and company goals. Teams may ask about innovation: is it always just things people ask for, or what about new things people aren't asking for? They may ask about technical debt: are we doing enough, and what is the right balance? These issues pop up everywhere, including at Optimizely. We're not a perfect universe; it's about how we resolve those issues.

Lawrence Bruhmuller

At Optimizely, we have a legacy monolithic app at the heart of our product that has been around for a while. Despite good efforts, it still slows developer velocity and slows some decisions about new architecture.

The tension arises when no one self-managed team feels it has enough bandwidth to make the big investments needed for needle-moving impact in this area. Everyone across engineering is frustrated because things are slower and clunky, but no one seems to have enough remit to take it on. Then enter a platform or infrastructure team: a separate set of engineers with the explicit goal of improving architecture and infrastructure for everyone's benefit.

But staffing that team directly takes away from product development capacity. Meanwhile, re-architecture projects typically have a low success rate. If you're going to bite the bullet and staff such a team, how can you be confident it will provide business value soon enough and build confidence in the approach?

Claire Vo

From a product perspective, most PMs understand the need to invest in a project like this, but we're stressed because we're ultimately accountable for roadmap outcomes. We want to be sympathetic and help staff it, but we're also trying to figure out how to do this work while making progress against customer problems.

Product tends to get a lot of pressure from non-product and non-engineering parts of the organization and other executives to push more on customer-facing work. Sales wants more to sell. Marketing wants more to market. Customer success or support wants bugs fixed. Customer-facing investment is easier to understand when you are outside product and engineering. These are common problems Lawrence and I think about a lot.

Lawrence, how do you think about fixing this when we face a challenge like this?

Lawrence Bruhmuller

In this case, a big architectural or re-platforming project, even if it is engineering-driven, very technical, and has ROI that may take longer to show results, must have full visibility and alignment with the product team, and depending on its size, with the broader company. There should be no hidden work, and there must be accountability that the right impact is delivered.

Sometimes I see a tendency to shunt off resources and do this work in the background. That does a disservice to the value and importance of the work. It should stand on its own and be justified. These efforts need strong advocacy from the highest levels of engineering leadership.

You have to decide you're going to do it. To quote Yoda, there is no try for these big bets. You're either going to do them or you're not. If you do them, you need leadership focus, your best engineers, cleared space, and comfort with the risk and reward.

More generally, it comes back to collaboration and alignment at the highest levels of leadership so we can send a unified message to our teams. If there is a big project like this, it is important that Claire understands how it works, why we're doing it, what the risks are, and how we'll stay on track. That unified message can go all the way down, and we can model that behavior for individual teams with an engineering manager and product manager.

Claire Vo

This also comes down to culture and reinforcing the culture you want. Is there distrust? Do PMs distrust that engineering is making the right decision? Where does that come from? Does there need to be a bigger sense of ownership in one part of the organization or another? As Lawrence said, if you're going to do it, you're going to do it and be accountable to the results. How do you drive that in the culture?

How can we cultivate more transparency? No hidden work. Why are we hiding work in the first place? What about our culture says we do that? How can we have a higher tolerance for failure and a higher cadence for learning? Sometimes you're going to get it right, and sometimes you're going to get it wrong. Product gets it right and wrong all the time; engineering gets it right and wrong all the time. You need to cultivate tolerance, and even willingness, to fail, because only by being willing to fail will you do really great things.

The last thing Lawrence and I want to convey is that reducing friction is an iterative process. Our teams are made of people, and people and code are both finicky. Things change. 2020 is proof that things change, and what you learned today or yesterday might not apply tomorrow. Culture matters, especially when it is hard to connect, so do things that bring you together.

The three big takeaways are: align at the organization level, align at the goal level, focus on culture, and as Lawrence says, there is no try. Get aligned.

Thank you for the time. I think we're here to answer questions, and we will continue to do our best to be a wholly aligned product and engineering team.

Lawrence Bruhmuller

That's right. Thanks, everybody. Hope it was useful.