Crafting a Technical Strategy Kevin: [00:00:00] Hello and welcome once again to "It Depends: Lessons in Technology leadership." I, as always, am your host. My name's Kevin Goldsmith. I'm just back from the oh 1 1 1 CTO conference in San Diego where I was this week and really enjoyed it. They're not paying me. I paid to attend, so. This is unsolicited, but it's small conference. It's been going on for a few years. A good crowd of folks, very senior, very experienced, great to learn from, great practice sharing great, talks. Really, really enjoy that conference and learned a lot. So I wanted to give them a shout out. It's always a good use of my time when I attend. This week we're gonna talk about strategy, technical strategy for your organization. It is that time of year. We're into November. We're at the point where if you haven't already had your [00:01:00] Q4 board meeting, if you're a CTO, that's coming up and usually somewhere in there you're gonna want to be communicating. You're also gonna be wanting to talk to your team. About plans for next year and coordinating with the rest of the executive team. If you're not a C-level person, if you're a vp, if you're a director or even an engineering manager or a lead or architect, this is still important having a strategy for your team that aligns to the rest of the organization. If you're at the C level, you're aligning it to the business and the business goals. If you're a vp, if you're a director, if you're an em, your strategy is gonna align to the strategy of your organization, which is also hopefully aligned to those business goals. So it's an important thing to have a documented strategy. And I say documented because that means you've actually. Not only articulated it, but shared it without that [00:02:00] documented strategy. Your team doesn't quite know where you're going and where you're trying to get to, which means that when they make technical decisions, architectural decisions, implementation decisions, new libraries, things like that. Without that understanding of where the organization is trying to evolve to, they won't take that into account when they're picking these things, which means that the organization will be really challenged. Because you'll be going in different directions, different teams will make different choices because individuals are gonna be picking based on their own sort of interests or their things they're excited about or things they've heard about without really understanding where you're trying to get to. It's something that I often get from an organization. What is our strategy? Where are we going? And it isn't that I don't have it in my head, it's that I haven't [00:03:00] done the work of articulating it and sharing it. Part of my experience is that I've seen what happens when you aren't very good at articulating it, or you haven't done the work to share it with your team and socialize it and make sure everyone understands it. Because I've had the problems where people are going in different directions because. They don't know what direction you are trying to lead the organization into. And again, it's not that I haven't had a strategy , and it's not that I haven't articulated it, it's that I haven't done the work of formally documenting it and sharing it and communicating it. You always are gonna have strategy. Hopefully if you're a leader of any size of team, you've got that. "Where are we trying to get to with this team?" It's the work of actually making sure everyone understands it and is aligned to it. It's absolutely critical , and it is critical that at some level that is aligned to the business. If you are pursuing a [00:04:00] technical or organizational strategy that is different than the business, you are putting your organization in conflict with the business, and that doesn't last for very long because the business will correct. Because essentially you're now fighting with the rest of the company. Without a strategy, you end up with a lot of constant rework, shifting priorities. People don't understand why we work on this now. Why are we working on that? We don't understand why this is important. A lot of times because of Conway's law, and we've talked about that recently , you end up with architecture that reflects the org structure, especially past org structures and not the future goals that you're trying to get the organization to. Engineers end up making really inconsistent technology decisions 'cause there's no shared North Star. You end up with friction in with the product and business stakeholders, especially if you're committing the technology team to projects that are driving your [00:05:00] strategy, whether you've communicated or not, that the business doesn't understand because you haven't shared it with the business. And so what happens is they, from the outside, it just looks like, why is it we don't understand why the team is doing this? This isn't clear to us, which creates a lot of friction. They're like, why aren't you doing this thing we think is important? Your teams are doing this thing. We don't understand why they're doing it, and you may have a good reason for it, but they don't see it. Let's talk about what a good technical strategy looks like. As I said, it's aligned to the business goals. If you're a executive leader, you should know what those business goals are. If you don't yet know what the business goals are. You can have a long term strategy, and that might be around evolving the architecture to a more modern architecture or improving scalability, addressing tech debt. Specific areas of tech debt. Little bugs doesn't count as technical strategy, quality, improving quality. That is a strategy, [00:06:00] but it should be at a suitably high level if you're further down in the organization. Oh, it can be at a much lower level, but again, it should be thinking long term, a year, two years. If you want to think out, five years, great. But be realistically vague because the industry changes so quickly. Five years ago, you wouldn't know what today was gonna look like. 2020. We had no idea what the technology industry was gonna look like. And any plans you would've made in 2020 would be just totally wrong now. So you can have these kind of broader goals and it should be on a suitable timeline. It should be aligned to the broader business goals, or at least not in direct conflict with them. The business doesn't care about having a modern architecture except that. Having a modern architecture means that you scale better as the business grows. It means that you have easier maintenance. It means it's easier to hire people because you have an architecture that those people understand. There's a lot of [00:07:00] benefits there. Those are all the business benefits, and your strategy should be aligning to your business goals. The strategy should be coherent. It shouldn't be a bag of doorknobs, a bunch of different random goals. All the goals should be aligning. They should be taking you to a place they should a north star that you are trying to drive the technology to. It should be easy enough that anyone can understand it. Anyone in your organization should understand that strategy, so it should be communicatable. It's gotta be a living document because the industry's changing. The technologies we use are changing. Again, five years ago we wouldn't have been talking about, AI generated code. Now it's all we talk about. Amazon has this kind of idea of working backwards. You start with the press release and you work backwards. How do you achieve it? You can do that. That's a great way to approach a strategy. What would it look like in two years if everything was better in the technology [00:08:00] team? In my team, or in the company? Or in the organization? That's a good way to start. If you're trying to figure out, " how do I articulate this North star? How do I think about what that should be?" Think about the organization you're in now. Think about where you could be if everything worked great in two years and then articulate that. the general idea is that working backwards is a great way to come up with a strategy. Think about the challenges your business is having. Think about where your business is trying to go. Think about the things that are currently slowing you down, and then imagine a world where these things were gone. What would that world look like? How would it be to be in that world? And what is between you and that world? And that's your strategy. And then that helps you lay out a roadmap against that strategy. What are the things that are inputs to that strategy for your team? We've talked about business goals multiple times now. What's the company trying to achieve? So your company has strategy, how [00:09:00] are you gonna align to that strategy if the company's goal is to grow by 10 x? Will your system scale to support 10 x? How are you gonna get them to that? If your company's planning to enter a bunch of new markets, let's say you're only in one language today, are you gonna be ready for all those markets? Are you gonna be ready to support payments in all those markets? Are you gonna be ready to handle the privacy regulations in all of those countries? Are you going to be able to handle how people want to work with your product in all those different places so that your technology strategy will be aligning to that business goal? Maybe you're gonna try and move into adjacent industries as a company or new product areas that address different types of businesses. Can your technology organization support it today? And if not, what do you need in order to achieve that? Another input is your current state of your architecture or your technology [00:10:00] organization. Where are you today? We talked about that. Then this idea of working backwards. Where do you want to be? Where are you today? So think about that. What is easy? What is hard? What's breaking? What is slowing down the organization that you would want to address? What are the people you have and the skills and talent they have? To address this kind of future state you're trying to achieve? Are you going to need to upscale people? Are you going to need to. Hire different people or bring in new skills to your organization. That's part of your strategy as well. Are you going to need to outsource areas that you don't have skills in? Are they critical to the business? If they're critical to the business, they're part of your competitive moat, that's probably talent you want to have as full-time. That's not necessarily something you want to outsource. Is this an area you wanna play in? That you don't have the skills in, but you're not sure you want to get into this space. Maybe you don't have a mobile app today and you're thinking, well, maybe we should have a [00:11:00] mobile app in order to address this new market. It's more critical there. Do you need to hire a mobile team? Maybe not yet. Maybe this is something you outsource today. You validate the market and then you decide, okay, now we're gonna bring that in-house and build it now that it's a critical part of our business. That's strategy, that's a strategic decision, and that would be outlined in a strategic plan. That's something your team would need to understand. That's something the business needs to understand. We are outsourcing this today if this works, if we validate the hypotheses. We're gonna bring it in-house. Everyone needs to understand that because otherwise your team doesn't understand why you're outsourcing it. The business isn't budgeting for this to eventually come in-house, things like that. This is a critical piece. The people and skills you have today, and the people and skills you'll need for that future state. And then what are the steps you'll need in order to get [00:12:00] them? What are the things that are gonna make sense? You should be paying attention. What's going on in the industry? Where are things moving? What trends are we seeing? How are we going to address them? Do we need to address 'em? Are they critical for us? Do I think they could be critical? Again, a few years ago, we wouldn't have been talking about AI generated code. Now, we talk about it all the time . A couple years ago, you probably could have recognized that this was the direction it was going. Does it mean you need to hire fewer people because you think you can make your team more efficient using these tools? Does it mean you need different skills within your organization because you can let the AI do some of the things that maybe people were doing today? So how do you re-skill the people who currently do that job and get them ready to do a different job because now you have a different need than you had today? Things like this. Where are we going with cloud technologies? Where are we going with mobile technologies? Do we need to be paying more attention to things like smart [00:13:00] glasses? Depending on your business, you may. Do we need to be doing more with audio, with spoken word interfaces. This is all the kind of stuff you should be thinking about. It may not be relevant to your product, it may not be relevant to your business, or it may not be relevant today, but it may become relevant and just. Being aware of what's happening, being aware where the technology's going, being aware where software development is going, and trying to decide early on if you wanna approach that, if you think it could be there, put it in your strategy. If you think we can wait and see on this. That should be understood as well, because otherwise people on your team see it and you've decided we wanna wait and see, but they get excited about it and they wanna push that into their team. And they haven't been told no, if you haven't documented this, they need to understand, Nope, we're waiting and seeing on this right now. So this is why it's important not only to think through these [00:14:00] things, but it's also very important too. Write 'em down to codify it, to make it understood within your organization. 'Cause otherwise people don't know and they do what they think is the right thing to do. When you're thinking about these inputs, you need to be listening first. You need to be curious. And then once you understand, or once you've been deliberate, then you codify it into your strategy. Now let's talk about how you craft that strategy. You've taken these inputs, you've been thinking ahead, you've been looking around, you've been understanding the business. All these pieces. How do you craft the strategy? You identify the guiding principles. What are the things that are gonna guide our direction? And they should be suitably. Broad and suitably vague. We want to be simple in our architecture. We wanna be understandable, we wanna be maintainable, things like that. [00:15:00] Okay. Well that's independent of any particular technology choices. So what are your guiding principles, for your organization, for your technical strategy? We believe for security that we want to do this or governance is critical. What are those guiding principles? We wanna make sure users never experience this situation . Then once you've identified those kind of broader guiding principles, not too many, not too few, a handful, three to five, let's say the guiding principles for your strategy. Now you can articulate your key technical bets. Let's say, for example, a key technical bet. We're going to evolve to an event driven architecture. We're going to. Really focus on observability. We are going to retire our legacy systems. We are going to be highly scalable to support the direction the business [00:16:00] wants to go. We're going to move from on-prem to cloud, from cloud to on-prem, from microservice to Lambdas, whatever. That is your key technical bets. And again, on a reasonable timeline, if you have these really massive, monolith legacy systems and you're like, we're gonna be microservices in six months, maybe that's reasonable for your team. Maybe it's not, but it should be an achievable goal. An achievable bet. Each of those bets should be connected to a business outcome because otherwise, why are you doing it? We need to move to an event driven architecture because the business is moving to this real time service for our customers and the current way we process things makes that. Not reasonable, or it makes it very expensive and hurts our margin or whatever. So this is why [00:17:00] we need to move to an event driven architecture, for example. Each of those bets should be connected to a business outcome. We are doing this to support the business, not we are doing this because we want to . If you are at the C level. You should be validating your strategy with your peers and the exec team before you roll it out to your organization because they need to understand it and they need to be aligned with it because they may have their plans and they may be expecting your team to deliver capability, and if it's not reflected in your strategy, that's gonna be a problem. If you're not at the exec team level, if you're, in, middle management or you're a team lead, you also want to get your cross-functional peers, design and product to also be aware of the strategy that you're putting into place because it's going to affect their strategy and what they want to do. And you should be coordinating. Between [00:18:00] the three of you or the two of you, product design, whomever your cross-functional peers are that are focused on your team, they should also be supporting your strategy and your strategy should be supporting their goals and what they're trying to achieve. It all should be coordinated because again, this is an alignment. This is to service. Alignment not only within your team, but from your team to the rest of the company. So everybody's goals and everybody's strategies should be supporting everybody else's. Once you've validated with your cross-functional partners, you finalize the document. Hopefully you've had internal folks or your team review at least parts of your team. Now you communicate it broadly, and you communicate it repeatedly because you tell it to people, they forget. You put it in confluence, you put it in notion or whatever. They don't read it. You present it in a town hall. You put the document [00:19:00] in Confluence. You remind people whenever you're. Creating a new project that supports the strategy, you point back to the strategy so that people understand this is where we're going, this is how we're getting here. This new thing we're talking about is aligned to this strategy document. And it needs to be a document, not a video. Not only conversations. This is where I'm saying, learn from my lesson that it's important to actually write it down and it's important to share it, and it's important to share it repeatedly and refer to it often. ' when I haven't done that. I've ended up having to go back, and I have to say, no. Remember we talked about this that one time? Of course they don't remember. Communication around this is absolutely vital. Make it visible. Put in your all hands. Document it, share it in onboarding with new employees. Make sure you're using it to drive architectural [00:20:00] and hiring decisions. Hiring managers, when they're talking to candidates, I get this question all the time from from. Applicants. "What is your strategy? Where are you going? Where are you trying to get to in a couple years?" Because they want to know if this is something they're interested in. Everyone in your organization should be able to answer that question in a job interview. When you're interviewing somebody. Revisit this document. You should definitely be revisiting it. And updating it annually. If you update it too often, people aren't going to understand 'cause it's changing too much. Your strategy shouldn't change. It shouldn't be at such a low level that it's changing all the time. 'cause then people can't keep up. But it should be updated at least once a year and you should be revisiting it at least quarterly. To make sure that the conditions of the business haven't changed. We were gonna go in this direction. We've decided that direction isn't gonna work for us, so we're not doing that [00:21:00] anymore. If you've built a whole strategy around supporting that, the growth of that new business, the company was gonna get into, yeah, you need to update the strategy. 'cause you don't want people working in that direction anymore. So you need to update it at least once a year. You need to revisit it at least quarterly just to make sure that. It is still aligned to what's going on with the business. Businesses change stuff comes up. If you are a senior leader, if you're a mid-level leader, you need to make sure that the strategies of the people that report to you are aligned to your strategy. So if you're a director, you need to make sure that your organization strategy and you still need one, should be aligning. To the CTO strategy , you should be aligning to your boss's strategy, which should be aligned to the strategy a level above that. If you're an em, obviously your strategy is gonna be a lot narrower. It's gonna be a lot more specific to your team and what your team does. You still [00:22:00] want that strategy. You still want to make sure that that is aligned and that it's aligned not only to your. Boss's strategy, but it's also aligned to your peers strategy. If you're an EM to the other teams and your boss, if they're a director or vp, whatever, should be making sure that all their team strategies are aligned to their strategy and that their strategy is aligned to their peers and or their boss. These all have to support each other. If they do not support each other, you are not aligned and you're gonna have lots of problems. So let's talk through some pitfalls. Your strategy is not a roadmap. You may generate a roadmap from your strategy, but your strategy isn't a roadmap. Q1, we do this Q2, we do this. Q3, we do this. That's not a strategy, that's a roadmap. This is why I said it shouldn't be specific. It is about the outcome, not the output. You also don't want it to be so vague that you can't use it to guide architectural [00:23:00] decisions. A strategy isn't, we are going to be aligned with the most modern software development practices in the industry today and the most efficient architectural decisions, right? That's not a strategy that's just. A word cloud. Can't make it too specific. Can't make it too vague. It should be guidance. People should understand, am I making a decision that's in line with that? And if your statements are too broad, any decision's gonna align with that. If your statements are too narrow, then it's not necessarily flexible enough. To adjust to the business changes or to individual team decisions. Again, being aligned to business outcomes is absolutely critical. If you can't explain why this is aligned to the business for your cross-functional peers, they're not gonna understand why you're doing it. They're not gonna understand why it's [00:24:00] important and they're not gonna support it. And in fact, they may challenge it, especially if they believe their goals are aligned to business outcomes and yours aren't. The last pitfall I wanna talk about is making sure that your strategy is at a level where you still. Allow some autonomy within the team to make decisions. So again, if it's too specific and it's too narrow, one, it becomes a roadmap and not a strategy, but two, it takes all decision making outta the team, and you wanna give them freedom. You're trying to guide their decisions, you're trying to give them the context to make good decisions. You're not trying to take the decisions away from them. So it needs to be at the right level. Where they have some autonomy in the decisions they're making. You are giving them the power to make good decisions. That's the other critical piece of the strategy and why we do it. To close, how do you know if your strategy is working? If you've [00:25:00] developed a strategy, you've shared it, you've communicated it, you're referring to it . You're making sure that it aligns with your peers. You're making sure that it aligns with the business. You're making sure that it aligns with your boss's strategy. If you've done that, how do you know it's working? Decisions should get easier. You as a manager or architect or lead. You shouldn't be in a position where you're having to correct teams or refocus them or redirect them because they've gone off in a random direction that isn't aligned with where you're trying to bring the organization. That's number one, and that's one of the critical benefits decisions for you. Get easier decisions for the team, get easier, and you reduce a lot of rework. Engineers understand why they're doing things. They understand why what they're doing aligns to your strategy so that you're giving them purpose and you're [00:26:00] giving them autonomy because you're giving them a context in which they can make good decisions. That's two of the three drivers of motivation from Daniel Pink. Autonomy Mastering Purpose. So it makes the teams happier. Integration moves faster with fewer mistakes because multiple teams are aligned within your organization, or you and your peers are aligned if you're an em. So that you all understand where you're going so you don't have as many conflicts between teams and the platform scales as the company scales or you're able to support the business and where the business is going. That's how you know it's working. So I hope you feel a little more comfortable with the idea of why you need a strategy, how to approach creating a strategy. it's important and it's important to get it right and it's worth taking the time to do it. A technical strategy isn't about predicting the future. [00:27:00] It is about making sure your team is aligned on how you'll face that future together. Thanks everyone. It's a little bit of a shorter one because I've been traveling this week. If you have questions, I'd love to answer 'em in a future podcast. You can get your questions to me. Contact at, it depends. book.net. It is the contact info for me. You can also reach out to me on social media, LinkedIn, blue Sky Threads. I don't really read Twitter anymore, but I still have an account there. Instagram if you want. Whatever works well for you. Happy to get your questions, happy to answer them. And if you disagree, I'd love to hear that too. I'm very happy to. Correct. Or if I miss something or you think I really said something wrong, yeah, maybe, let me know. I also. Want to let you know I'm speaking at K FU in Montreal in February. I'm giving two talks there. I've talked at that conference before, but this is the first [00:28:00] time I'm talking in person. Very excited to do that. Will hope to see you there. If you are gonna attend, let me know, and we can connect in person. I will see you next week in the newsletter. I'll see you back in two weeks on the podcast. Have a great week.