Decentralizing Decision-Making with Shawna Martell & Dan Fike

Introduction

Thomas Betts: Hello and welcome to another episode of the InfoQ Podcast. Today, I'm joined by Shawna Martell and Dan Fike, who both work at Carta.

They recently spoke at QCon London about decentralizing decisions and empowering individual contributors through something called Navigators.

Architects are always saying “it depends” when they're asked to make a decision because context is so important. I want to know more about their approach and how it moves decision making as close to the context as possible. So, Shawna and Dan, welcome to the InfoQ Podcast.

Shawna Martell: Thank you so much for having us. We're so excited to be here.

Dan Fike: Yes, it's going to be a lot of fun.

The need for a clear engineering strategy [01:19]

Thomas Betts: So in your presentation at QCon, you talked about the Navigators group and that's how Carta is trying to streamline the process of making decisions. Before I get into the details of how the program works, can you set the stage for why it was needed? What were some of the problems that you were hoping to address?

Shawna Martell: When we think about the problem that we were trying to solve, what we heard from our engineers was that Carta was lacking a clear engineering strategy and that was actually what they were struggling with. They didn't understand what rubric to hold their decisions up against in order to understand if they were aligned with the organization or not. That makes it very difficult when you're trying to make a decision to understand what principles should I be following when I'm making these architecture decisions. Like you said in your intro, it depends on so many things, but if it's not clear on what it depends on, it's really difficult to navigate those tradeoffs effectively.

You can see that as I talk about this, I actually use that word navigate. Our navigators are a result of our engineering strategy, so it wasn't enough to document the principles that underpinned our decision-making. What we really needed beyond that was someone who could help interpret that strategy locally within their teams to help them understand "How are the decisions that we're making aligned or misaligned with the principles that the organization has said that it really espouses?"

Thomas Betts: I hear things like strategy and sometimes that gets to it's vision-y and it's like this ephemeral thing and engineers don't like talking about the big words, but I think it's important to bring this in and saying you had some big engineering strategy. What were you trying to accomplish and what made you say, "We're going to sit down and rethink where we're trying to head?" Because that's what your strategy is. I'm trying to reach these goals. How did you quantify those and why was it important to make that your first step is to write all that down?

Dan Fike: It's actually really interesting. We didn't look at the organization and say, "You all need a strategy. You're doing things wrong." What happened is people throughout the organization asking, begging for it. They were like, "We are making decisions. It feels like we don't have the right context or guidance. It feels like we're making decisions arbitrarily or maybe at random." They were craving it. So, when we've sat down to produce a strategy, it wasn't to institute something upon everybody. It was to fulfill something they were asking for, which was a cohesive set of principles that we can agree on in advance, instead of relitigating things time and time again and not really having conviction about the answer we land on.

Document where you are, so you can come up with a plan [03:50]

Shawna Martell: Well, and I think it's interesting, when we got started on this process, we weren't actually setting out to tell us where to go. We were trying to document where we were right now. What are the principles that are underpinning the decisions we're making today? Let's write those down. Maybe we like them, maybe we don't, but it's important to just document the existing status quo for how we're operating today, because until we all stare at that and really agree, yes, this is how we're operating right now, it's very difficult to incrementally change how you're operating because you don't have a standard baseline of where you're starting from.

It was difficult as we started this process. It's so easy to want to write where you wish you were and that was an anti-goal. We explicitly needed to ball up anything that we wrote down that was where we wished we were and throw that away and maintain the understanding of our current decision-making practices.

Dan Fike: There's really two reasons it was important to do that. The first reason is if we just write down this imaginary world we don't live in, everyone's going to look at us and be like, "They're off their rocker. What company are they working at? That's not how things work around here." It just gets ignored. The other reason is frankly, the most effective way to understand what is not working or what needs to change is to write down something that might feel absurd and be like, "Yes, but that's what we've been doing. You don't have to like it. That's what we've been doing." From there, we can start to agree on what needs to change and you can change your strategy gradually.

Thomas Betts: I think that's really interesting because we've talked about architectural decisions on the podcast before and one of the things that people realize is there's all these implied decisions, these accidental decisions. Even if you didn't consciously choose to do something, that's the architecture you have and it wasn't documented. Somebody didn't write down the decision, but that's where we ended up. At some point, you say, "We want to improve our architecture process. We're going to start doing ADRs. We're going to do whatever it is and start documenting decisions."

It's sometimes useful to write down what was the decision that got us to where we're at right now. What you're talking about is, "What were the decisions? What got us to our current state of our decision-making process about our architecture process?" It's definitely a meta discussion, but is that what I'm hearing from you guys?

Shawna Martell: Yes, it's funny, so a lot of this comes from guidance from Will Larson who now just so happens to be our CTO but wasn't when we first started down this road. One of Will's pieces of advice is if you're struggling to identify your strategy, write down five architecture decision documents and tease out of them what are the underpinning principles in all of the decisions that you find that you're making in these documents. That is your strategy as it exists today.

Discern facts from principles [06:38]

Dan Fike: I want to call out one of the things she said is the word principles. We talk a lot about principles in the QCon talk and one of the things I want to do is contrast that with facts. Oftentimes when people are playing back why we got where we are, they're describing facts. The situation was this, but that's not actually what I want to capture when I understand why we did some particular thing. A fact is something like X. X is true, X is false. A principle is like when X, then Y. When not X, then Z. These are the principles we want to distill out of these decisions, and sometimes you have to really go in with glasses on looking for principles to see them. Otherwise, it's very easy to see all those facts and think that was the thing.

Thomas Betts: Yes, I think that's also why people are looking at architecture decision records, not to just be the here's the pretty diagram that we drew of this is what we want it to look like. People say, "Well, why did we want it to look like that?" That's your decision record. The decision record captures here are the trade-offs we considered. Here's what we said was good and here's what was bad and why we went with this as a final answer. You're saying you wanted to capture the why of all of your process. How are we doing architecture decisions? How are we making our systems built?

Dan Fike: Yes. Here's a fictional example for a moment. You might have some feature you're looking to implement and you can build this as like, "I'm going to construct a new endpoint inside of some existing service," or "I'm going to go build a new service, a new microservice that features just this one endpoint for this one purpose." Two options, there are pros and cons for each. You can write down an explanation of the pros and the cons and that you chose these pros as they were more important to you, but it doesn't actually establish the principles that the organization has about what's important to them.

You might have decided that in your case you preferred this element of scalability, but why do we care about scalability for these kinds of things? Maybe this isn't actually a thing where scalability matters and we should only really be focused on the maintenance efforts that are required for the engineers who support it. Maybe that's actually the priority at play in this scenario and being able to outline the principles of when you reason about one thing over the other in an abstract sense steers those decisions.

Navigators vs. Cartographers [08:45]

Thomas Betts: I want to go back to you mentioned not just coming up with here's the state where we want to be, because I think outside of this architecture decision, big strategy, a lot of times we have a product that comes to the board. It's like, "Here's the pretty picture. We want it to do this. We want these features and just make it happen." People start designing for that end state without thinking, "Oh, well, how do we get there?" And then someone comes up with a PowerPoint like here's the roadmap for the next year and here's how we're going to get there, but there's no road built yet and you don't actually know where your starting point is.

I think that's another key aspect of this is that in order to know how to get to your destination and come up with a roadmap, you need to know where you're starting from. I think that also ties into why you use Navigators as the name, helping us find our way along the thing. Am I stretching the metaphor too far?

Dan Fike: It might be a bit of a stretch. One of the reasons we really wanted to lean on the term navigators is because we could contrast it with the term cartographer. One of the questions that came up in the Q&A for our talk, we made this analogy, a cartographer is very much the person building that map and that is not what we want our navigators to do. The strategy and the vision and the plan combined, there's a process by which we produce those. The navigators are surely by virtue of being senior talented people in the organization involved in that, but that is not because they are navigators.

Once the map is laid, the navigators are helping all of these other people understand and interpret it because it can be confusing. It can be confusing to understand how the thing we are doing this week or this month intersects this longer term principle that helps move the direction of the company in a six-year timeline. What we want to do is we want to really look at everybody in the organization and say, "Listen, this is a map. This map is at your disposal. You can use it. You can make decisions in accordance with these principles, but maps are hard to read. It can be hard to find help when you need it. So, we've put a big navigator label on someone's forehead so you know who to go to when you're stuck reading the map." Does that make sense?

Who are the Navigators at Carta? [10:54]

Thomas Betts: I have questions. Describe the Navigator program. What are these people that have this tattooed across their head that says, "I'm a navigator?" Who are they? How many of them are in your organization? Where do they sit? Tell me more.

Shawna Martell: So we have a dozen navigators across an organization of about 400 engineers give or take. Then we also have the additional role of our CTO, Will Larson, and Dan Fike is his deputy who helps us navigators navigate really. We sit everywhere. There are folks that are deep in the organization who are navigators. There are folks who report to VPs. It's less about what your title is or where you sit and more about have you shown that your judgment is appropriate to the problem at hand for your team and that we can empower you with this tool of the engineering strategy and that you are prepared to be held accountable to the CTO when you make decisions using that strategy.

So, you could sit anywhere, but when the time that your team is making a decision, if it turns out that it doesn't shake out to be aligned with the strategy, you can be pretty sure you're going to hear from the CTO whether he's your direct manager or not.

Thomas Betts: But the navigators aren't the people making all decisions. Like you said, they're not the cartographers designing it, but they are responsible for making sure that the team they're with is following the strategy.

Shawna Martell: That's right. So, definitely don't expect the navigator to be making every decision. We're not hoping for them to become the bottleneck or the person that has to bless everything that's coming out of their team. They are a resource for the folks that they're navigating when they're struggling to make a decision or they're not sure how to apply the strategy, and they're also responsible for keeping their finger on the pulse of what's going on to make sure that they insert themselves appropriately if there does seem to be something that needs their advice or their input.

Dan Fike: That's the part right there that might seem a little different than the stuff we've been talking about so far. The navigator, in order to do their job well, has to have really deep context on the area of the product or code or whatever it is in this case that they are responsible for. They need to have this deep context. If they aren't informed about a team in their scope over there that's built a thing that is crazy, then they're lacking the context to do the job well. They need to understand where their team's work intersects the strategy. So, are they again, making every decision? No, they're not making every decision, but they're probably aware of every decision.

If they're letting the rogue decision slide, that's an issue. Ideally, when things happen that are contrary to our strategy, a navigator should know about them and either fix them or as is often the case, surface them as a shortcoming in the strategy itself. The navigators are essentially the largest input to the strategy as it evolves. Being able to spot that there's a team over there, the strategy just didn't work. It does not give them the guidance they need. It leads them to the wrong decision. It's imperfect and needs to be corrected. Navigators need to surface that just as much.

Thomas Betts: So when you get to the place on the map where it says there be dragons, now you have to figure out what does the land actually look like in that area and say, "Okay, this is a big gap in our map of knowledge and our map of strategy." So the information flows both ways and they're that conduit up to the bigger broad strategy decisions and then down to their team.

Dan Fike: Yes, you asked who these people are and she mentioned there's 12 of them. There are folks, front-end engineers, back-end engineers, site reliability engineers, security engineer. They're from all over the organization, and notably, while they all have a direct relationship to the executive who's running the Navigators program and owns the strategy, they exist elsewhere in a hierarchical org chart with very indirect paths that eventually roll up to the executive. In fact, some of our navigators don't even roll up to our executive, which is interesting, but what they look like are root nodes in a shadow org chart, in a secret org chart of influence that exists parallel to the actual management hierarchical org chart.

A lot of the folks that are selected for navigators are selected because in this shadow org chart, they have influence over the right set of people and the judgment to recognize how to interpret the strategy for those folks and help project that information downward. It's somewhat less of a hierarchical structure this is your role in the org chart and more leveraging of the natural inclinations that exist already amongst relationships.

No architect titles, but navigators may have architecture responsibilities [15:37]

Thomas Betts: So does Carta have architects? Because sometimes the role of an architect is same way we talk about a lot on the podcast cover on InfoQ and all over is what should architects be doing and making decisions and helping people make decisions and being a leader in that is one of those rules for a modern architect, but it hasn't always been... The ivory tower architects sit over there. They make the decisions. They hand them down. Go forth and do what I say. Do you have anyone that has an architect role or is that just not part of the structure?

Dan Fike: We don't have any formal architect roles or titles. One of the things that Will Larson writes about in his Staff Engineer book is that architect is one of the archetypes of a staff engineer profile. We do have staff engineers and some of them are functionally operating as architects where they're on projects or teams that such a thing is warranted. Generally, it's not a thing we make a point to have a principled opinion to have present in every project or team, and a big part of that is because we want the decisions we make to be further decentralized amongst the other ICs in the team.

We don't want to create that choke point. The idea behind us writing down a strategy is not just to allow navigators to agree on some principles, but to allow people who are another junior software engineer working on some particular task to be able to hold up their own decision making against this benchmark and understand that they're doing a good job without having to get an architect to weigh in.

Anybody can make an architecture decision [17:02]

Thomas Betts: So about a year ago on the podcast, I talked to Andrew Harmel-Law, and he wrote an article about the architecture advice process. I think you guys even quoted him in your presentation, and I like the idea of anyone can make an architecture decision as long as they consult with both the people that are affected by the decision and the people with relevant experience. How does that work at Carta? Is that basically what you're following?

Shawna Martell: Yes, I think that that's a direct quote from our talk was that anybody can make an architecture decision as long as they fulfill the requirement to seek advice. The advice comes from the combination of the strategy and our navigators where now our expectation is that everyone is empowered to be able to make a decision and they have resources that help them hold those decisions up against a measuring stick to say, "Okay, the decisions I'm making are or are not aligned with the organization's take." What's interesting about those decisions is like what Dan was saying before, sometimes you hold up your decision next to the strategy and you say, "Wait, these are not aligned."

Almost certainly we have found that that is something we are missing in our engineering strategy and that's not a huge shock. It was what five of us that cobbled this thing together to put together what ultimately became Carta's engineering strategy. If it were right the first time, something is broken. These are the tools that help us iterate and figure out what did we get wrong the first 17 times and we'll get it wrong the 18th time too, but it's incrementally less wrong as we hold up these individual decisions to see where it falls short.

Dan Fike: I think one of the other things that contrasts this with the duty to seek advice he was referring to is that fundamentally the source of the advice you are seeking is the organization collectively through the strategy, not strictly a person. I think that the attempt there is instead of having people push their decisions up to the advice giver, they're self-fulfilling and the advice giver is themselves digging in to keep informed and know already. They're following up with the people on their team to understand what's going on. So, the advice isn't necessarily explicitly sought out from the navigator. It's sought out from the strategy and the navigator is keeping an eye out to make sure we didn't mess anything up.

Some gaps in the engineering strategy are intentional [19:24]

Thomas Betts: Yes, I think it's really important to call out that people are making the decisions, but those decisions are informed based off of whatever criteria. When you're making those trade-off decisions, why are you trading off performance versus scalability if those are the two axes or how does it affect and how do I make a decision of what's important in this context? That's where your strategy outlines those things. Is that where you're saying you're finding gaps? We care about scalability here and we care less about scalability over here.

Shawna Martell: I think it's been more cases where we just didn't form an opinion at all in the strategy, but it has percolated through the organization that we should have one.

Dan Fike: Yes, I think an interesting illustration of that, it's actually something we're working on right now. We had some guidance for a while around whether some feature or service you're trying to build exists in the existing monolith we have or whether you build something wholly new. The guidance we had given was, "You know what? We're working on a happy place for new things right now. It's not ready yet, so just build it somewhere else. Don't go create a new repo and a new thing. Don't create more debt for us to solve later, but don't wait either. So, put it in the monolith. Put it in one of our existing monolith or existing platforms and it'll be easy to move later."

Beyond that, we didn't have very specific guidance around, "Well, do I put it in the monolith as a new endpoint? Do I build it as a separate service? How do I keep it encapsulated?" We had abstract direction around encapsulation, but no specific guidance around how you build it into the existing monolith. In that case, it actually wasn't an accident. We knew we couldn't produce universal guidance on that. So, a lot of it was let's spend time with the navigators for them to understand why we can't produce universal guidance on that and direct people to check in with their navigators. I don't have better advice for you as an organization yet.

We need to develop those principles. Why don't we go ahead and try a few things over the course of the next six months? We'll understand as each of these decisions are made, what are the principles that are actually winning the arguments so to speak in our decision making? Only then can we really refine our strategy. In the meantime, it remains a bit of a dead space.

Thomas Betts: Does that come back to the point I brought right at the introduction that this is trying to put the it depends as close to the context as possible? Because you don't have one simple answer in that case of here's how we solve the monolith problem. Every time you decide to still do that, you want to leave a little bit of wiggle room. Here's the big guardrails. Don't fall off the cliff, but stay in your lane or figure out where your lane is. So, how do the navigators help in that situation where they say, "Here's the big strategy and how do we figure out our micro strategy within this team?"

Shawna Martell: I think the way that this has manifested most is in this decomp example, really our guidance was, “Do what works for you.” The navigator had sufficient understanding of the context of the problem, whatever that problem was, as well as a relatively good understanding of broadly how we wanted to imagine our future to reason about this specific problem within the context of their team. I think that's most often how this is played out.

Navigators collaborate together, but do not have any collective responsibility [22:42]

Dan Fike: One of the things that the navigators do collectively is they spend time together. They don't make decisions together. They're not making consensus together. They're not sitting down to write the new strategy together, but they do develop a relationship with each other and they are pretty smart senior engineers at the company. So, a lot of times when you enter into this gray zone where the it depends might be unique and hard to map onto the strategy, navigators are consulting with each other.

They've built enough of a rapport to understand this feels like something that maybe Kevin or Amy or somebody has already seen before. Let's pick their brain and get some additional insight in here. Navigators as a unit, as a collection, they don't really have any collective responsibility, just individual responsibilities, but because they all have this navigator title in common, they do spend time collaborating on some of the hardest decisions they have to make locally.

Thomas Betts: Yes, that's interesting. That's where you get I'm doing this type of work. I've exercised that muscle in how to make these decisions and I can share that knowledge to other people.

Dan Fike: I've seen a lot of leaders or other companies say, "You know what? Let's just get our best and brightest people in a room and I'm sure they'll do smart things." This is an attempt to do that. I don't want to downplay how smart the people who aren't navigators are because we've got a lot of smart people out there who just don't have that title. They're fulfilling an organizational need, but they are developing relationships with each other that we haven't really found as good of a way to do elsewhere and it pays off.

Thomas Betts: It sounds like this is a good use of put the smart people in the room to solve a cross-cutting concern. Don't put all the smart people in the room and have them write that one microservice over there. That's not a good use of their talents. Maybe that T-shaped organization I can think broadly even and then be deep on my team and my specialty, but I can talk to other people who are T-shaped and we can see where we overlap and say, "Okay, I'm not going to have the same exact problem as you, but I can explain my problem and you can understand my problem and then we can talk about it together."

Dan Fike: I totally agree. I also would suggest that if we put all of our best and brightest people in a room to work on a microservice, you'd get the worst microservice that you possibly could. Just too many people in one thing.

Navigators as mentors [25:00]

Thomas Betts: Right. The other part of that role, and I wonder this goes back to teaching other people to make decisions, is there an explicit or just implied mentoring responsibility? One of the things I've seen companies and teams struggle with is getting especially new in career younger engineers to be comfortable making decisions. They're sitting there afraid to make a decision, making it wrong or whatever it is. They're expecting the answer to be handed down to them and we're trying to get them more comfortable with I can give you a problem and you can come up with a solution. So, are the navigators doing that mentoring role and teaching people how to make decisions?

Shawna Martell: I think that it would be really hard to convince me that if you weren't already really focused on fostering the talent within your team that you would make a good navigator. These folks are positioned in the organization within their teams and regardless of the navigator role, they're senior leaders. Their responsibility is to ensure that the more junior folks on their team understand how to make decisions, how to negotiate trade-offs, how to seek advice.

If we don't have any navigators today that were not already doing that work and I can't anticipate that we ever would, because when you have a leadership role in the organization, when the organization really trusts your judgment, almost certainly you're also committed to fostering the talent within your teams and the organization more broadly.

Choosing the Navigators [26:23]

Thomas Betts: So did people apply to be navigators? Were they hand selected and chosen like, "Hey, I think you should go check out this program"? How did the 12 get together?

Dan Fike: It's a combination of having been around and seeing who those shadow org chart root nodes are. You know where to start. There's a little bit of input from the VPs that run a particular organization like, "Hey, I need somebody in your org. I don't have a good insight. Who do you think? Here's the description of what we need, nominate somebody." Unless they're giving me a junior employee or a manager, no managers, we'll get to that later. Unless they give me a junior employee, I'm probably going to trust their judgment on it.

Managers cannot be Navigators [27:03]

Thomas Betts: Okay, tell me why no managers.

Dan Fike: I knew that was going to come up as soon as I let it slip.

Shawna Martell: So I think it's really interesting when you think about the space of problem that we're trying to solve. So, in a previous life, I was an engineering director. I've done the management gig a little bit, and those folks, what they're really focused on is typically how do I ensure the overall health of my team? How do I foster the individual folks and make sure that their performance is... Lots of performance management, lots of meetings in my experience as a manager, and those folks are much more like team and execution oriented broadly.

What we're hoping that our navigators can bring to that is their deep technical understanding to marry that with the team focus of their managers to make better decisions. So, it's really two different lenses looking at the same set of problems, and we haven't found that including the manager role within navigators gives us that additional plus one that we're looking for in these individual decisions. What we really want to do is marry these two lenses in order to make both people more effective in their role and that so far, so good.

Dan Fike: One of the other ways I like to think about this is one of the mental models we have at work is an engineering manager, their job is to optimize for their team while minimizing disruption to the organization holistically. Whereas a director, really a director is probably optimizing for the organization while minimizing disruption to their team. Since most of the teams are not going to be reporting directly to directors, what you have is a manager and their team very oriented around optimizing for the team. What we can do with strategy navigators is we can inject a little bit of additional optimize for the organization in there, uniquely trying to find where the optimizing for the organization, optimizing for the team actually can point in the same direction.

That different lens, bringing that strategic element that's really about the organization holistically into these decisions is something that often gets deep in the technical details in a way that I don't expect all of our managers to be and I wouldn't expect all of our directors to be. It's a rather unique insight that they can contribute to some low level decisions that shape big organizational outcomes.

Measuring success [29:26]

Thomas Betts: Shawna, you said, "So far, so good." How are you measuring success? What's an example of where the navigator's approach is better than what you had before?

Shawna Martell: I have an example. I really love this example, and I talked about it in our QCon talk too. It was shortly after we released Navigators and engineering strategy. One of the teams that I was navigating had been considering, and is often the case with a new platform, considering and reconsidering if they were going to build a new platform service. There was a problem that had manifested in several different domains. With a little bit of imagination, you could see how it might manifest in yet another domain. So, they were like, "We're going to solve this. We're going to solve this problem once and for all, for everybody," which sounds great.

I understand where they were coming from completely, but when you really dug into the minutiae and you looked at the actual real nitty-gritty details of the problem, I was pretty unconvinced there really was a one-size-fits-all solution to solve this for everybody. Before strategy, before Navigators, I would've needed to build consensus with a bunch of different people with product, with the engineers, with engineering leadership. I would've had to go on this road tour of this is why I think we shouldn't build this particular platform and then convince these groups probably one at a time, slowly building this sphere of consensus. I'm quite certain that it would've been slow and tedious.

By the time I was done, I might've been a little bit grouchy about it, but now I was the Navigator and I also knew that the strategy said we don't build platforms as a one-size-fits-all solution. We find a problem. We solve that problem with that customer in partnership and then we iterate. It was really easy as the navigator now armed with a strategy to hold this decision up against that strategy and say, "This is not how the organization wants to start new platforms." Product engineering, that was actually really honestly the end of that conversation.

I know I was much happier that I didn't have to do this slowly build your consensus sphere over time and hope that everyone remembers that you talked to them three weeks ago. It's empowering to be able to say, "This is how the organization thinks, so this is how we should operate."

Thomas Betts: I like those as the default answer. If you follow the strategy, that's fine. There's always times when it makes sense to do something different, but you now have to convince me that it's worth it to go off our strategy and make a good argument. Often that's where it falls apart. Whereas if you're going back to your old process of choose A versus B and you're rethinking about it every time as opposed to A is the standard and B is different as opposed to A and B are equal, it changed that decision process a lot.

Shawna Martell: Well, and it was really useful for it to be really clear who the decision maker was. In a pre-Navigators world, I probably would've needed to not only convince people that this is what I thought and this is why I'm right, but this is why they should care. Navigators smoothed all that over pretty effectively.

How to get started [32:30]

Thomas Betts: So if someone is listening to this and thinking, "Oh yes, there's definitely some stuff that sounds familiar," I know I'm internalizing this and thinking about stuff in my organization, what would be some advice on how to get started? Maybe it's not to create the Navigators program exactly the same, but where should they be looking? What are the pain points and how you get started? What are the solutions you should be thinking about?

Dan Fike: So a Navigators program without a well-articulated organizational strategy isn't going to do much by itself. The first place you got to start is going to be the strategy and the problems you're looking for that indicate that you're missing a strategy are going to be largely rooted in either really slow decisions, decisions that keep escalating up where it seems like they shouldn't need to, or a sense of being lost amongst the people on the team. The big sign for us was people saw other decisions and were like, "I don't know why they do this and we do that." It's not even I don't know why they do this. It's maybe we should do theirs. Maybe they should do ours. I don't know which is right. So, these are the symptoms we were seeing.

It's largely qualitative, right? It's not a number. It's not like, "Oh, we had at least 14 projects that came in late in Q3." It's not a number like that. It's very qualitative in terms of how people seem to be struggling and what's escalating that shouldn't. So, the first step there is not navigators. Navigators are a means to landing the strategy. Strategy is where you want to begin. For that, like she was saying earlier when she was talking about Will Larson's blog post, you want to start with looking at the decisions you've already made. Look at a couple design docs, look at the past ones, write a few new ones, and try and pick apart these principles. Find something that's not controversial.

Start there, put out three things, then four things and five things that nobody's going to argue with. Once you start to land those, you'll see a lot of people will be a little upset at the reality that they're in. They will. They won't like that our decision making is actually everybody does what Mark says. They're not going to like that. It's a decision-making policy, but it seems to be the only thing that we've been doing, and it's from there that you can start to actually figure out the quality of life changes. You need to make to your strategy to help the people who are making decisions and help the organization land in a better place.

Thomas Betts: It's funny that you said it's qualitative and not quantitative, but you're saying you need to write down where you're at and then it's the same principle as you need to measure something before you can improve it. So, we can't come up with a solution until we know what our problem is and the first step in knowing our problem is what do we do? That gets to a lot of things about just engineering culture and the way things operate. You're right, taking the time to think about that, write it down and understand it.

Archeology helps to understand your existing, unwritten engineering strategy [35:13]

Dive in a little bit more when you said go find the design docs, because it seems like going back to that map analogy, you have those little waypoints that you've hit before, but maybe the design doc just said, "Go do this," and it doesn't say why. How do you tease out the why from that document?

Shawna Martell: It depends, and I am not trying to be smart, but it is true. I think that this is a little bit of archaeology. Once you start digging through your past design decisions, it's going to become clear the implicit trade-offs that the organization is making. I bet you a lot of them are not going to be written down explicitly in any of those design docs, but you're going to see that we're really leaning into performance over scalability right now. That's clearly where the organization is trending. Is that right? Is that wrong? I don't really give a hoot. I'm going to write down what I have discovered in the archaeology of our past decision-making to say, "This is what we're deciding today."

I don't think that I can think of a single thing in our strategy that when we looked back at past decisions, it was explicitly in one of the documents that we did A and that wasn't really how they fell out. It's the stuff that's in between the lines as to why did we do this thing that was for performance, instead of scalability. While we have to tease that out, it's not explicitly in those documents.

Dan Fike: At the end of the day, there's a bunch of things that nobody wrote at all. Nobody even mentioned scalability anywhere in this doc. Nobody even considered building a microservice for this. They just added new endpoints. There was no debate about whether or not that's even the right answer. They just did it.

Thomas Betts: Yes. So, start with figuring out where you are. Come up with a strategy of where you want to go, and then once you know where you want to go, figure out the right people to help you make those decisions following the strategy. Is that basically the summary?

Shawna Martell: Yes, and I think that engineering leaders who are listening to this almost certainly have in mind a handful of people in their organization already. They're thinking of the folks who when they need to make a tough decision, these are the people they go to or these are the folks that everyone's always going to them for advice. That's probably where you're starting. That's probably your first set of navigators and you're going to need to figure out how do you deploy them effectively across your organization. It may be that it's perfectly lined up and you have one per team and you can just go have lunch, but it probably won't be that easy.

You will probably have some teams where you actually need to insert someone who isn't there right now and expect them to gain the context in order to be that team's navigator. Dan does that to me all the time, so I think that you have different folks who are going to be able to operate in different ways. Your senior leaders, though, they know who these people are.

Thomas Betts: Well, I think that's a great place to end. I think, like you said, the senior leaders who are listening to the podcast are going to say, "Yup, I know I'm going to go pick out Dan, and I'm going to send him over there." I want to thank you again, Shawna and Dan, for being on the InfoQ Podcast.

Dan Fike: Thanks a lot for having us.

Thomas Betts: Listeners, we hope you'll join us again for another episode soon.

Mentioned:

• Accelerating Technical Decision-Making by Empowering ICs with Engineering Strategy
• Staff Engineer by Will Larson