Substack Week: Engineering Strategy, Bridging Technical Excellence with Business Success | Aleix Morgadas

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches

Episode: Substack Week: Engineering Strategy, Bridging Technical Excellence with Business Success | Aleix Morgadas
Host: Pasco Duarte
Guest: Aleix Morgadas, Engineering Strategy Consultant
Release Date: February 19, 2025

---

Introduction

In this episode of the Scrum Master Toolbox Podcast, host Pasco Duarte welcomes Aleix Morgadas, an engineering strategy consultant renowned for his insights on aligning technical excellence with business objectives. The conversation delves deep into the nuances of engineering strategy, emphasizing its critical role in bridging the gap between technical teams and overarching business goals.

---

Guest Background and Motivation

Aleix Morgadas shares his journey into engineering strategy, highlighting a pivotal moment in 2020 when he transitioned into a leadership role within a large organization. Faced with the challenges of impacting a vast engineering department, Aleix found himself grappling with the complexities of engineering strategy within a business context.

[03:14] Aleix Morgadas: "I was quite lost on some of the engineering aspects or engineering strategy aspects, more on about impacting bigger organization."

To navigate this, he turned to writing, which served as a tool to crystallize abstract concepts into tangible insights. This process not only deepened his understanding but also fostered a collaborative environment where peers could challenge and refine his ideas.

[04:05] Aleix Morgadas: "It forced myself to go deeper. Why do that? And checking my assumptions and the ways of words doing it."

---

The Importance of Engineering Strategy in Business Alignment

Pasco Duarte underscores the rarity of discussions around engineering strategy, despite its vital role in synchronizing technology with business objectives. Aleix emphasizes that without a robust engineering strategy, technical teams often find themselves relegated to tactical discussions, such as managing technical debt or adopting new frameworks, rather than contributing to strategic business decisions.

[08:03] Aleix Morgadas: "Engineering strategy doesn't happen in the vacuum. It needs to align with the business strategy."

This misalignment can lead to scenarios where strategic decisions fail during execution, either due to a lack of technical feasibility or insufficient understanding of the business context.

---

Four-Step Process for Designing an Engineering Strategy

Aleix introduces a structured four-step process for crafting an effective engineering strategy, drawing inspiration from Richard Rumelt’s "Good Strategy," John Doerr’s "Measure What Matters," and other strategic frameworks.

1. Understanding the Business Context and Purpose

   The foundation of any engineering strategy lies in comprehending the business landscape and the organization's core purpose. Whether the business operates on a B2B or B2C model, or its revenue streams are transactional or subscription-based, these factors profoundly influence the engineering strategy.

   [22:47] Aleix Morgadas: "Strategy happens within a business context and purpose, so it's not happening on the vacuum."

2. Identifying and Defining Pains

   Recognizing the challenges faced by both the business and engineering teams is crucial. These "pains" drive energy and focus, ensuring that the strategy addresses real, impactful issues.

   [15:22] Aleix Morgadas: "On engineering strategy, usually when you come from the top it has the business pains... they're missing a way to be on the decision making."

3. Establishing Direction and Guiding Policies

   Once the pains are identified, the next step is to set a clear direction that aligns with business objectives. Aleix advises against rigid policies, suggesting instead the use of flexible guiding principles that can adapt as the strategy evolves.

   [26:54] Aleix Morgadas: "Strategy is about focusing on learning... the action needs to position you in a better situation than you were before."

4. Defining Coherent Actions

   Translating strategic direction into actionable steps is essential. Aleix emphasizes selecting initiatives that are non-competing and aligned with the overall business strategy. This ensures that efforts are not fragmented and that each action contributes meaningfully to the strategic goals.

   [22:47] Aleix Morgadas: "The guiding policy or the direction is more like... it's abstract enough that you know there is a lot of work but it's not actionable. You need to break it down."

---

Role of Middle Management, Scrum Masters, and Agile Coaches

Pasco inquires about the responsibilities of middle management and Scrum Masters in shaping and executing engineering strategies. Aleix stresses the importance of these roles in bridging the communication gap between technical teams and leadership.

[14:15] Aleix Morgadas: "By understanding how the strategy is being formed and how it deteriorated, they can add meaningful inputs at the right time."

He advocates for empowering Scrum Masters and Agile Coaches to voice team challenges and align tactical actions with strategic objectives. This participatory approach fosters autonomy and ensures that strategies are grounded in the realities of day-to-day operations.

[18:44] Aleix Morgadas: "People start having this, okay, if we contribute as a team... it's a win-win."

---

Implementing and Executing the Strategy

Transitioning from strategy formulation to execution requires careful management to maintain momentum and adaptability. Aleix shares his experience at Creditus, where he implemented a strategy focusing on mobile and platform stability. By involving teams in decision-making and allowing them to volunteer for initiatives, he ensured commitment and minimized resistance.

[35:47] Aleix Morgadas: "By making things optional... we reduce a lot of the risk about execution."

He highlights the importance of setting success metrics to determine when to pivot or advance within the strategic framework. This iterative approach mirrors agile methodologies, allowing for continuous learning and refinement.

[32:40] Aleix Morgadas: "Engineering strategy needs to have success metrics. And is it... when you stop doing the strategy to move into the next thing."

---

Building Trust and Autonomy

A recurring theme in the conversation is the establishment of trust between technical teams and strategic leadership. By demonstrating the tangible benefits of strategic initiatives—such as improved deployment speeds and enhanced team capabilities—Aleix was able to garner increased trust and autonomy for his engineering teams.

[37:40] Aleix Morgadas: "When you finish understanding the pains... the impact of the company and it will give me the right experience."

This trust is further reinforced by aligning engineering actions with business outcomes, ensuring that initiatives are not only technically sound but also economically viable.

---

Resources and Further Learning

Aleix directs listeners to his Substack newsletter, which offers in-depth exploration of engineering strategy concepts. Additionally, he mentions a comprehensive 50-minute talk that chronicles his journey in designing and executing engineering strategies, providing concrete examples and actionable insights.

[38:37] Aleix Morgadas: "I have... a talk... how to help people design and execute their own engineering strategy... concrete examples about things like how you create a strategy with domain-driven design, with context mapping, with team topologies."

He also recommends following him on LinkedIn for regular updates and early ideas, which often serve as precursors to more detailed blog posts.

---

Conclusion

This episode offers a profound exploration of engineering strategy, highlighting its indispensable role in harmonizing technical endeavors with business objectives. Aleix Morgadas provides a pragmatic framework for crafting and implementing effective engineering strategies, emphasizing collaboration, adaptability, and continuous learning. For Scrum Masters, Agile Coaches, and engineering leaders seeking to elevate their strategic impact, this conversation serves as an invaluable guide.

---

Notable Quotes:

• Aleix Morgadas [04:05]: "It forced myself to go deeper. Why do that? And checking my assumptions and the ways of words doing it."

• Pasco Duarte [22:27]: "Separating strategy from execution is like separating head from shoulders—conceptually possible, but with deadly consequences."

• Aleix Morgadas [15:22]: "It's super important that you don't jump into action... define problems, but we're not solving them."

---

Resources Mentioned:

• Aleix Morgadas’ Substack Newsletter: Substack Link in Show Notes
• Aleix’s Comprehensive Talk on Engineering Strategy: Watch Here
• LinkedIn Profile: Aleix Morgadas on LinkedIn

---

For more insights and actionable advice, subscribe to the Scrum Master Toolbox Podcast and join the community of Scrum Masters and Agile Coaches dedicated to continuous improvement and strategic excellence.

Transcript

[Pasco Duarte]

Hi there, Pasco Duarte here, your host. I wanted to share a story with you. You know how sometimes Agile just feels like following another checklist when like processes and frameworks feel more important than what we are trying to achieve and sometimes even like handcuffs. I was talking to a customer of the Global Agile Summit and he used a term that kind of stuck in my he said I have Agile fatigue. And I've heard that a lot from people since then. But here's the thing, it doesn't have to be this way. So we started thinking and at the Global Agile Summit, which is happening this May, we're bringing together practitioners who've actually done that, who've broken free from this, you know, install the framework kind of mindset. We want to focus the summit on real life, first person stories of Agile all succeeding that inspire you to action. We're talking real experiences, practical solutions and of course amazing insights from leaders like Gojkoacic, who will be one of the keynote speakers, and Jurgen Apelo, who will be one of the keynote speakers as well. If you're ready to leave the Agile fatigue behind, just join us in Dalit. The early birth tickets are now available@the globalagilesummit.com and mark your calendar. We will have workshops on May 18th, that's a Sunday. And then the conference itself will happen on May 19th and 20th of 2025 in Tallinn, Estonia. So let's make Agile exciting again. And remember, go to agile globalagilesummit.com that is and get your early birth ticket. Now it will only be available until early March, so grab it now. And now onto the episode.

[Alex Morgadas]

Hello everybody.

[Pasco Duarte]

Welcome to our Substack week where we interview thought leaders who publish newsletters on substack to help you find inspiring voices that drive our community forward. Today we have with us Alex Morgadas. Hey Alex, welcome.

[Alex Morgadas]

Nice to be here. Thank you for inviting me.

[Pasco Duarte]

Absolutely. It's a pleasure to have you here. So Alex is a engineering strategy consultant that focuses on the socio technical aspect to overcome the high stake business challenges. He shares his knowledge frequently in his newsletter. The link is in the show notes so make sure that you check it out while leading a temperature SaaS product to assess team cognitive load for healthier teams. So be sure to check out his newsletter and of course today you're going to know a little bit more about him. So Alex, let's get started with the topic of your substack newsletter was quite surprising when I found it. It's engineering strategy. What got you started in that topic?

[Alex Morgadas]

So I remember 2020, I started more in the leadership positions. I became a manager and joined a big company, more like 3,000 people, 300 engineer, tech department. And what I found is that I was quite lost on some of the engineering aspects or engineering strategy aspects, more on about impacting bigger organization. And I found that the best way to learn more it was about forcing myself to write and move those abstract concepts into more concrete. And I found that by trying to explain them, it forced myself to go deeper. Why do that? And checking my assumptions and the ways of words doing it. And also helping other people. But I will say that it's more other people helping me to understand what I was wrong or I was right and then learning more about the topic.

[Pasco Duarte]

Yeah, that was quite a while back. We're recording this in early 2025 and you've been writing about this for a long time. I absolutely agree with the fact that or your observation rather that when we try to write about something, we have to learn and understand it better before we can write or as we write. Right. Because there are different questions that come up and we try to tackle those questions. Is there like a specific question that got you started or a specific aspect of engineering strategy that you say, okay, I really need to write about this because otherwise I will not understand it.

[Alex Morgadas]

I think it was like some of different topics, but what they found myself in is that strategy is mainly used within business and product. I found myself that my peers from product, from business, they were talking all the time about the strategy, money, focus and engineering had a second voice in that table. We didn't have the vocabulary to be having a voice for impact. Yes, we have architecture, we have to manage design, we have a lot of things. But we were missing a way to be on the decision making. And I found that those toolings are good, but they don't talk enough the business language. And then I found myself like okay, how can I adapt those well known frameworks ways of working into or engineering strategy world kind of reducing the gap between business and engineering from a strategy perspective. And that's what it brought me started about why I started doing this. I would say that that's, that is what helped me. It is, hey, I understand your business problem, I'm talking your language and now I'm bringing you the engineering perspective. And that's why it's important to tackle this. Otherwise we're in the same team, we want to accomplish those goals. But you need to understand engineering also have their own challenges, they want to help you. And sometimes it's Focusing on products, sometimes focusing engineering. And it's not like me or you, it's like what makes sense now so we can accomplish that thing. And that is what it really sparked my desire to help other people to hey, you can also impact business with using the proper language, the proper frameworks and then we can have this impact and not be like only tech debt. Only like, hey, what do you need? Hey, why we need platform? Like, no, let's make more reasonable decisions and drive that value to the business as well.

[Pasco Duarte]

For me, I have to say it was very surprising to find that so few people talk about engineering strategy. And of course your newsletter is one of the places where people can go and and learn more about engineering strategy. And why I find it so surprising is that when I talk with ctos, we have a series of episodes with ctos here on the podcast where we explore exactly the problem of aligning technology and business in terms of strategy, direction, vision, et cetera. And very often there isn't, as you say, that language. Right? Because the strategy within the technology departments needs to be aligned with the strategy within the sales or product or top level strategy for the business. And if we don't have that ability to discuss strategy for technology, we end up only discussing the details. Just like you said, right? Like yeah, let's talk about tech debt or the new web development framework that we need to onboard to the organization and hire people that already know how to work with. But those are all very tactical. So I was really happy to see your newsletter because it really brought to the fore this idea that CTOs are responsible for a very specific and important aspect of technology company strategy. Right, which is engineering strategy.

[Alex Morgadas]

That's right. And I will also add that I found that this newsletter is helping some CTOs, but for my surprise, it is helping out of middle management as well. People that sometimes the CTO comes with a strategy and they don't know how to challenge it, how to implement it, how to contribute to it before it's in a document and now it's super rigid. So it is helping more people than I thought. And before I didn't have like understanding that the middle management played that bigger role into making an engineering strategy happen, not only in like designing it, but also in executing it. So as you said, it's like, hey, how we can move from tactical things into more strategic things and also challenging engineering, saying, hey, what you're doing doesn't make sense. For example, like hey, you want to expand and now you're talking me about implementing kubernetes like how those two things add up. And if you don't have the language to say that, hey, it's not like they don't allow you to do that. It's like, hey, maybe it doesn't make sense. You don't have the language or the reasons to say why that's needed. And it's good that you don't get maybe like the initiative founded or whatever. And we need to also be able to contribute in a reasonable manner. Like, hey, I am doing initiatives that needs money, this needs a return of investment. How I can measure that and have this language about hey, at the end it's about how I can help the business to make more money in terms of maybe new features, new capabilities or maybe reducing the costs. Those things is like that decision making is what is helping not only CTOs but all the middle management that they know how to make the right questions and the right calls. By doing that and knowing that you're contributing to the business, they started to gain way more autonomy because people like, okay, I understand these people understand the business, they are doing that because I understand my business model, my business needs, okay, I trust you. And they start getting a lot of autonomy along the way.

[Pasco Duarte]

Yeah. And that aspect of autonomy has a very critical impact. Right. Like you just said, maybe technology does understand that we do need to move to kubernetes, but if we can't explain that in the context of the wider business strategy, it's just not going to get funded and then we are stuck with whatever technology was there at the time and then we don't know how to contribute to the overall business strategy. And there are also other aspects, especially for people out there that are working in high growth scale ups that may be sold to other companies. A very critical question is how do we devise a strategy that enables acquisition? I'll just give an example. I'm working with a client where they have a core technology organization that serves two other technology organizations that are being sold. Right. And these other technology organizations, they are product organizations, they're going to be sold to separate companies. And now this core, this services or platform technology organization needs to develop their own strategy in order to enable that sale. And we don't know what it means in practice, but we need to develop that strategy. We need to have a perspective, an idea of what it would be to serve this product organizations when they are split and sold off to other organizations.

[Alex Morgadas]

That's totally. It is what it is. That's right. It's like, hey, engineering strategy doesn't Happen in the vacuum it needs. It's not like a silo that enables all this. Like it is. For me a good engineering strategy is the same business strategy from a business. Sorry for an engineering point of view. It's like if you cannot tell the difference, then it's a good thing. If you can say oh, the business is going this direction and then. But we are doing that. It's like hey, something is happening there. So I hope that I'm helping people to reduce the gap, be more aligned and have the right questions to get the good enough answers. Because I would say the strategy doesn't have best answers have like good enough next step to get into a goal.

[Pasco Duarte]

Right? So also because strategies need to evolve just like software needs to evolve, right? Like we, we make a certain number of assumptions as time goes by, maybe some of those change and strategy needs to adapt to that as well.

[Alex Morgadas]

Exactly. So that happened to me and it's something that I tell people like hey, don't do a 2025 strategy. Maybe you can do Q1 2025 strategy, but at some point you need to review those. And happened to me before, it's like hey, what you will do for this year is like no, no, I will start this. Those are my assumptions. I'm working with the team to verify that those steps that we are doing are good enough and by we reach this point we will review it. And it was super important to make the process of engineering strategy not that painful. Because if you need a lot of bureaucracy, a lot of sign offs, a lot of presenting, these people are very busy. So if you are unable to access them and then you make the process super tedious, you will prevent the strategy to happen smoothly. What we did was like hey, we don't need to do a very big one. Tell me please, my VP of engineering, which are the things that you want to involve and the ones that I can just iterate fast. And then we know when we need to talk and when we need not need to talk. And that enabled us to go quite fast into hey, we involve C level or senior leadership in this moment it was head of engineering, so I wasn't have some autonomy. But I also knew when to involve the right people. When hey, this is bigger. We were quite off on the strategy and we are only three months in so we could still react. Just imagine that you only do strategy once a year. Then it's like hey, now you have a lot of assumptions. You have a lot.

[Pasco Duarte]

Can you imagine? Because if you look back into the history of software Development. Not that long ago we would do testing once a year. Imagine that. And now we're talking about how crazy it is to even do strategy once a year. I think we have evolved. We should tap ourselves in the back and be happy that we are finally moving in the right direction when it comes to being adaptable organizations.

[Alex Morgadas]

That's right. So at the end for me using engineering strategy as a term it was getting a lot of concepts like evolutionary architecture, TD things like how I can learn faster that I'm going in the right direction. And for me applying a lot of these agile principles, extreme priming principles into strategy, using the business world and kind of feel natural after some point like hey, why we were not doing this before. So I think we can, we know a lot, we learn a lot as industry and we can apply those principles to areas that they are not yet that mature with our needs. Like hey, check fast, verify that you're going in direction, fail cheap enough and then learn faster. Right.

[Pasco Duarte]

So yeah, yeah. In the Substack newsletter you talk about this four step process for designing an engineering strategy. Before we go to the process though, I wanted to ask what do you think that middle management scrum masters, agile coaches need to be aware of? They need to know in order to be able to help their leaders prepare an engineering strategy.

[Alex Morgadas]

When, when I was at Creditus I at some point people started to know when to be involved and before just explaining all of that what they tell them, hey, strategy, even though it's a top down decision, it doesn't need to be designed as only top down because top level leadership has one vision and teams have other vision and it's not like one or the other, it's like the mix of them both. And usually what I tell them is like hey, on engineering strategy usually when you come from the top it has the business pains, what we want to accomplish, but it's not connected to the team's pains. And sometimes we can say hey, we want that but then the day to day of the team is not able to reach that for whatever reason then the strategy needs to be somehow realistic enough to make able to move step forward. People start to say hey, we are going to do this. The teams and the scrum masters and the principals start saying hey, that's great, let me check what is preventing us to do that today. They start to add things like hey, these are the pains from the teams. Maybe people don't have skills on observability and you're assuming in their strategy that we know observability okay, what we can do here, they start signaling possible risks about not being able to execute the strategy effectively. That's what I started to sense from my reports. And they start getting like, hey, I want to involve early so I can bring up the issue. I know it's not my last call to make what I focus, but at least you have information. So I know that you as a leader, at least you make an informed decision. And then people get a lot of buy in because at the end it's like, okay, I see the strategy take into account my pains. It's not only mine because that's something interesting. People think like, oh, it's only me that I'm suffering this. But then people start signaling those pains and they're like, oh, it's not me, it is me and the other team. And the other team, okay, maybe we can do something together. We are not alone on this. Then people start having this, okay, if we contribute as a team or as a tribe into making that, we know that we are contributing to the strategy but also solving our own pains. It's a win win. That's how people, by understanding how the strategy is being formed and how it deteriorated, can add those meaningful inputs at the right time. Because that was important before it happens that there's a PDF or a Google Drive or whatever there before that's done. Because then changing that is quite hard. They know how to contribute lean enough, which means, hey, they don't need to be super bureaucratic. It needs to be something like more easier computer vision. They can contribute and then at least they know, okay, that's the goals. My C level understand my pains. They took into account what is important, what is not. Because you cannot do everything and then make the decision. And then now I know how to contribute to make that happen. So it is super important people understand the language of the business and how contribute and then connect the day to day pain to the pain of the business and then okay, that's important to me to communicate effectively. Let's find others and then do this impact early on.

[Pasco Duarte]

I really like when you mentioned that one part of the process is to figure out what are the pains that we want to address. Even just that aspect, okay, there's top level management pains, there's middle level management pains, and there's execution day to day team level pains. And we need to figure out, okay, which of these are actually important for us to move forward with the strategy that we want. Now in the newsletter you talk about this four step process in designing an engineering strategy. Before we go through the steps, just highlight for us how the process goes. What's the source that you use to kind of design that approach that you have developed for engineering strategy and how does it usually flow?

[Alex Morgadas]

I used to inspire by the BATA strategy, good strategy from Richard Rumbold in combination with some North Star from John Kadler and some other work from other people. It's inspired by these people that work in that and that in that engineering strategy. What I found is that there is two kind of strategies. The deliberate one, the one that is communicated and worked. Maybe there is a document that says that's what we want to do. And the merging strategy, things that how people react to the day to day. And that's also strategy. Right. So it's like and it happens in different frequencies and some is more formal, the other is more informal. But the both are needed. What they found is that usually there is always like understanding what is happening, making some decisions and then execution. The ones that I don't like is the ones that separate the people that design that from the people that execute when there is a strong division.

[Pasco Duarte]

Can you give an example of what that means?

[Alex Morgadas]

Yes, I think we all suffer this. I remember that, hey, we decided that we will work focus on that. Then for example, we want to iterate this, we want to release these products. Then you're like okay, but you didn't take into account that maybe the team doesn't have the mobile capabilities or the mobile skills or we are missing some important components that we need to externalize or we don't have the right people. And then you make all the work at this super strange situation because if you succeed on the strategy, some people said oh, it's because it was well designed and if you fail it's because you had a bad execution. And so for the teams executing it is like it's a loose situation almost. It's like if they did well, it's because it was well designed. If they did bad, it's because it was not well implemented. So what we start to do is mixing up people like hey, it's not like me or you, it's we. And we start to involve people that make decisions more in the day to day, like understanding the pains, understanding why it is failing. And then people start realizing oh, we thought that I didn't know about this other thing. And then leadership was more committed into adapting and helping and being involved. And hey, I am available for you because I know that you're addressing my needs and I know that I failed on that. Because of something which is good, we learn fast and we focus more on learning and then adapting versus me versus you. And I think that when we move away from some people design, some people execute, and it's like all people is involved. We improved a lot the team morale and the psychological safety. And a lot of things happen along the way.

[Pasco Duarte]

This is actually a great point. I usually describe it like, separating strategy from execution is like separating head from shoulders, conceptually possible, but with deadly consequences.

[Alex Morgadas]

Don't do that if you can.

[Pasco Duarte]

All right, but let's go through that process. So you define this four step process, outline the steps for us.

[Alex Morgadas]

Sure. So we need to understand that strategy happens within a business context and purpose, so it's not happening on the vacuum. So you need to understand where you are, which is your purpose. And the context can be, I am a B2B or I'm a B2C. I am a transactional model, I am a subscription model, I am in selling ads. That's your landscape. So you start with this. It's very different a B2B enterprise than a B2C. The strategy of engineering will be shaped a lot by only this. So you start with this, you start with the purpose. Maybe your purpose in impacting and helping users to have less cognitive load. Maybe it's more about measuring, I don't know, the efficiency about parcel shipping, whatever is your purpose. So you start by this. And then I tell people, don't put goals, don't put like, I want to earn 30% more or whatever. You just need to focus. You need to have a sense about what you want to accomplish, maybe to start a new market. And then you add them, but it's not like a goal. Maybe it's like put them as information about what you maybe start thinking. And then you talk about which are today's problems. We talk to these pains. I like a lot of pains because it drives a lot of energy there. So if you ignore them, it just kind of adds up. And then you have a list about business pains. Things like you cannot. You ask people like, hey, what you're preventing. You're like, oh, I want to ship 10 more capabilities. But we ship one capability once a month. Maybe we ship four a month, maybe it can go faster. And then you ask the developers, oh, but I have a lot of technical left here and I don't know this. And then we're all the time it's failing because we have no testing. And then you start sensing about the problems, you don't tackle them. That's super Important that you don't jump into action.

[Pasco Duarte]

So first figure out what the problems are that you want to solve.

[Alex Morgadas]

Exactly. And sometimes surfacing the obvious because people think, oh, that's obvious. Like Don, maybe it's obvious for you and maybe not for the next person. So only by surfing the pains, you start creating alignment about the problems and then you need to over enforce like, hey, we define problems, but we're not solving them. Because we will only solve those that are preventing us to reach our business objectives if they are not aligned. For example, hey, we want to make the customer satisfaction is very low because of the failure of the platform. Okay, maybe we want to invest in testing, but why should do a rebranding? Okay, but there is no connection or is very low correlation between this action and this pain and that goal. Therefore we just start discarding things. Because a strategy is important what you do, but more importantly what you don't do. And trust me, everyone wants to put more things. The strategy is hard to execute. The less things you need to tackle at the beginning, the better.

[Pasco Duarte]

One would have even the argument that if we take this evolution of strategy, we have to have a direction for sure, but we don't need to solve all of the problems to that end state, because actually by solving one, we might uncover other aspects that are more important than the list we created in the beginning. Right? So there's an argument also to understand, okay, these are the possible problems. Let's choose one right now, let's solve that first and then assess the impact so that we can then decide what's the next one.

[Alex Morgadas]

And that's super important because by doing you learn and you want to be doing. And that first step at least when you start doing strategy for the beginning is like do the less effort action that you can do, because then you will see how hard is it to do something. So I don't like the strategy that like, oh, we want to reach that point and it's very far. Maybe that's something else, maybe that's an inspiring thing. But you need to go to the next responsible step and then from there you learn and then you go and then you choose another path from the things you learn. Because the important part of a strategy is that you focus on learning. And that action that you make or that direction that you take, it needs to position you in a better situation than you were before.

[Pasco Duarte]

And this already goes into the next step, right? Like this, giving direction and having you call it coherent action. Can you break that down for us a little bit?

[Alex Morgadas]

So in the Strategy There is three components by regional Rumble says diagnosis, guiding policy and then current actions. I say to engineering team, it's like you need to analyze the problem or understand the problem, then you need the direction. I say the direction because people usually say oh, that's where we want to go. I found that guiding policy for some policies like, oh, policies, we don't like policies. That's bureaucracy. So sometimes I adapt the language to have less barrier. So adapt the framework to your own needs and your company language so you don't have language barriers. So that's my suggestion. And the guiding policy or the direction is more like, hey, in order to accomplish this we need to focus on mobile. We need to focus on mobile. Maybe we need to focus on platform. It is enough abstract that you know there is a lot of work but it's not like actionable. You need to break it down and that's when we move into querying actions. An important aspect here is querying action because you can do a lot of actions but maybe they are competing between themselves. I say, hey, is this action current with the business strategy? With the strategy and it's not competing with other actions. When you are small enough, you can have current actions if you're super big. I found that sometimes I ask people, I have some clients that say, hey, they are 4,000 engineers and say you cannot have everything clearing, at least design things that are not competing. I don't ask you for currency, I just like for not competing things like oh, we want to move into transactional business and the other part is moving into subscription. Like hey, those are competing actions, you cannot do both. Right? So the querying actions is something I like because people can get involved in querying actions. And I will give an example. When I was at Creditus, I designed a strategy that implied focus on three aspects. It was mobile and platform. Stability was the two main pains. We had some issues, recurring issues. We were solving it, some of them impacting customers. But lucky us was not the majority and mobile was super slow. Just to give you an example, we had four teams. Only one team was doing mobile, therefore and all the teams were doing was a mobile product. But not the teams had mobile developers. So we needed to do like hey, we, we will focus on mobile because that's a business problem. It's preventing us to ship fast. And we will focus on stability because it's impacting the customers and we're getting bad reputation if we don't solve this on the long term because it was increasing the defects of the platform and Then we decided to say we will focus on platform stability and mobile. So correction was let's do a training, let's do implement. People said, oh, query interaction, let's add Kafka and move to event driven architectures. Like that is an action, it's coherent but the cost is quite high. Give me three alternatives to this coherent action and say, okay, we can add circuit breakers, it's coherent, less cost. Great, we can start by that. And then in order to achieve performance stability, we have things like from moving to event driven, from only adding red tries on the HTTP level. And we had the good shape of options on that matter and we said, okay, who wants to lead adding CQ breakers into the platform like hey, I want to contribute, I want to learn. And then people signal themselves like, hey, I want to lead this action that is cross team. I want to have cross team impact. Great, you lead that if you do this action and then it's become good enough. Because engineering strategy needs to have success metrics. And is it, hey, when we stop doing the strategy to move into the next thing because you can be doing that forever so you want to know when to stop. And then people say like, oh, by only adding circuit breakers and then moving to event driven, only in this use case we succeed. Like great, stop, we move to the next thing. Then people start realize, oh, if I lead the experience and know how to influence in the bigger scale, I can be promoted to staff engineer as senior. Because I said to people, you don't need to be staff to lead this, you can lead that help, but you can also contribute and collaborate with other peers and then you get experience and then you're doing architectural work, that's your opportunity. Why we are saying this yes and not that. Because if you tell me hey, I want to try GraphQL, I would say like, it's not querying with anything. We said, you will not get this initiative founded, therefore you will not have a success story about impacting the strategy. Therefore in your performance review it will be hard to argue why you need a change of role. Then people realized, okay, if I contribute here, I know the impact is directed to the business strategy, the impact of the company and it will give me the right experience and I can feel in a, in a I can fail and the impact is low. That's important because if you can have a space to learn and experiment and the failure is not that high, which is the problem of experimenting there, it's like, hey, you need to do that. You know that maybe you failed for two Weeks, but it's not. You fail for two months. So the people become like, yes, I can do this. I can have my peers helping me. People know what I'm doing because everyone knows why we're doing this. So there's no actions question asked, like, why are you doing that? And then people became more like, okay, let's do that. I'm very engaged.

[Pasco Duarte]

And actually what you're saying is very important because as you engage the organization with those coherent actions, you're also at the same time putting into practice a very effective way of leading change. Because of course, you know, implementing strategy is in the end a change process. And you're allowing people to volunteer. And that serves two critical purposes. One is you find the people who want to be part of it. Those are the ones you want to help you and also the ones you want to support. Right? And then you're also allowing people to grow and to signal that they are ready to grow. Right? They are ready to step up in terms of responsibility and in terms of developing their knowledge. And that can be extremely powerful to develop the organization itself. Right. The group of people working in the strategy towards the future.

[Alex Morgadas]

That's right. So at the end is I see all these people, I see the people that has more pain. And we also identify current actions that has no one know they're involved. And then we know, hey, this needs to happen. But I see that no one wants to volunteer on that. So we are ready only by making. That's the good thing is like by making things optional, you know, where the things we will focus and the things that not. And that that thing was a legal thing, like know your customer involving legal. And people didn't want to do that and then say, okay, only by making instead of assigning people, allowing people to volunteer. I already know that this will fail if I don't step in. Maybe I do it myself, which is great. Which is a problem of me doing in a connection nothing. I say that, hey, I see this, you focus on that. I will focus on this. And I need a person to help me, who wants to help me. I know it's not funny thing doing little stuff, but needs to happen. And then people say like, okay, volunteer. And I really appreciate the people that, hey, I know it's not funny, but I'm happy. So we reduce a lot of the risk about execution only by doing that through this. When you finish understanding the pains, understanding the business and the team pains, you set the direction to focus on. We will focus on mobile and platform stability. You set A set of current actions and only you start with the lowest, bigger impact, lowest effort, and then you review. If you're impacting writes, then you move into execution. And execution is super tricky because the status quo is not doing engineering strategy. The status quo is shipping features in that case. So I needed to be sure that people have the room to make it happen. I learned a lot there. First I tried to set, okay, we will meet on Fridays and we will check how the progress is done. Long story short, no progress was done. Okay, what's happening, why it's aligned. Everyone sees that it's important. Then you need to dig it into like, what is preventing you to do engineering work. It's like, oh, well, it's because we have this engineering pressure and so on, so forth.

[Pasco Duarte]

Yeah, feature release pressure, of course, yes.

[Alex Morgadas]

And then you need to move to product and say, hey, we agreed on this. We involve you product in the engineering strategy. It's not us, it is both. You understand that this needs to happen to reach your goals and you are making yourself not. You cannot succeed without this. So we will do room and then you at the same time, hey, I will get my engineers, we will focus on that. And I will isolate some of them first because I needed to be quite bold here. It's like, hey, you don't have these engineers available. Why? It's like, we have pressure, sure. But if we don't do that, trust me. When do you want this by? One month or something? Okay, we will focus on these two things that are only a total one week of work and you will lose one week of work. Engineers impact. I said to them, like, nothing because we are always late, which is the impact of being still late. It's like you're trying to do. It's not working this way. It's like, let it fail. We move, we do that. And then it's like, oh, now we ship this. We are going faster. Okay, I see that is succeeding. I didn't thought that was succeeding. Okay, you have my trust. You're helping me as a product to shift faster. Because now before, I need to coordinate your teams. Now my team knows how to do one mobile page. Okay, Now I have more autonomy. Okay. I want more of this. And then as they see you succeed and give them more, like succeed for them, then you get more trust. And then you get trust along the way. And that's the thing is like, if you give people some reasons to still fund you and say, hey, yes, do whatever you need, I know that you're addressing my needs. And by you succeeding, I succeed. It's a partnership. But at the beginning it doesn't work because the trust about succeeding on that is not happening.

[Pasco Duarte]

And this also kind of reinforces the tip you gave earlier which is like focus on the strategic action that is the fastest, the lightest, the least kind of disrupting so that you can get quick feedback, you learn. But also as you just said, you build trust with your strategic stakeholders. Right? Like product or top level management. Alex, this has been a fascinating conversation. Now you have a lot more on your newsletter in substack. The link will be in the show Notes. For example, you also have a template that people can use and we'll link to that in the show Notes. But besides the substack newsletter for which the link is in the show notes, is there like a resource, a book, a video, a blog that you could share with our audience that wants to dig deeper into this topic?

[Alex Morgadas]

I have how it is called like a talk, it's recorded. I will share that where I call about all the journey that they did from how to help people to design and execute their own engineering strategy and they explain from ignoring a strategy to from copying others why that doesn't work into start applying a strategy. And then I give concrete examples about things like how you create a strategy with domain driven design, with context mapping, with team topologies. And then I explain the full journey from not understanding anything into successfully iterating two times for a team. And that is a 50 minutes long talk, almost an hour. And it's great enough for people like okay, I see the framework applied and how it's being iterated and which are the failures, which are the succeeds. So it's in English. I think it's a very. I think it's a good one for the people that prefer audio or video learning. So yeah, absolutely.

[Pasco Duarte]

So we'll put the link to that in the show notes to make sure that people can go and easily watch that first person account of engineering strategy definition and implementation. Alex, it's been a pleasure. Before we go, where can people find out more about you and the work that you are doing?

[Alex Morgadas]

I will say that LinkedIn is the best place. I communicate there a lot. Sure my blog is there but usually I iterate more on some ideas, early ideas that I have, I usually publish them on LinkedIn try out and then if people like those resources, usually I convert them into a blog post more extent. So I think LinkedIn is the right place to find me.

[Pasco Duarte]

Absolutely. Alex, it's been a pleasure. Thank you very much. For your generosity with your time and your knowledge.

[Alex Morgadas]

Thank you for your time. Thank you for inviting me.

[Pasco Duarte]

We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes. Share this podcast and let other Scrum Masters know about this valuable resource for their work. Remember that sharing is caring.