Episode 17 | Building Product Delivery Organizations with Jonathan Nolen from LaunchDarkly

Eiso: [00:00:00] Welcome to Developing Leadership the podcast where I, Eiso Kant, and my co-host Jason Warner share our thoughts and lessons learned on engineering leadership through the years. 

Today we welcome Jonathan Nolen, Senior VP of Engineering and Product at LaunchDarkly, the scalable feature flag and toggle management tool for modern enterprises. Jonathan joins us to talk about his hundred plus people product delivery team. A term coined by the company where engineering product and design come together. We spoke about what this three function team means for engineering organizations and how you can build a culture of shared responsibility throughout this structure.

We also shared our advice as engineering leaders on building the capabilities and measuring the impact of this integrated function. Today, I want to give a special shout out to BenEIsBest for leaving a review on Apple Podcast titled "Jason Warner MVP." We really appreciate it. So if you enjoyed the episode, leave a review on Apple Podcast or Spotify and share it with another engineering leader. 

As always this episode comes with accompanying show notes featuring our favorite moments from the chat and [00:01:00] a deep dive into today's topics. Find them at developingleadership.co or linked in the description. 

Hi, everyone. We're back again with another episode of Developing Leadership. Jason and I have a special guest with us today. Jonathan Nolen who is currently the SVP of Engineering and Product at LaunchDarkly. One of my personal favorite companies which is why I'm excited to have you on board, Jonathan. 

You were at Atlassian for about 12 years, and then, you joined LaunchDarkly when, when the engineering org was less than 10 people. Tell us a little bit about yourself and, and what made you decide to make that shift?

Jonathan: Sure thing. First of all, thanks so much for having me. It's, it's great to be here with you today. I've really sort of chosen my career path based on the products that I have loved that I have seen be successful and that have really spoken to me and the teams that I've been a part of. So way back [00:02:00] in 2002, I was part of a small team building a website, rebuilding a website, in fact, and we were all really dissatisfied with the tools that we had to work with and I managed to discover Jira at some point.

And I found it over the weekend. I bought it on my credit card. I installed it under a desk and came, and came on Monday morning and started using it. Within months it had taken over the entire company that I was at and every development team was now using Jira and, and was vastly more efficient for it. About 6 to 12 months later, we did the same thing with Confluence. We bought it. We had it, we, we were using in our, in our small team of about 10. And within months, the entire company had transformed around this tool. And, and I knew that there was something amazing there.

And so, I got in touch with Atlassian and found an opportunity and joined Atlassian in 2005 when they were less than 30 people. And I was there, as you said over 12 years and pursued a whole bunch of different roles in both engineering and product over that time, but it was all about trying to make sure that every team was able to experience that same transformation of collaboration [00:03:00] that we had seen, you know, back on my team.

Around 2014 or 2015, my team at Atlassian, obviously, you know, a very small part of Atlassian at that point, but we were working on a new product and we realized that we needed a feature finding solution. It wasn't even called future management at that point, but feature finding solution. And we knew about LaunchDarkly because it had been founded by a former Atlassian and we started using it.

And it was transformative for the team that we were on. It allowed us to move at a pace and with a level of risk that was just unheard of in the rest of the company, and frankly, in my whole career. And within a matter of months it spread to every other team inside Atlassian and I saw that transformation and it's one of those things that once you've experienced it, you would, you would never go back to trying to build any software product without feature flagging and recognizing the opportunity there.

I thought Atlassian had grown a lot by that point and I was thinking already about, "Well, it might be fun to go do something smaller again." and LaunchDarkly I [00:04:00] thought was just such a, a fundamental and important tool that every development team worth their salt is going to need over the next 10 years. And fortunately, I had an opportunity to join them at a really early stage. I'm about four years into that journey right now and we're, we're just scratching the surface on that mission, but in the same way that we think every team or that at Atlassian we thought every team could benefit from improved cooperation. I'm convinced that every team can benefit from feature management and we're gonna, we're gonna get that tool in everybody's hands over the coming decade.

Eiso: That's fantastic. Tell us a little bit about the size of, of your product engineering org today and what does it look like so people listening can, can use that as context for our conversation. 

Jonathan: Sure. So the company overall is, uh, I think we just passed 400 people. The product delivery organization which is sort of my area, um, and that is a combination of engineering, product and design. We're about 125 people.

Eiso: You just use the word that I instantly fell in love with but I haven't heard anybody use in a long time is product delivery organization. [00:05:00] You're not calling it product engineering, not engineering and product and design. Talk to me a little bit about the philosophy of you as SVP of a product delivery org and, and why is it called that way and what does that actually mean in practice?

Jonathan: Sure. So, and admittedly it was, it was sort of a, a term that I think we made up. I'm not sure that I've heard it elsewhere either. But we wanted to make sure that we were giving equal weight and importance to the three aspects of the triad and I'm sure we'll get a chance to talk about that concept a little bit more later. But product, engineering, design, we didn't want to, we did not want to privilege anyone over the other two and we wanted to make sure everybody had an equal voice, an equal seat at the table.

And so, we were trying to find a term that could encompass all that. And we also wanted to focus people on what we were really doing, which was delivering a service. Many, many teams over the last 10 years have, have gone through this transition. We certainly went through it at Atlassian, in shifting our mindset from building software and even shipping software to delivering a [00:06:00] service, and LaunchDarkly, of course, was a, you know, SaaS company from the very beginning.

We've always been about delivering service and there's a whole new class of behaviors and tactics and tools and techniques that you need to do that well that I didn't have to worry about 15 years ago. Feature management being a prime example. But trying to orient the team and, and realize that our job here is not to write software, it is to deliver software in production to customers so they get value out of it. And so, that's sort of I guess why, why the word delivery is in, is in our organization name.

Eiso: I love that. Jason, you yourself as well found yourself responsible for engineering product and design and, and a couple other functions as well over at GitHub. What was the, the response at a company much larger in size where, where you made that decision and how did that change over the years?

Jason: Sure. Yeah. So at GitHub when I joined, I had product, engineering, design, and a host of other functions as well. And it was a little bit of a, let's just [00:07:00] say, a, a conversation when I was going into the interview process saying, "Hey, I want, I want to have product as well." And there are some GitHub specific reasons for that, but also just, in general, where I thought you had to take the product, it needed one voice. One voice at the top. One voice to push. One voice to have accountability and expectations.

And I thought it was incredibly important. And we kept that model, you know, for two years up to acquisition. And then, post-acquisition I still ran product, engineering, and design for a little while. And then eventually we split off the functions into, we brought in a product leader, we elevated a design leader. And then, I kept engineering. And then, eventually towards the end of my tenure I moved off of engineering as well and we brought in a new engineering leader.

And we called that EPD as most people do, engineering, product, and design, and eventually all three of those reported up to the CEO. So those, that was kind of the evolution of that. In retrospect in my opinion, [00:08:00] it was a mistake to break up the EPD's from one person who was not the CEO into the CEO. And it's not, this is not a conversation about me. I think it has to do more with what the organization's expectations are and who they feel accountable to. And I thought that it would have been a mistake to do that that way and I think in retrospect in some ways it turned out to be that case from an operations perspective.

Eiso: I'm gonna switch back and forth between both of you right now with a question that I can imagine is on quite a few people's minds which is GitHub, LaunchDarkly, the engineer is also the user. So having EPD be one cohesive unit and I really like the term product delivery team as one. Is that uniquely possible or uniquely preferred, because you're building a product where engineering is the user as well or is this something, Jonathan, that you imagine every engineering or every company in the world should be following? And if so, why or why not?

Jonathan: I actually think [00:09:00] these are sort of orthogonal concerns. So first of all, it is certainly true that we benefit from being developers building a developer tool, actually using the tool that we work on every day. That's a huge advantage for us. It's a shortcut in a lot of ways. And I experienced the same thing at Atlassian and I can imagine GitHub had a similar experience. So I don't want to discount that advantage, but I think that's, that advantage is not, it's really quite separate from the choice of how do we want to structure the responsibility between engineering, product, and design? And I think frankly, any company would benefit from that organization. 

You know, I really appreciate what Jason had to say and the thought process he, he went through to do the same thing at GitHub, because, honestly, those three functions cannot accomplish anything on their own. They have to work together. They can only be successful together. And so, by putting them on the same team, in the same reporting line with the same goals, and the same sort of executive sponsorship. I think it can [00:10:00] circumvent a lot of acrimony or finger-pointing or, you know, it, it aligns everybody and points in the same direction towards the same goal. And so, I think, you know, even if I were to go start another company in a totally different space, I would do the same 

thing. 

Jason: This could be a long topic. So I feel a couple of things on this. One, if you asked someone who came up through the engineering ranks, this question, you'll get the answer that they should be the same organization to the same person. But if you ask someone who came up through the product design, you're likely to get a different answer. And the reason why is that what Jonathan just said is that at the end of the day, engineering, they all need to work together, but at the end of the line is engineering and a lot of the delivery of these things and they feel the pain the most.

And so, when you look at how to fix this. You say, "Hey, we actually need to be one cohesive organization and unit." But everyone upstream from that pain says, "Why? It's working for us. "But we're not delivering." "Well, [00:11:00] that's your problem." but the engineering person understands where the pain is.

 It's kind of the same thing as you don't go ask the application engineering team how to make the system more stable, you talk to the infrastructure team, because they're the last in the line about what's, where the stability's coming from and the issues. And then, you talk once you know what those issues are to the application engineering team about changes that might need to be made in that. 

And let me flip it around another way too. I do think in, at least, GitHub specific case it was only possible, because it was a developer oriented product. I doubt you're going to make these, these decisions with an engineering oriented leader like myself at an Uber, as an example. But it is rather common these days for a CPO title to have engineering and product and design together, but it's not very common for a CTO title to have them at the moment.

And again, I think those things will change over time, but, you know, I think the way that organizations currently think about these things is still dated. [00:12:00] It has to do with experiences they have as they grow and where the market is, but also just point blank, you know, you know my feeling on this Eiso. We've said this many times. Leaders in general in the industry are few and far between. Like true, actual, real leaders. Not mechanics, not people who just run a function, but leaders. So it's hard to find someone who's capable of running all of those functions at once.

Eiso: So at this point, I'm going to try to put you on the spot a little bit here, Jonathan. Given what Jason just said, right? True leaders are, are far and few between to have the capabilities of really running this, this integrated function. 

What do you believe has uniquely positioned you, to be successful at running this function? And what are some of the things that you would pass on to somebody who aspires to be that leader who, who really brings engineering, product and design together?

Jonathan: That, that is a fantastic question. So I mean I'll, I'll start by saying that as a leader, and, and actually [00:13:00] sort of throughout my career, I have always been sort of broad rather than deep. And so, I have, I've had, experiences in and learned about and, have have opinions about product and engineering and design. But most of all, I've had opinions about what we need to do for the product and the customer and how do, you know, what, what are the, what are the resources we even have need to make that thing happen?

Having some, some vision and some opinion across all three of those functions it's, it has been helpful to me. And then, also, and then the flip side of that is recognizing the place where I need depth and the places where I need help and the places where I need to fill in my gaps and finding really, really great people who can do all those things. 

I worked with the, the head of… I mean, I guess, he's the chief design officer now at Atlassian. A guy named Jurgen, and he introduced me to this concept that was not novel to him, but, but of a, of a T-shaped person. And so, we, I think look for that also in our leadership ranks and [00:14:00] trying to find people who are very good at one thing, but also have some vision and some opinion about the things adjacent to them. And so, if you were, if you were going to be a really successful engineering leader at LaunchDarkly, you have to have some product opinions, you have to have some sense of how you, you want the product to work and how, what you think it could do, and be able to discuss and debate those things intelligently with all the people around you and just bring some opinions to bear.

And in, in the same way if you are a product manager at LaunchDarkly, you have to have strong opinions about how things should work, but you have to have enough depth in how engineering teams function and how they plan and, and how they prioritize to be able to, to be an equal part of that conversation with your engineering counterpart. And so, we really look for people who have that kind of breadth and if you sort of get enough overlapping teaching people, you can build a really amazing team.

Jason: I couldn't endorse that enough. I think I'm gonna, what I'm gonna say here is that, it's unique in some ways but the T-shaped people are incredibly [00:15:00] important. But when you look back or, or particularly when I look back and I think it was possible, because I was not exclusively an engineering leader. I had broad applicability. I had, I wanted to know what the customers were doing. It was different than what we might classi- the industry might classically define as an engineering VP or an engineering leader.

And in fact, when people outside of the sphere talk to people who I think have done these disciplines and I look more like a CPO maybe, but even more like a CEO, because you think about the business first or you think about the, the products and the customers in a certain way. And in fact, you know, up until GitHub that I was held back in some ways, because I had depth, but I had way more breadth as well than what people would classically look for in an engineering director or an engineering VP, at the time, which I think is changing. But it was interesting how it held me back to some degree at certain times too, because then they would say, "Hey, you should go work in marketing or sales or product or any of those [00:16:00] other, but why are you in engineering doing that?"

But I think that's the, the challenge is that engineering needs that too, engineering needs T-shaped people. They need differently T-shaped people as EPD or product delivery they need T-shaped people that overlap with each other.

Jonathan: Well said.

Eiso: Couldn't agree more. And, and so, Jonathan, very practically for somebody who this idea is resonating with, right? The notion of product delivery, T-shaped people, talk to us a little bit about how that's translated into how your organization looks like. Who's at what level? How are you running meetings? Can we imagine, you know, cross-functional all the way down to, to the team level or how is this currently structured?

Jonathan: Sure. I'll answer this in I think the two most important things that we have done. The first is structural. We have borrowed from Atlassian, and I'm sure a lot of other places as well, the concept of the triad, different people call it different things in different organizations. I've heard it be called triumvirate at some point, which I, which I love as a Roman history nerd, but ideally at every level of the [00:17:00] organization, we have a, product leader, an engineering leader, and a design leader.

So starting the squad, that's our unit of scale. It's usually six to eight engineers. And then, and there are, those three people responsible for that squad, for their goals, for the roadmap, for their impact, for every decision that gets made. And then, all the way up the chain we try, we try to build those triad counterparts as, as rigorously as we can.

Now, in practice, no organization is static and you, you grow and sort of branch off new nodes at different times and there are always fewer product managers and designers than there are, are engineers. And so, it's always moving a little bit as there are sometimes places where there's not a clear counterpart. But we basically treat those as like bugs to solve or things to grow out of rather than the ideal state.

So once you have that triad, then we work really hard to instill a sense of shared responsibility. And this is, this is actually one of the more controversial things that I personally believe, because there is a very strong culture and a whole bunch of technology organizations of the directly [00:18:00] responsible individual. There are many places where that actually does apply and, and we use that concept at LaunchDarkly, but at the squad level in, in the product delivery organization, at the triad level, we try to make the triad responsible.

So from the very beginning of an idea, you have the engineer and the product manager and designer in the room trying to make the decisions. We try to make sure, and, and we do that to make sure that everybody has as much context as possible about the problem we're trying to solve from the earliest research phase. So you were sharing all your customer conversations, you're sharing every bit of research you're doing. You are the engineers in the room, the designs are, are being whiteboarded and debated.

And again, shortcut we do, it does help that we are building a developer tool, but it is not necessary for that to be the case. Every time the, the squad presents or reports on their results or they, they share, you know, they share. We try to make sure all three of those people are metaphorically standing in front of the, of the company or the leadership team saying, "Here's what we have done."

And, [00:19:00] you know, my ideal for the function of that organization is that if the engineering manager is, uh, you know, sick for a week, then the product manager can step in and provide the direction the team needs to keep them running smoothly because they have enough contacts or if the product managers have a customer calls for a week or a conference or whatever, the engineering manager can make sure the right decisions are made so that the team can move forward, because they have enough context. And you can never quite hit that ideal, but like we get as close as we possibly can.

So that's the structural thing that we've built in the team and the good news is, you know, it just scales by adding more layers. So we're adding, this year we're adding more folks at the middle layer who have a triad responsible for multiple squads who are pushing all, you know, towards one goal.

The other thing that we have done is really about the hiring and progression of the people on the team, particularly on the engineers. The two sort of philosophies I have here is that we look for as many, basically product engineers as possible. There's this fantastic talk that, uh, one of my former colleagues named Sharif gave [00:20:00] about what is a product engineer. But it's, but basically it's a thing that is just product instinct, product sense, product gene, whatever you want to call it. But people who understand why we are building what we're building or, or even care to understand to try to find that out and have, the more of those people you have on the team, doesn't have to be everybody, but the more of them you have on the team the more likely that you're all gonna end up pushing in the right direction.

So we look for that when we interview and we also, we try to highlight that in our current progressions and, and in my first year, I had to build out a career ladder for engineering. Actually, really for all product delivery at LaunchDarkly and it evolves all the time. But the foundational principle that I've tried to, I try to build into that was that we measure people based on the impact they have on the product and the business. And that as you sort of move your way up in that ladder, we expect you to understand more of the why. We expect you to be able to lead. We expect you to be able to articulate the value of why we're doing this thing, what customers actually want.

And, and that's for everybody. It is not sufficient to be incredibly technically [00:21:00] talented, but, you know, just execute orders. We want you to actually understand why, why we're doing a thing, and, and honestly to have opinions and challenge, right? Like you should know enough that if you think we're going in the wrong direction or wasting our time or building a thing in the wrong way, you should feel confident to say, and saying, "Hey, no. I don't want to, I don't want to, you know, throw my valuable talent after a bad idea. We should be doing X instead." And then, work that out your, with your triad or squad.

So those are, those are two things that we try to build in to help this whole process work smoothly.

Eiso: You touched upon something you said on your career progression ladder, you put a lot of emphasis on the impact on product in the business. Impact does not necessarily mean effort, impact does not necessarily even always mean technical skill. 

How are you currently communicating this with the engineering org? What are you using to define what impact really means? And, and in practice does this mean that, you know, a team that is placing a bet on, on building a product feature that might be, [00:22:00] let's call it technically less challenging than a team that's placing a bet on an internal facing infrastructure feature is, is finding themselves with very different impacts and maybe one will be considered far more successful? And how do you, how do you measure impact, uh, is part of my question as well when it's maybe easy when you build an application but can be very challenging when your internal customer, when your customer is an internal stakeholder?

Jonathan:  Well this does require quite a bit of discipline of us, as leaders, to have the right definition of impact and think broadly about it. It's really easy to fall into the trap of like what is visible is impactful and what's invisible is not impactful, but like that is, that is a really damaging way to think about it. One of the things that we talk about a lot and I guess one of the ways that you can see this manifest is that it's going back to the thing I said earlier about deliveries. Like we are running a service and I, you know, I have been part of products in the past that had great features and great ideas and [00:23:00] great design and great experience and no stability and they died. So it is just as impactful to make sure that we are scaling, that we are, that we are healthy, that we are available, that we're able to handle the growth that's coming with us, coming to us that we're investing in, the platform and the architecture that's going to enable the rest of the team to be faster. All those things are impact.

Because one of the reasons that I kind of like this whole concept is that by saying, "Look, we value impact." It forces everybody and every team to at least think about. Like, "Well, how do I articulate the impact of what I am trying to build?" And as long as, you know, as long as we, we don't fall into the trap of thinking like visible versus invisi- invisible, the squad or the, or the individual or whoever can say like, "I am working on this thing to accomplish this goal that would be beneficial, and so I can at least, you know, I can give one sentence why this is impactful." and if I can't do that, then that's a pretty good question I should maybe be spending my time elsewhere.

Eiso: That, that makes a ton of sense. So Jonathan, throughout these four years, you've gone under an immense amount of growth and, [00:24:00] and I can imagine quite a, quite a bit more growth to come. Talk to us a little bit about the, the challenges of scaling this philosophy and, and approach as you're growing.

Jonathan: Honestly, the, the most difficult thing about this has been the transition from in-person to remote work. It forced us to, the first two years when we were, when we were all in the office together, we were growing at a healthy, at a healthy pace and we were bringing these people into the team and we were onboarding and acclimating them pretty well and we were able to lead by example in many cases. And you could observe the way other people around you work. You could observe the way other squads worked and, you could pick things up that way.

And through any company's life as you grow, eventually that breaks down and you, and, and you gradually invest in more and more like rigor and process and documentation all sort of stuff. But when we suddenly all went home in March of 2020, it's like we, had to leap forward a couple years in, in the way that we invest in process. And it has taken us quite a while actually to catch up to that. [00:25:00] But, you know, we, we are on boarding new PMs, and new engineering leaders, and new designers, and new squads and trying to, trying to teach them the way that we work and what our values are and, and again why we do the things that we do.

So we've ended up writing a lot more. We're starting to develop, build up more explicitly like training classes. We're trying to get more cross-disciplinary, cross-squad pollination so that you can, we can, we can force people to like observe the way other squads are doing things and what's useful. We knew that like growing at this rate was like you have to be very deliberate about it. You have to understand that, you know, if you're. if you're doubling every year the stuff that works today is not necessarily going to work tomorrow and you have to be ready for that and I say a lot that, you know, part of our job as leaders is to make a bunch of small changes over time so that we can avoid one huge disruptive change. And so, we are still doing that, but it just, it got a lot harder, the last couple of years.

Jason: Something I'll add to that. I've only worked in mostly distributed organizations, so when COVID hit, you know, GitHub didn't really have to adapt that much. We did have to adapt some things. But [00:26:00] one of the principal tenents that I look for in growing and scaling organizations is "who?" Like individual leaderships can you bet on? And, that is something that I don't think is distinct from in-person or remote, but is much more important I think in remote in many cases.

And also going back to the EPD comment about the triad. I still think individuals do matter, because individuals can make a difference. And when you're scaling, it is critically important to know that you have someone who is top tier pro, on their game, but, or, or versus an up and comer who you want to make a bet on, but understanding how you're going to engage with them differently.

And my flip side on the EPD answer which you gave earlier, which was, "hey, we want to treat them as a triad." I definitely agree with that and I think that's the right approach and whenever, you know, if they're standing in front of an audience, you want them to be out there together and when they're presenting product work, you want them to be together, all that sort of stuff.

I typically have found that no matter how much I want to treat them as a triad from an operational perspective. There's [00:27:00] always one who tends to take the reins more and it doesn't matter to me where they come from, E, P or the D. But typically somebody is organizing the work a little bit more than the other people.

Jonathan: Yeah. I, I have observed exactly the same thing. One of the things that as we've been building more triads over the last couple years, I've realized that like not only do you need extra skills, you also need the right mix of personalities.

Jason: Yes.

Jonathan: But the thing that I, the thing that I'm trying to hold to in all that is just as you said, the "most active leader," it doesn't always come from a single discipline. It is the person with the right personality, the person who has the drive and it could, and it could be a designer or a product manager, an engineer. I don't care, just as long as there's someone doing it.

Jason: Yeah. I 100% agree. I think that the personality meshes are important, but Jonathan, you've been a listener, you know, how much I like to use sports metaphors. But again, I don't care at the end of the day how certain things happen in sports, but what you care is that you win or on the play, you're disciplined or on the series, you [00:28:00] execute appropriately. And then, you know, the outcome wins. That's kind of the outcome.

Again, you don't care if it's the quarterback per se that X, Y, and Zs in the huddle and whatnot. You maybe prefer it from a traditional other perspective. But at the end of the day you just want leader to step up and that you win the Super Bowl.

Jonathan: Absolutely.

Eiso: I wanna maybe throw a curve ball here. Triads, leveled up, up on triads, right? Like you're saying, you naturally have within these triads people being the, the more leader type personality in the group. But I can imagine that when you have triads stacked on top of triads, what do your reporting lines look like? 

Are you finding yourself with, even at your skill already, conflicting groups or triads where there ends up being politics for leadership if you have two people who are both equally ambitious? When you have them all reporting into another triad, I, I can just imagine what used to be a [00:29:00] one-on-one meeting is now a three-on-three is a six-person meeting. Are there any challenges or, or hidden costs to this that maybe are worth discussing?

Jonathan: One point of clarification first, is that we, you know, within the product delivery, we still have traditional reporting lines. A product manager reports to a senior product or, you know, someone up the chain eventually reports to me. You have a manager relationship, you have traditional one-on-ones. That's all, that's all fine. The thing that you share are goals, goals and outcomes, right?

The principle that I come back to here is that, there is only one bucket of time. And so, you cannot have a set of engineering goals that's just the same for a set of product goals, because you're, you're using the same resources at the same time. They have to be prioritized against each other. 

And, and so, by basically making that explicit saying like, "okay, as a triad, you are, you are gonna, you are gonna give us one set of goals, one set of targets, one set of, you know, one roadmap. And it has to encompass everything that you're required to balance. It has to balance service health. It has to balance feature progress. It has to balance user experience. It has to balance bug fixing. It has to balance all the things necessary to [00:30:00] make your part of the business successful and we trust you as the people closest to that problem to be able to make those tradeoffs better than we can. 

Your success is the team success. In fact, that like, that's one of our, one of our product delivery values that we wrote several years ago. It is called invest in the team. We succeed or fail together. And so, we, we try to hit that at every level. 

And then, I've been incredibly blessed, both at at Atlassian and here at LaunchDarkly, to have worked in, in what I would describe as very non-political places. We worked really hard to not let that infiltrate the culture. Working transparently and openly and collaborating openly I think has helped us do that, but we've been able to I think keep all that to a relative minimum to the point where, you know, people are just focused on the success of the product, the, the needs of the customer and ultimately driving, you know, driving LaunchDarkly to a really great outcome. 

Jason: A meta comment I'll make here is that organization, you know, hierarchies organizational charts stuff like that just get super complicated really quickly. And it's [00:31:00] difficult to organize yourselves in any sort of way that like feels very, very, very good long term. One of those comments Jonathan made earlier, which was small changes, because big changes can be disruptive, very much agree with.

It's just constantly tinkering with things just because, you know, small changes are way less disruptive. But there always at some point becomes a question about a reorg. And how do we organize product, engineering, and design together separately, independent of each other? No really good answers here. For what it's worth, context, incredibly matters about where the product is, where your service health is, what your infrastructure looks like, what your delivery mechanisms look like. Like a lot of context matters. 

But one of the things that I do first think about is how do I have to, to structure engineering? And I know people are going to say I'm biased because I'm an engineering leader. That's where I grew up. But no. It's actually because it's the largest organization with the most people and I have to figure out how they are structured [00:32:00] semi-loosely. And then, I'm going to go and understand a little bit more about my product and design organization. I'm not gonna adhere 100% to like what I have inside of engineering as a, as a mechanism. But I do have to have a view on what engineering looks like before I can go to the other ones, and I also have to understand priorities.

Now the flip side of this I will say that I've seen product organizations who are organized very differently than their engineering organizations so much so that there's, it's very difficult to understand the two and how they can work together. And product leaders don't fully understand what I'm about to say, but engineering leaders are shaking their head vigorously right now if there is no alignment between engineering and product. They don't understand how they can deliver. Those are the worst performing organizations that I've ever seen in my life.

Jonathan: Yeah. I could not agree more. When I think about how we, we organize ourselves and how we evolve and it's very much evolution, because, you know, the structure we have today is definitely not going to work next year so we need to be ready for that. But I try to think about two [00:33:00] things. One is autonomy. So how can I, you know, sort of divide the team so that they can make decisions and move quickly and be as unencumbered by their teams as possible? And the other one is can I, can I clearly articulate a goal, a mission, a, an outcome for that team? 

And so, like autonomy obviously, it, it includes the, a technical dimension, right? Like, you know, what code, what code is team A gonna work on versus team B, and how often do they overlap and what services do they own together and, can you avoid that? So like you do have to, you do get to think about that a little bit, but I would caution to not let, the technology or the software drive your organizational design, as a first principle.

Jason: I so adamantly agree with you here. That it's, it's rather amusing. But I would say this. What I look for is dependency management. Does X team depend on another team to be able to control delivery? And does, you know, Y team depend upon Z team and Z team, et cetera, et cetera? You, you start to understand that there's [00:34:00] a lot of dependency management now in place.

And the other is, who talks to the customer at the end of the day? Does, does A proxy through B who proxies through C to get the customer information? And I mean this on the engineering side. Do they have direct visibility in line of sight to customer delivery? I really want people to have those sorts of agency moments where they can be delivering discrete, independent product lines as possible. 

But one example of this is I remember one time joining an organization and I saw that there were many, many, many small highly high agency teams that had component ownership essentially, but there were two or three people, but nobody could deliver anything to production without being a dependency map that required at least three or four other teams, because those components don't work independent of each other they have to work in sync with a bunch of the other components of the subsystem.

So all's I did at that point was draw a circle around those five teams and said, "Great. You're one team for, for the purposes of me. I need one road map. I need one [00:35:00] whatever." Everyone in that team got a little annoyed with me in the very beginning of that. And then, about five months later, everyone's like, "Oh. Okay. This makes a lot more sense all of a sudden, you know? Like I see this now from a delivery perspective." Yes. We still own the components inside of it, but they have to work in conjunction, one road map forces this.

Jonathan: Only one buck at a time.

Eiso: Couldn’t agree more. Jonathan, I love that today you, you introduced us to, what I do think you might have coined the term the, the product delivery org and, and introduce some fantastic concepts for people to dig into like the T-shaped person. Is there anything else that you'd love to leave listeners with as kind of parting wisdom on today's topics?

Jonathan: I guess I would say don't underestimate the ability of the engineers on your team to think broadly, to understand the context, to get the business, to have good opinions and know how to apply their own talents in their own time in the best way. If you have a, [00:36:00] structure that is not set up to take advantage of that, you're just wasting a lot of valuable energy and momentum that you could get. So think about how you can take those people, start with the people who already have strong opinions and have good product sense and empower them to move your whole team forward more quickly. 

Eiso: Couldn't agree more. I see Jason nodding his head as well on this. Thank you so much, Jonathan. It was an absolute pleasure to have you with us today and I hope we get to have you back in the future and dig into more topics. This was fantastic.

Jason: Jonathan, it was awesome. Thanks for coming.

Jonathan: Thank you, guys, so much. This is a fantastic [00:37:00] conversation.