S2E40 – Defining Technical Strategy

Show Notes

What is technical strategy? Is it a document explaining how to extend your data platform? A set of wiki articles on how you’re tackling technical debt? A forward-looking treatise on how you will integrate generative AI into your tech stack?

In this episode, Mon-Chaio and Andy dive into the intricacies of creating a tech strategy for engineering leaders. They explore why having a guiding doctrine is crucial for decision-making processes in tech organizations. By discussing concepts like Wardley Mapping and the distinctions between strategy and operational effectiveness, they offer insight into establishing a unique value proposition, integrating choices across value chains, and maintaining a long-term strategy even amidst distractions.

Tune in to learn how to formulate a technical strategy that aligns with your business goals and propels your organization toward sustained success.

References

• The Role of the Chief Technology Officer in Strategic Innovation, Project Execution, and Mentoring
• Strategy: Creating and Sustaining Competitive Advantage
• Corporate Strategy: Past, Present, and Future
• Business Strategy and Organizational Performance
• Strategy Mapping with Simon Wardley – Define Tomorrow 2018
• Wardley Mapping Part 1: How and why to map your business

Transcript

Mon-Chaio: All right, Andy, once again, another episode. What are we going to be talking about today? Should we make it up on the spot or should we look to our guide … we don’t have a guiding document, do we, about what we’re going to do in this?

Andy: Are you saying we’re unprincipled?

Mon-Chaio: Yes? Oh, and no. So a little behind the scenes for long time listeners or people that care and maybe this is their first episode. We do have a little Trello board that we use where we plan out what episodes we’re gonna do next. Sometimes that episode list can be four or five episodes long, but very often that episode list is zero, would you say? Or one?

Andy: It’s usually week to week Isn’t that Agile? Aren’t we being Lean?

Mon-Chaio: We very much are. And I think that’s okay. But even though we don’t have a queue for all the episodes that we want to record in the future, we do have two things in our Trello board, don’t we, that are guiding season two. I think we called them themes, maybe? Is that what we called them?

Andy: Yeah, I think they’re written down as themes in there.

Mon-Chaio: And the goal for us was to try to think about what this year might look like, and whether we could have something that grounds us, that gives us directionality, so that we’re just not all over the place. One day we’re talking about the Prussian army, the next day we’re talking about how they build metal water bottles. Although that kind of is how things … devolving, but we have ostensibly a direction, right?

Andy: It’s a random walk in a direction, I think, is what our themes help us with. They give us that little bit of guidance on, is this somehow connected? Oh, yeah, it’s connected. We should go in that direction.

Mon-Chaio: Yeah, and then as we start to go, we might loop around a little bit, but we do have what might be considered some construct of strategy: those themes. And I think for most people, they have this concept that a directional strategy is probably pretty important.

Andy: Mmm hmm.

Mon-Chaio: And that’s actually what we’re going to talk about today, but because we are The TTL Podcast, Tactics for Tech Leadership, we’re going to talk about what does it mean for tech executives to be strategic?

Andy: Oh, so not just what you should find in your strategy document.

Mon-Chaio: Mmm hmm.

Although that may be part of it, right? And I think this topic is interesting because, for the most part, I think people understand what it means for a product leader to be strategic. Often a CEO is your product leader and they understand what’s product strategy means. Something around what is the market research? What’s the next four years of the market going to look like? What are the economic conditions that are going to impact whether we can sell this product? How much we can sell this product? Is our product going to be commoditized, so our customer is going to be able to get it from a lot of different places, or just from us.

Those types of things we think about in terms of product strategy, and I think most people understand that. But, at least in Big Tech, when you go down the technical chain, even beyond the CTO, every technical leader has something that they’re supposed to do with regard to strategy. And then the question I’ve always had in my mind is, well, what is that that technical leaders are supposed to be doing? I’ve seen a lot of variations of it and none of it is has ever seemed to me to be great. And so I thought, well, why don’t we talk about this?

Have you seen that Andy in smaller companies? Do technical organizations do strategy in small organizations?

Andy: Yes. I mean, there’s absolutely clearly the business strategy, the product strategy. The technical strategy shows up as well. It’s probably not usually as formalized, but it’s a thing that’s there and it shows up in a lot of conversations. It’ll be in individual pairing conversations, but it’ll be in like the planning conversation around what are we doing next. It’ll be in the retrospectives about how are we doing. It shows up in all those different places, which I think even just adds to this question of, so what does it mean to be strategic?

If it’s all this stuff that you’re just kind of doing, what is this stuff that you’re doing?

Mon-Chaio: Yeah. What is it? Interesting for me is after we decided that we were going to do this topic, I sat down and I said, well, what are we going to look at? What is the research around this? I did not think that there would be anything related to efficacy of technical strategies. And in a very cursory search, I found nothing. Again, for our listeners, remember that we bias very strongly to things with larger sample sizes that have been rigorously studied instead of your random blog posts written by your appeal to authority. There were a lot of things that were appeal to authority around what a technical strategy should be, but the rigorous study of it, in my cursory search did not turn up anything.

Andy: Yeah, I didn’t find much of anything either. I did look, I was like, what would research into strategy look like? And I think it would ideally look like something about, are different approaches to creating or communicating a strategy more or less effective for outcomes for an organization?

I didn’t really find much. I think I found it for other kinds of strategy, but not for technical strategy. You saw it for business strategy and for product strategy, but not for technical strategy. I did find one article. I didn’t bother reading it too much because it seemed kind of separate from our stuff, but it was for a tech strategy for Chinese tech companies. And I thought that could be interesting, but it was the only one. And it did seem a little distant from where most of our listeners would find themselves.

Mon-Chaio: That makes sense. So because I couldn’t find much in my search for technical strategy, I tried to figure out whether there were other research around strategy that maybe we could draw parallels to, whether strong or weak parallels, to at least frame our thinking, check our thinking. And so I looked into what makes a good business strategy in general.

Andy: Mm.

Mon-Chaio: And the research there was also fairly mixed for me. There were two things that came out of my research that I thought were interesting. One was that when they looked into strategies, they found that hybrid strategies worked better than static strategies. So, this idea that as an entire organization, your organization itself doesn’t necessarily have one strategy. It can have many strategies for many different parts.

. The other thing that I found was interesting was a lot of these research papers started to try to define what strategy is and I thought that might help us ground a little bit.

Andy: Yep, I was laughing because to me, every time I found a definition for strategy, it’s been like the classic, like researcher problem of everyone defines it differently. I can understand how they’re all connected, but they all end up being different and some of them I’m like, ooh, I’d like that one and others, I’m just like, I don’t understand what you’re talking about. So what definitions do you have Mon-Chaio?

Mon-Chaio: So I have many definitions but I actually like what you said that there’s I think a set that they tend to coalesce to. And so as I was reading the research, one big point that came out is strategy is about making choices. Or another way to put it, it’s as a framework to guide choice making.

Andy: Exactly. And that’s what I also came up with all the time, which means that a strategy is not only what you’re going to do or why you’re going to do that, but also what you’re not going to do and why you’re not going to do it.

Mon-Chaio: Absolutely. The other part of strategy that came across to me really strongly about all these definitions is it’s about how you lead to long term success, not short term success, but long term success. So, if I were to distill down my reading of the research into strategy and try to distill it, it would be that strategy is about putting a framework in place guiding how to make choices to sustain long term success.

Andy: Exactly. Did you get that one from Simon Wardley? Because I think that’s almost the exact same definition I heard from him when I was researching.

Mon-Chaio: No, no! In fact, I got it from something completely different. Part of it came from this meta study around the Miles-Wood typologies. Another came from this HBR, I think it was HBR, professor who did this great slide deck on what is strategy, trying to teach strategy to people.

And again, they had all these different definitions, right? For example, the HBR person says specifically: “strategy is the set of long term choices that an organization makes to distinguish itself from competitors. It defines a company’s distinctive approach to competing and the competitive advantage on which it will be based.”

That’s very specific, that latter part, which is why I didn’t include it in the bigger definition. But as I kind of piece them together, that long term choice making framework, that really came out of it. Choice making framework, success in the longterm.

Andy: All right. So I agree with that definition. I think it matches the way that I’ve started to figure this out. But how does that play out? Okay, so strategy, long term choice making framework what does it mean for me? Say I’m mid level in a software organization. I’ve got a few teams underneath me that all have their managers, and I’ve got the CTO above me, and the CTO comes to me, and he says, for your area, I need you to come up with a tech strategy.

What does this look like? What do I now do?

Mon-Chaio: I think, in order to have that conversation, Andy, we need to dive into at least what I found as the next level of what makes a good strategy. And again, this is a generalized good strategy, not a tech good strategy. And then we can try to connect it to tech. And we may disagree with points of this. But we can talk about it.

One thing that comes out is that strategy is not aspirations. It’s not specific actions. And it’s very different from your mission and value, right? Because these specific actions don’t guide choice. They don’t help you make good choices. And I think the mission and value and aspirations are too broad to actually help you make good choices.

So I think that’s one.

Andy: So in my situation, what you’re saying is what I don’t do is I don’t go into JIRA and start creating a bunch of tickets that are like “upgrade to Rails …”, I don’t know what version it’s, on 4.0, 5.0, who knows. And then, ” Rewrite X into Elixir” and things like that.

That’s one thing I don’t do. It’s not these specific actions. But it’s also not go into Confluence and create a new page called “My Team’s Technical Strategy” and then put something on it that says,” we are going to be leaders in our organization on delivering value to our customers. And we’re going to do that by enhancing the functionality of our application through the best of breed methods.”

Mon-Chaio: Exactly. Great, Andy. Those are both what it’s not. And the latter one, some folks might think, but that sounds close to a strategy. What’s wrong with that? And in my opinion, what’s wrong with that is it doesn’t have any distinctiveness.

Andy: Yeah, it doesn’t guide any choices.

Mon-Chaio: and it doesn’t guide any choices.

It might, right? You might, you might say, well it guides a choice because if it isn’t a best and breed method, then we’re not going to use it. Okay, but that’s almost a false choice. Because, of course you’re not going to use non breast and breed methods. Right? And if you’re saying

Andy: I often try to choose the worst methods I can come up with.

Mon-Chaio: just to be difficult, Andy, um, you could also write specifically and the method we’re going to do it is we’re going to do weekly code reviews. I think that’s also wrong because it’s one, too specific. And also secondly, it’s not distinctive. Every company in the world does weekly code reviews. So why write that down?

What does that mean in terms of your strategy? You’re not. distinguishing yourself from other engineering teams in your own company or other engineering teams in other companies.

Andy: hmm. Mm hmm.

Mon-Chaio: So if we move on to the next one that we can think about, this HBS author says that strategy, you have to distinguish between strategy, which is creating unique competitive position.

Again, this is business strategy, so we can try to move it down to tech, creating a unique competitive position and doing things differently. That is strategy versus, and oh, I see this so much, operational effectiveness. Which is assimilating and extending best practices and doing the same things better.

Andy: Right.

Mon-Chaio: part is operational effectiveness. The former part is strategy.

Andy: Right. So my strategy is not, uh, we are going to get our cycle time down to four hours. and have, uh, five nines of uptime in the fourth quarter. So that, that’s also not my strategy.

Mon-Chaio: it is, yeah. And, I will pop, pop, I will posit that your strategy is not. We will move from monolithic to microservices. In order to improve our ability to release faster. and more independently. I would say that’s probably also not strategy.

Andy: Okay. Okay. Like I might be able to get behind

Mon-Chaio: we can,

Andy: We can debate that one little bit, but, uh, yeah.

Mon-Chaio: that’s getting closer. That’s getting closer. He proposes a test for what makes a good strategy. And so I’ll end on this test and then a quick note about why, and then, and then we can talk through your example. So this test has five features to it. First is a unique value proposition versus competitors.

Andy: Mm

Mon-Chaio: Now, how does that translate into tech? Maybe that’s a unique way of doing things that other teams in your company aren’t doing or other engineering teams in your vertical are not at other companies aren’t doing. Second, a distinct value chain involving clear choices about how the company will operate differently to deliver on its value proposition. Okay, that’s kind of similar to the first. You have a different value prop, and how are you going to operate? And I think this starts getting into things like organization, culture, that sort of And I think where processes reinforce that, maybe processes. Number three, to your point earlier, Andy, making clear trade offs and choosing what not to do.

Very, very important. And I actually really believe that it can’t be a strategy if you have not chosen what not to do, okay. Two more. Number four, Integrating choices across parts of the value chain so that the functions fit together and reinforce each other. I think that’s a huge part of strategy. Strategy is around connecting disparate parts. If you’re just a single system, and we can talk about what that means, I don’t actually think you need a strategy. Because so much of strategy is about communication and it’s much, you have much higher bandwidth communication internally that I don’t think using a broad strategy as a guiding principle is as important and maybe is actually less effective than just using more specific principles. So if you’re a two person team, as an example, trying to decide how you’re going to write this piece of software, I think I can just tell you, Andy, hey man, send me a PR every night. I don’t need a strategy guiding me around, oh, our goal is to make sure we get multiple I’s on this in order to X. I can just tell you, get me a PR. But when there’s multiple moving pieces, I can’t tell 3000 people, get me a PR tonight, get me a PR Saturday night, get me a PR Friday night, right? So there needs to be something that guides and connects. And so I think that’s what number four is about. It’s about how does the strategy integrate these disparate pieces and help make them more part of the whole.

So that’s number four. Number five, the continuity of strategic direction and the continuous improvement in realizing the unique value proposition. And then he, he, he ends sort of, I wouldn’t say he ends, but the last part is, again, that the essence of strategy is about making choices. It’s about guiding people to make choices. And I think a lot about that with autonomous teams, because when you have autonomy, you want them to be able to make their own choice. But, going back to number four, how do you guide them so that when everybody is off making their own choices, they’re more likely than not to reinforce everybody, each other’s choice independently versus do what we do, which is talk about building metal water bottles for 20 minutes.

So those five things, and then the generalization hope, does that help us? Can we use those to extend to business strategy to technical strategy?

Andy: I think it helps us some. It helps us in the outline. But I still don’t think it gives us too much guidance as to like, if I was to walk into the building and look around and say, which of these technical leaders is doing something that indicates that they’re being strategic versus others that are doing something that is not necessarily strategy, maybe it’s something else.

It still doesn’t quite help me. I have a proposal for something that I think might help, and we can see if it would us get something that fits this test.

Mon-Chaio: Great.

Andy: And that’s a specific technique called Wardley mapping.

Mon-Chaio: Aha.

Andy: Now, the basic idea is that to, to think strategically, you need to think with maps.

A map has several characteristics to it. Space has meaning, and it has an anchor. You can think about a physical map of, of a country or something, um, it has, uh, orientation to north, so it’s always anchored in some area, like, you can always tell that this corresponds to something else.

And space has meaning, so, uh, his thing is like, if you move New Zealand or Australia over near Bristol, uh, that completely changes. what the world is like and

Mon-Chaio: that completely changes what the map

Andy: what the map means. And yeah, uh, and if it were real also changes what the world is, what your conception of the world should be. And, and so his idea is that this, what you need is to think with a I would say this dimensionality, that you have these axes and these dimensions that mean things, and that you need these maps to help you work your way through it.

Because as you were saying, Mon Chaio, it’s about communication. Primary purpose of this tool is to get people to think through these things, um, and that helps them develop that strategy. His idea is take value stream mapping, where you’ve come up with, you have your users, they have their needs, that their needs are met by certain things, and then those things have what they need that are met by other things, and then so on and so on.

And in his examples, it always comes down in the end to electricity. Like, eventually you just get to the point where you need electricity. It’s it’s a useful one because it, it helps us later. Uh, but you could have other kinds of needs. I was thinking about this recently. The user has the need that can be fulfilled by our software, but the user might also have a need that, uh, that they can, um, trust the software in some way.

So they might have like this more, uh, uh, uh, governance need or, uh, something like that. And then you have a value chain that provides that, uh, uh, need, need for them. So something along the lines of maybe you have an audit trail of the changes that have been made, and you are presenting that to them, or there’s an audit that you need to fulfill it with, uh, showing your test results, things like that, so that they’ll trust the release of software enough to put it out into their production systems.

So, you, you have this value chain, and that’s one dimension of the map. And then you have another dimension of the map, which is where, uh, kind of along the life cycle, the product life cycle, uh, each one of those things finds themselves. And so, for instance, electricity is a utility. There’s, there’s no difference between the electricity I get if I buy it from Eon versus if I buy it from Octopus.

for anyone in Europe. It’s all the same electricity. There’s no differentiation. And so it, It would be insane, it would be strategically weird for you to decide that you’re going to make your own electricity unless making your own electricity has some very clear benefit for the rest of that value chain.

So then you figure out where each thing is in that. product life cycle. Is it Genesis? Is it, kind of being, uh, created? Is it product? Is it utility? And that helps you start informing what kinds of things are going to be happening in that space. So, for instance,

log pipeline probably is somewhere between product and utility, depending on how you view it and what your needs for it are. Well. If I view it as product, if we kind of are thinking that it’s product, then we should probably look at pulling in Elasticsearch and Kibana and Logstash and just building up an ELK stack and running it that way.

If I view it as utility, I don’t care about it, it’s just a thing, it needs to be there, then I’d probably connect everything into CloudWatch. and just live with that or buy Datadog and use it there. It, it’s not a thing that I think about. But if for maybe that governance need that I was talking about for my customer, that the logging for that, the ability to track this stuff is actually not product anymore, or it’s very early stage product, it might be a strategic thing for us to say, There’s an aspect of this that we think we have an advantage in if we do it ourselves.

And so the idea behind the Wardley maps is that through analyzing this value stream, this value chain, and placing it on this map, we can have these conversations about what are the trade offs we’re going to make? What are the choices we want to make? Which ones can, do we need to build ourselves? Which ones should we just buy and never think about again?

and we can evaluate that and then we can test it against the real world. Did we make the right choice? Because we can see how things changed and whether or not particular things lived up to the promise that we thought they had if we were going to build it ourselves.

Mon-Chaio: hmm. Mm

Andy: So that’s the specific thing. If I was sitting there as this middle manager, uh, and being told I need a tech strategy that I think I would want someone to be able to walk in and see me doing is going through this kind of mapping conversation.

with parts of my team and using that to build up what is our understanding of where things stand, where they’re moving to, because that’s another big aspect of a map is that they can, you can move things through them and it means something to move it. Uh, and, and we can analyze that and start coming to a common understanding of what are the choices that we’re making and why are we not doing certain things and why are we doing other things?

So I think that’s my proposal is, I think if you came in, that’s what you should see me doing.

Mon-Chaio: Interesting. I really like Wardley Maps, and I think To your point, it gives you a place in order to have a conversation.

He in fact talks about that, that you can go to finance even with your quote unquote tech map. Um, and he gives an example where he’s like, you don’t even need to know what these things mean. Um, I could put bogus labels on them and we can still have a conversation about should I build or buy based on where they are in the evolution chain.

Um, so I like it as like a conversation piece as a piece of like aligning on a critical language, on a central language in order to move something. And I think that it’s valuable if you sit there and create Wardley Maps to start your strategy conversation. But I don’t think that strategy is a collection of published Wardley Maps.

Andy: I agree. I think the wordly maps would act as reference points as maps later on.

Mon-Chaio: Mhm.

Andy: And then combined with it, you should have a short, to the point analysis. of what it means to, to the group at that time.

Mon-Chaio: Yeah, I think I could probably get behind that. I think Wardley Maps can be a starting point. And I think it could be an anchoring thing for a strategy. But I think when we look at successful business strategies, I think that there are parts that are very difficult to represent on a map. And in fact, just like other maps, there’s zoom levels, right?

So, As you think about strategy, there’s the high level, there’s the mid level, there’s the low level, there’s digging into a component. You can build maps for all of those types of

things. And I, honestly, I think often as you’re thinking through it, you should build those maps. But when we’re using it as a central way of informing choice making, especially in larger groups, I don’t think 16, 000 zoom levels of maps is a great way to communicate. I think that has to be distilled down into something that takes those zoom levels and says, look, you know, we’ve looked at all the zoom levels and now this is what we believe. And this is what our unique proposition is. And this is how we differentiate.

Andy: Yeah. And I, and I think that’s still in there. Um, I think it would come along with the map, I think, but I think I wouldn’t want to cut the map out because the map to me, I don’t know, it’s this thing I’ve experienced where a graphical representation sometimes can mean much more to me than just the words on the page.

Mm hmm.

Mon-Chaio: I think it’s tough, Andy, because there’s always this concept of you want to go back to first principles. And I think often that’s useful. To be able to say what grounds you

but I don’t think that’s often the most valuable way to get information across. If you think about every new hire coming in saying, I need to get back down to first principles and I need to re deconstruct your thing because I saw this map and I don’t believe this should live here and we should move this here.

Let’s have a conversation around that a year and a half into the project. I just don’t think that that’s a great way to communicate at times.

Andy: Uh, but I, I, I think I disagree on something in there, what you just said, that someone comes in and they disagree about the assessment that we’ve made about where something is and why we’ve made the choice. Mm I think the strategy is something also that it gets constantly re evaluated.

Mon-Chaio: Oh, I

Andy: If someone comes in and they say, Oh, well, you, you’ve assessed that as, uh, as some sort of novel technique, but I see that you also assess that a year ago.

Since then, everything has changed. And that is now very much an established thing. And it’s, there’s nothing strange about it anymore. Like, Oh, well, that changes our assessment of what we’re doing.

So I, I think, I think, I think we might be agreeing with each other, saying, uh, well the maps are there, we, we do want to distill it down, and, They’re not static, but maybe I’m misunderstanding. What is

Mon-Chaio: I don’t have a problem,

Andy: I

Mon-Chaio: um, I don’t have a problem with the maps being there. In fact, I, I think they’re useful. Let me bring the discussion into something else, which is also near and dear to our heart, which is this podcast. Uh, and maybe our consulting and what we do with companies. So when you go to a company, Oftentimes, you want to tell them about a strategy for how they should be doing something.

Namely running their engineering organization. Now, what are the maps that guide that? What are the foundations for that? If you think about for us, the foundations for that are our research papers that we read to anchor us in what we believe. Now, it’s fine and I think it’s valuable for someone to say, look, you’re giving me the strategy, except that thing that You know, Tu Shan wrote in 1976 that backs up a third of your belief around this, I don’t agree with, let’s like dig into that research paper, often isn’t very useful. And so the presentation of it isn’t, here are the research papers that ground this, and then, you know, here’s a summarization of them and that’s the strategy. I think the presentation is, here’s the strategy, And like, believe this, there is grounding. And yeah, if you want to dig into it, you can dig into it, but I’m not pointing you at the research papers at all times.

Just like I shouldn’t, I don’t believe I should be pointing you to the maps over and over and over again.

Andy: I think, I think that’s then our difference is, uh, you’re seeing the, you see the maps as the nitty gritty details as we tried to figure out what’s going on. And I think I see them as the result of having worked out.

Mon-Chaio: Yeah, and, and that’s, that’s what I don’t think. I think like definitely they trigger conversation and I think conversation leads to perhaps a different map, but I think the value of the maps is not documenting those conversations and telling why. And how to make choices based on those conversations.

It’s about the ability to start those conversations and to surface things that you might not surface otherwise, because in terms of the maps themselves, the types of choices that you’re, that you can awardly map specifically. Right, there could be other

Andy: hmm. Mm

Mon-Chaio: In terms of worldly maps specifically, there are two main dimensions on which you can make choices on the map, right?

You can, I mean, yeah, you can make choices based on the evolution dimension, or you can make choices based on the value dimension. That’s the only thing the map in its static state, like when you see it, helps you make decisions. But I don’t think those are the only decision points for a technical organization.

Andy: Okay. Yeah. So I guess then that gets us into what are those other areas of, of a technical strategy that we’d need to cover.

Mon-Chaio: And I don’t necessarily know that I have a specific set of saying, Hey, you should have these seven things you should always cover in technical

strategy. Because I think everybody’s different and I think every team is different. Um, which is why I kind of like the high level thing. And if we want to explore We can talk about what it isn’t.

And we talked a lot about what possibly it isn’t, right? But the way I think about technical strategy is if we connected the business strategy, it is, it is to me, how you uniquely in your technical operations or product are differentiating yourself from your competitors or your peer teams. And how the choices that you make based on that differentiation sets you up for long term success. So I think technical strategies need to lay out, need to focus on things that sometimes we call one way doors, things that are difficult to change. Those should be the things in the strategy, things that are easy to change.

You can experiment on, right? Like I’m just going to do this for a And if it’s not quite right, I’m going to change it. But things that are difficult to change often when you set them in motion, especially in larger organizations, there are ripple effects. Um, things like, like deploying an HR system across a company. Yeah, it’s easy to roll back insofar as I just click rollback, but everything that’s happened since then around, Oh, well, the performance review process needed to be adjusted because the HR system didn’t support these one types of metrics or whatever, or those aren’t difficult to roll back, right? So I think the difficult to roll back things should be in your strategy document.

The easy thing, the things that you can cycle on shouldn’t. Um,

Andy: So there’s actually an interesting point of the Wordly Maps, which is outside of the maps, he has a few other things that he just kind of takes as given. Uh, one of them is called what he calls doctrine. And these are basically the, the principles by which you operate.

Mon-Chaio: yeah, you say a few, I think there are 40 or

Andy: there’s 40 of them, 40, 40 doctrine statements. And, and my understanding is the way that he treats them is that this is just what everyone does. This is just what you do. And because of the doctrine, that determines how the map should get interpreted. And I think what I’m hearing from you is you’re saying, no, doctrine itself is part of your choosable strategy.

And I actually think I’d agree with you when, when I heard that, like, no, no, here’s the 40 doctrine, uh, elements and you just work from there. I thought, but that’s not always true. Some organizations, their doctrine. might be at odds with the doctrine that he has set up. Now, you might look at it, and you might say, well, but his might be a better doctrine.

That can be true. But you’re, you could decide that your strategy is, for instance, I, uh, part of his doctrine is, I think, short cycle times and quick feedback loops and that kind of thing. But maybe you’re in a highly regulated industry where Uh, none of your customers are willing to take on quick experimentation.

Now you need to come up with a strategy, a doctrine that somehow lets you still operate and work with those customers that are maybe very averse to change, because if you go in and you’re like, okay, we’re going to deploy to you, uh, every two hours, uh, some new changes, they’re going to be like, whoa, whoa, whoa.

No, you’re not.

Mon-Chaio: Right.

Andy: And, and so you need to come up with a doctrine, a way in which you operate that informs how you would be doing those things, which then informs how you would interpret what’s going on in that, uh, evolution of various stages of your value chain and what it means to operate with those things, because your doctrine changes how you view.

the world around you. So, I think what I’m hearing from you is no, the doctrine itself needs to be part of this.

Mon-Chaio: I like it. To use, yes, to use the terms that Simon Wardley uses. Yes, the doctrine itself needs to be a part of this. And I think we could say that there is a doctrine that includes a set of different things that aligns most companies. But as we were mentioning earlier on in our culture episode, It can’t be 40, right?

If you want something that’s inclusive and not exclusive, it needs to be some minimum set. And in our culture episode, we talked about like two or three cultural ideals that you align on at the top level that then cascades down. So I, I think yes, a doctrine has to be a part of this because a 40 item doctrine just simply cannot align to the way most people work.

Andy: Or it might be that at the very top, you have this minimal doctrine, and then when it comes down to me being this mid level manager, I add a few more bits of doctrine into the way that we operate. And then kind of down to my teams, uh, they add a bit more doctrine and then it gets down to the individual development groups.

And then they’ve got maybe the 40 elements of doctrine because they’ve, they’ve said, this is how we are working for our piece of this whole strategy.

Mon-Chaio: Yeah, I think that’s very possible. And remember that strategy, and if we say doctrine is part of strategy, that makes sense because remember strategy is about making choices, right? And the point of a strategy document in my mind is, and we can talk about a specific tactic here too, is to give AAA teams the authority, autonomy, and accountability to make their own choices. in timeframes that tend to be longer and have high likelihood that those choices will align well with the other independent choices that other AAA teams are making. And so, to me, this leads to the fact that, well, if you’re not in a AAA team. If you’re in a component team, um, I think technical strategy, uh, is actually kind of useless to me.

Um, we, I mean, parts of it may be useful, but generally I wouldn’t put it on a line level manager of a component team to say, please come up with a technical strategy. I think it has to minimally start at the AAA

Andy: Yeah, yeah, I, I, I’d agree with that. Okay, so if I go through our list, if, if I go through our tests, what we’ve discussed, um, the, all of the discussion around the map of where do you stand, you can add your competitors into your map to figure out how are they different. And then as we were talking about, you, you can add in a narrative, something explaining that beyond the map. Uh, you’re writing your distinctive value chain, um, and, and the clear choices that you’re making about how you’re going to operate with that based on whether or not you’re considering something to be, um, in genesis or, uh, utility phase of the evolution.

Mon-Chaio: Along the spectrum Genesis to utility,

Andy: Yeah, somewhere in there.

And you deciding where you’re going to put that part of your value chain is a clear choice about how it is that you want to operate with it.

Mon-Chaio: hmm. Mm hmm. Mm

Andy: You are making trade offs and choosing what not to do. That’s kind of pushing stuff over towards utility or, or something like that. And, or you can call it out and say, these are things that we are just absolutely not doing ourselves.

We are going to outsource this. We’re going to contract it. We’re going to do something like that. Um, integrating choices across the parts of the value chain. Well, I think that’s a lot of that is a bit of this conversation, but I think a lot of that is the thing that you were catching on, which was it’s the doctrine.

It’s how are you going to operate to pull all of this together and make sure that we, we all interpret the landscape in a similar fashion. And the continuity is, well, have it written down. If you don’t write it down, um, you’re, you’re going to struggle with continuity. And then the continuous improvement is keep revisiting it. If, if something turns out to not be what you expected it to be on what you had written down, that’s the perfect point to figure out, okay, did we mis evaluate this? Is this actually not in utility? We were treating it that way, but it’s not behaving that way. and, and, and then re evaluate it and change it and communicate it back out.

Mon-Chaio: hmm.

Andy: And then if you can do all of that, I think, I think you might be being strategic.

Mon-Chaio: I think so. I think you’re definitely being more strategic you were before. Okay. I think this is probably a great place to end it for today. Uh, I’m sure we could probably fill another episode or two on this conversation. Uh, but, uh, I think as a primer to technical strategy and what technical leaders should be doing, um, any last parting thoughts to anyone from line level managers in charge of AAA orgs to CTOs of organizations around how they should be being strategic?

Andy: I actually want to call out one thing. I don’t remember if you said this earlier, it was from that, um, Harvard business school slide deck as well, that your organizational structure should follow and reinforce the strategy.

Mon-Chaio: Hmm. I didn’t say that, uh, because it was time constraints, but I’m glad you pointed that out. I love, I love organizational structure. I’m of the people on the, on the continuum that really believes organized organizational structure dictates things more than you might imagine. Of course, a lot of people don’t, right?

A lot of people believe that they’re immaleable and why should you care about structure? You just move and whatnot. But to me, organizational structure is one of those things that enables a strategy and is long term and is difficult to change. It’s one of those one way doors. When you set up two teams, it’s difficult to then like tell them that they should be three or that one of them should exist in Africa or now all of those front end developers are no longer needed because we don’t have a front end product anymore.

Andy: Yeah. It,

Mon-Chaio: And so,

Andy: you’re going to hire, how they’re going to interact, what they’re going to create. And then if you try to change it, you’re changing all of that. And so, yeah, that analysis of your value chain and what kinds of things you’re going to be building in that. And Why you need them and all of that absolutely will start dictating what is the structure you need to execute on that strategy.

Mon-Chaio: so important. All right. And the last thing that I’ll point out is that on the very last slide or one of the very last slides, this The professor mentions a point. He says strategy creates alignment and motivation. Great. We agree with that. Maintain discipline around the strategy in the face of many distractions. So we won’t talk about that here. There is a conflict, a small conflict there between Continuous improvement of your strategy and maintaining the discipline of your strategy. Remember, strategy is long term. And so, how do you balance that? When should you be revisiting? How often should you be revisiting?

What parts of your strategy are okay to revisit often and change? What parts should you hold to and say, Look, we’ve agreed to this, we’ve communicated it, this is how we’re executing. This is a great thing to talk about, but not here. If you would like to talk about it, email us. If you are a company having trouble with this, both Andy and I have helped lots of companies try to figure this stuff out.

You can email us too. We do help companies. We do help individuals get in touch with us at hosts at the TTL podcast. com. And if you have a chance, recommend us to a friend, rate us, help us spread the word. If you don’t like us, help us spread the word too. We would really like to know if there’s many people that disagree with us. All in terms of trying to figure out how to get better for ourselves. All right, I think we’ve blabbered on enough for today, so I’ll just leave you with, until next time, be kind and stay curious.