Designing an Engineering Strategy. Part II
Understanding the high-stake problem
I divided this topic into four posts/emails.
Part II. Understanding the high-stake problem. [This post]
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:
4keymetrics.dev - In Development
24 DevOps Capabilities
Here there's an excellent resource to base your survey on.
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.
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.
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
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
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!
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?
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.
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 II. Understanding the high-stake problem. [This post]
License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.