Designing an Engineering Strategy. Part II

I divided this topic into four posts/emails. Part I. What the heck is Strategy? Part II. Understanding the high-stake problem. [This post] Part III. Giving direction and coherent action. Part IV. Executing an Engineering Strategy Engineering Strategy Template Now that we know what an Engineering Strategy is let's find how to identify a high-stake business problem and the risks that would prevent us from reaching our goals. Up to today, I didn't find one technique that, by itself, addresses all the angles that I need to design an Engineering Strategy. Instead, I combine multiple disciplines that help me gather meaningful information to understand the problem better and several techniques to address them. I will share how I use the following techniques to gather meaningful information in this post. Team Topologies Domain-Driven Design Wardley Mapping 4 Key Metrics of Accelerate 24 DevOps Capabilities Conway's Law Lean Inception Approach Business OKRs Sociotechnical Systems System Thinking Starting from the business and product Starting from the business is the best filter I know up to today. Engineering can be everywhere, yet we need to know where to focus. That's what business and product do. Let's filter our area of impact to what matters. But what if the business is wrong? You all will learn from the situation and improve! That's why being hypothesis-driven is so essential. You start from an assumption instead of a fake fact. As Technical Leaders, we need to be close to the business, listen to what they say, ask questions, be informed, and stay curious. We tend to assume more than we might realize. Stay humble on those sessions! If they aren't helpful for you, think about what you can do to make them useful. Help the business bring those insights that you need! Filter what’s not relevant for the business objectives OKRs, Product Roadmaps, Features Descriptions, Goals, anything that the business can give you to help you filter out what's not impacting the business the better. It will help you understand the area you need to pay more attention to. ⚠️ It doesn't mean that you should not consider Engineering Blockers that aren't 100% related to the OKRs, for example. You, as Technical Leader, need to be wise and know what can impact those OKRs even if they don’t show an evident 100% correlation. Understand that you cannot do this alone Plus, it doesn't make sense to do so. The more people you bring in, the more insights and more accurate your data will be, yet you cannot stop everyone from bringing insights, so you need to find a balance. Identify frictions and possible barriers When you come from a Software perspective, you might focus on Architecture and Domain-Driven Design. Even though they are crucial to defining a good Engineering Strategy, they do not provide all the dimensions required to identify fiction and possible barriers preventing us from reaching our goals. Start with the team Team Communications and Information Flow Ask the team to share with whom they talk daily and who talks to them. I ask each team member to draw a diagram of the team's communications, dependencies, and how the information flows in and out. Here are the dimensions: In and Out Communication, and which information flows between them. Strong or weak dependency Which is the "distance" between teams that people feel Team Handovers Identify how the product is shipped to the customers and how many teams are involved in the progress. Those are handovers can be damaging for our organization on preventing a fast flow of change. Read Team Topologies for more. Team Knowledge and Motivations You should know which skills each team member in your team has, but having that at the company level might be more challenging. Moreover, it changes rapidly over time. Ask your team members to answer a survey with the skills you consider relevant for the business. Here is a link to some of the things I asked when I ran the survey. You will see that I ask for technologies, methodologies, and practices like Test-Driven Development, User Story Mapping, High Available Systems. I use 5 possible answers: No experience Some knowledge but not comfortable for production Comfortable using in production Used in production and able to teach others Be a reference in the field with vast experience in production I will also recommend you to ask the team members about: 3 things you’re good at 3 things I would like to learn more Knowing what people feel confident with and also what they want to learn more about, can be a good pointer to choosing technologies, methodologies, and approaches to develop your product. Continue with Engineering Experience and Maturity 4 Key Metrics of Accelerate Knowing the 4 Key Metrics will show which performing stage is the team. And knowing in which stage, it will show where you can improve. Yet, how does it relate to Engineering Strategy? Lead Time. If your Lead Time is high and the business wants a timely go-to-market strategy, you have already identified a barrier preventing you from reaching the business goals. Here are some tools: Haystack Sleuth 4keymetrics.dev - In Development 24 DevOps Capabilities Here there's an excellent resource to base your survey on. devopsefficiency.com Running a survey to know the maturity level of the 24 DevOps Capabilities will give you a good perspective on which areas might prevent you from introducing rapid change. Knowing them in advance is vital before jumping into designing the engineering strategy. Measure Cognitive Load When the cognitive load is high, your desires for things to improve, tests, product enhancements, and other stuff will come slow, with poor quality and slow change flow. Your best intentions to improve your product will vanish because the team cognitive load doesn't accept more. 👇 Here is a link to a Team Cognitive Load Assessment by Team Topologies Authors. https://github.com/TeamTopologies/Team-Cognitive-Load-Assessment DDDing After dedicating a huge effort to understanding the human part, we start with the business and systems part. Finally! Domains and Subdomains + Context Mapping Map the current moment as Domains and Subdomains plus Context Mapping. Then, share what you did with other senior people that work with you. Iterate until you have a clear picture of the current situation. The debate is more important than the result. It doesn't matter if it matches at 100% the reality; it's about a shared understanding between the team members. To collect this info, you can use Miro or a dedicated tool as DomoRoboto. DomoRoboto Tool Systems Dependencies and Ownership Ask each team member to draw the system’s dependencies and who owns each system. Here, you’re looking for: Team’s understanding of the system dependencies If they are synchronous or asynchronous Team overlapping on a system Systems owned by several teams Systems owned by no one Team owning too many services Assessing team’s awareness of the challenges and risks You will be surprised how people already thought about the problems and come to ideas, solutions, assessed risks, and their concerns. Some will struggle to explain their thoughts, but they definitely feel the pain the most and are already trying to fix the stuff. I used a Miro board with the different areas so people can give their inputs collaborative. Psychological Safety Over the past years, I noticed that human barriers like a team with inadequate psychological safety will be the most challenging barrier to overcome even with the best architecture ever. Tooling like Officevive can help you gather crucial feedback to have the necessary conversations to help the team improve and perform at their best. You don’t need all this info at once I don't know your experience, but having all this information when designing the Engineering Strategy is a fairy tale. It never happens, but you should have more info each time you do an Engineering Strategy than before. You should be wise on which area to gather the information that can impact the better your Engineering Strategy and let the rest go. If we interpret the Engineering Strategy as a Knowledge System, there's output and learning after each definition and implementation. That learning should become part of the input for the following Engineering Strategy. A kind of a Reinforcing Feedback Loop. You become better on each iteration. To know more about Systems, check Thinking in Systems. Learning about TT + DDD + WP Fast Flow of Change by Susanne Kaiser Designing for Adaptability. I had the opportunity to attend to Sussane Kaiser Workshop about connecting the dots between Team Topologies, Domain-Driven Design, and Wardley Mapping. It blew my mind 🤯 I’m able to add adaptability dimension to the Engineering Strategy because of her workshop. If you had the chance, I strongly suggest you attend it! Another option is to pre-order her book about this topic, Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies: Architecture for Flow Books Strategic Monoliths and Microservices This book has been missing in our industry, a book that helps technical people but also business people to see how we are doing architecture for a business purpose. It’s not a Domain-Driven Design only book, yet it includes the necessary stuff and beyond. This book isn’t entry-level and you need reflection to understand it in depth. Yet, you get a lot of value from it! Team Topologies Understanding Fast Flow of Change is essential to manage high-stake situations. How much will it require to resolve this high-stake situation? Which teams will be involved? How do they communicate? Accelerate Come on, I quote this book a lot. You already should know why Accelerate. Long story short. Measuring Engineering Performance done well. Continuous Improving Mindset guided by Metrics. High-performing teams and organizations. Wardley Maps If you haven't heard about Wardley Mapping, you definitely should take a look at this book! It's licensed under Creative Commons and accessible on the internet. I consider the book to be quite dense, and sometimes I felt that I needed some practical examples to become more familiar with Wardley Mapping. Hired Though did an excellent job in this regard! Check out the courses here. Meme for you Index Part I. What the heck is Strategy? Part II. Understanding the high-stake problem. [This post] Part III. Giving direction and coherent action. Part IV. Executing an Engineering Strategy License This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.