1. Library
  2. Arrow Icon
  3. Triads: Product Marketing, Engineering, Design
JUN 29, 2022 - 47 MIN

Triads: Product Marketing, Engineering, Design

  • Product Management

In this Heavybit Speaker Series, Karishma Irani shares her biggest takeaway from working with LaunchDarkly's Product Delivery team -- 'Triads', where Engineering, Product, and Design partner on every project from planning through delivery.

  • Triads: Product Marketing, Engineering and Design
    • What, Why, and When?
    • Triads in Practice
    • Common Pitfalls
    • Tools of the Triad
  • Q&A
    • Implementing Effectively
    • Triads and Hiring
    • Super Triads
Download slides


Triads: Product Marketing, Engineering and Design

I'm Karishma Irani, I'm Head of Product at LaunchDarkly, and I am speaking to you today from Oakland, California. The topic that I'm about to speak about today, Triads, it is a topic that's extremely near and dear to me. It is something that we talk about on a daily basis, we practice this model on a daily basis and my salary is actually directly tied to the number of times I say triad in this presentation.

For those of you who are not familiar with LaunchDarkly, LaunchDarkly is a feature management tool that helps customers deliver, control and measure their software. Simply put, it's powered by feature flags and powerful feature targeting capabilities so you can actually control how to release your features and you can control your user's real time experiences using feature toggles and advanced targeting capabilities.

I've been here for about three years. I joined when the company was 70 people, I think I was the second PM and since then I have hired and built our entire PM organization which is now over 10 PMs.

Prior to LaunchDarkly I was at New Relic for about four years, where I helped launch and scale the infrastructure monitoring product to make it the second highest revenue generating product, as well as built the initial prototype of the Kubernetes monitoring tool. I've been in devtools for the majority of the last decade and this is an extremely exciting space for me.

As someone with a computer science degree who's always been excited with building tools for developers and working with developers, these products seem to draw me because you work with engineers that are extremely opinionated. They care nearly and dearly about what they are building because they're the ones that are going to be using these products.

Both at New Relic as well as LaunchDarkly, I've been fortunate to work on products that I and the teams, and my teams that built these products both use on a daily basis. And I will confess that that's a huge advantage because occasionally you'll have an angry engineer storming off to your desk going, "What the hell did we do and why did we ship this?" And those are the best parts of my days.

What, Why, and When?

Today I'm going to talk about what are triads, why do I believe in triads as a structure and when is it a good time for an organization, at what stage, to adopt the triad structure. Then we'll transition into what triads look like in practice, so what does this look like on a day to day basis and how does it impact your product development.

Then we'll transition to some common pitfalls, because I really hope that by the end of this talk, we're all convinced to go and give this a shot, give the triad structure a try. I do think it's important to keep in mind that it doesn't always work for every organization and there are some things that we've learnt through hard experiences that I want to share, that I hope all of you can avoid. Then finally, what are the tools for triad?

What exactly is a triad? This is called different things in a bunch of different companies, so we did not invent triads, it has been something that a lot of companies practice already. Atlassian does this, HashiCorp does this, I know we have listeners from both.

At LaunchDarkly, triads are the intersection of product management, design and engineering, and it is essentially a group of three people on every team or squad, as we call them, that's responsible for everything that team builds.

They're responsible for the outcomes of that team, the health of that team, the roadmap of that team, the vision, their collaboration with leadership, the customer satisfaction, all of it.

And so why exactly do we think triads are a good idea? Because if you think about it, the PM is trying to build something that's valuable to the business, as well as the customers, design is trying to build something that's usable and provides a great user experience, and engineering is trying to build something that's feasible, that's within the limits and still accomplishes the goals.

At the intersection of valuable, usable and feasible is when you have a triad. And so why triads? This sounds extremely complicated. Let me tell you a story about how teams I've previously been on or organizations I've previously been a part of have done this. As a PM, I've worked with design and engineering to ship every single feature I've ever shipped.

So what's new about triads, what's different about them? It's that in the past I would typically have a roadmap which lives in a secret Google Sheet of mine and I suddenly decide, "Okay, cool. We as a team need to build X." That's when I schedule a meeting with the designer, I download the motivation and inspiration of the project to the designer and work with them to whiteboard a few designs.

So after a few weeks of back and forth, we have some lo-fi mocks that were ready to hand off to engineering to start building. At that point we handed off to engineering and I disengage once development has started and engineering coordinates with the designer to clarify any questions that they have or request any resources or components that they need. Meanwhile, I as a PM am focused on the go-to-market.

Now, that's the risky part, that's the danger zone when engineering realizes that some of the things that I have aspired to build and that design has designed aren't necessarily feasible and so they end up building something that is different, or they're stuck in this endless loop of trying to deliver the thing that PM and design wants them to build.

Now, let's say we finally get this out the door and we ship it, who's responsible? Who's responsible for the quality of this feature? Who's responsible for making sure that this doesn't just end up as shelf filler, that it's actually usable and valuable for our customers?

And so the goal of triads is to ensure that when PM has ambitious goals, that design can make sure that we have a clean, usable, intuitive design for those things and engineering can break it down into small pieces to make sure that they deliver this incrementally and on time to our customers, and build it in a feasible way. Disclaimer: this is a PM's perspective. I think every feature that I propose is the Swiss Alps. I'm just kidding, but my engineering manager hates this line.

But yeah, this is essentially what a triad is and why I believe triads are important. But let's walk through a few reasons about why you should consider using triads.

The first is shared ownership leads to shared outcomes. When we think about planning for a feature and I ask you, "Who's planning this feature?" Your first intuition might be the PM, but are they really planning the entire feature? Are they planning how complex the design is? Are they planning the data model changes, the backward compatibility with the SDKs?

No. When we think about planning a feature, the entire triad, it requires a PM's perspective, it requires a designer's perspective and an engineering manager's perspective, or engineering lead's perspective.

So we believe that having shared ownership over the entire project, over the team's roadmap, over all of the resources and the vision leads to shared outcomes.

Engineering cares that the feature is usable by customers and has a good design. Design cares that this feature isn't just a well designed feature that isn't being used by anyone, and is actually adopted because it solves the product use case that the PM set out to manage. And so there you have it, we believe that shared ownership and when PM and design and engineering are placed in charge of ownership it leads to better outcomes.

The next reason is handoffs can be a bit rough, they can be deadly. In the example that I previously highlighted, I honestly thought that including engineering in the brainstorming sessions with me and design might be a waste of time for them.

However, in retrospect when I think about it, having an engineer in that team would've resulted in us course correcting pretty early on and taking into consideration the technical limitations, and would've probably shaved two to three weeks of course correction off that project.

It also leads to a process where engineering, design and PM are aligned on what needs to be built and they've all validated the proposal before the engineers actually start writing any code, and this avoids trash which we all know can impact engineering morale.

Another reason why I believe that triads work really well is an approach that I call It's Not A Democracy. I jokingly say that when I have triads where someone has a strong opinion and truly believes that a feature should be built in way X and not Y. In that case, having three people on a team allows for tie breakers. Turns out there is no way to not decide between two options when three people vote on it, and so we truly believe that in a triad you don't have to...

Not every person has to agree with every decision, but it definitely brings in three very important perspectives and doesn't provide a privileged position to either PM or engineering or design because we believe that all three of these functions are essential in building a strong product delivery organization.

In case you haven't already caught on, at LaunchDarkly we've coined the term Product Delivery to describe what a lot of organizations call product engineering, or just product, or application engineering or even EPD, engineering, product and design.

When we think about our team here, the team that we're building, we think about is as a service, we want it to be healthy, we want it to be stable, we want it to be scalable and reliable. And so we want to have PM and engineering and design have a seat at the table when we're planning an experience for our end users.

Then finally, we believe that product development is a team sport. My manager who is our SVP of Product and Engineering occasionally jokes about T shaped people, which is something that he learned from his prior experience at Atlassian. It is when someone has in depth knowledge about any one of these disciplines but is also broad enough that they can take into consideration the other two portions of the triad.

And so if you're an engineering manager, of course you need to know how to write code and of course you need to know how to manage people and an engineering team. However, you also need to have some sort of a design sense, a good design sense, and the ability to work with and appreciate the art of design.

Similarly, you also have to care about why a product roadmap matters and why you need to ship X over working on something that's just addressing tech debt, for example. Similarly, as a PM you have to care that you're not just constantly shipping features and being a feature factory, but instead you're building experiences that your customers want to adopt.

It's built on an engineering foundation that's strong and stable because your engineers have had the ability to address tech debt. So when you think about product development, the way we approach it is we treat it is as a team sport.

It's every person's responsibility to care about what we ship, and this occasionally results in engineering interns reaching out to me and saying, "Hey, I saw this design be presented in our Monday demo meeting and here's an idea of how my previous team built a similar feature, and we can make this change." And that happens almost every week and it's amazing.

So when you truly inspire everyone and make them believe that building good product is everyone's responsibility and everyone should deeply care about it, you're going to have people start thinking about the end user and start thinking about the product experience, and you're going to find a lot of great ideas everywhere.

This is also how we build product minded leaders, so ultimately your engineering manager or your designer is going to progress in their career to be a leader that ends up building great products. Whether they're a PM leader or a design leader, they need to know how to collaborate with leaders from these other disciplines and the way to do that is by building this muscle early on.

If you're still not convinced, here's an example. So I have to confess, this is something we recently planned and this is a screenshot of the LaunchDarkly application. Essentially, I'm looking at a feature flag here and I'm looking at the targeting page for that feature flag, and you can see that this is essentially what LaunchDarkly allows you to do.

You can say, "Hey, I want to turn on this experience for users that match an enterprise trial or an enterprise plan," and that's how you can control who sees what. But in this case, we had a triad that was considering adding the ability to discard changes.

Let's say I end up on a feature flag targeting page, I'm looking at what the current rules are for controlling the end user experience, and I make some edits. At that point I decide I actually don't want to make the edits and I want to go back. Previously the way you could do that is you just click outside, you click in the left nav, or you try closing the tab or you try refreshing, and the little browser warning pops up that says, "You have unsaved configuration changes. Are you sure you want to exit?"

This was a bit inelegant, we had a team that decided to build the ability to discard all changes so the user could stay on a page and not have to refresh or navigate away in order to reset their edits. Seems reasonable. When we went ahead and tried building this, the triad met and the PM had a vision for more of an undo button where if a user made, let's say three changes, and clicked on undo once it would just reset the last change, the most recent change. Seems reasonable, we're all used to using products and applications and tools that have undos and redos.

Then because engineering was part of the triad and part of that discussion, they realized that the way we have certain things structured, you couldn't just undo the most recent change. You'd have to undo all of the changes.

Eventually we figured out a way to do that, by building some additional functionality, but this is an example of where if PM and design would have just met and designed the feature alone, they would've ended up giving engineering something where discard change, they would've expected discard change to essentially undo the most recent change but that wouldn't have been possible and it would've reset all of the user's changes.

That is why having a triad where all three disciplines provide input, plan a feature together and agree on the outcome leads to one consistent user experience. And so we actually course corrected in probably the first planning meeting, but I wanted to use this as an example for just how the PM not being aware of a certain limitation in the way the API has been built or design not being on the same page about does the PM want to undo the most recent thing or all of the edits, et cetera?

It could have led to a really bad outcome, but having the entire triad in the room definitely helped.

So let's shift to when is a good time to adopt this triad structure, and I will admit I've only had the experience of working in a formal triad structure at LaunchDarkly. But my peers have had the privilege of working in triads elsewhere too, and so based on some crowd sourced information, basically what we figured out was if you're an early stage company, let's say you're a team of one or ten or twenty, you likely don't have a dedicated PM or a dedicated designer at that point.

I'll take, for example, our early LaunchDarkly team. While I wasn't here, our founder, John Kodumal, CTO and Founder, he's extremely design and product minded too, even though he's an engineer by craft. And so as he was building the first version of LaunchDarkly, he put on his PM and design hat and he played the role of a single person triad, and that's totally valid, that's absolutely reasonable at an early stage, where the founding team plays all three roles.

Then you think about a mid stage company, early to mid stage, still pretty early, and at that point which is where LaunchDarkly is at, we're at Series D, we're about 450 people. Defining triads can be extremely useful, it leads to high quality deliverables because you're still at the point where you're building your initial product. What I mean by initial product is it's the one that's going to be used by the first 500 or the first 1,000, 10,000 users.

So it's that high growth phase. During the hyper growth phase I definitely recommend having PM, engineering and design collaborate on everything you build to make sure it has all three disciplines factored in.

Then finally, if you're a larger company, I just threw in a large company there, but I am thinking let's say of 5,000 person company. At that point you might still decide to keep triads at the team level or at the squad level, which by the way, squads at LaunchDarkly are anywhere between four to ten engineers. At that point you might decide to keep triads but you might assign GMs who are responsible for one or more triads or the deliverables that come out of them.

At that point you essentially function at a mini CEO level, you have multiple CEOs across the organization who are responsible for different products or different experiences.

Triads in Practice

All right, so hopefully we understand what triads are, why I believe they're useful and when I suggest using them, so let's look at what triads look like in practice. You typically have two phases of a project, I'm obviously oversimplifying it here, but you have discovery and delivery.

Discovery is when you're deciding what you want to build, when you're planning it, and delivery is when you're building it, testing it, you're doing GTM, your Go To Market strategy and so on. You might even decide to phase it out, but I digress. Coming back to it, you have two high level phases, you have discovery and delivery.

At LaunchDarkly, in addition to practicing triads we practice what's, in my opinion, the main benefit of a triad which is the ability to do dual track Agile. So I know it sounds like a bunch of mumbo jumbo, but dual track Agile is basically where your triad is validating ideas by doing discovery relatively quickly.

So instead of deciding, "I want to build X," spending three months planning X and then handing it to your team, you're time boxing your discovery phase as a triad and you're doing discovery on idea two while your team is building idea one. Then you do discovery and idea three and four, and invalidate them as good ideas.

Then move onto five and six, which you're like, "Yeah, these are reasonable." And you have mocks that are design mocks, that are about 60% of the way there. You have product spec and scope that's been validated by the engineering lead, and of course you have engineering input from the very beginning because of the triad structure.

At that point, the way triad versus the rest of the squad or team that consists of your engineers that are actually going to build the feature, the way that looks is like this, where while your team is building idea one, your triad is doing discovery on idea two.

Then when the team starts building idea two, presumably a larger project, your triad's had the opportunity to invalidate two ideas and start discovery on idea five and so on. What I'm trying to visually represent here is that triads break the typical, the conventional Waterfall model where PM plans something, PM picks an idea on the roadmap, works with design, plans it, then hands it off to engineering and if it's invalid, engineering has to send PM and design back to the drawing board.

It creates this spirit where engineering isn't necessarily working on really exciting things, and it creates trash of course. And so in this dual track Agile world, because you get input early on you know that the ideas are feasible, they're valuable and they're usable, so you can quickly plan them, do discovery and then hand them over to your teams so they can start building it.

Common Pitfalls

So that's what triads look like. Sounds pretty great, but what are some common pitfalls? I assure you I have run into every single one of these, so I want to share them with you so hopefully you can avoid them.

The first one is need more discovery. This isn't necessarily design discovery or engineering discovery, this is more, "We as a triad need to do discovery on this project. We need more time." So if you go back and look at this, let's say idea two took extremely long to actually discover and complete discovery on.

That creates a gap in the team's workload and the engineers are waiting for the triad to complete discovery. So similar to every project where you typically have milestones and you have weeks planned and you provide some kind of estimate and you say, "Hey, this project is going to take four weeks."

Similar to that, I highly recommend time boxing your discovery and typically having it end right before engineering is done with the current project so that they have the discovery work that you've completed to start work on the next project.

The next pitfall is the too nice, indecision state. Okay, I'll admit I haven't run into this one because I'm not too nice. But the too nice, indecision state is when you have three members and they're not agreeing but no one actually wants to run into any conflict or disagree with the other person.

So even though, let's say a PM thinks that the designs aren't good, I'm just going to pick an example. PM might not want to say that to design, and so they might just end up talking around it or not actually addressing the problem. Or if engineering says, "This is going to take eight weeks," and design thinks that's bizarre, design doesn't actually want to say it.

So I personally believe, and this is something we teach every new triad member and actually every new team member at LaunchDarkly, healthy challenging and healthy push and pull and back and forth is actually a critical component of a good, healthy team. Again, I want to put the emphasis on it being constructive. You have to be respectful of your peer, you can't just say, "Hey, I think this isn't great."

You need to provide a better suggestion or you need to describe why you think it's not great. So making sure that you have the foundation, you have the trust and the visibility to break out of the too nice indecision state.

The next one is stuck in process hell. Okay, so I described the triad structure and how that essentially requires engineering, PM and design to work together all the way from the start of a project to the end. While that sounds great, sometimes it can lead to process overkill.

What I mean by that is, let's say, there's a straightforward project which basically requires executing on an engineering task. You don't need to schedule a triad meeting and have design be there and product be there just for the sake of it. If you believe, if you truly believe and your triad agrees that this is a pretty straightforward problem to solve, you can absolutely circumvent the triad processes or the conventional triad processes in order to make progress and favor velocity in that situation.

Then finally, triad member unavailable. In retrospect, I feel pretty stupid about this one. But I remember being in a situation where I pushed out discovery for a couple weeks because I said, "Hey, the designer is out on vacation." The whole point of triads is that if any one member of the triad is unavailable for any reason, you can still continue making progress as a team, and that's because you have the entire context, you have the shared context from the beginning.

I have the same context that my designer did, I have the same motivations, the same understanding of the project, the same understanding of the goals of that research. And so I didn't actually need the designer there, or need to be blocked on the designer in order to proceed.

Similarly, there are situations where I have PMs that aren't available and design and engineering just hash out the project and you have design or the engineering manager put on the PM hat and think about breaking it out in phases and scoping it. The whole point of triads is every person has a shared context and so you can go ahead and make progress even if any one member is unavailable.

Tools of the Triad

All right, so what are some helpful tools of the triad? I'm going to provide a disclaimer and say a few of these things are extremely specific to LaunchDarkly, but I didn't know them before I joined LaunchDarkly and I would definitely use some of these in any organization or any team that I started next. So similarly, I hope you can benefit from using some of these.

The first is collaboration. Collaboration is the main thing when you think about a triad. If you force a PM and engineering leader and designer who don't want to work together, who don't respect each other's disciplines or roles and who don't understand what the purpose, what the goals of a triad are or what the benefits of a triad structure are, they're not going to work well together. You're just going to find three grumpy people who schedule a bunch of meetings and keep disagreeing with each other.

And so collaboration is the primary tool of the triad. Whenever you're in doubt, whenever you feel like you're stuck on a decision or any of the other triad members aren't making progress on their specific focus areas, just meet and collaborate and hash it out.

I've been a PM lead on a project where I just didn't know how to break it up into smaller phases, but I knew I couldn't wait for 14 weeks in order to get something in front of customers. And so instead, I considered going into a PM cave and thinking about it for a few hours, but I just scheduled a call with my engineering lead and designer and they helped me out, and that was extremely useful. Again, they had a shared context at that point, so I didn't have to then have a second meeting to inform them about the phases so that was extremely useful.

Then most importantly, just enough process. Triads are great, triads are helpful, but the point of a triad is more about mindset and collaboration and each discipline providing input on making progress and it's less about following along a more stringent process where you need every person in every meeting to help make decisions. That is not how triads should be operated, so make the process work for you and not the other way around.

Let's take a look at a small project. A small project is what we define as one to three weeks at LaunchDarkly. This typically includes feature durations, UI/UX improvements like the one I just showed around discarding changes, discarding edits before saving them, or hackathons. We do them every quarter at LaunchDarkly.

The typically way a triad functions or the typical process that triads follow in order to make progress on small projects include problem definition. This is an extremely and somehow the most overlooked and underestimated part of the project planning process. I can not emphasize enough how important it is, even when it seems redundant, for the triad to meet and agree and say out loud what they believe the problem that they're trying to solve is.

I think at least I fall into the camp where, when I see a problem, I jump into solution mode and I've had to train myself back from not doing that and actually focusing on a problem, drawing a box around it and making sure that I have the problem scoped and also defining what I won't be addressing as part of that problem. That's really helped keep my entire team and triad on the same page about how we're trying to benefit the customer.

Solution brainstorming. Sometimes this includes engineering bringing solutions to the table, sometimes it's PM proposing different ways in which we can solve it, and sometimes it includes whiteboarding sessions where design will join, share their screen with an iPad and a pen and draw stuff as the PM and engineer describe things and they work together on what they expect the flow to be.

Milestones, which means engineering milestones, so figuring out how many weeks the project is going to take and what you're going to work on week over week.

Then finally go to market, which may include a blog post, an end product announcement, an email to your customers, a press release. Just anything. So this is what a small project looks like when a triad works together.

However, when a triad works together on a larger project, which we at LaunchDarkly consider things like annual borders, new features, or even new product launches, these are what we consider large projects. In these projects I consider the triad adopt a few more tools, the first being data gathering.

This could be a formal customer research project where you go interview, have calls, talk to a handful of customers, existing or prospects, or also dig through your support tickets, dig through feature requests from your revenue team. Look at the data for how your customers are using your product today and you'd be surprised to find ways in which the data tells a really clear story.

So one of our recent features was inspired by tracking instrumentation on how many times a customer does Command F to search for something on one of our pages, and that led to a really cool feature idea. So again, data gathering is an extremely important process, but the reason I didn't include in the small project slide which is the previous one, is because it could potentially slow you down in those phases.

In all cases I suggest doing some sort of data gathering, but for large projects I suggest having it be an explicit phase of the triad.

The next is problem definition followed by solution brainstorming, which we already reviewed. In this case, assuming it's a large project that has designs associated with it, or let's say it's a database migration and you might have tech stacks with phases and risk plans. In those cases, that would be what you critique, but in this case you do design crits for looking at what the triad whiteboarded and the mocks that they came up with.

Then finally you might share this with your leadership team. We do this through a process called Demo Trust, which you can read about. Atlassian actually has a great blog around this. Demo Trusts are a quick and relatively informal way of meeting with your leadership team and having the triad present. The triad metaphorically stands up in front of leadership and presents what they're about to work on and shares it with leadership and asks for any input or feedback and just the general thumbs up.

Milestones, we covered this already. Blitz. Blitzes are my favorite thing. Blitz is essentially what's called testing or bug bashing at other companies. We do this by using LaunchDarkly to turn the feature on in production just for our account, just for ourselves. Again, that's one of the benefits of using LaunchDarkly which is you can QA in production.

So definitely recommend doing this, I have found a lot of things which I would not have caught in staging or pre prod just by queuing in production. Blitzing is the process where you and your team do that. It could also just be a triad. Then if it's a large project which includes a lot of validation phases, you might want to do a beta before you do a larger production release with GDM.

We've talked about where triads fit into the product delivery organization, the tools of a triad, common pitfalls to avoid, why should we have triads, when should we adopt triads, when do we think we're going to grow out of them, et cetera. But the most important takeaway is all software teams should ask themselves two questions, and I know we do this every week. It's, "Are we delivering at the right pace?" And, "Are we delivering the right things?"

When you put these two things together, you get a triad with high velocity that's using the right processes to arrive at the right solution for customers. That's all I have for you today. Thanks for watching.


What are some processes that teams can start to implement to effectively transition into Triads?

So the one thing I recommend when a company is transitioning from, let's say a founder playing all three of those roles, or a head of engineering and head of product playing those roles, then transitioning into a triad structure is to continue playing that for a little bit longer.

The one mistake that I have definitely made previously is when I got to LaunchDarkly, I believe we had one designer back then, and so it was obviously they were an extremely well resourced and they were busy working on other important projects.

I had an onboarding project. So I worked with my engineering counterpart who had been playing all three of the roles of the triad and they basically explained how they would walk through the product decisions, what design trade offs they would make, and it wasn't just like, "Cool, Karishma. As you're the product manager, let me take a step back and suddenly stop having product opinions." I obviously think there's a fine balance there, there's a fine white line to walk and you can obviously end up diminishing trust and the sense of autonomy if you do that for too long.

However, going back to John's example, even today if I am brainstorming an idea with him, he's not just up here, he's everywhere actually. I can say this because he's not watching this. But John will somehow respond to an idea with great input for how we can approach that from a good design standpoint, how we can GTM that to get customers excited about it. And so that muscle never really goes away if you've been playing that role for a while. It's about finding the right way to channel it, and so that would be my advice.

Has the Triad structure changed your approach to hiring? How do candidates react to it?

Yeah, that's a great question. What still strikes me as funny is when I have a phone screen with a candidate, with a prospective PM candidate and I describe the triad structure to them, I'm usually met with a, "That sounds pretty obvious. Why are you describing it to me like a new, groundbreaking concept? That's how we work. I work with engineering today, I work with design today."

Yes, that's true. But when you think about a triad, it's not just, "Has engineering provided an opinion? Has design designed something? Have you checked all three boxes?" It's about all three disciplines and

all three individuals meshing in to form one entity that's responsible for how that project shapes out to be, and responsible for the outcome, the customer outcome, the business outcome.

And so when I usually describe this to candidates they go, "Yeah, that sounds relatively obvious." And then I've had PMs who've joined my team in the last year or two years who've confessed that they definitely didn't fully internalize what I meant by triads when I explained it, which actually might just be feedback for me describing it better.

However, the way it's impacted our hiring process is it's definitely made us look for or be picky about someone who doesn't just care about being the best engineer or the best PM or just an amazing 10X designer.

We care about having someone who actually cares about building good product, which means having an understanding of all three disciplines even if you don't have formal experience in it, or just having the desire to collaborate and learn from your peers in these parts.

So when we do an engineering interview, it's not just core challenge, technical questions, pass. That engineer meets with PMs on a team and PMs ask them about what are the kinds of things that they're excited to work on and what are features that bore them, or what are engineering tasks that bore them.

Similarly, design will meet with them, show them a design and ask them questions about what you think, and usually we get confused engineers who are like, "Why am I doing a design crit?" The point is there is no right answer, is actually the secret in order.

It's not unusual that if you were an engineer at LaunchDarkly a designer would walk up to you and say, "Hey, you're an engineer at LaunchDarkly. You use the tool every day. I'm working on this design, what do you think?" And you just have to have a desire to collaborate, provide input, ask the right questions and care about the ultimate experience we ship.

Is there a tendency to apply similar structures to other levels of the org? Do the heads of these functions serve as Super Triads?

The short answer is yes. When you started asking me that question, I thought that you were going to ask me if other parts of the organization like revenue or marketing have triads, and I was a little confused. But now your question makes sense. Yes, basically the way we think about triads isn't just at the squad level. It is at every level, every tier of the product delivery organization.

Like I mentioned, our CTO and Cofounder, John Kodumal, is kind of all three functions in one person and that's definitely benefited me becoming a better PM. It's cut me some slack in some projects where I'm like, "I don't have the time for that," and he'll go ahead and help me out.

But when we think about the folks that report to John, it's a head of product, that's me, a head of engineering and a head of design who actually starts on our team on Monday and I'm very excited about her joining. So yes, we meet as what we call a leadership triad team and we talk about organizational triad things like people, processes, project velocity, outcomes on previously shipped projects and just the general health and velocity of our product delivery organization.

Again, similar to me hoping that a PM doesn't independently and autonomously make a decision on a project without consulting the EM and designer, I too would not introduce a change to our product delivery organization even if I think it's just a PM process change without consulting my head of design and head of engineering.