The outcome of the strategy becomes culture
On this post, I use the term “Strategy” as what Richard Rumelt's defined on his book "Good Strategy / Bad Strategy".
“Culture eats strategy for breakfast”
I also found the sentence as “Execution eats strategy for breakfast”. It is interesting the amount of organizations eating strategy each morning. 😅
Those sentences bring me interesting thoughts regarding how culture, strategy, and execution are related to each other.
Each organization has an strategy. It is usually not explicit, not written down, and, probably, not good. They live on conversations between people, they are communicated by decision makers and (miss) interpreted by everyone else (decision makers included).
The strategist journey
My journey on strategy had five crucial moments which I can relate to my maturity as a person doing strategy. I hope you can relate to those turning points and identify which is your next step as strategist.
I added some levels for later reference.
L0. We don’t need an strategy, just execute
We were working in a mobile application consultancy at Barcelona during 2014. Mobile apps started to become a thing in Barcelona and there were few players that provided custom-mobile applications as a consultancy.
We were a young company composed of people with few experience running a business and some experience building applications. The clients that we attracted shared a common thing, tiny budget.
When the budget isn’t much, you start leaving out key aspects of the development journey. OK, let’s skip this, let’s get the requirements, and we just do, at the end, it is a very basic application.
Recipe for failure. Lack of enough experience, ignoring important steps, we were “cheap” (in terms of budget, in terms of outcome, maybe expensive).
The outcome of the projects where something like:
✅ Project delivered fulfilling the requirements.
⚠️ Enough quality that it is stable, but not that easy to extend.
⚠️ Project delivered late (2 weeks to 1 month)
❌ Overwork.
❌ Low margins up to losing money per project.
Failing once is OK, repeating the same failure is incompetence. We needed to change how we were working.
L1. Let’s copy what others do
You start looking for a success recipe, how can we address the overwork, the low margins? We were able to produce a solution that our clients were happy for, yet, our business model wasn’t looking good.
We stopped to think. What is missing here? How others are doing it?
When you stop to think, but you need to keep the business running, you don’t think much but google silver bullets to magically solve our problems. We found few:
We need to be lean! → Which meant, we need to produce the same value with less resources.
We need to do agile! → Which meant, we reduce what we spend on gathering the requirements (it was done for free) so that we do it while the development and we charge for ti. 🚩 Doing agile instead of being agile.
We do DDD and TDD! → Which meant, we fix our engineering quality and software extensibility with this two things that people said it was software excellence. And we could charge more!
You can guess right. We also failed, but now we were lost. We did everything by the book, why are we still failing? The problem isn’t us, who is making this to fail? Is it the client that don’t understand agile? Is it the team that isn’t committed enough with the strategy and they are doing it wrong?
Insights of this approach
This approach had several key problems:
It doesn’t address the actual business high-stake challenges. Either us as a company nor the client.
It copied the success case of other companies without understanding their context nor ours. You might be familiar with:
Why are we doing this? Because everyone else is doing it.
2021. Let’s hire a lot! Why? Because everyone else is doing it.
2024. Layoffs. Why? Because everyone else is doing it.The separation between who decides the strategy and who does the strategy created a lose-lose situation for the employees. If we succeed, it is because the strategy was good, if we failed, it is because they didn’t followed the strategy good enough. So, push harder!
The strategy was about a list of desires without a proper understanding of how to make it happen. If people wasn’t familiar with DDD, Lean, Agile, TDD, does it mean that they need to learn that by themselves? We do it as a company within working hours? We were on low margins, it is hard to invest in that situation.
The danger of this approach is that you find people/reasons to blame of why it failed because the strategy is rock solid. You close yourself to learn about your mistakes.
You might even be in the naive position of saying, I will help my team to up skill so that they can implement my strategy correctly. Even though it makes a lot of sense to help people learn new skills needed for the strategy to be successful, it is the initial chain thought what it is dangerous. The strategy fail because they don’t do it good enough.
This mindset can lead into drastic decisions such as hiring new people that you think they will address your problems, laying off your team because you think they aren’t senior enough, create an environment of extra hours and pressure, etc.
Worst case scenario, you start doing “re-orgs”, and we know how painful they are for everyone. Please, don’t do this, it just shows incompetency.
L2. Strategy needs to address the business needs
This is the first turning moment. Here is where I started to think about strategy properly. It was around 2018, when I attended DDD Europe and I listen to Simon Wardley’s talk of Crossing the river by feeling the stones.
I accumulated at least 4 years of experience and failures, which I haven’t been able to learn from because I lacked some deeper understanding on strategy.
The Simon’s talk helped me to understand the importance of the business context to make informed strategic decisions that addresses the business needs.
It helped my mind to the “click”.
I started to learn why I was doing those mistakes. So, I took the next 2 years in a learning mode and no decisions. This was key to be able to reach the next maturity level.
Making that kind of level decisions have a lot of implications that go beyond the business, it impacts people.
I decided to make questions to help me understand the rationality behind why we are doing this over that. I was lucky enough to be surrounded by awesome people during my journey at ThoughtWorks Barcelona.
The key aspect that I learned during this phase is to make the right questions. Depending on the people you collaborate and the questions you make, it will create way different strategies.
Insights of this approach
It forces you to understand the business context before making decisions.
If helps you to understand why certain decisions were made and in which context.
If helps you gain business knowledge. Without understanding the business context and needs, no strategy should be done.
Learn before you do.
What I somehow I missed during this phase was empathizing enough the context things were made. I focused on understanding the business domain, needs, goals, and objectives.
I was able to understand and practice the DDD strategic patterns to have meaningful conversations with domain experts, and see how those things impacted the business.
Yet, I was blind on the context I was in. At ThoughtWorks, you get a huge good software excellence foundations that help you gain business velocity and stability. I thought we were doing a good job because we were doing the right things and the things right.
I didn’t understand the amount of support you get just to be exposed to that environment. Things like:
Agile practices and ceremonies
DevOps culture
Software Development best and good practices
Consultancy skills constant training
All those things that you obtain to be there aren’t just because yes, it is because they address key ThoughtWorks business needs that help them achieving ThoughtWorks and Client business goals.
L3. Strategy addresses the business challenges understanding the current context
After my journey at ThoughtWorks, I joined Creditas as Engineering Manager and later on Head of Engineering.
At this moment, without all the ThoughtWorks supporting infrastructure I realized how important it is the context you are in and how it limits you on addressing the high-stake business challenge.
At the beginning, the strategy I proposed partially worked. It was strange, similar business needs compared to a previous experience at ThoughtWorks but very different outcomes.
It is not only the business needs that matter, it is also the current organization context that influences the strategy. If you ignore where a team, group, or the whole organization are, you can address the business needs, that you won’t be able to articulate/execute the strategy.
I started using three tools that would help me understand the context
1:1s
I scheduled multiple calls with as much as people as possible to understand not only the business context, but the team, architectural, technical debt, skills, etc.
I captured all those data points in a shared document with the organization and a Miro board to I could ask people if my understanding was accurate.
Kanban-Maturity Model
With the 1:1s, I was able to identify that I was wrong in one assumption. I expected the teams to be in a ML2 or ML3, it was the maturity level I was used at ThoughtWorks which the strategy I was suggesting could work.
I noticed that key teams were behaving as ML0. I had to adapt the strategy to this reality. And it meant, before we can address those business needs, we need to up skill the team. So, up skilling was part of the strategy, not a requirement for the strategy to be successful.
DORA metrics
Understanding the engineering maturity is key to see how fast we are releasing software, and how often it fails. A must do!
Problem is, if the maturity is low enough, you won’t have the tools to measure it automatically and you will need to do it manually.
You can learn more about this journey here:
L4. Strategy addresses the business challenge and will position us in a new context and culture
This is something I learned during my journey at Creditas. An strategy is highly influenced by the culture, it guides or limits what you can do or not.
If strategies are planned for one month, they get reviewed and approved by the C-level at the beginning of each quarter, and then your performance are measured by the output of it, they will be strongly influenced by this approach.
If at the beginning of the company, people decided to go microservices (probably an unwritten strategy that become part of the culture), proposing a monolithic service at team level would imply inertia. We don’t do this here! Microservices work fine and we have a lot of supporting tools for it.
If we are custom building almost everything, proposing adopting an off-the-shelf solution would impact convincing multiple people and creating process to buy external software.
Why do we need to buy this now? We have a team that already this on the past and worked well.
Past brings inertia to change. What worked on the past might not work on the future.
I found that success cases brings a lot of friction to make things differently. Yet, when you propose something that wasn’t done before, and it works, it influences the culture A LOT.
Example:
Leader: We tried to delegate to the product teams to make this but it failed. That’s why we pass the requirements and they just deliver.
Aleix: I see, we are under pressure to meet goals and meeting those goals are related to your performance review, and, therefore, your salary. It is hard to leave room for failure in this situation.
Let me propose something, I want to create a workshop to pass those requirements in a different way, I propose a Lean Inception. It will be 3 full days were we will go though the business vision and goals, which are the product needs, and the features that we want to deliver.Leader: Why should we do it? It involves a lot of people and the current process just works
Aleix: It partially works, we have several reworks and the lead time is quite high because we require extra work redoing things that we misunderstood. It is not that the requirements are bad, but that it is hard to fully understand the big picture with the features alone. My hypothesis is that we will decrease the lead time for features and make the software more reliable.
Leader: OK… Do you need me for the three days? I cannot make it.
Aleix: Indeed no, I need you at least on those 2 sessions of the first day, the rest is optional to you. Does it work for you?
Leader: It works for me.
We did a Lean Inception, the first day created that much interesting conversations that people stayed for the 3 days! It was the space where decisions were made and people wanted to be part of it.
It was a good first step, but we still needed to deliver.
The team enjoyed being part of the decision making, they felt heard about their concerns, and leadership saw an engaged team. That created more ownership by people and, even though, we didn’t deliver everything, what matter to the business was done.
The business goals were achieved without requiring everything to be delivered. Understanding what is important and has more priority helped the team make sensible decisions autonomously!
You know what happened the next quarter? People asked when was the Lean Inception. Both, teams and leadership.
Lean Inception become part of our culture.
TLDR strategy
Understanding: The lack of space and collaboration between leadership and product teams (before was mainly leadership → product → design → devs) created silos and low ownership. Creating a culture of fear to failure (it has implications on people’s salary) and aiming for perfection always.
This implied that we had less room for failure and leadership had more presure to deliver and, therefore, micromanage. This implied that teams had less control, ownership, and were siloed. Causing longer lead times, rework, and production issues.
Direction: Increase team ownership aligned with business needs.
Coherent actions:
Create the space for all people have the right conversations. → Lean Inception
Create the continuous space to speak about the business → Open zoom rooms with the PM and inviting key people to discuss the business domain.
Create a shared collaboration method between all roles → Train people (PMs, Designers, Devs, Business, Ops, …) on Event Storming to reduce the misunderstanding that happened on spoken only conversations.
The outcome of the strategy becomes culture
Culture guides and constrains your strategy. The interesting aspect is, how can you influence culture that lead to better strategies??
Multiple organizations share that they need to improve their organization culture, yet I know few successful cases where it actually happen.
I do believe that strategy is the strongest driver to make it happen.
Do you want to influence your company’s culture? Think of strategy in the next way:
How can I address the business needs, understanding the current context and culture, in a way that:
1. The business needs are fulfilled.
2. The approach we took becomes part of the culture. Either to reinforce or to change direction.
What happens if an strategy fails to address the business neeeds?
What is important is how you treat failure. If failing to address the business needs is blame and more command and control, you are creating a culture of fear.
If you treat it as a learning. You create a culture of continuous improvement.
What happens if an strategy addresses the business needs in the wrong way?
We achieved our business goals! What did it require?
Extra work
Top-down deadlines
Pressure on delivery
Hero culture
What the company saw? The business goals have been achieved!
Do you know what will happen next? Those actions will be repatead and even pushed even harder, because it worked once!
Now you have a top-down hero-culture and will only increase within your organization if you don’t take drastic actions.
Recap
Be meaningful of how you design and execute your strategy because you might get a success once that put your up for failure on the future.
Thank you a lot for reading this post 😄.
I love to read your feedback and opinions to help me improve. You can DM at my LinkedIn or just leave a comment using the following links: