Transcript
Fike: I’m hoping you all can help us settle something. We’ve been trying to figure out something between us. She thinks she’s right. I think I’m right. We figure, there’s a bunch of very clever engineers out here. Let’s see who they think is right. The decision we’re trying to make is turning out to be a little more controversial than we’d expected.
Martell: Historically, we’ve built our systems using Django. Our monolith uses it. A lot of our standalone services use it too. We’ve got a new team. They’re looking at bringing up a new service, and they really want to use SQLAlchemy instead. My take on this is that Django will meet their needs and do the job, and it’s good to keep a consistent approach across our teams and projects.
Fike: I don’t disagree with this sentiment, but Django is a whole web framework. It’s so much more than we need. We use it today to build REST APIs and legacy SSR pages, but this team just needs an ORM. Asking future hires to ramp up on an entire web framework just for that seems excessive. It’s like trying to plant a rose bush with a bulldozer.
Martell: I don’t disagree, but I just don’t think it’s the right take in this case. Can you help us out?
We’re not here to talk about Django, or SQLAlchemy, or any ORM. We’re here to talk about the debate, the decision, because this decision, like most hard decisions, doesn’t have an objectively correct answer. It depends.
Fike: This is always the answer, it depends.
Martell: We weren’t even talking about the feature sets of these different technologies. Do we need something that supports Postgres specific column types? That could be an input to this decision. Instead, we were talking about the principles and the people. It’d be a lot easier if we only had to deal with the technology, because the principle and the people’s problems, that’s when it gets real sticky. Getting all the priorities and context into a room and ensuring that it’s considered can be a lot of work, and in my experience, sometimes just pretty frustrating.
Often, you go through all this work. You talk to all these people, and you end up just making the same decision. Maybe you feel a little bit better about it, but the more time you spend in these debates, the more likely it is that everyone’s going to walk away saying, we don’t have an engineering strategy. What we want to talk to you about is some changes we’ve made to how we work at Carta, to consolidate the inputs to these decisions and empower our engineers to drive outcomes with higher conviction and in less time.
Background
My name is Shawna Martell. I’m a senior staff engineer at Carta.
Fike: I’m Dan Fike. I’m the Deputy CTO at Carta.
We are the creators of a program at Carta that we call navigators. Navigators are essentially individual contributors that we task with applying and evolving our engineering strategy. The real core thesis behind navigators is that it exists to empower our individual contributors to lead, to do their best work, and to land better outcomes for themselves and the company. I imagine some of you are here trying to develop leadership skills in yourselves and others might be here trying to develop it in your peers and your teams.
Some others, like Shawna and I, are probably here for a bit of both. Shawna and I are both individual contributors in fairly different leadership roles, and we’ve taken very different career paths to get here. We have both seen and participated in several past attempts to make decisions more quickly. Nothing has worked as well as what we are doing now, which is why we want to talk to you about some of these past attempts we’ve seen and why they failed. We want to talk about what we’re doing instead. Why it’s working. What we’ve learned along the way. What you can do to recreate this.
The Importance of Leadership in Decision-Making
Martell: If you’re building software of any complexity, or you’re selling software in any complex business space, your life is invariably filled with questions where the only correct answer is, it depends. Do we need a relational database or a non-relational one? Do we want to buy this off the shelf or build it ourselves? Can this procedure be eventually consistent or not? Do we want to move fast and accrue some tech debt or do it right the first time? Do we want a monolith or microservices? Are we going to push or pull?
Fike: It depends.
Martell: You said it depends. What does it depend on?
Fike: It depends on a lot of things. It depends on how much it’s going to cost. It depends on your time to market and other business goals. It depends on the existing architecture patterns in play today. It’s going to depend on the staffing of the team, their skill set, and who’s going to be the long-term owner of this. It’s going to depend on your performance requirements and your failure tolerance. I’ve seen architecture decisions decided by whether or not our support staff observe daylight saving time.
Martell: It depends on a dozen things. Which one is most important?
Fike: It depends.
Martell: This is why leadership is so important. So much about leading is making decisions. What do we do? We put on our leadership hats, and we do some research and we make a decision. How does that play out in practice? On my experience, it’s often countless documents and meetings. Then, in the really worst-case scenarios, you end up in a situation where the meeting is actually about the document and not the decision, or you’re negotiating the decision-making of others.
Often, you find yourself chasing consensus, and consensus can get pretty hard, especially as your organization grows. You either need to get a representative from all your teams into a room, and that doesn’t scale particularly well once you have dozens of teams, or you have to slowly build your sphere of consensus over time. How does that look? Probably looks something like this. You got to get some time with Sarah, because she’s the real influencer in SRE, but Mike from infra, he’s going to have some input too.
Based on his feedback, you have to go back to Sarah. Then go talk to Omar. His product’s going to have a bunch of work, but you need he and Mike to really iron out a few of these details. You can’t forget about Jill in product. You can spend weeks, if not longer, building this plus one at a time consensus tree, and then by the time you’re done, half the people you talk to don’t remember you ever talked to them.
I’m being a little bit cheeky here, but like consensus, it can be a pretty big time sink. Sometimes you get to the end of this exercise, only to realize no one actually agrees on who the final decision maker is. I’ve seen this a lot in my career. I’ve also seen several examples of companies trying to streamline this path to consensus, and very frequently it takes some form of committee. In one case, it was literally called the Jedi Council.
Fike: I’m a big Star Wars fan, and even I found this one really hard to believe.
Martell: Dan, I find your lack of faith disturbing. This isn’t an obviously silly idea. It’s got a lot going for it. It’s really clear who you need to convince. The decision makers, it’s pretty plain. You can even get time with them during their biweekly review hour or whatever, to bring your proposal. It has some drawbacks too.
Sometimes it ends up being a thing you have to go present your proposal to get promoted or to establish your clout. It can be really hard to know how much context to bring to the committee, because you don’t know how much context they need. I’ve even seen cases, especially in larger organizations, where you can end up waiting weeks to get a slot, and maybe you’re blocked that entire time because you don’t have the committee’s blessing yet.
Carta Engineering Architecture Review, and Engineering Council
Fike: We’ve tried a few simpler versions of this at Carta. When we were smaller, we had something called the engineering architecture review. This was a periodic meeting where some engineer would throw a proposal onto the agenda, they’d show up, and all of our most senior engineers from different products would just show up and weigh in and offer feedback.
The idea was, if you can get the blessing from that crew, if you could get them happy, you were probably making a good decision. Anybody want to venture a guess how that played out? In practice, consensus was just impossible, and it was really unclear how to make a decision in light of that. Slowly, engineering architecture review just became the place where neat but controversial ideas would go to die. People started just finding a way to work around it entirely. We scrapped that, and we put together something we instead called the Carta Engineering Council. This is another council.
This was a smaller group, and it was curated to have a specific membership that included some staff-plus engineers and some VPs and some managers from around the company. The idea was, instead of them having this de facto role of saying no to bad ideas or just ideas they couldn’t agree on, they were explicitly tasked with saying yes to good ideas. They saw a lot of ideas and got a lot of questions. You can see some examples up here. There are conversations around tech debt, conversations around new technology and best practices.
If anybody was building something complex across team boundaries, where they typically would find themselves unsure who to consult or who makes a decision, who approves it, the council existed in theory to provide those answers. In practice, your council members were too far from each other in their day-to-day work, to actually have any shared principles that inform their decision-making, and they were often too far from the work that was being discussed to actually participate in the discussion very effectively.
When you don’t have the right context to critique an idea, you often fall back on critiquing the proposal, like the document and its structure and stuff like that. The Carta Engineering Council wasn’t as destructive as the engineering architecture review of the past, but it wasn’t terribly helpful either.
Engineering Strategy
Martell: This whole time, Carta was going through a lot of change, changes in leadership, rapid growth. We were outgrowing our monolith, acquisitions. The list really goes on. All of these changes made it harder for our engineers to make decisions with conviction. The tools we had to offer them left a little bit to be desired, and we found ourselves in this position again, where folks were saying, we don’t have an engineering strategy.
It turns out that this is actually the root of our problem, even when we knew, ostensibly, who could decide something. Without some set of shared principles, that decision could, at best, feel arbitrary or unfair, and at worst, just never get made at all. It means when we say it depends, folks don’t know what all it depends on or how to resolve those dependencies. We did something that probably seems pretty obvious at this point, we wrote an engineering strategy.
Fike: I can hear some of you saying, “I thought this was a talk about navigators, not strategy”. You are in the right place. Navigators works at Carta because of our strategy. I know some of you hear the word strategy and are going to picture very different things in your head. Let me go ahead and tell you what strategy means to us, because a strategy is not a vision and it’s not a plan. A vision is just an outline of where you want to be in the distant future, whereas a strategy, these are the real principles in play that you can apply to help move closer toward that vision.
A plan is just the actual work you’re going to do. Ideally, the vision is going to inform your strategy, and you employ the strategy when building your plan. I know it gets pretty abstract talking about strategy. Here are some concrete examples from ours. If you look at that first one, it’s actually pretty easy to imagine architecture decisions and sequencing decisions that are more or less made easy by trying to pursue that. To put it very simply to the engineering organization at large, our engineering strategy, it’s just the principles and guidelines that drive our decision-making.
Martell: We did have an engineering strategy. We were making decisions, weren’t we? Even if we’d just been flipping a coin on every decision, which I can assure you we weren’t. We were making decisions underpinned by some principles. If we had been flipping a coin, wouldn’t have been fair to say our strategy was to spend no time making decisions, and just go-go-go.
Fike: There are probably people who maybe think they don’t have a strategy, but in reality, the strategy exists only implicitly or culturally. We would argue that that’s not enough. There’s a lot of power in simply writing it down. Half of the value in writing it is going to come from the writing process itself. It really forces you to think deeply and critically about why this is the right principle for your company.
Since good writing pursues brevity, it also forces you to differentiate between the principles that actually provide valuable decision-making characteristics and those that might just be your opinion. Lastly, if you write it down, it gives you something to argue about. I’m only half joking. You might think that you and your peers and your teams are very aligned, but you would be surprised at how much misalignment is going to surface just by simply trying to document this.
Martell: Most importantly, once we’ve written it down, it allows us to elevate our ideas, to give voice to the engineering organization itself. This isn’t just your opinion. This is the company’s opinion. Instead of engineers needing to ask, what does Matt or Karen think about this? They can ask, what does the company think about this? Additionally, once it’s written down, it becomes much easier to communicate changes, because your strategy will change over time.
Fike: We’ve never written anything quite like this, especially at an organization with 400 people. When we set out to do this, we started doing research, looking for prior art. How have other people approached this in the past? One of the things we came across was this guy, Will Larson. He’s written extensively about engineering strategy.
This really jumped out at us, because Will Larson also happens to be the guy who literally wrote the book on staff engineering. We subscribe to so many of his thoughts on IC leadership, and frankly, you should too, that we really took his direction on engineering strategy to heart, and we sought to apply his learnings.
Martell: This whole time while we were doing this work, we were actually between CTOs. In a lot of ways, it was up to a small group of us to put this together. Then, a few months later, we got a new CTO, it was Will Larson. You can imagine how validating that felt.
Fike: Will’s perspective is actually an extension of Richard Rumelt from his book, “Good Strategy Bad Strategy”. As such, our strategy really has three primary components to it. The first is the diagnosis. This is really describing your current situation. What’s working well, what’s working poorly? You’ll see an excerpt from ours on the right there, just to serve as an example. The second component, this is where the real guidance is. These are an outline of the principles that underpin our decision-making.
Ideally, these follow from the diagnosis. The third component, this is really an enumeration of any actions that we want the organization to take holistically, to either apply or maybe even just enable that guidance. Sometimes a strategy might only have guidance and no action. That’s totally cool, too. As we put this together, we were really focused on what we were doing today. When we looked around, as you might imagine, there are one or two areas where maybe things weren’t working quite as well as we’d hoped, where maybe in the past, we’d seen some of the wrong things get prioritized in our decision-making.
We were very tempted to fix that, to create guidance that would explicitly prevent that. We knew, if our engineering strategy was a wish list of how we could imagine the company operating in some alternate universe, it would be viewed as merely aspirational or unrealistic. The engineers in the organization are likely to reject or dismiss it as vaporware. We sought instead to just document reality. How are we making decisions today? What are the principles being applied today?
If we were making decisions with a coin flip, which again, we were not, we should write that in the strategy, and we should feel properly ashamed by it. Once this status quo strategy is out in the wild and the controversy had started to settle, now we could start to enact changes incrementally, where the before and after is very clear, and the rationale for the pivot is well explained.
Martell: Our example here in maintaining the status quo in v1 was around how we’re breaking out services from our monolith. We’d spent so much time thinking about what not to do, which was grow the monolith. We hadn’t spent enough time understanding what we expected people to do instead. At the end of the day, our operating principle there really ended up being, do what works for you.
Fike: Before we rolled this out to the organization, more broadly, we got a couple other staff-plus engineers in the room together in person with our new CTO, really to finalize the details and pick out a couple strategic follow-ups we’d want to land. You can see some notes here. As an illustrative example, know that one of the things we wanted to do was extend the engineering strategy after release with some guidance around how we build platform technology.
One of our other takeaways from that gathering was that we can’t just drop some strategy docs into Slack and ride off into the sunset and consider our job done. We recognize that it can be difficult to understand how to apply that strategy in every team, that there are often going to be edge cases where the strategy doesn’t work as intended. One of the pieces from these original notes that I do want to call out is that we knew we needed to identify some individual contributors around the company that would act as local guides to help other teams interpret and apply that strategy.
Navigators – How it Works
This is really where the idea of what we call navigators was born. How is this going to work? How do we actually make this look? We found ourselves recalling two patterns we’d seen previously, one of which was this concept of what Netflix calls an informed captain. They describe it really well on their website.
For every significant decision, Netflix identifies an informed captain of the ship who is an expert in their area. They are responsible for listening to people’s views and then making a judgment call on the right way forward. We avoid decisions by committee which would slow us down and diffuse responsibility. It is sometimes challenging and always important to identify up front who the informed captain is for a project. We really liked this.
The second thing we recalled that we really liked was this blogpost from Martin Fowler’s blog back in 2021 titled, scaling architecture conversationally. The main takeaway is that the author was advocating that decisions should be made locally on teams. They should be free to act with autonomy, so long as they first satisfy a duty to seek advice. We wanted the autonomy from the Fowler article supported by a well-defined, explicit advice giver, such as an informed captain, but with adherence to a central strategy. This is navigators. It might sound like another word for a committee. It’s not a committee, and I’ll explain why.
In a committee, generally, the strategy would be centralized, and all of this domain and context would be decentralized. Some poor engineer would be responsible for bringing that context to the committee, where it gets combined with a strategy and a decision comes out.
Instead, with navigators, we don’t send the context to where the strategy is. We send the strategy to where the context is. Navigators are already members of the teams they support, and every team is in scope for exactly one navigator. This navigator maintains alignment with that central strategy. They combine it with the domain context and technical context they already have, and they make a decision locally. It’s all decentralized.
Martell: It’s one thing to decide what we want navigators to be. It’s another to decide who we want them to be. I think the best way to describe this is to show you how we roll this out to the organization. Let me highlight just some of the really important parts of this document. How about we dig in to our core thesis? I want to break this into three really important pieces. The first piece here, we talked about this a lot already, it’s really important that our navigators maintain an alignment with our engineering strategy.
The second, we’ve talked about this a bunch too. This is around how we want to boost velocity and reduce our reliance on consensus. The third part, though, this we haven’t really talked about yet. Here we’re discussing what it means to be a good navigator. Navigators are existing technical leaders. They already have deep technical and domain context, and we trust their judgment, but we’re equipping them with a new tool, the engineering strategy. With that new tool, we’re also offering them an extension of the CTO’s authority in their teams.
The CTO is going to hold them accountable for how they use that authority. We’ve decided at Carta that all of our navigators are going to be ICs and not managers. In our experience, giving this type of authority and autonomy to your ICs is uncommon, but we would encourage you not to underestimate your engineers. A sufficiently senior IC can take their deep understanding of the technical details and combine it with a pretty well-informed understanding of the organization more broadly.
Their lens is going to be different from your managers, who are focused, or at least more focused on teams and execution rather than software and systems. We believe that this IC perspective is a critical component in making decisions in software, and not just architecture and design decisions. Carta expects managers and navigators to work together as a team with complementary perspectives. We talked about this at the very beginning.
Most technical decisions aren’t just technical so managers and navigators understand collectively our technical and people constraints and use that information to guide their teams. We find that it makes both the navigator and the manager more effective in their role. To that end, we do expect our navigators to help make technical decisions with their teams about what we build and how we build it. They’re not expected to micromanage every design or implementation, and they shouldn’t be writing every design spec.
They do need to stay close enough to their teams to understand decisions that might conflict with the engineering strategy, and stay close enough to the strategy and the intent behind it to know how to resolve those conflicts. Maybe the engineering strategy is wrong or lacks an exception. Our navigators are best equipped to understand those things and escalate as needed.
Fike: I would wager, some people think this sounds like a bit of a promotion. What do you think?
Martell: I don’t blame you if you think so. In our experience, that’s not how this has played out. For the most part, the folks that we made navigators were already doing this work in their teams already. It’d be hard to convince me you’d be a great navigator if that weren’t true. We really changed these three things for the folks that we made navigators.
We established a well-defined point of contact that even folks outside of their teams were well aware of. We created the opportunity for smoother working relationships with navigators across the organization. Through their very tight alignment with the engineering strategy, they were now given the authority of the CTO within their teams.
Fike: I put up a slide earlier that said we wanted 12 navigators. I also said we had 400 people in the organization, and full coverage, everyone has a navigator. If you do some reasonable math, the manager has 10 engineers. That would be 36 navigators. We do, in fact, only have 12. I wish we had fewer. The challenge in trying to keep this group small is really rooted in having teams that are very siloed, or they operate with some unique context.
In one place in the organization, we had an existing individual contributor, technical leader in an organization of about 60 engineers who had pretty good context on what was going on over there, that was easy. Elsewhere, I had a team of about five people who have a niche skill set and are working on unique data problems. In that situation, I really have two choices. I can add one more navigator to the collection with a relatively narrow scope, or I can find an existing navigator and stretch them over that area to avoid growing the group.
You will find examples of both amongst our navigators. It’s really a balancing act between the effectiveness of any single navigator forced to ramp up on a new area and hold context, and the effectiveness of the navigators collectively, where too many and it becomes hard for those navigators to maintain an effective relationship with each other, and it becomes hard for them to work together to iterate our strategy.
Martell: Navigators are a really important part of the future iterations of our strategy. We’ve already talked about, navigators are the result of our engineering strategy. They’re also the interpreters of our engineering strategy, and we expect them to help us iterate it going forward. This creates a virtuous cycle. The example for us here was around those items we talked about adding to our engineering strategy that were specifically focused on platform technology.
Our navigators being the senior tenured ICs that they are, had seen enough examples at Carta of platform gone wrong and platform gone right to have deep insights into how to help us repeat past successes while avoiding past mistakes. All strategy is inevitably going to be a balance between global optimization and local optimization.
For some teams, it’s almost certainly going to be worse locally. Our navigators are best positioned to identify and help their teams navigate these edge cases, ultimately working to improve our strategy. It also means that no single navigator is quite positioned to own the strategy in its totality. We definitely don’t want it to be blocked by consensus. We talked before about how expensive consensus can be. We would recommend that your strategy be owned by your executive, a CTO or an SVP. I’m going to keep saying executive, but it doesn’t have to be the CTO.
Really, any senior leader can own your strategy. Your navigators are going to be a resource to that executive, helping them understand how to, over time, iterate the strategy. Also, your CTO or your executive is going to be a resource to the navigators. We’ve been incredibly fortunate to have a CTO that works really closely with our navigators, and that’s created a relationship that’s symbiotic, making everyone better in their role. It’s honestly a unique group in my almost 20 years of working, and one that I’m incredibly proud to be a part of.
Fike: I totally agree with that. We’re about a little over a year into it now. We’re on our second cohort of navigators. Shawna, how do you think it’s going?
Martell: Pretty good. It’s not just us who think so. We’ve gotten really great feedback like this. Decisions going from months to days is quite literally exactly what we were going for. I know it’s one thing to throw up this mostly anonymous quote and be like, going great. I’m going to tell you a story of a before and after to show you how this has changed our decision-making. Let’s rewind all the way back to the beginning. Should we use Django or SQLAlchemy?
This is a real decision that I had to make several years before we were talking about navigators or engineering strategy. I’m going to tell you the truth. I talked to so many people, and I spent so much time making this decision. In the end, I think I made the wrong choice. We deviated from the common Django model, and we used SQLAlchemy instead. With the benefit of hindsight, and now our engineering strategy, I would go back and change this if I could. I want to contrast that with a decision that we had to make after navigators and engineering strategy.
One of the teams that I was responsible for navigating was discussing building a new platform service. We were encountering a problem we’d seen a few times previously, and it really didn’t take that much imagination to imagine it showing up in some other domain in the future. The team was excited to dig in and solve this problem once and for all. It’s true, there were a lot of surface area similarities, but when you dug into the details, it seemed to me there was enough deviation that a platform wasn’t immediately obviously the right choice.
In a pre-navigator’s world, I was going to spend a bunch of time, and I was going to talk to a bunch of people building consensus around the idea of not building this platform. I was also going to have to convince people who in the world the final decision makers were. In a navigator’s world, as the navigator equipped with our strategy, I could very easily say, no, we weren’t going to build this platform because it wasn’t aligned with our strategy.
It actually wasn’t aligned in several different ways, but I’m going to highlight just one of them here. This was trying to be a one-size-fits-all solution: solve it once for everybody. Carta had decided that wasn’t how we wanted to start new platforms.
Fike: I really like this example, for a number of reasons. First and foremost, it’s very clear who the decision maker was. You also had documented guidelines to inform your decision-making. You could hold that decision up against the engineering strategy to show others how it was and wasn’t aligned. You didn’t have to litigate or relitigate the principles that inform that decision. You could just weaponize the platform strategy.
Martell: In a lot of cases, navigators can resolve these issues in their teams, like in this case. If there are cross-team concerns, we expect both navigators to be involved. This cropped up for us last year just as ChatGPT was taking off. Our data team and our SRE teams were misaligned on how to ensure that our engineers could prototype with the software while not running afoul of our data handling policies.
The two appropriate navigators got into a room, and they were able to find a direction pretty quickly. If they hadn’t been able to gain alignment, then we would have expected them to escalate. Escalations are actually a really important part of how navigators navigate. I know that word has a negative connotation. Something gets escalated, then something went wrong.
Fike: Wrong? It means something went right.
Martell: When you’re trying to increase the velocity of your decision-making, escalations are actually really great. Our intention is to inject strategy locally, so that we can decide things locally. That’s not going to work in 100% of cases. You’re going to have decisions that involve the tradeoffs of business priorities of multiple teams, and that’s something that navigators alone can’t fix. Those types of decisions need to go to someone with a wider field of vision, so you need to escalate. Give it to somebody who can reconcile misaligned incentives or competing business goals. The quicker you escalate to that person, the quicker you’re going to get a decision.
Fike: As often as we’ll find navigators escalating up to our executive, interestingly enough, we’ll also find our executive escalating to our navigators. Maybe escalating isn’t quite the right word there. If the executive found themselves in a unpleasant phone call with a very high profile customer, or if they’re hearing incompatible stories from different parts of the organization, a navigator can actually be immensely valuable as a direct resource for that executive.
They’re not uniquely capable of doing so, but the navigator’s existing relationship with that executive, their well-defined area of scope in the business, and the confidence that that executive has in their deep technical context can give that executive a very accelerated path to the answers and action that they might need, following those events.
Implementing Strategy (Strategic Thinkers and Navigators)
We talked about a lot of stuff so far. Consensus, bad, strategy, good, navigators, useful. Maybe some of you are thinking of trying it yourself. How do you go about that? We would encourage you, no matter whether you’re an IC or an executive, wherever you are in the organization, start by writing down your engineering strategy and make sure it reflects the truths in play where you are today. Take the wish list that might come up along the way and set that aside.
After you’ve got this out, then it’s time to start identifying some concrete follow-up actions. These can be actions that are part of the strategy, or things you’re going to want to do in like v2. If you’re an IC out there, you can just work on a team strategy. This doesn’t have to exist only for the entire engineering organization. Remember, when you’re writing, half of the value comes from the writing process itself.
After all, writing is organizing your thoughts. If you’re having trouble figuring out where to get started, look back, look at decisions you’ve seen made already. Why was tech debt acceptable in situation A and totally unacceptable in situation B? Dig into that and understand the principles that are informing these decisions. This is going to help you understand what your strategic guidance should be, and maybe where it needs to change going forward. We mentioned earlier, we got a lot of guidance from Will Larson before we started this.
The most valuable piece of guidance we got from him at all was to just do it. I’m going to shamelessly quote him, “Start wherever you are, and start now”.
Martell: I can assure you, if you’re looking for reasons not to get started, they will be absolutely everywhere. You will be missing context and information, and that’s ok. You’ll be surprised at how much you learn just by getting started. You’re also going to have pages of stuff that looks like this that you end up just throwing away later. We have so much stuff that didn’t make the final cut. Some of it was just aspirational and unrealistic. A lot of it was simply broad and unactionable.
If we’re being really honest with ourselves, some of it was just us pontificating. If your strategy doesn’t help you make decisions, it’s not strategy. Maybe you still want to write it down, but write it down somewhere else. This is one of my favorite examples of something we just cut, only accrue tech debt intentionally. I agree with that sentiment completely, but if you’re already having a discussion around tech debt, you surely have at least formed some intentionality.
If you aren’t, writing it down in this document probably wasn’t going to change that. We couldn’t see how this was going to substantially change our decision-making, so it didn’t make the final cut. If you’re the IC on the team and you’re writing the strategy, congratulations, you are also now the navigator. Ask yourself, how can my strategy inform my team’s decision-making? You have a new tool in your toolbox now, use it, and show other people how to use it to make decisions.
Once you have a few examples of your strategy informing your decision-making, empower your manager to encourage other teams to write a strategy too. This can work from the ground up, especially if you can show results, because I’ve never met a manager who didn’t want to hear about better, faster decision-making.
Fike: If you’re an executive or a senior manager out there, you’re probably already aware of who the people are in your organization who are strategic thinkers, who are supporting the company more holistically, get them together and collaborate on a strategy with them. If they’re included in the process, if they have more ownership over this strategy, they will be more aligned with it, and they will be more effective at implementing it in their teams.
These ICs, these are probably your first batch of navigators, and you should see how far you can stretch them, maybe further than you have in the past. After you’ve done that, now it’s time to find some other folks to fill in the gaps, but only if you’re confident in their ability to align with that strategy, to collect new context, and to demonstrate good judgment.
Martell: We understand that the navigator’s pattern has some risk with it. You’re putting a lot of trust into these ICs to make decisions with autonomy, and it’s a lot of responsibility. It’s another reason why this accountability piece is so important. Your executive needs to be prepared to hold these folks accountable for their decisions, and another reason we think it’s important to keep this group pretty small. You won’t get it right the first time or the second time, and probably not the 10th time either. We took two-and-a-half months to get this from idea to launch, and we’ve been iterating it ever since. Success is finding ways to adapt as your organization learns and grows.
Recap
Fike: Essentially, a written strategy and a dedicated group of individual contributors can really help us skip out on consensus and accelerate decision-making. That same group of individual contributors can help us iterate that strategy and act as a very valuable resource to your executives in other ways. At Carta, we have found this to be very transformational in how we work.
Questions and Answers
Participant 1: How easy is it to form staff engineer in Carta, the navigators?
Fike: Staff engineer is almost like an orthogonal axis on how we think about these. We do have levels that go up through staff engineer. Most of our navigators, not all of them, are staff engineers. There’s definitely a lot of intersection in what constitutes a good staff engineer versus what constitutes a good navigator.
Generally speaking, a staff engineer is going to be accountable to the team for some outcomes in slightly different ways. Navigator’s jurisdiction really starts and ends around the engineering strategy for the company. It’s the reason we call them navigators and not cartographers. They are there to follow a map that they’ve been given and ensure that it works well, and surface areas where it doesn’t. They’re not going to be making decisions beyond that.
Their authority doesn’t extend outside of the context of what the strategy is really espoused to cover. Staff engineers are going to have slightly different roles. We put up earlier, navigators are not micromanaging every decision, and they’re not writing every tech spec. I don’t think staff engineers should be doing that either. It’s closer to what a staff engineer role might be in a team, in that they have accountability beyond what the strategy says, and more locally, to even things the strategy is indifferent about.
Participant 2: In your company, how do navigators work together? How do they collaborate, or do they at all? Because you could say, they work in different teams. They are the decision makers that apply the company strategy in their respective teams. Maybe there’s no need for them to even talk to each other, but I assume they do. How do they work together? What does the relationship look like?
Martell: It depends. It is the truth. When we have things that cross team boundaries, the expectation is that both navigators would be involved in making that decision. It’s a place I go when I have something that I’m trying to align with the engineering strategy and I want a second opinion. We don’t work as a collaborative. This isn’t a cabal. We’re individuals that work within our teams, but we are people who work together to answer strategic questions and place to get advice. It’s a place that also our CTO will come to us for advice.
As far as like, do we work together in a committee and have lots of meetings and stuff? We don’t. It depends on the individual situation. I talk to other navigators at least every week, if not every day, about something.
Fike: From a process point of view, there’s a navigator Slack channel, and that’s really it.
Participant 3: How would you compare this role to enterprise architect or technology architect?
Fike: In much the same way I was talking about staff engineers earlier, architects are going to have obligations beyond what the strategy is covering. For example, the Django and SQLAlchemy example we put up earlier, the strategy does have an opinion on that, because of Django’s existing presence in Carta.
If somebody was building some new service to do something, we’re writing Java code, and we need to understand the right way to represent timestamps and deal with time zones, because there’s 45 ways to do that in Java. How are we going to do it in our process?
The strategy does not care. Somebody should care. Somebody should try and pursue consistency locally for that. Architects, or even tech leads are well suited to do that. I think that there’s a world where the way that tech leads and navigators work with managers ideally looks the same. I don’t think all tech leads do. We all have examples out there, counter examples. I think good tech leads will interoperate in much the same way we’re trying to establish our navigators do, in terms of collaborating with managers to take in context that’s beyond the technology.
Participant 4: One of the things that I’ve seen when we’ve done something similar, or we’ve tried something similar, is that actually maintaining that strategic alignment between these types of people becomes quite difficult, particularly if they come from different backgrounds or radically different parts of the company. What are your tips and tricks for actually getting that alignment?
Fike: It’s not always easy. I’m not going to say tense, but it’s not always easy. We haven’t really had many examples of needing people to disagree and commit, and that’s in large part because our navigators tend to be people who are tenured and understand a lot of the rationale behind what we’ve done. We haven’t had someone we hire recently coming in without the deep Carta context, and then we throw this responsibility on them. We have had some disagree and commit, although it’s usually more about the surrounding decisions around how this strategy gets applied, as opposed to the raw principles therein.
The raw principles are pretty well agreed upon. Part of how we get that to work is by avoiding the stuff we might be tempted to put in there that’s just opinions. I have a lot of opinions about how maybe we should do something differently, or one way or another. That does not belong unless these are truly dealing with some diagnosis we’ve established around what’s working well or working poorly at the company. It’s short. It’s succinct. Our entire engineering strategy document is two pages.
Participant 5: I was wondering about the concept of scalability of this idea of just making a group not too large? For a couple of hundred people, that might work, but what happens when the company grows to thousands or tens of thousands of people? What is your feeling on that?
Martell: I think we feel pretty confident that we’re not totally sure. We haven’t done this at an organization any larger than the one that we have. This is me talking off the cuff, imagining how it might work. It could very well be that, instead of having a group of navigators that, in our case, really is very closely aligned with our CTO, that you have lots of individual groups of navigators that stay closely aligned with their engineering executive. Maybe it is an SVP. I used to work at an organization of 120,000 people, which is more.
What I imagine if we had tried to get navigators there, there’d be a little bit more localized groups that did adhere to engineering strategy that maybe does come from the top, but actually has its own individual strategies in their pockets of the world. We do even see that at Carta. There are individual teams that have their own strategy documents that inform their localized decision-making.
Participant 6: Is there a relation and how does it work with product managers, with product development by the navigators, or there is no relation and they don’t show up with that?
Martell: There’s no official relationship that I can think of in anything we have written down. I’ve historically worked on a few different teams as their navigator, and in 100% of cases, I was also dealing with our product folks. I think that at Carta, it tends to be that our senior engineers do generally work with our product folks more than in some of the other companies that I’ve worked.
There are definitely senior engineers who are not navigators that work very closely with their product counterparts. It’s something that I think actually is very refreshing at Carta that the engineering and the product stay pretty well aligned, at least in my experience. It’s not unique to navigators.
Fike: I actually think that the reason our navigators are working so closely with product is because they’re existing technical leaders, they’re really good senior engineers, and all of them should be close to product.
Participant 7: I think what you’ve shared is very interesting. In my opinion, it’s within the spheres of engineering. How does that play out when you bring in the business side of things, when you bring in the priorities that this is really something we should be working on now, not later? Were there any showdowns between the navigators and the product managers? How does engineering strategy play alongside with product strategy, if there’s such a thing, at Carta?
Fike: One of the main reasons we wanted to establish this engineering strategy to begin with, is to help settle these debates. When I tell a product manager, actually we need to slow down and build this right, I have the voice of the executive in the strategy that is written for the whole engineering organization, to wheel in that conversation. It no longer becomes, this product manager assuming I’m just an engineer who likes to do things one particular way.
It becomes, no, this is a very deliberate calculated move on behalf of engineering to say that this particular audit logging, we must have audit logging, or some security thing. It’s established and proven, this is something we need to do. There are things we didn’t put in the strategy explicitly because we actually might want them to bend toward product a little bit more. That’s ok.
Martell: In the example that I mentioned where I ultimately had to say no to a proposed platform, that original idea actually had come from our product organization. We had to have a conversation about why that particular approach was not going to be the solution to this problem. I was able to use the engineering strategy as my tool there.
See more presentations with transcripts
