Claire Vo on Building High-Performing, Customer-Centric Teams in the Age of AI

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie from the InfoQ Engineering Culture Podcast. Today I'm sitting down with Claire Vo from LaunchDarkly. Claire, welcome. Thanks for taking the time to talk to us today.

Claire Vo: Thanks so much for having me.

Shane Hastie: My normal starting point in these conversations would be who's Claire?

Introductions [00:48]

Claire Vo: That's maybe a question I need to ask myself on a daily basis. Who is Claire? In the context of this conversation, I am Claire Vo. I'm the chief product and technology officer at LaunchDarkly. I lead our entire technology organization, so not just engineering, but product management, design, data. I even, pretty surprisingly, have a couple sellers on the team for our new incubation product. I have a pretty broad remit.

Functionally, my job is to build a really high performing team where we can make great investments in R&D, and bring great products to our customers, and great value for the company.

Shane Hastie: What is a high performing team today?

What is a high-performing team today? [01:29]

Claire Vo: It's a really great question. For me, I think about performance from the lens of our ultimate goal. To me, our ultimate goal is to solve hard problems for customers that have value to those customers, that have commercial markets for them, and that can build enterprise value for the company. To me, a team that is building towards our ultimate goal, which is really customer-centric and value-driven, is what I like to see engineering organizations.

Of course, we want technical excellence. Of course, we want camaraderie, and culture, and engagement. Of course, we want innovation. And of course, we want to attract competitive talent. But at the end of the day, that is a means to the end. We'd really like to say customer-centric in what we're trying to achieve for our colleagues and the business.

Shane Hastie: Customer-centric. As an engineer, how do I become customer-centric?

Engineers need to be customer-centric [02:29]

Claire Vo: Well, lucky for us, our customers are engineers. We're in a really privileged spot. LaunchDarkly is the leading feature management experimentation platform in the market. We serve engineers, that's our job. We build dev tools for engineers. Be build for builders. That's actually one of the things that attracted me to LaunchDarkly, is it's really candidly fun to be able to build for builders, and building technical tools for technical folks is very interesting.

One, whether you eat your own dog food or drink your own champagne, we are power users of LaunchDarkly at LaunchDarkly. We use LaunchDarkly to release, test, optimize our own code in production. We use it for small things, for big things. We use all the features. We take advantage of the full platform. One of the ways we become customer-centric as an organization is we act as customers.

That's not just the engineering organization. Product managers are expected to use the product. Our designers are expected to use the product. The product is not just the UI and the web app, it's our SDKs, it's our data export tools, all those things that make up the whole platform. I would say that's one primary way we're a little advantaged in being customer-centric.

But the other way is we stay very close to customers. My expectation in my organization is that everybody's having customer conversations. Live, real human-to-human customer conversations every week. That's not just the realm of our salespeople or our customer success team. Engineers need to know their customers that they go to to discuss their most challenging skill issues. Product managers need to have a group of customers they can rely on for early feedback on products. We really stay close to customers.

Then I think the third thing is we really bring a beginner's mindset to our product. LaunchDarkly has been in the market for over 10 years. In those 10 years, you can build up a lot of tolerance for the sharp edges in your product, or the things that you've gotten used to clicking around or hacking around. I really think it's important for folks to come to their own products with a beginner mindset, look at it with fresh eyes, and think, "If I knew nothing about LaunchDarkly, would this be easy to do?" Those are just a couple ways that we're really customer-centric in my organization.

Shane Hastie: You said make a great culture. What does that feel like? What does that look like?

What makes a great culture? [05:01]

Claire Vo: Yes. It's really funny. I have this fancy, C-level title, and tend to go into growth and scale stage startups, so much later stage startups. Everybody thinks that I get hired to make teams act like a big company. I come in as the grownup and I say, "Okay, this is how you're supposed to run an engineering organization at scale, or a product organization at scale", et cetera. Of course, my leaders and my team across the board want to do things to professionalize the way we operate, and make sure that we're showing up for customers with stability and pace. All those things are great. And I get hired to remind the team to operate like a startup.

To me, a great culture is one that is very close to customers, that moves fast. Where there are builders in the team who want to bring their technical, and intellectual, and creative skills to problems people have. I think a culture that is very close to how a startup would operate. Lower process, lower BS, lower politics, focus on the customer, focus on building, have fun. Those, to me, are the cultures I thrive in. Whether or not that's the best culture or not, that is the culture that I prefer to operate in. Then the non-negotiable is, as I said up front, high performance. All of that does not matter unfortunately unless we build great products that have market acceptance that can grow the company to the ambitions that we have.

I do bring to great cultures a focus on what really is our job. Because I think a lot of times, teams lose sight of that. They think their job is to do the work that gets them promoted, or their job is to do the work to make them look good in front of executives. None of that is actually their job. Their job is to help us build a great business and have an impact on users. I think that centricity about the job to be done is really important in great cultures.

Shane Hastie: You also, when we were chatting earlier, spoke about a culture of experimentation. How does that play out?

Encouraging a culture of experimentation [07:06]

Claire Vo: Yes. What I really think is to build great products, you have to be quite hypothesis-driven. You have to build, test, iterate over time.

One of my things that I say commonly is no genius product managers. What I mean by no genius product managers is product managers can hone product sense, and build intuition, and have experience that helps them narrow the surface area of the right problem to solve. But the reality is we have to remain humbled by users and be able to be humbled by the market. It is less important to be right out the gate, and more important to be fast out the gate and listen to what users say.

I really do think it's important that we approach every build as a hypothesis. "I believe that there's a great market here because what I know is that this data tells us there's an opportunity, and I think we can do X by building Y". That's a perfectly valid hypothesis. Then you have to have two things to make this culture of experimentation work. You have to have a real intellectual honesty accountability. "We had a hypothesis. Are we really holding ourselves accountable to that outcome?"

I'm sure you, like I have, have been in teams where everybody says, "Yes! We're going to hit this OKR or this goal, and I have this beautiful strategy and plan to do it". Then you build the beautiful strategy and the plan. In the end, you don't really hit the OKR. People say, "Oh, well", there's this excuse and that excuse. You really have to have a culture of accountability. "We said we were going to do something. Did we do it? If we didn't do it, let's understand the why".

The second thing you really have to have is a tolerance for failure. Which is the organization has to be resilient enough to tolerate getting it wrong. That means people have to be okay with being wrong. They have to be okay with saying, "My hypothesis was incorrect". And the organization itself actually has to be embrace people that can do that, because those are the folks that have the iterative, scrappy mindset that's really going to get you moving in the right direction with setbacks.

I think those two things. Of being intellectually honest and accountable, coupled with a high tolerance of failure and a hypothesis mindset, in a team that moves fast, you get to the right answer quickly and then you're pretty unstoppable.

Shane Hastie: You have both product and engineering under one umbrella.

Claire Vo: Yes.

Shane Hastie: Most organizations don't do that.

Having engineering and product under a single leader [09:32]

Claire Vo: More and more are, but the CPTO role is relatively rare. I've actually done it twice now. I've had a couple revs at this particular role.

Here's where I think it works well. I think the technology team, or at least that's what we call it. Some folks call it EPD, we call it technology. I've worked at other companies that have cute, little names for it. But that triad of functional teams, having a singular identity, I think is really healthy for culture. The idea that engineering and product are inherently at odds, that design is always an afterthought, I don't think that's necessary. I think it is often a reflection of how organizations are run under siloed executives.

I really believe that, whether or not it's reporting to me, a singular identity as an organization that represents the R&D investment in a company is very healthy. It creates better collaboration. It creates more innovation. It allows you to identify and overcome friction within teams. It sets a standard talent bar across all those orgs. I think it's very healthy and I've seen it play out.

I also think, in certain organizations, it can be really helpful for the CEO, as I say, to have a single person to hold accountability for R&D. Especially if, like at LaunchDarkly, we have a CEO that is not the founder, it can be very, very helpful to have an executive that represents the full investment in R&D, the team, the technology, and the product at the executive level. There's full accountability across that investment, which in most software teams, is the biggest investment in the company. I think from executive organization perspective, it can be useful.

But I think the skillsets are pretty rare and it takes a certain type to be able to do it. I have a technical background. I'm a classic generalist. I've been a founder. I've actually done revs in all these organizations because I myself have the personality of curiosity and learning. I have worked in startups, which means you get exposed to a lot of things. I've built up the scale operational experience, technical expertise, and strategy experience to be able to operate across all these functions. Then of course, I have amazing leaders across those teams. But I have people that report to me that say, "I never want your job. I don't want the whole thing. That seems hard". There's definitely folks that love the specialty, SVP Product, SVP Engineering role.

I do think from an identity perspective, from an R&D investment perspective, and for certain types, it can be a really functional structure for a software company.

Shane Hastie: Down at the place where the work gets done. How do we get the product and engineering folks working well together?

Getting product, design and engineering working together [12:30]

Claire Vo: I think there's a couple things. And you forget one, design. Everybody always forgets design. That's the other thing that I always do. I'm like, "D is part EPD".

I think there's been a lot of thought around this classic EPD triad, engineering, product, and design as shepherds for building a product experience. I think that continues to be true. But down at the team level, how do you actually make that happen? Well, one, I do think you have to have true triad-level accountability and parity on teams. Product doesn't lead everybody else. Product, engineering, and design jointly are the leads for an initiative.

Then the second thing that I think folks forget that we do culturally is that doesn't mean they're siloed. That means they're a cohesive unit. We have an operating principle in our technology organization called There Are No Lanes. What do we mean by there are no lanes? You don't stay in your lane, and you don't expect others to stay in their lane. There are no lanes. We have a shared goal. We are a team. We have skills that vary. If it makes sense for me to help in your lane, I have permission and accountability to do so.

There's some pretty interesting examples of this in this new world of AI where designers can start to build code and prototypes. And engineers can start to generate product requirements. And product managers can start to wire frame and do some really interesting design work with these AI tools. Rather than saying, "No, that's design's job, or no, that's product's job", what we're embracing is this flexible creativity and skillset in our teams which allows us to move faster and build ultimately better products.

Those are the two things. I think parity at the lead level, and then real embrace of this one team mindset.

Shane Hastie: You touched on AI.

Claire Vo: Yes.

Shane Hastie: What is happening with the adoption of ... And we're in many ways very early in the AI revolution. But what's happening in that team level you mentioned in using some of the tools?

The adoption of AI in development [14:38]

Claire Vo: It's a combination of tremendous excitement and a slow pace of adoption. I have a very unique point of view on this. I am probably what one would call an AI maximalist. I am not very risk averse around this topic. I think, in fact, most teams are moving too slow against becoming more AI-driven or AI native. We've been fairly aggressive in our adoption and experimentation, and again there's that word experimentation, our experimentation with different tools, because I really believe that fundamentally how software is built is changing. And I don't mean over 10 years, I mean over 18 months. It is just night and day. The cost of building is collapsing. The way we build is collapsing. The tools we use are changing.

I really take the approach that I should not build the, for example, engineering organization of January 2025. I should not build that team. I should think, cast forward five or 10 years, "What is this team actually going to look like? How are they going to operate? What is the world going to look like?" And work back into what do we need to do now to be world-class then? I'm really, really very much on the edge.

I think what's happening at the ends, at the leaf, is experimentation and pilots. I think there is increasing acknowledgement that, for example, coding copilots and coding agents have a place in the stack. There is a risk and compliance framework that can accept these as part of scaled engineering organizations. You can get over that hurdle, both from a security and an IP perspective, relatively well at this point, especially with the larger foundation model providers. Then it's, well, what the heck do I do with this thing and how does it change how we work?

My general approach has been to, one, allocate budget to it. I don't think you can experiment without money, so we put aside money for it. Even if it gets wasted, it's worthwhile because we learned. Two, name people accountable for every experiment and have them articulate what the outcome of that experiment would be. Then three, it's funny to say internally, but build in public. Which is we are very open with our experimentation in using these AI tools. We show the good, we show the bad. We have a Slack channel called Project Building with AI. People post, "I tried to have Cursor do this and it was amazing. I tried to have Devon do that and it failed. I tried to use V0 to do this and it was amazing. I tried to have ChatGPT do that and it failed".

That very open, and again intellectually honest assessment, allows us to identify opportunities to really transform how we build products here at LaunchDarkly. I think there will be increasing excitement. I am definitely driving it, both tops down and bottoms up. We're seeing real value, so there's a there there.

Shane Hastie: You mentioned building the team for three, five, 10 years.

Claire Vo: Yes.

Shane Hastie: What is that team going to be?

What will teams look like in the future? [17:38]

Claire Vo: Oh, I have so many opinions on it. My real hypothesis is that teams will largely be led by what I'm calling the AI-powered triple threat. Somebody who is fluent enough across technology, product, and design to actually take those three roles and collapse them into one, and be a singular leader for a team or a business unit. I think that model is really starting to show up in my mind and it'll be interesting to see if it actually shows up in organization charts. I think you will have teams that are combinations of humans and agents orchestrating across workflows. I think those teams will be building a lot of product.

I actually, in addition to being an AI maximalist, I'm an optimist. I think technology has generally only pushed us forward in the world. In building an amazing world with amazing product and amazing economic impact, and therefore amazing human impact. I think we'll see a lot of really, really neat things be built. But I think the shapes of the teams are going to look so different.

Shane Hastie: What do we need to do to help the people of today become those team members?

The need to invest in learning and development [18:44]

Claire Vo: One, we need to invest in learning and development. This is a real upskilling moment. It's really funny to take teams where folks have spent a tremendous amount of time in their academic training, and then their professional training. These are senior engineers, and staff engineers, and principle product managers who are so adept in what they do. And say, "Guess what? You are actually not going to know how to do your job in two years and I need to reskill you in how this is actually going to look". I do think there's this learning and development motion that needs to happen.

Then I think there is cultural things that, if you don't have, it will make it very hard for you to get here. Again, they're things that I have said are important before and I'll continue to say. You have to have a culture of experimentation. You have to be willing to try things. You have to have a willingness to fail, and admit where things are working and where they're not. Then you have to, I think in general, have an optimistic outlook. People can get very afraid about how changes will impact their jobs, their livelihoods. I think it is naive to ignore that and claim that that is not something that is on people's minds.

And at the same time, I think leaders have the opportunity to frame and build companies that have tremendous upside for the individuals that participate in them. Professional, personal, economic, just core satisfaction. But I don't think, if leaders ignore that piece of it, they will be very successful.

Shane Hastie: You mentioned reskill. You mentioned the culture. What are the skills?

New skills to learn [20:20]

Claire Vo: There's a couple things that I think about. One. There is actually, from a technical perspective, you were talking about engineering, understanding how these models operate, how they operate inside products, what their tool sets are. There's functionally this whole world of AI engineering. That I think is a skill that technically needs to be built in actually product, engineering, and design teams. That is just a whole new surface area of how we build software. It's very different.

The second skill is how do I build alongside copilots, agents, and AI-enabled tools? What's really interesting is it is muscle memory you have to break, not value you have to prove. What I mean by that is, a simple example. Everybody knows if they go to ChatGPT, they can accelerate some part of their day. I think people have generally accepted that, they have proven it to us all. They just forget to go to ChatGPT. They forget to make that part of their workflow because they're so used to, when I have a task to do, this is the place I go to do it. Then I'm 75% down the path and I'm almost done, so I'll just do it. I do think there's this workflow operations model that you really have to, somebody when I went to lunch called it whole team behavior modification. You really have to get the whole team to start doing handoffs and work in a very different way. I think that's pretty interesting.

Then the third thing is there are these tools themselves that have a learning curve. Let's just take, for example, one of these AI-powered IDEs like Cursor. People get bad outcomes from Cursor because they don't use Cursor well because they have not learned to use a conversational coding copilot well. There's setup you have to do. There's practices you have to do. I think there is actually learning the tools themselves enough to get value out of them that I also think is very important.

Shane Hastie: But those tools are changing so fast.

Claire Vo: Yes, but I feel like the skills are replicable across tools.

Shane Hastie: A lot of good stuff there. What haven't I asked you that I should have done?

Engineering crossing time and space [22:23]

Claire Vo: One of the things that I don't think we talked about is maybe how it's going to change geography and how teams are composed across timezones and what it means. You and I are speaking from quite a distance. Post-COVID, we've gone through this radical reimagining that what work looks like. I think that AI itself will have impacts on who you hire, where you hire, when they work, how they work.

I actually had a moment this morning. I'm pretty experimental and I use Cognition Labs' Devon copilot. This morning, it was so funny because it works synchronously. It does planning, and it's an agent so it works synchronously. It's working and clicking off tasks. But it is a copilot in some extent. Occasionally, Devon will ask me, "Hey, can you review this PR? Or I need this environment variable set up", all those sorts of things. I was thinking there's this challenge of this agent can work in infinite time space, and I myself am limited by my body.

I actually said to Devon this morning, it was so funny. I said, "Hey, just so you know, I'm going to go grab a cup of coffee. I'll be back later. If you need something, I'm not going to be here". It got my brain thinking that I think organizations are not prepared for how operationally this will cascade out across their orgs. They're not playing those game theory games of if 10% of my engineering workforce actually becomes an agent, do I need follow the sun coverage on my human engineering team to keep that agent team productive?

Maybe I push it really far and I think about the future more than other folks do. But if you're, for example, San Francisco-based or a US-based team, how you set up your team to operate alongside agents can be a competitive advantage and a strategic advantage that I don't know if enough technology leaders are thinking through. I know you're the people person, and soon enough you will be the people plus agent person, I'm presuming. Because you said, "I spend my time with the humans". You're going to spend your time with the humans and the prototype humans. But it is really something very interesting to think about, the human interactions both from a collaboration perspective, as just candidly, the operational perspective is something I think leaders need to consider.

Shane Hastie: Wow. Claire, thanks very much. If people want to continue the conversation, where do they find you?

Claire Vo: I am on X. And of course, I am on LinkedIn, Claire Vo.

Shane Hastie: Thank you so much.

Claire Vo: Thank you.

Mentioned:

• Claire Vo on LinkedIn and X

About the Author

Claire Vo

Claire Vo is the chief product and technology officer at LaunchDarkly. Before LaunchDarkly, Claire served as the Chief Product Officer at Color, where she developed the company's digital health platform and the supporting lab, clinical, and operational software. Prior to Color, Claire founded and served as CEO of Experiment Engine, which was later acquired by Optimizely. At Optimizely, she took on the role of CPO, where her responsibilities included scaling the enterprise experimentation platform, expanding product lines focused on developers and data, and leading technical partnerships and integrations.

Show moreShow less