Commander's Intent: Aligning Independent Teams to Common Goals

To access the presentation slides and more content regarding Commander's Intent, click here.

David's notes:

History’s most notable military commanders, including Helmuth von Moltke, Napoleon, and even the ancient Romans, all shared a common problem: organizing large numbers of people into an effective force. The size of the armies made quick, widespread communication difficult; and constant change and the fog of war made communications to and from a central command with the soldiers inaccurate and ineffective.

Perhaps surprisingly, there are many similarities between the needs of battle and of product development. Like a military commander, CEOs, CTOs, and Chief Product Officers may lead groups of people that are too large to readily centralize every decision. Executives cannot be expected to understand all the nuances or always be available to make decisions for their teams.

The typical alternative to centralized command and control is to have independent and empowered teams. Without proper coordination this too will fall short; independent and empowered teams pulling in opposite directions add cost and produce little value.

Commander’s Intent is a way for teams to function independently but remain coordinated. It is a powerful technique to align empowered teams to common goals and to foster innovation. It allows an organization to scale to any size with minimum communication overhead.

In this presentation, we discuss the five steps to implement Commander’s Intent and the advantages of doing so.

---

Transcript:

Alexander Agent:

Hi everyone, welcome to our workshop today on Commander's Intent. Without giving too much away at the top, today we'll be discussing how to align independent teams to common goals. Today's workshop is brought to you by Interna. Interna enables technology companies to ship better products faster, quickly plan and execute successful product roadmaps, achieve product-market fit more rapidly, and deploy capital more efficiently.

I'll go ahead and pass it over to David and he can introduce himself and then we'll jump in.

David Subar:

Hi. This started out as a one-person conversation, then a two-person conversation, and then I put it out to a couple of groups and 16 people signed up, of which eight are on now-- so more may join. I had originally planned to do this just very informally when there were just going to be three of us; but with more, I actually put together slides, so I will be showing some slides. With that, I will start the screen share. There we go.

Commander's Intent-- and Gerry, I'm going to put you on the spot as we start talking about how we got here. For those who are not familiar, several of us on the call are in the LA CTO Forum. We had a round table last week; and in our roundtables, people ask questions, different members ask questions of other members of common problems they have. Gerry asked the question, and we started engaging in a conversation. Gerry, this is where I put you on the spot. Can you repeat the question that you asked last week, and we'll use that as a setup for the rest of the conversation.

Gerry:

I was wondering how other guys in the CTO Forum-- and girls-- deal with nurturing a culture of innovation, and how they developed that. I just identified one of my issues-- I feel most of the innovation comes from me on my team. I really am trying to look for a way to develop the other people on the team-- all the way from developers to managers-- to be more innovative in their approach to solving our problems. David brought up the concept of Commander's Intent. Maybe that's missing a little bit in our organization.

David:

Thank you. That was perfect. That was almost like I told you I was going to ask you and we practiced, which we hadn't. I'm going to talk about Commander's Intent and why it's valuable, and how it helps create not just a culture of innovation, but also a coherence of independent teams. It has several benefits and I'm going to give you guys a structure on how to both create an environment where you use Commander's Intent and then bring the teams together having done that. My intention is that even though I have a bunch of slides, that this will be interactive. If during the slides you have questions, feel free to ask questions or you can also hold them to the end. Either way is fine. You can also chat them in Zoom, in which case, Alexander will bring them up.

A lot of you guys know me, but some of you don't. I'm going to give a little bit of background, just for context. I've been a CTO and Chief Product Officer of a number of companies throughout my career. I started my career doing research and development in AI and ML some years ago. Then eventually moved up, became a developer, manager, director, CTO, and Chief Product Officer. For the last eight years, I started this company Interna, and we've been consulting on product management and engineering, looking at how to make those groups more effective, how do you build quickly, ship quickly, get product-market feedback, and do it again and again.

The reason that I give you this context is we look at lots of different companies, everything from small startups-- here, I'll just do the fancy logo slide-- from small startups to large corporations like The Walt Disney Company, Fox, places like that. We look at-- we evaluate product management and engineering teams, and come up with, essentially, internal due diligence. We coach and mentor CTOs and Chief Product Officers to help them up their game; working on topics like this, we function as interim CTOs and Chief Product Officers; we do due diligence for companies too, doing investment; but because of that, we see a broad perspective of companies and get to pattern match. I just give you that as context for how to think about Commander's Intent; and when you ask questions, you'll understand my answer.

The nature of what I'm going to talk about starts from a military background. For some people, this might be controversial. The conception of Commander's Intent started there. The reason it started there is they have a very complex situation to manage. I have three military leaders that are shown here. The first one is Napoleon. Napoleon is well known but his big innovation, or one of his innovations maybe I should say, to management and military management in particular, was that he was one of the first people that had complex organizations that he had to manage. It used to be that armies were small-- the leaders were on the battlefields with essentially the individual contributors to use terminology from our world. Communication patterns were easy, and the situations weren't all that complex.

Napoleon was sending out large armies of multiple people over broad areas, where both the situation was complex and the communication patterns were complex. He realized that he would not be able to not only communicate with his people in real-time, but also the situation would change. He needed to have an organizational structure, a management structure, that allowed his armies to be successful under these kinds of situations. The next guy, whose name I always screw up-- and I'm going to bring up the next slide-- was one of the Prussian generals to do German unification. He's the guy who famously was misquoted as saying, "No military plan survives first contact with the enemy." And in the next slide, I have what he actually said. He recognized that if you gave somebody instruction, even if it was well-formed, at a distance they're going to need to make decisions, because the instruction you gave them was no longer going to be valid when the situation, when people started doing stuff.

The third guy here is James Mattis, who was a battlefield commander in Afghanistan, and eventually became Secretary of Defense. No matter how you felt about our last administration, you could find reasons to like him or to dislike him. What he understood, and his contribution, is the relationship between the general in the field combatant or the manager and the IC in our parlance, was not one of "I'm going to give you orders and you're going to execute them." It was much more of a pure kind of conversation and had to be that way in order to not only create Commander's Intent but to have the teams understand it and have the proper feedback.

I point these people out because they have situations that are in some way surprisingly like ours and really develop the concept of Commander's Intent and how to manage in complex situations. This is the general's name that I can never pronounce correctly. What people think he said was "No battle plan survives contact with the enemy." What he actually said was something slightly more complicated but with the same context. "No plan of operation extends with any certainty beyond first contact with the main hostile force." There's more nuance here-- it's the same concept but the nuance becomes important.

As I mentioned, command and control doesn't work. People think the military uses command and control in the US military. By the way, as I mentioned, early in my career I did research and development in AI and ML. I did it in a military-owned think tank. In having done that, we're mostly doing AI and ML on Soviet battle tanks coming through the Fulda Gap in Germany, and how do we know if they were really doing that, or it was just some operation they were testing and how to understand that. In doing that, in my first few positions, I actually worked with a lot of ex-military brass; in particular, a general that I became very friendly with a guy named Mack McKnight. What you find is that the humility of these people is surprising. My mental conceptualization of what it was like to be a general and what it was like to be in the military was completely wrong.

These guys knew that command and control doesn't work, me telling you what to do, and you executing it because of the complexity of battle-- there's a latency of communications, you're out in the field, and you have to make real-time decisions. Things change, “no battle plan survives first contact,” the fog of a war, there's a bunch of stuff you don't know and then commanders don't scale. Even if we didn't have latency communications and I was a General, and you came to me with every decision to make, I don't have enough hours in the day. The command and control just fundamentally doesn't work.

For our field-- doing technology-- battle and software development are very similar. We're both dealing with unknown situations. Our outcomes are both uncertain: uncertain in our perspective in that we don't know if we can really build it. We think we can. But also, what I really think is we're trying to build value for someone in the community, for some customer; we don't know if we're going to actually do that. Our resources are always limited, you never have enough developers and speed is critical to success. The context of what we're trying to do is very much the context of what the military is trying to do, and so some of the lessons map well.

In order in that situation to be successful, you need your teams to understand your goals. If they're going to operate independently, if they're going to be empowered, they need to understand what it is you want them to do. You need your multiple teams to be able to operate independently and simultaneously but get the cohesion to what they're trying to get to. People talk about the Spotify model-- I was talking to one of the former executives of Spotify and he said their model was built for this. They recognized that they were going to have several big competitors-- they didn't know who it was for sure, but Apple or Google, or Amazon-- and they knew that all of those companies were going to have a lot more resources.

What they chose to do with the Spotify model is-- what they thought they could do is out-innovate their big competitors. The Spotify model that you've read about was built for that, a bunch of independent teams operating simultaneously and coming to end results to meet some objective; their objective was not to release code, their objective was to build a system to deliver music to people. In one way, they're swarming the battlefield. You need to have smart teams with the right tools and the right process. They need to be not just empowered but have the environment that can make them successful. Then as they do things, you need to communicate back because you need to know, "Did we fulfill the intent or not?"

Those are the fundamental concepts you need, and what I'm presenting to you is a model. We're going to go to each of these steps. First is that your teams need to understand what your intention is; you need to communicate it to them and you need to communicate to them clearly. We'll talk about how you do that. Then you want to test your intent: is it right? You want to empower your team, so they execute on it, we'll talk about that. Then there's three responsibilities you have to have fulfilled and then you're going to want to retro to see how you did. This is the fundamental process of thinking about not just how to create Commander's Intent, but how to make sure your teams execute on it-- particularly, if you don't mind me extending the metaphor, a battlefield in the fog of war where things change quickly.

Let's go to what Commander's Intent means: on the high level, it means the team understands what I as their leader wants. The military actually has spent time thinking about specifically what are the attributes, or what are the purposes of Commander's Intent, the attributes I'll describe in a minute. Each of the armed services in the US have a slightly different definition; I prefer the Navy definition, I think it's more concise and more relevant to us. I actually spent time looking this up again last night. I think that their definition is interesting and I highlighted particular things here. Clear, concise expression of what is the purpose of what you're doing-- why are you doing it, and what is the end state you want to get to. Those are two different things: I want this, and I want to get here for this reason. Both are important to your teams, and I'll explain why in a minute. It provides them with focus and it allows them to achieve what you want without further orders even when things are different than you expect.

I think this is a well-thought statement, but I think what I want to point out here are two things: There are three, four, five ways for product developers to develop anything. Just telling them the end state that you want them to get to is good, but it's not sufficient because they can arbitrarily pick to do any of those ways, either three or four or five different times. If they also know the purpose, they're much more likely to develop it in a way that gets you to your goal, so both saying what the end state and the purpose is becomes important because you want them to be able to execute without coming back to you all the time.

If you look more at the statement, there are those two things-- the end state, the purpose-- but one of the things you need to tell your team. “I would like you guys to build this system for this reason, and here are the things that I see that might be blockers.” I keep going to military metaphors. I read about two weeks ago, it was the anniversary of the raid on Abbottabad, and there's a long article in The Atlantic about it, maybe it was three weeks ago. It's an interesting article, I suggest that if you guys are interested, ping me and I'll try to find it and send it to you.

General McRaven was the head of the SEALs and they built a model of Bin Laden's compound in Abbottabad and they brought the SEALs together and McRaven put the model in front of them and he said, "We believe Bin Laden lives here and we would like you to try to capture him and if not, kill him. Here's our objective: we want to get Bin Laden. The purpose is we want to try to stop Al Qaeda; and here are the risks: it's near the West Point that Pakistan has; we're not going to tell the Pakistanis we're flying into their territory. There are possibilities there might be fights here." Then he said to the SEAL team, not how are you going to do it but, "Your job is to go away and tell me how you're going do it." I'm stepping ahead of myself in the presentation.

The second thing is: after you tell them your intent, you want to have them ask you questions about the why. It does a few things: one is it ensures they understand. You don't want them to accept that everything you say is golden; they know some stuff you don't know and so you should require them to ask you questions. "I've told you what I want to do, past my intent, past what the statement I gave you was. I as the leader have a broader understanding of the context; you as the person who is the individual contributor--” people that execute it are closer to the data-- “You might know some stuff I don't know. I know some stuff you do and with your questions, it might indicate I didn't communicate well. It might indicate I missed something; it might indicate I didn't tell you something; it might indicate you don't understand. But the idea is that you want to harden what your intent is; you want to test it to make sure they understand it, to make sure you didn't miss anything.

So step one is to create an intent and communicate it. Step two, have it tested by the team asking you hard questions. Now, you need to empower the team. Now-- this goes to when McRaven put the model up, he said, "Your job is to come back with a plan of how you're going to take Bin Laden from Abbottabad." McRaven didn't give them the plan. He didn't have some extra team of experts say, "Okay, you guys with the guns just follow this." The team owns the plan. If you're going to empower them, they need to own the plan.

Once again, they know some stuff you don't know. They run the exercises every day; you decide the what, they decide the how. If you want the innovation that Gerry was talking about, you've got to not tell them how to do it. They're going to tell you how to do it, but now you're going to reverse roles. Before, they asked you questions; now, you're going to ask them questions. There are things you know because you have more experience, but the key here is to ask questions and not tell.

Now, little interlude. I think this is one of the most important concepts. There's a big difference between teaching and coaching. Teaching is when someone doesn't know how to do something. You tell them from scratch and you explain to them how to do it. Coaching is when they know how to do something, but you don't think they're at 100% efficiency. So, you ask them questions; asking questions tends to be a respectful thing but once again, you're testing ideas. Maybe they actually knew it and you didn't. If you tell them, they will tend to do what you told them to do. If you ask them questions, there'll be information exchanged and you'll learn, and you do a couple of things:

One is that besides learning, the responsibility of explaining becomes on them. They will tend to come to you with other meanings-- knowing you're going to ask questions, they will be prepared to answer them and they'll be more empowered. This is where you actually get the innovation and people engaging because they're coming to you with solutions, and you are battle testing them. When they bring you solutions, you ask questions, you don't tell. That's step three.

Step four, there are three sets of responsibilities. Creating a definition of done, which is, “What is it? How are we going to know you're going to achieve this?” You have to jointly come up with that. The most obvious thing is in that section I have is ‘Theirs’: what are they responsible for? Well, they're responsible for execution. They're responsible for a report-- you don't let them go dark, they've got to report to you regularly. I suggest demoing often. Most of that's pretty obvious and pretty common. What your responsibility is as their manager becomes particularly important.

People talk about servant leadership, this is where it happens. Your job is to create an environment where they can be successful-- whatever tools they need, processes they need, your job is to lay that out so they can run. The SEALs raiding Abbottabad didn't go out and buy the Blackhawk helicopters, they were supplied to them. The maps of the terrain were supplied to them. Those are the environmental factors. As the team is processing, your job is to get impediments out of their way, so you create the environment, and now you’ve got to knock things down like, "Johnny's having a hard time getting ahold of the product manager." Your job is to address those issues.

I had a team I was working with and they were working late. I was with the team, and I was like, "What do you guys need?" One of the guys said, "I'm really hungry." I was like, "Great. I'm going to go order you guys pizza." I was the guy who went around and found out what everyone wanted, ordered the pizza. Then, the trash got filled, and I was the guy who emptied the trash, not because I'm a great human-- it's because that was the most valuable thing as a manager at that point-- if your team is executing well-- that I could do, that you could do.

Establish your intent, harden your intent by letting them ask questions, empowering the team-- how are they going to execute, asking them questions-- and then doing the executing and you going and getting impediments out of the way. Those are the fundamental things to make Commander's Intent work in an environment like ours. One more thing I'm going to suggest is-- and I’ve got no bullet points for this-- but all major projects, you should do retrospectives on. People think about retrospectives a lot on, "Hey, we ended a sprint, let's retro the sprint." That's interesting. That's important, but that's tactical. When you end a major project, you want to do two kinds of retros.

One kind is: how did this thing work, this Commander's Intent kind of management style? You're going to want to modify this, and iterate this, and modify this for yourselves. The second thing you do is-- product management and engineering are actually one team. Your intent is to build some software that is creating value for some of your customers. Something that teams regularly miss is, “Let's retro whether the bet we made was or wasn't a good bet.”

Our intent-- your Commander's Intent-- upfront was, "We're going to create this product for this type of user to create this type of value for them.” Did you get it? Did you not get it? If you're not retroing the bets you're making, your intent that you're putting out there, you can run through this whole process and not get better at it. Retroing the process of communication, retroing what bets you make are an important part of making Commander's Intent work for you. That's it in a nutshell. That's what there is to know about Commander's Intent. Questions? By the way, I'm glad to work through scenarios if you have specific things in your organization, and you want to talk about how it might apply for you.

Gerry:

That all makes a lot of sense to me, David, thanks. I think what we need to work on-- and like I said in the Forum meeting-- the reason why I like this is because it's something that I can work on, and it's easier for me to have something to work on myself than to have 25 other people working on something. I think, at least in my case, a big part of the solution is upfront, when we're talking about the problem and how we're going to solve it. That's where I think we're forking off, at that point it becomes-- I try to solicit questions from the teams a lot, but I need to work on not giving them the solutions just outright.

David:

Right. That's exactly. The key is: don't solve the problem, present the problem. Make it their problem to figure out the solution. By the way, it's a muscle. The first time through, you might have to give them a smaller problem. People have been trained to, "Okay, I'm going to do what I'm told.” If you give them a large problem and ask them how to solve it, they could be in polemics about how to start, or even about what their power is in the situation. Start with a small one.

Nian:

I have a question. In the scenarios where you do have a lot of knowledge, or you've thought about it, obviously, because you have that intent, what are recommended ways to essentially hold back, as it were, because you've thought about it a little bit? Is it going through those exercises? Is it something that you reserve as a midway retrospective? I don't know. It's like, you want to be able to-- the information you have can help jumpstart, or do you wait for them to ask the questions? I guess that's step two, or three? I don't know.

David:

After you've given them the intent about them asking the question, then?

Nian:

Yes.

David:

Silence is a very powerful tool. My recommendation would be, explain what you want and why, and what impediments you see in the what room and tell the team. The team should know, like, "Here's the process we're going to run. You're going to be responsible for the how. I'm telling you the what and the why.” And just not saying anything. At some point, if the room is silent for five minutes-- to me, I don't know what time it is but something over 30 seconds-- say to the team, "I'm going to ask you to come back to me in three days with the solution. Do you have everything you need to be able to do that?"

Then if the answer is yes, and you still think they don't, then at that point, you could ask more directed questions. "Do you understand everyone that we have to interact with in the market? Do you understand what the user wants and why?" I would hold that off at last and try to avoid asking that question at all if you could. Bhavini, you had a question?

Bhavini:

Hey, thanks a lot, David, for setting this up, and Gerry, for seeding this whole thing. My question is, for the first one, right, for the “Communicate Your Intent--” is that at a higher level or elevation of our planning and objectives? That's OKRs-- or different companies would do it in different ways on strategic themes, et cetera? Is that the right understanding?

David:

I think that maps pretty well and I may have misunderstood the question a bit. It's great for OKRs because OKRs are literally, like, "Here's the objectives. Team, go figure out how to get proposed key results and processes, you need to meet these objectives." That maps 100%. My argument is that Commander's Intent scales to-- I don't want to overstate it, but to arbitrary size projects. If you have a team of four developers, you can do this with your four developers if you're the manager. If you are a director, the problem is size-- it’s just bigger-- but now you're asking your multiple managers to address this and have their teams address it. It kind of fractalizes up and down the organization.

By the way, I have three children. They're all perfect, just like all of yours. I use this with my kids because I want them to be empowered. My kids are super smart but I want them to be able to exercise not just their intelligence, but their knowledge of their ability to do things. By the way, they come back and sometimes their answers, I perceive, are wrong. I ask them questions, and it turns out like I was sometimes wrong about them being wrong.

It's effective. I have three daughters. I'm going to brag for a minute so I apologize. One is actively becoming an Assistant Director in TV. My middle one just got accepted to med school. My little one is going to apply to med school. I'm not going to be there with them in any of their work situations, and a lot of their life situations. Like I said, they're super smart but turns out being smart is very common. It's being able to be empowered and to drive your way through life that becomes important, and I want them to be able to do that. I find this is very effective for that too. Sorry for the bragging.

Bhavini:

You've really raised them well, I should say, David. David, you mentioned a really key thing about questions. It's a muscle to not prescribe, but rather ask questions. What has worked for you, or is there a cheap bag of questions, et cetera? Because I know when I try to catch myself, sometimes instead of telling, I'll be like, "Okay, I have to get into question mode." Or catch myself doing leading questions, and then I'll be like, "Oops, sorry. I didn't mean to."

David:

Well, I don't have a standard bag of questions but I'll tell you what my triggers are to ask questions. By the way, this is much easier to describe in a presentation than to execute. Any time I find myself doubting what was proposed and I find that drive to say, "Oh, I think that's a mistake. We shouldn't do it that way." That physical feeling of, “This is wrong. I can just go fix this. I'm going to tell them what to do.” That's your clue to say, not just “Have you thought about this?” but "What do you think might happen when we scale twice as big?" or-- I'm trying to take another example of "Based on what you know over the market, do you think this is going to hold when our competitors get to here?"

I already have the opinion of like, "Oh, that's not going to work." It's like, this is not going to work twice as big. That's my opinion. Oftentimes, I'm wrong-- they're closer to the problem than I am. But it's recognizing that internal feeling of "These people are about to screw up, and I’ve got the solution. I'm just going to tell them." It's not just a muscle for them, it's a muscle for you too. You’ve got to practice and you are going to get it wrong sometimes, and that's okay.

Jason:

I have a question. First, I want to say thank you so much for doing this. If you really did put this presentation together, just on the fly, that was amazing.

David:

Literally last night, we put it together.

Jason:

One of the key pieces was us as leaders behaving in a certain way, but another piece is how the team behaves, which is asking the questions... as you said, hardening the intent. How do we encourage our teams to do more of that?

David:

Ask you questions.

Jason:

Yes. Because theoretically it means you control your behavior. We can't control other people's behavior, but we encourage them to move in that direction.

David:

Part of it is-- one of the things that I mentioned before is asking, “are they ready to go ahead and come to the solution?” The second part is: when you ask them questions about their solution, that will reveal if there's things they should have asked you that they had not. I'll go to my previous question, "Is this going to work when we scale twice as big?" and the team might come back and say, "Scale twice as large? I didn't know that was a thing." It's like, "Well, that was a thing and maybe I could have made myself clear in the intent; but was there a way that you could have asked that question?" Part of it is, you're asking question sets a bit-- so I'll tell you another story. I at one point got offered a job at Microsoft and there was this guy I was going to work for named Robert Robby and I was going to be what's called a PUM, Product Unit Manager of the part that was going to do internet identity, Microsoft's group for internet identity. Robert said to me, "You're going to brief Bill Gates once a month." I said, "That's awesome."

He said, most of the other PUMs only brief him once a year, but you're going to brief him once a month. I said, "That's awesome." And he said, "No, it's really not." He said, "He makes Steve Balmer cry." I said, "What's that about?" He said, "Bill Gates's breadth of knowledge was so broad, that he could ask you questions in your area that you hadn't even considered." He said, "When you brief Bill G, you better be on your game." The bit was set, the expectation was set that like, "I need to know everything before I went-" Now, I didn't take the job-- I don't know what that experience would have been like, but I probably would have cried too. But I knew going in that if I took the job, I had to be on my game and answer hard questions. And Robert didn't say that to set me up; Robert just said this is part of the job, you better be ready. And I think that kind of culture setting is important.

Now, it wouldn't be my goal to make my direct reports cry. I don't think that's particularly useful or nice, but I have no problem asking people really, really hard questions. By the way, I also hire for that actually. I've got a whole other presentation on hiring, and how you think about hiring, and how you think about recruiting, and how you're going to make your company more attractive, money being fungible and all that. But this kind of Socratic question-answering is key to the hiring process, the bit set for how you hire and the kind of people you hire, and this kind of organization you have.

Now, once again, don't be an ass when you ask people questions. Understand, you're being hard on the problem, they should understand you're being hard on the problem and not on them; but they have a responsibility to come in like you're going to storm Abbottabad. You're with a bunch of your colleagues, do a good job. Now, by the way, none of the stuff we're doing is probably as important as storming Abbottabad; but it's important, and if it's not important maybe we shouldn't take this job, we should take a different job. I'll give the-- I'm out of time but if you guys are interested in talking, I’ll give the presentation on recruiting.

Jason:

Definitely. The people in the process are very important. I'm sure we all see in our own teams there are going to be some people who you say to them, "We want to do this, here's why." And they come back, and they ask a million questions; and then there are all the people who say, “Okay.” And then they go off and they do something and they come back and it's totally missed the point.

David:

Right, but don't let them do it like-- they've got to come back and tell you what they're going to do before they start anything. That's important because I've done other things like, "Okay, I'll go do that." Earlier in my career, I did that and found exactly what you said. Now we've expended a lot of energy and a lot of time to get to a thing that didn't solve the problem. They've got to come back and tell you the how.

Jason:

There's a feedback cycle.

David:

Feedback cycle, and it's critical.

Jason:

Yes.

David:

Other questions? Okay, one last slide, if I find it. We can adjourn now. You guys want to talk or you've other questions, here's how you get a hold of me. I'll send the slides around, and you guys can take this and keep this. As I mentioned, at Interna, this is what we care about: how to make product management and engineering more effective. By the way, effective. Not efficient. If you run really, really fast in the wrong direction, you just get lost faster. How do you make teams that build products that create value for a market? We think about this stuff all the time. If you want to chat more, this is how you get a hold of me.

[00:45:40] [END OF AUDIO]