Let’s see some of those, and see in which step on the engineering strategy can we tackle them.

1. Poor Planning & Execution

• Lack of situational awareness: Leadership ignoring the landscape they are competing in.

• Unclear Goals: Vague or unrealistic objectives make it hard to measure success.

• Lack of Alignment: Strategy isn’t connected to the organization’s mission, values, or resources.

• Overcomplication: Too many priorities or steps dilute focus and effort.

• Ignoring Implementation: A brilliant strategy on paper fails if execution isn’t planned (e.g., no timelines, owners, or milestones).

2. Human Factors

• Resistance to Change: Employees or stakeholders may not buy in, especially if they feel excluded from the process.

• Poor Communication: If the strategy isn’t clearly explained, teams won’t understand their role in it.

• Lack of Skills/Resources: The team may lack the talent, tools, or budget to execute the plan.

• Leadership Gaps: Weak or inconsistent leadership fails to inspire or hold teams accountable.

3. External Misjudgments

• Market Shifts: Assuming static conditions (e.g., customer needs, competition, technology) can render a strategy obsolete.

• Ignoring Feedback: Failing to adapt based on real-time data or stakeholder input.

• Overestimating Control: External factors (e.g., regulations, economic downturns) can disrupt even the best-laid plans.

4. Structural Issues

• Siloed Thinking: Departments working in isolation create misalignment.

• Short-Term Focus: Prioritizing quick wins over long-term goals (e.g., quarterly profits vs. sustainability).

• No Flexibility: Rigid strategies break when faced with unforeseen challenges.

5. Measurement & Accountability

• No KPIs: Without clear metrics, progress can’t be tracked.

• No Consequences: Lack of accountability.

• Overconfidence: Assuming success without testing assumptions (e.g., pilot programs, A/B testing, failing small).

I will update the list as I discover more factors 👍

As you can see, strategy fails for multiple reasons. And I’m sure you faced several of those factors on your journey as strategist, leader, or person that has been exposed to bad strategies.

When we design an Engineering Strategy, we might be tempted to jump into architecture, tooling, deployment pipelines, methodologies, … Things that are more related to Tech.

That’s an avoidable mistake.

You can find more info on Engineering Strategy in the next Introductory guide.

Because we all missed the big picture before hitting the wall. Some of us had the chance to realize that was our mistake, and we can do better.

When you start designing your engineering strategy, take a step back and do a collaborative assessment on the state that you’re in.

Factors to avoid during Purpose, Business Context, and Analysis

At the Purpose and Business Context, and Analysis, take a step back and consider all the previous factors as part of the strategy.

During those steps, I carefully review them taking into account:

• Poor Planning & Execution

• Human Factors

• External Misjudgments

• Structural Issues

Here is a list of strategies that set the purpose and analysis to avoid those factors:

Factors to avoid during Direction

When you’re setting the direction, pay extra attention to the next factors:

• Poor Planning & Execution

• Human Factors

• Measurement & Accountability

Here is the example list:

Factors to avoid during Coherent Actions

When you’re deciding and executing the coherent actions, that’s a great opportunity to stress the strategy and see which are the areas that you need to improve.

The main factors to look for are:

• Poor Planning & Execution

• Human Factors

• Structural Issues

Here are some posts that used the coherent actions to iterate the strategy.

Taking the Strategy Common Failure Factors into account won’t necessarily avoid them, but can help to reduce the chances of designing and executing a poor strategy.

I always have those factors present in during my journey, and the more people aware of those that can have this holistic view of the company situation and context the better, brining those concerns early can save you months of suffering.

This will avoid you to be blind sided by stuff that’s not 100% “tech”, but influences 100% the strategy outcome.

💬 Let us know in the comments which are the main factors that caused a strategy of yours to fail, and what did you learn from that experience!

Leave a comment

All of a sudden, in the slides there were a new team.

I had a new team that nobody asked me for my input, nor informed me before that decision was made. It just appeared out of nowhere.

This is that kind of situations that sucks are unfortunate.

In that situation, I could have focused on:

1. Why I wasn’t included in the decision-making, or

2. Understand the reasons of that team, and how can we leverage it for the challenges we had.

I went for the second.

Simplified conversation.

- Aleix: Which is the mission of that team? How will we work together?

- Product leader: The goal is to improve our Customer Experience. We take a lot of time to resolve tickets, and our CX team needs better tooling to support our clients. This team will be in charge of a new dashboard.

Conversations are unstructured, therefore, we always need to extract the intentions from the noise.

There were things we were aware of, I just found that the operation model that the decision was made was based on a previous sociotechnical structure.

On the old operating model, the company founded teams based on technology components. A mobile team, a backend team, a web team, and, in this case, a CX team doing a dashboard.

The product had a broken experience due to the handovers between teams, no single team owned the product E2E.

So, we moved towards a team owns the full experience. You can see the full journey to reach this point here.

The new operating model worked well, we had fewer bugs, fewer incidents, we were going in the right direction.

Yet, that decision was made. My main opinion of why that happened is:

• Information flows slowly to decision makers. This was due to the new approach was bottom-up, and it didn’t happen in the closed leadership meetings.

• Investing in new teams, during 2020, when the budget is easier, and you need less negotiation between parties.

• Having a single team to own the CX at the tribe makes a clear focus, clear ownership of the metrics, and makes the reporting faster to the specific leader that’s responsible for that.

The team was created odd

The first odd decision was that the team didn’t report to any of the tribe leaders. They reported directly to our product business vertical product leader. And that created a flawed communication, even though we included the team on all the tribe meetings and ceremonies.

The new team was created without the support to succeed.

The business challenge

Regardless of how that team was created, we knew that CX metric had to be improved. We were driven by two:

• ✅ Fewer tickets per month. We succeeded on this.

• ⚠️ Reduce time to resolve a ticket. We still had to improve this by a lot. And, indeed, that’s what the new CX team was funded for. 👈

The CX tribe team approach

During the quarterly planning, they presented their approach.

That didn’t make sense at first, since the team approach and leadership expectations weren’t aligned.

We managed up the miss alignment on expectations. The approach wouldn’t meet the leadership expectations, which impacts our customers and the product experience.

Diagnosis

High lead time to resolve customer support tickets

CX team didn’t have the proper tooling to understand the state of the accounts for them to resolve the tickets autonomously. Each new ticket required a developer to dig into the state for:

1. Understand what’s not working.

2. Apply a fix, usually implying API calls or DB changes due to out of sync systems. We weren’t fully consistent due to the high distributed system we poorly designed. We were improving this at good rate.

So, CX had two problems:

1. They couldn’t answer the customer with we understand what’s your problem, and we are resolving it. They couldn’t have a predictable way to know when things will be resolved.

2. They had a strong dependency on developers’ availability to look into those issues. Which means, outside working hours, they would have to wait until next day to get the answers and fix.

This caused another issue into the teams.

• A lot of distractions and unplanned work to support our customers manually.

The teams and their missions weren’t aligned with new ways of working

CX tribe team was added without understanding the current tribes challenges and structure. The team had to understand the full picture, and start creating human connections to succeed in their mission.

They weren’t autonomous to accomplish their goals, yet they didn’t collaborate with teams to be sure they accomplish it. Instead, they were focusing on the technical challenge of a new greenfield architecture.

Direction

At this point, I had to decide how to accomplish the business goals in this new scenario. And I decided to go with the next approach.

This direction had several implications:

• Product teams will develop their own dashboards, protected, but not having a good overall UX for the CX team, but good enough.

• The dashboard will only contain the use cases that CX need.

  • When a CX opens a ticket into the team, we don’t resolve it manually but create a new dashboard feature to help the CX to do it by themselves.

  • We dedicate the right amount of time to be sure they are autonomous. This means pairing with them, documentation, and so on.

• We will ignore CX tribe team work until it is the right time.

  • I would focus on containing the noise from the team when leadership asks why we’re not using the dashboard they are investing it.

  • The internal Dashboard will have the basics that later could be reused for the new dashboard when it is available.

Execution

No internal per team dashboard was happening

During the execution I faced a very strange challenge. The dashboard wasn’t being developed within the teams, it was taking A LOT.

The dashboard wasn’t that complex: View information, perform some API calls. Replicate what we were doing in the DB and API manually but in a web page.

After sometime asking the team to prioritize that, I realized which was the problem.

People weren’t comfortable with frontend development. Indeed, some shared that they were backend developers, and they wouldn’t do any HTML work.

This delayed everything. Starting from 0 were preventing people to develop the dashboard. I didn’t realize this was happening until very late.

You can see how we moved from per stack developer to full stack developer here

So, I adapted to this reality, and I did a hard push to create the backbone of the dashboard using only spring boot templates. Instead of aiming for a React frontend, we just needed a simple HTML template, to call certain endpoints, and ensuring the security.

When the team had some basic structure in place, extending it was a matter of copying the existing structure.

The dashboard wasn’t beautiful but useful.

Not enough dashboard adoption by CX team

We did the dashboard, it was resolving the tickets, it wasn’t being used by the CX team but by our product manager.

The product manager, she is a lovely person, preferred to take all the burden by herself over passing the tickets into the developers.

We succeeded on freeing the developers from unplanned repetitive work, but now our PM was super busy, and probably burning herself out.

We asked why she was doing that, and how can we help her.

The problem was that CX was used to passing the tickets to our team. Now the tickets were resolving faster (since the dashboard made something super trivial), so, the business objectives were accomplished.

But in the wrong way.

This usually happens, OKRs looks good, but the approach creates the wrong culture.

We had to intervene to accomplish the same OKRs but with a better approach.

CX resolving the issues by themselves, not by our team members, regardless if they are devs, product, or design.

So, we started pairing with CX team, do proper training, and documentation. We showed them that it was less painful to make it using a messy dashboard that resolved their issues fast, rather than opening tickets into our Jira board.

The key area was to kind of use Jira during the process, because that’s the system they used to report their progress. We adapted a little the process to help them show their progress and impact. That boosted the adoption by a lot.

Once that was done, almost all the tickets were solved at CX team level, reducing by a lot the unplanned work for our team.

Within a month, we achieved the OKR of “Reduce time to resolve a ticket” to within hours compared to days.

What could we have done differently?

Two main things went wrong here.

1. We invested into a team to create a dashboard that nobody used. We wasted human time and system resources.

2. Created a dashboard outside the common legacy CX tooling increased adoption friction.

Leadership invested into a new team because that was the operating model we had back then. Each leader had a budget, and they used it to create their own teams they had clear ownership of.

Instead, I would have had added dedicated team members into each team in order to understand the whole product domain, and adapting it to the CX needs instead of creating more communication and managing structure.

My decision of burning money

I knew that by ignoring the CX tribe team creating their own tooling meant that we were burning money, in terms of people’s time and system resources.

At some point, I had to decide which problem to address, and burning money was the cheapest approach to overcome our business high stake challenges.

Sometimes feels like wasting that is the wrong approach, nobody wants to feel they are wasting resources. But looking back, the decision we made was the approach that wasted the less of resources and people’s time.

By focusing on the new ways of working, and the team being autonomous to deliver a solution within the same quarter, indeed, same month, had the biggest customer and business impact.

The friction with leadership team

This created friction within the leadership team during the whole quarter.

Because we were asked to use what they decided to invest.

But here I followed the Team Topologies Platform principle. Do not force adoption. If the platform isn’t good enough, the best we can do is drop it.

At first, this was a very odd decision for other leaders. It felt like I didn’t care about the teams job, but the goal was to show a better way to solve the same thing with the new operating model we had invested for the past months.

This turn out to be a great business case, and we started replicating the approach.

What started as a temporal dashboard, I think it had been there for way more years that we would have expected. 😅

The end of the CX tribe team

That team were in place for 5 months, after seeing no much progress but the product teams resolving those CX metrics by themselves, the leadership team decided to dissamble the team.

Edit for context clarification on 27th April 2026

Previous content has been left as it is.

Where the CX tribe team came from?

Big companies have a lot of business units and reporting structures. Not all of us can be part of all the decision making, and sometimes you gain the information on the last responsible moment.

My managers and myself were in a high pressure times, and we cannot forward all the information at the best moment.

One might not like to gain the information “late”, when the decision is already done, but it’s part of the job.

The important aspect here is how we involved the team into the tribe.

The misalignment goals and duplication of effort

We had the misalignment on how we could handle the business challenge of:

• ⚠️ Reduce time to resolve a ticket. We still had to improve this by a lot. And, indeed, that’s what the new CX team was funded for. 👈

Here we had two duplication of effort planned:

• At Tribe level with each team with their own dashboard 👈 What we had planned until the new info came.

• CX tribe level team to create a unified dashboard

The misalignment was in the delivery time, and teams involvement.

We needed to reduce the Key Metric of lead time to resolve a ticket, the CX tribe level team had 3 months to deliver a functioning dashboard that then each team had to develop their own features.

Speaking with the other EM, we notice some things:

• They missed a lot of information until we spoken about what was being developed and the current status of the project. What looked easy at first, turned out to be a bigger project than expected due to all the distributed logic problem and technical debt.

• The new team was understaffed and didn’t have all the resources to succeed. They required help from all the tribe teams to develop their features into the new dashboard, but this wasn’t a product priority for some quarters.

• Doing the dashboard while hiring was a huge challenge, the hiring process was too long for the team mission delivery time.

• If we had to improve the Key Metric within the same quarter we had to do something else.

Then it was when we followed the approach of:

• Develop internal per product dashboards, even though we would drop them later, with reusable APIs that the new dashboard could call later on.

• We reduce another point of collaboration between teams, because there was already a lot going on, and we didn’t want to add yet another priority into the table.

We delayed the problem of integrating to the new dashboard until later.

When you have 5 high priorities and you have to choose your battles

I remember on those times that we were in constant pressure to deliver a high impact product initiative. I had to decide which battles to fight. I recall this one to be one of those where more collaboration wouldn’t help, or, at least, I couldn’t support it good enough to succeed.

In this scenario, and based on all the information I had back then, duplicating components instead of collaborating seemed a good option.

We duplicated components, with an API first approach, to collaborate later.

The later never came

The new dashboard took way longer than expected due to all the team dependencies, within our tribe, and with other teams.

This was important for CX, but it didn’t have enough business attention and resources for it to succeed.

What happened is that the internal dashboards kind of did the job for the CX team to support the clients, and we didn’t continue with a more unified dashboard (maybe it was later, but not when I was in the company).

At the end, it was a two people team, understaffed, and without the proper support for multiple parties, me included.

Because the business goals were meet, we decided all together that was OK to stop investing in the initiative.

The dashboard

Each team had their own dashboard, but we had some principles after some iterations:

• The information and actions have to be developed with an API first approach.

• The dashboards had to be linked togeter from one and another to help the CX team to have an easy navigation.

• They have to be protected and use SSO from the company to not force the people to log in to each one with different credentials.

Which it turned out to be a mix between Spring Boot templates and Vue components. The goal was to reduce yet another service to be deployed an managed.

Senior dev: I’m so productive with AI, I just pair with it and ship a lot of code

I’m seeing a lot of this content on LinkedIn. At first, it just feels wrong. And after thinking it in depth, it is so wrong.

Imagine a junior on your team hearing seniors say they’re so productive pairing with AI, they can ship a lot of code by themselves now. Not only that, but now we use Claude Code subagents and agent teams, we can automate a lot of work!

I wouldn’t like to be a junior in that team. I would feel so anxious.

“So, if seniors are more productive with AI agents, how can I learn? Will the AI replace my job? Why do seniors prefer to just use Claude over spending time with us? What happens if I’m so slow compared to them? I’ll use Claude Code as seniors do, and open as many PRs as possible to show my impact.”

I cannot imagine what a junior might feel right now. Too late to learn the fundamentals without the “productivity” pressure, too soon to have the new practices well established.

If you’re a junior, please share your experiences in the comments. It will help others become aware of this problem.

And then, us as seniors, we decided to move our attention into AI agents, learn the new thing, and stop doing the necessary pairing to help them grow.

Pairing is Beyond Code

I discovered pair programming early in my career, but it wasn’t until I joined ThoughtWorks in 2017 that I fully understood its potential. Seeing it in practice really helped.

Pairing goes beyond writing quality code. It might feel like the obvious benefit, but it is way more.

This post isn’t about listing all the benefits—they’ve been shared many times—but here’s a short summary:

1. Knowledge sharing & skill development

2. Improved code quality

3. Enhanced problem-solving

4. Increased focus and accountability

5. Better team dynamics

6. Faster onboarding and reduced risk (no single person holding all the knowledge)

7. Mentorship and career growth

8. And more...

Without going in depth into each point, we can see that pairing is about human work: shared understanding, upskilling each other, and oiling the whole team dynamics to achieve high productivity as a team.

We pair in the benefit of the team over the individual. We help junior team members become the seniors of tomorrow. We focus on shared understanding of the business problem, reducing the bus factor, and ensuring more people have the necessary context.

The Problem: Seniors Are Abandoning Juniors

Here’s what’s happening in many teams right now:

1. Seniors discover AI agents and see massive productivity gains

2. Seniors stop pairing with juniors because “it’s slower”

3. Juniors feel pressure to use AI the same way, skipping fundamental learning

4. Juniors ship code they don’t understand, unable to debug or improve it

5. Knowledge gaps widen instead of narrowing

This isn’t theoretical. We’re already seeing juniors who can prompt AI well but can’t reason about code structure, debug issues, or make architectural decisions.

Rethinking Pairing in the Age of AI Agents

Pairing doesn’t mean we need to go back to writing all the code ourselves. It means delivering impactful work while learning the new practices that are just emerging.

We’re seeing this trend: developers need to focus on product impact, moving from low-level code to business impact decisions. From developer to product developer.

Something we expected from senior developers, not so much for juniors a few years back. Now that’s becoming the expectation.

As seniors, we had years to learn the fundamentals, then learn about the business. Today’s juniors no longer have this time. We’re asking them to go from 0 to impact.

So how can we help them reason better about product decisions, and how to make better judgments on AI outputs that sound confident—often with solutions better than their own on the first try?

Practical Guidelines for Senior-Juniour Pairing in the AI Era

Here are concrete things we can do while pairing with colleagues (and alone in some cases):

1. Reason Before the Prompt

AI agents can drive your thinking process. They put their ideas forward, and then it’s hard to move away from those. They poison your thinking.

Example: You want to add a discount calculation. Instead of asking AI immediately, first write down: “We need to calculate a 10% discount for loyal customers on orders over $50. This applies to the cart total before shipping.”

Then:

1. Write down/explain to your colleague the intention of the change, at product level

2. Find the key areas to introduce the change—navigate the code to find what needs to change

3. Debate first how the solution looks like, its pros and cons

My suggestion: spend time doing it manually until the person gains proficiency on reasoning about the business and navigating the code. Regardless if it’s adding a feature, an architectural change, or tests.

Remember that smaller steps always help. Sometimes we think seniors do bigger iterations, but when we do, we fool ourselves, mess everything up, and go back to smaller iterations.

In case of doubt, reduce the scope. Yet, make the iteration vertical sliced—see a product improvement, don’t focus on the architectural layer.

Concrete tip: Draw an architectural diagram (C4 model) of what’s being considered. This helps you and your junior colleague point to which areas need change.

2. Add at Least Some E2E Test for the Happy Path

You cannot trust AI output without proper testing. And asking the AI itself to add the test might fail on business expectations.

Example: If you’re building a checkout flow, write a Playwright test that adds an item to cart, applies a coupon code, and verifies the total is correct. Don’t let AI write this alone—you define what “correct” means.

Do an outside-in approach and add an e2e test. It can be UI-level with Playwright, or an API call if the change is only backend.

Whatever suits you, that test will be your guide in the session. While implementation might change, a good test suite prevents a green pipeline and broken production.

Concrete tip: Dedicate time to write tests manually, or with AI support, but you ensure the setup and assertions make sense from a business perspective.

3. Compare Your Plan with the AI Agent Plan

Set the AI agent in plan mode. This is essential to dedicate time understanding the differences between your plan and AI’s plan.

Once you have the first step done, ask the AI agent to do the work in two different ways:

1. Guided mode: Give your change plan, the implementation details, and let AI implement it. Verify it solves the business problem, store in a git branch.

2. Open mode: Give only the change intention, at product level, and let AI figure it out.

This is interesting because it gives you two perspectives and outputs.

Concrete example:

• Branch feat/tax-calc-guided-mode: You explain “calculate 5% tax for EU customers on cart subtotal”

• Branch feat/tax-calc-open-mode: You say “add tax calculation for European customers”

Compare what each approach produces.

4. Compare Multiple Models

Decide which plan is best to solve the product problem and maintain good code quality.

You will see how each aims to solve the problem and the steps. But do not trust the first output—try multiple models and see how each reaches different solutions.

Store each result in different branches:

• feat/tax-calc-guided-mode (your plan)

• feat/tax-calc-claude-opus-4-6

• feat/tax-calc-openai-codex-5-3

Debate the different outputs and which ones are better. Ask:

• Did the model solve the right business problem?

• Did it add technical debt? Code duplication? Is it reusing existing patterns or introducing new ones?

• Are the tests good enough or are they superficial?

Pro tip: This is also excellent for mentoring—walk through the differences with your junior and explain why one approach might be better than another.

5. Do Code Reviews Together

Don’t just review PRs asynchronously. Schedule time to review together:

• Walk through what AI generated

• Identify areas needing refactoring

• Discuss trade-offs made

• Explain architectural decisions

This is where juniors learn to evaluate code quality.

6. Explicitly Teach Prompting as a Skill

Treat prompting like any other technical skill:

• What makes a good prompt vs a bad one?

• How to iterate on prompts based on output?

• When to give more context vs less?

Model this behavior yourself.

What This Means for Team Leads and Tech Leads

If you’re responsible for team health, consider:

1. Don’t celebrate AI productivity in public channels if it makes juniors feel inadequate

2. Create space for juniors to learn fundamentals without “impact” pressure

3. Pair seniors with juniors specifically on AI-assisted work

4. Measure what matters: Are juniors growing? Understanding code? Making good decisions?

Conclusion

The phrase “pairing with AI” misses the point. You’re not pairing—you’re delegating. And when you delegate without mentoring, you create a generation of developers who can prompt but can’t think.

The real opportunity is using AI to amplify human connection, not replace it. Use AI to handle the mechanical parts so you have more time for the human parts: mentoring, reasoning, deciding together.

The best developers in 2026 won’t be the ones who prompt best—they’ll be the ones who still know how to think, and who can teach others to do the same.

If you’re a junior experiencing this, please share your story. It helps the industry understand what’s really happening.

All strategies have a lifecycle, and they cannot last forever because context is in continuous change. Yet, some strategies are designed outdated.

I’m currently thinking and researching about the strategy lifecycle, and how the adoption speed by the organization influences the design of it.

Strategy lifecycle stages

• Genesis of the strategy

Strategies start emerging within the organizations in very different ways. Some are because there is a new quarter and that’s the company’s moment to sit down and “design” a strategy. Others appear when people feel lost and lacking direction, asking for a clear direction.

Regardless of the origin, there’s an event that sparks the need of a strategy, formal or informal one. See Strategy types here.

• Strategy designed/written/approved

I consider that strategies have different formats, some are written, others are drawn, and others use a format that’s useful for the people for that company.

Regardless of the format, there’s a moment when the strategy is considered mature enough, “approved”, and communicated to the rest of the organization.

My approach here is to be collaborative, to increase adoption, super important to reduce the time for the next step. You can see some of the ideas here.

Yet, on many organizations, this is done in isolation, and then communicated to the rest of the organization. We will see some of the consequences of this approach, and how to adopt other styles.

• Strategy “fully” adopted

“Fully” adopted here means enough people understand the strategy, and they are able to make day to day decisions to be closer to overcome the high stake business challenge.

Enough here will depend on the strategy itself, the company structure, and the context you’re in.

In some cases, I found that if 2 people within the key teams are able to push forward the strategy is enough. Other times, you need way bigger adoption.

But here, the more teams are involved, the more structure you have, and different layers of reporting, that influences the adoption speed.

During this phase, you focus on the actual strategy execution and how you check its impact, evaluating the expected outcomes vs the reality. This helps you to know how good are you doing.

• Strategy outdated

At some point, the context or the purpose will change. You will learn, and the diagnosis and direction are no longer relevant for the high stake business challenge. You will either evolve it, or just replace it with something that addresses what’s more important right now.

The stages are non-linear

This is the biggest mindset shift I had when thinking about strategy.

If you think of strategy as a plan, a linear plan, that strategy is doomed (if we can call it even a strategy).

Strategy is in the complex and complicated domains, therefore linearity won’t apply here.

Which means that you can switch from phase at any time given the situation at hand.

And those moments vary a lot.

There are no single reasons of why you need to go back and iterate your strategy, but it is better to face the reality that it happens. So, you can prepare for it.

Another way to see the non-linearity is that it can be certain scenarios that a strategy doesn’t go through the steps, and just reaches outdated at any point, triggering the cycle again, at any moment in time.

Those events that trigger an iteration are learning opportunities, and those vary a lot, they can be:

• The market condition changed

• The strategy was based on the wrong diagnosis

• Certain people in the organization vetoes the strategy

Strategy adoption

The adoption happens in multiple phases.

• Awareness: “I heard about the new strategy.”

• Understanding: “I know what it means for the company.”

• Buy-in: “I believe this is the right direction.”

• Commitment: “I am changing my daily work to support it.”

• Advocacy: “I actively promote this strategy to others.”

We tend to assume that leadership and management would be strategy advocates, but that’s so far from the reality.

And not everything happens simultaneously, strategy advocacy takes time, effort, patience, and commitment.

On the other hand, each phase requires a minimum of adoption for a strategy to succeed.

One could assume that the adoption curve is based on the common view of “cascading-effect”. The strategy starts on the C-level/board, and cascades down to business units, departments, teams, individuals.

Even though that’s could be common in some organizations, that’s not the only approach for a strategy. As I explain in my post Engineering Strategy is a Fractal, those strategies can happen in multiple levels.

So, those adoption curves, and the people need for each phase, and how many phases there are, will depend on the purpose, scope, and context of each strategy at hand.

That’s why you might have adoption curves between phases.

In order for the strategy to be fully adopted within the company, first we need the “buy in” and set the foundation with these teams.

Understand the phases and people involved

Here is a proposal that you can extend/adapt

Genesis adoption: People near to the high stake business challenge.

Usually very small groups, enough to start momentum to create the problem awareness.

In my case, it is usually 3-5 people that I start exchanging ideas in a very informal way. Mainly:

Does this problem exist? Do you see what I’m seeing? Is this the right problem to address to achieve our business goals?

Here I am to find the people with influence that can champion the strategy in the spaces that I cannot be.

This group sets the initial purpose and context. Determine if it is enough important, and what needs to be addressed. The problem space.

This people also identifies the right people that will help them to have the right conversation.

Strategy designed/approved adoption. Ad hoc teams of up to 10-15 people

Making sure that the strategy gets the right adoption happens before the strategy is approved. The strategy isn’t decided by the 3-5 people, but with a group of the key people with enough influence and authority to make this happen.

In my case, I think about this group about up to 10-15 people. Not more, since I might facilitate some workshops to:

- Verify the problem space.
- Define the direction.

Here, I suggest creating an ad hoc team with the right people on the possible areas that the strategy will land.

Sometimes we think about those people like only tech, or product-tech, but we need to think beyond that. Most of the successful strategies I had I involved People Partners, and Head of Ops to be sure we gain the early support on key departments that we would need their support.

You can learn more about how to set up the right ad hoc team in this post

The good thing is that these people could also create mini-workshop with their teams to start gaining insights, and start involving people before the strategy is decided.

Sometimes we have to trade the speed to strategy approved/designed in favor of a faster strategy adoption and execution.

Strategy full adopted: Involving the rest of the teams

In order to reach this phase, leveraging the ad hoc team or structure you decided, the key people understood the strategy before it got approved, and after approval, it wasn’t a surprise but a strategy with a vision that included their input.

Here, you don’t need all the organization to follow the strategy, but enough teams/structure to overcome the high stakes business challenge.

I have been involved in strategies that required + 6 teams to be in completely sync, and strategies that required 1 platform team to be very supported to make a vendor switch.

You need to adapt to your case.

Strategy outdated: Now, it is part of the culture

When a strategy succeeds, it becomes part of the culture. Now, everyone does that because it worked.

The new people that joins the company, that’s their reality, they don’t know the past. You created momentum.

But you also created inertia to change, because it worked.

So, the worst thing that could happen is that you achieved your goals, but with the wrong methods.

Because then, those wrong methods could become the culture.

Which ones? For example, asking people to work extra hours. Now, if you face a challenge, the company culture will be put extra hours.

Yes, you need to overcome your high stakes business challenge, but be careful of not compromising the future. Sure, if there’s no future, go for it. Yet, think that there are approaches that aren’t sustainable in the long term.

On the next post I will continue on this same topic going deeper on some areas of:

• How lead times between phases affects each other?

• What happens with multiple strategies happening in parallel?

• How the system aims to protect itself? What happens if the power structures resists the strategy?

Reply to the post with some questions you have from this post, and I will address them on the next!

The AI agents have been biasing, or even driving, my thinking a lot from the last months.

Recently, I was doing system exploration, root cause analysis, and understanding why the system behaved in a certain way using Claude Code.

The whole process felt wrong. It made me anxious.

Claude was aiming to jump into fixing mode, touching everything, adding console.log() everywhere. That same feeling when I started my career, and I had no clue what I was doing, but I had to act fast, try a lot of things, to show that I was doing my best effort.

As I progressed in my career, I learned to be calm, and approach the solution with patience, and in a systematic approach.

Claude Code made me go back to the anxious times. Jumping from file to file, changing things, trying things out, without stopping to understand the whole, without a method.

Indeed, I felt I was one prompt away of making Claude Code to fix the problem, but it wasn’t happening.

At that moment I closed my IDE, my laptop, and when to the office cafeteria with my notebook and a pencil.

So, I recreated the problem using visuals.

I’m a visual person, because I have a little of dyslexia, and reading is an effort to be sure I read the thing correctly. Claude Code wasn’t helping me there with all the words after each 20 words prompt.

I dedicated 20 min to understand the whole thing, by drawing it myself, I was able to see the problem on another angle, a systems angle.

10 minutes later, I went back to the code, and found the bug. It wasn’t in the code per se, but how the systems interact that we assumed certain things from the infrastructure.

That kind of error that only happens in prod, because in local and staging everything looks fine.

I enjoyed that process.

Stopping, using my problem-solving skills, and fix the issue that took me the whole morning.

Slowing down, the process of writing and drawing helped my brain to take the necessary time to think and understand the problem. Not to tell Claude to do 1, 2, or 3.

Tools matter. Tools are designed to influence how you behave.

Change the tool if it is not helping you.

You don’t need to adapt yourself to the tool if it isn’t helping you to achieve your outcome.

Strategy cannot be split into “decision” and “execution”. As leaders make decisions, and teams executes the plan.

Strategy is both. If you split them, you break the fast feedback loop.

At the same, who owns the execution can lead into misunderstandings like that the leader is the one executing, which leads into micromanagement, and unempowered teams.

That’s something we also need be careful, because it also reduces the feedback loop. It is better that multiple people think and reflect about the strategy, vs one person alone.

So, how can we make sure the team group of people designs and executes the strategy?

The strategy leverages ad hoc groups/teams

Organizations have strong team definitions. A person belongs to a team and reports to a specific person. Therefore, work needs to fit the organization design.

This limits us.

It makes our strategies to fit the operating model, and fight or surrender the existing structures.

Instead, strategy has to leverage informal team groups based on each context and purpose.

And that ad hoc team can own the design and execution.

This idea/concept is key to increase the odds of the strategy to make the desired impact.

This teams/groups are formed in very different ways. In some organizations, those manifest as Slack channels like #tmp_<inititative>. Each organization has its own definition.

What makes this kind of ad hoc teams quite suitable for strategies is that it has the right people with:

• Business context.

• Decision-making authority, including budget, and organizational influence.

• Team specific context and situation at hand.

• High-speed communication channel.

You optimize for fast feedback loop and decision-making.

Leveraging coherent actions

I always suggest people to have 2-3 coherent actions prepared for any strategy. For the next reasons:

• Not all the teams have the maturity to understand a strategy and be ready to translate that to time scoped coherent actions.

• Not starting soon enough to work on the strategy loses momentum, and people go back to work as usual.

• Longer feedback loop to understand if the strategy is helping us to overcome the high-stakes business challenge.

BUT, I wouldn’t make all the coherent actions be decided by the ad hoc strategy team. Because you want teams to start owning and showing strategic thinking and execution.

I suggest you to find that people in your team that:

• Start gaining ownership on the coherent actions, and start suggesting next steps that are coherent by themselves.

• They are able to spot important areas, and proactively communicate and solve by themselves, always aligned with the strategy.

Your goal is to identify the future leaders that can make strategy happen. You want to know how much guidance the team need, and purposely delegate more and more to the right people.

They will communicate early, and this will help you to achieve the right fast feedback loop your strategy needs.

And by being part of the design phase, they will be able to understand how that informs the strategy, and that feedback helps the whole organization to make faster informed decisions.

And by doing that, they will learn more about the whole process, giving them more context, better decision-making, and autonomy along the way.

After repeating this loop multiple times, you have trained a great professionals on strategy within the company.

Next time you need to overcome a high-stake business challenge, the key people would be already trained on the matter.

This sentence carriers at a lot of assumptions, beliefs, and responsibilities:

• You can plan in advance

• Product/project can define better specs

• Tech can estimate the time to deliver

The space I found this sentence the most is during retrospectives, when we expect something to take less than it is taking/took. Usually, we ask during the retro:

• What happened?

• What could have done differently?

And most of the time we tried to plan better, we made things worse. Because the more dangerous belief is that you can know in advance.

After walking the walk, we know a lot more. What helped us to gain the knowledge was the movement, the execution based on imperfect information.

Walking the walk, we reduce risk, we iterate fast, and we often communicate our learnings with the rest of the team, and organization.

Yes, that will imply rework, frustration, and feeling of waste.

Yet, that was what was needed to gain knowledge and move forward. That had value on itself.

What to do instead?

Identify if we are moving the responsibility to product

We all want to make our job better, and asking for better requirements is an easy ask.

“If I knew this in advance, this wouldn’t take this long.” - Every dev at some point in their career.

Instead, aim how you can collaborate with product to reduce the unknowns and gain rapid knowledge. Instead of full functional implementations, aim for short experiments.

Move from Factory Dev into Product Dev.

Identify if we could fall into the analysis-paralysis trap

We love certainty. We all do. Yet, that’s not reasonable. And with AI, this illusion is even harder to spot.

We cannot know everything in advance, nor it is useful. Some sort of upfront is reasonable, aiming to have a full plan from backlog to prod not useful.

Instead of assuming that more upfront planning would help, ask which areas would have worked better, and which areas wouldn’t be identified regardless of how much planning made.

Make those scenarios explicit, identify the things that took the most to learn, and the cause of learning it late.

Then you can ask yourself and the team “what can we do to expedite learning on these areas?”

Maybe the solution isn’t more research, but microtools to learn faster as you develop.

At this point, I want to introduce you the concept of Moldable Development.

If you are interesting on a new way to understand software, I would recommend you to take a look at it. I will write about my experience about it in the future.

What would you do instead?

Reply in the post on how did you approach this situation, I’m sure we all faced it at some point, but super interested to know how did you overcome the situation.

When I ask technical leaders about its strategy, it usually has two traits:

1. It’s only tech.

2. It’s about what they can control, or think they can control.

These two traits apply to CTOs to middle engineering management, and how those two traits apply will differ depending on the role on how they look like.

Engineering Strategy beyond Tech

Overcoming a high stakes business challenge from an engineering point of view can require all sorts of small actions in multiple dimensions, thinking only about the architecture, frameworks, Cloud, AI, and alike is limiting our area of impact.

Yes, those areas are essential to our work, but we need to think beyond those.

Maybe, in order to overcome the challenge, we need to think in terms of:

• Organizational structure

• Hiring processes

• Collaboration with Product and Design

• How legal is involved on the delivery

Etc.

When organizations reach a certain engineering maturity, the improvements will be beyond tech as a silo, but tech as a collaborator with all the other departments.

It is strange that we can work in isolation on the high stake business challenge, but we need to find what’s the best approach with the other disciplines in the company.

And sometimes, the best way to address something is to know when the solution isn’t tech related. That’s also a good outcome.

Engineering Strategy beyond what you can control

One might want to design a strategy within the constraints she or he might have.

• This is the product roadmap, I will design an engineering strategy dedicating the 20% of eng capacity.

• I have a team with only one backend, we will adapt to this constraint and make everything frontend because that’s how we can accomplish the roadmap. So, let’s make an architecture that takes this into account.

And most of us work within constrains that we cannot change, but we can influence our leadership to take into account what would be possible if we loosen the constraints.

We can start using the engineering strategy as an influencing mechanism to highlight what do we have now, what we aim to achieve, and what would be possible if we loosen or entirely remove certain constraints.

What for you is a constraint, for your leadership might not be.

You can start looking for areas that will better futures but improving today’s context.

This is called Ideal Present by Jabe Bloom.

So, when designing your engineering strategy, ask yourself:

• What would I do if you were in your manager’s position?

• If this constrain wouldn’t exist, how the strategy would change?

• What’s needed to remove that constrain?

You will find that most of those answers require collaboration and influencing, and that’s a crucial work from any strategist.

And I couldn’t help myself after feeling so frustrated by how she explained the recipe to me. It frustrated me in a familiar way…

Is my grandma the ultimate stakeholder!?

• Aleix: Hi grandma! Could you tell me how to prepare X dish?

• Grandma: Sure! Take a notes!

• Aleix: Ready when you’re!

• Grandma: Boil the water 💧

• Aleix: Sure! ✅

• Grandma: Add the potatos 🥔

• Aleix: How many?

• Grandma: A few

• Aleix: Like 2?

• Grandma: Yes, but depends on how many people. Pick some that are not too big not too small.

• Aleix: Okey…

• Grandma: Put them to the water and wait until they are done. 🍲

• Aleix: How many minutes? ⌛

• Grandma: When they are ready, you will know.

• Aleix: OK, let’s continue.

• Grandma: Add the carrots. 🥕

• Aleix: Sure! What’s next?

• Grandma: Put a side the beef, you want to fry it lightly. 🥩

• Aleix: The beef!? When I have to do the beef?

• Grandma: Of course you need to the beef before that! Didn’t I teach you anything? This kid…

And you can imagine the amount of back and forth that we had. Result?

She wants to communicate all the business requirements ingredients and processes. I want to make the dish as she did. And yet, we cannot make it right, regardless how much effort we put into it.

The amount of experience she has is something that cannot be transmitted with a recipe, I have to practice.

And here we had two options.

Pair cooking

Pair with a senior cooking grandma to gain experience while receiving timely feedback that supports my growth in form of yelling, but also enjoying a good time with my grandma.

Not this way! You have to cut the potatoes thinner! That’s how your grandpa liked it.

Agile cooking

I don’t have the support of the Subject-matter expert (grandma), but I can leverage the feedback from early adopters of the MVD (Minimal Viable Dish), my partner and friends, until they churn because of being at risk to be food poisoned.

Focusing on gathering feedback from them, improve the booking process and product, until I master the recipe.

Conclusions

Enjoy the time with your grandma, she will teach you valuable lessons.

One being preparing you to deal with the messiness of the world.

Regardless of how much we try to make sense of the world and have more accurate requirements, there’s no way to transmit all the knowledge and experience without the practice.

Best case scenario, collaborate with the stakeholders and SME to have the shortest feedback loop possible. In case that’s not possible, reach for feedback from early adopters, and mature the product and method!

I hope this post helped you to call your grandma to get that recipe that you enjoyed that much when you were a kid.

We have a lot of marketplaces that have to balance the offer with the supply, while creating an added value for either or both sides to ensure people use the platform.

Here is a list of common marketplaces you might be used:

• Airbnb: Short-and-long-term homestays marketplace

• Fiveer: Freelance marketplace

• Amazon: Third party sellers can use Amazon as a platform to sell their products

• Uber: Drivers provide rides to passengers.

• JustEat: Restaurants deliver food to consumers

• LetGo/Wallapop: List and discover second-hand items near you.

And a lot of them have a common business capability, the chat.

Chat: Business capability facilitate the communication between both users to ensure they don’t leave the platform.

Churn is always a problem when people leave the platform and start a direct relationship, and more when the CAC is higher than the LTV for a single transaction within the platform. When you need recurrence, which it is almost always nowadays.

So, the chat has become a critical capability as the whole product experience to ensure we keep the users within the platform, and not bypass it.

The chat: Core or supportive capability?

The chat capability isn’t a business differentiator anymore.

It lives within the supportive, and still quite tailored to the business domain that using a generic off-the-shelf solution might not be an option.

But the chat capability have a huge rival. WhatsApp.

The constant upgrades on features on WhatsApp, like reactions, reading status, last time read, multimedia messages, stickers, the real time capabilities … All those features that people are used to, you don’t have the scale of Meta to invest on them. But you are expected to move into that direction (Red Queen effect on Wardley Maps).

So, you are in a though spot:

• Should we use an off-the-shelf solution that costs a lot of money that doesn’t adapt enough to our user needs?

• Should we invest into a custom solution, acknowledging that we will have to keep investing as the messaging apps keep evolving?

• Is “not developing a chat” an option? People will bypass our platform anyway.

Wardley Mapping a Chat

Based on how I understand the landscape, visualized using a Wardley Map and a Core Domain Chart, suggests to us that custom-building it isn’t a good strategic decision.

Either relying on existing tools, or adopting an off-the-shelf solution, looks like the right decision to make.

Yet, the devil is in the details.

Any B2C marketplace has million of conversations and messages per month. And based on the current pricing models, it can cost millions per month to outsource this to a third party.

So, we have a business capability that’s cost of doing business, it is not a business differentiator, and we are in macroeconomic that makes it tougher to compete on margins that are shrinking.

It is valid to ask:

AI is accelerating development, we can do more with less, our competition is doing it, shouldn’t we internalize this, and save us the cost of this external tool?

Let’s assume we decide to build-it in house

Building an in-house copy of WhatsApp isn’t viable nor realistic. You won’t have the same requirements as WhatsApp in terms of million of concurrent users, for example.

But there is something that we can use in our advantage when we need to build internally a commodity. It is a well known domain:

• Certainty: Commonly understood (in terms of use)

• Market: Mature market

• Market perception: Ordered / trivial

• User perception: Standard / expected

• Understanding: Believed to be well-defined / stable / measurable

On the other side, those properties make this domain to have higher expectations of usage.

So, in this case we aren’t experimenting, and aiming to reduce the cost of learning. We are developing a well understood domain. So, we need to focus on a methodology like 6-sixma or Lean to develop this business capability.

We can “know” how much it will cost us, and often it is a lot.

How do we build it?

We know the chat capability has specific business needs, but we also have a tech stack, and people skilled with certain tools, and methodologies.

So, how do we develop the chat?

• Using existing tech like Ruby on Rails and Postgres, or we opt for a known technology to work for chat-like systems like Elixir?

• Do we invest in new talent to develop this system? Do we train existing talent, and take advantage of AI? Do we leverage existing tech stack instead?

All decisions are about trade-offs.

And on those decisions, we need to add the domain specific knowledge we have about our users behaviors.

For example, in a B2C about selling second-hand items near you. You can have million of messages per month, but you also know that:

• Conversations aren’t long, and they have a short duration.

• Conversations are co-located. A person in Spain won’t be talking to a person in South Korea to sell a second-hand item.

Understanding this domain specific behaviors, we can shape our custom-build solution more tailored to our needs without reaching the level of WhatsApp for example.

My decision-making path

and how AI influenced how I would run experiments to verify the most viable solution.

1. I would externalize as much as possible. There are a lot of hidden costs on internalizing commodities and products beyond the invoice and the end of the month.

2. In case I need to custom-build it. I would:

   1. Do a deeper research of viability using industry known approach.

   2. In case it is needed and viable to be on specific tech, like Elixir in the chat example, I would experiment with this approach to fully understand the consequences. And I mean also in production.

   3. Otherwise, I would default to current tech stack, and do our best to fulfill customer needs.

      1. This will help us to leverage existing talent and keep the tech stack as homogeneous as possible in case it is important for the company.

Why AI is changing this decision-making process?

Because AI is trained on known data, known products, and everything that’s already present in the web. And generic and supportive subdomains, products and commodities fulfill these criteria.

AI can help us a lot on what’s not a business differentiator but cost of doing business. The LLMs can help us to extract those decisions made in the past that are relevant for our use case.

But this will also have consequences:

• Using LLMs will be about the past, not the present, nor the future. We will also be behind of the rest if we only rely on the LLMs.

• Custom-building has a lot of hidden costs, a lot of them aren’t public, therefore LLMs cannot help us to anticipate those.

• We might end up in a sunk-cost fallacy, where we keep investing instead of decide to go for an off-the-shelf solution.

So, for one side, I consider that LLMs might be opening a space where more big companies will internalize those generic external services to reduce external cost. At the same time, this will start to increase all the hidden work to support those services.

Why internalizing everything isn’t viable

I provided this example for the chat, but you might consider applying the same decision to all third party services. That survey tool, that analytics tool, the CRM, …

And the truth is, those domains are huge, and I don’t consider reasonable to expect that a LLMs will be able to:

1. Understand all the domain specific knowledge required.

2. Support you maintaining the systems.

3. Support you on those edge cases, and industry changes that will force you to keep investing on those systems.

So, why do I consider a chat to be in the messy middle of the decision process to consider custom-building it?

Because, even though, from a capability point of view, I do consider it is a supportive one. In terms of the long term product strategy, you aim to reduce people moving to an external provider, and that’s why, in this case, it can make sense to make it internally, with all the consequences.

You might be investing millions, but you also can reduce the churn and increase the LTV enough that it makes sense. Remember that B2C are economies of scale, and at scale, the numbers can work.

• feat: added email notification on product shipped

• chore: upgraded library version

• fix: JSON parser for DTO

A common value proposition from AI vendors is to delegate the commit message to AI.

It is useful, but generating a commit message doesn’t provide much value.

A good commit needs to help our teammates (and our future selves) to understand what changed and why.

And, a common thing that happens nowadays is that a lot of code is AI generated. I want to understand if the code that’s there has been written by you, which will have a higher chance that you will remember certain decisions you made, or it has been delegated to AI, which means that you might not member all the changes introduced.

What’s missing in the commits is this critical information.

That’s why I started adding some contextual information to my commit messages.

ai-{feat/chore/fix/docs}: <description>

Following the conventionalcommits.org specification, I started adding the suffix `ai-` to my commit messages to indicate that the commit contains code generated by AI.

Providing this context to our future selves will be key to understand how we are changing code.

• ai-feat: added email notification on product shipped

• ai-chore: upgraded library version

• ai-fix: JSON parser for DTO

Losing knowledge with LLMs

If you have been in the industry for a while, you know that knowledge is a headache for any company.

That’s why pair programming, mob programming, technical huddles, Architectural Decision Records, documentation, and so on have been adopted by more and more companies.

Because we learned the cost of losing knowledge.

And with AI, we are losing knowledge and know-how faster than ever. See Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task paper.

If we aren’t pairing as much, and we delegate a lot to LLMs, what can we do to minimize the knowledge lost?

The problem is even worse as you think about it.

LLM providers harvesting business knowledge

Each developer is sending a lot of information to LLM providers. They are able to identify patterns not only cross your company, but cross competitors, and industries.

We are making our LLM providers to sense all the industry for a fraction of what it costs you to learn about it, and they will be able to out innovate us.

The need for self-hosted open models will become more and more obvious.

Each developer deviating about a common shared domain model as the LLMs introduces more local bias

Any person with a DDD background understand the importance of the Ubiquitous Language, and that all the people understand the meaning of each concept.

I’m seeing an increased problematic as we use more LLMs. Because of how many variables there are when we develop.

Imagine how fast we start losing the shared domain model when:

• Using different LLM models: Each model has its own training set, its own definitions, and its own bias.

• Each conversation with the LLM adds more context to the specific memory. But developers don’t share their chat memory between them. Creating bias, and re-work when different developers work on the same parts of the code.

• Because it is easier to talk to an LLM (and we are disincentivizing the collaboration with product, design, and business that took us that long to build the culture of), our shared mental model will become worse and worse over time.

  • Creating more knowledge silos than before.

We need to be careful when leveraging the LLMs because they are trained on what’s known. And innovation isn’t about what’s know, but about unexplored space.

Using DDD terms, LLMs help us a lot on supporting subdomains. The core domains, those that are about the unknown, the hard stuff, why users buy you and not the others, that’s the hard part.

LLMs won’t fix those, but good cross-team collaboration will.

Keeping the AI conversations within the Git history

commit 7457ef3dd201d0702c0f82e6e703b53f87db770e
Author: Aleix Morgadas <hello@aleixmorgadas.dev>
Date:   Thu Aug 7 13:32:42 2025 +0200
ai-feat: <description>

# Prompt
<Prompt that triggered the change>

# Outcome
<Copilot, Agent, whatever chat that caused the changes>

# Meta
model: sonnet-4
mcp:

I started adding all the information produced by AI as part of the Git History as a countermeasure to losing knowledge in the mid to long term.

That’s the only countermeasure I found that can help us to not lose all the knowledge it took us that long to gain.

I just copy the prompt and the outcome of the AI chat that explains the changes, and which model/MCPs have been used.

Here is an example with Cline Code Extension.

This way, by the time we start adding the right capabilities, we store as much of the information within our Git History. So that, by the time we want to start experimenting with all this information, and business knowledge, we have the data already in our systems.

Interesting that we started collecting all data from customers that we didn’t need as a company during the “Big data” hype, and we kind of forget some of those learnings.

Some examples would be:

• Learning from each other’s prompts.

• Knowing the decisions made with the AI and the developer that lead into the changes.

I signed with Rover.com to join the M&A Integrations team as Staff Eng 👏

I’m super happy to join a company that we are users at home, and see the other part of the product.

LATEST NEWS! 🚀 After some months of consideration, I’m ready to start for my next professional challenge, as FTE for a product company. Hybrid at Barcelona or Full remote.

You want to know why now, see How did I get here?

How can I help companies?

I adapt a lot to the company challenge at hand. I don’t consider one-size-fits all solution or silver bullets exist. That’s why I focus on deeply understanding the company context and business, the product, the users, and their needs, and how everything fits together.

This mindset let me into driving initiatives such as:

• Execute a strategy that has been blocked for a long while, and you feel that the teams don’t understand the big picture.

• Incremental architectural modernizations.

• Understand the team bottlenecks, and drive improvement initiatives, that required:

  • Technical migrations

  • Upskilling team members

  • Coordinating multiple releases with multiple teams without downtime

• Understand legacy systems that were causing production incidents, and stabilize those systems to keep adding value to our customers.

• Set good and best practices to improve the engineering maturity, with good CI/CD pipelines, adopting key XP practices, setup good testing based, and good observability tooling.

For which position?

I’m looking for a Staff+ Engineer position.

I’m a strong contributor to the company strategy and making it happen with a hands-on approach. I have been leading cross-team initiatives, some with direct authority, but most required influencing key stakeholders, and teams to move the initiative forward.

That’s why I consider that working as Staff+ Engineer I can contribute to the product development, improve the system’s architecture, and mentor other engineers along the process.

Which domains/industries I have experience with?

I had the opportunity to work on multiple domains, industry, and business models. Here is a list of the ones I feel more comfortable with:

• Fintech that implies regulation (Creditas)

• Dev productivity products (Teamperature)

• Dev tooling (Testcontainers)

• Two-sided marketplaces (Under NDA)

• E-commerce (Otto)

Contact Info

If you think I can help you, or you know of a place I can fit, please, reach out with the following information, or just reply to this post 🙏

• My LinkedIn: https://www.linkedin.com/in/aleixmorgadas/

• Email me to: hello@aleixmorgadas.dev

• Schedule a 30-min call with me: https://cal.com/aleixmorgadas/30min

• You can see my CV here.

How did I get here?

For the last two years, I have been pushing my mission forward:

And I did it in two different ways; building a product and offering my training services. The latter is working better than the former so far.

Started with EnablingFlow and later joined Teamperature

The mission of Teamperature aligned so well with my personal purpose. So, I decided to join Teamperature with Manuel, co-author of Team Topologies.

I had been part of the Team Topologies community for a while, and the problem we were solving as a product as something I did as a Head of Engineering.

It was the perfect match, but the market isn’t there yet.

The developer productivity market is tough, and we were pushed into offering services on top of the product. I can explain more about this in another post.

Engineering Strategy Academy

For the last 2 years, I have been coaching Staff+ Engineers and Engineering Managers. It has been an amazing experience.

I had a constant flow of people asking how to level up their skills, and have bigger impact in their organizations. Stuff from driving huge architectural migrations, while getting the buy-in from the C-level, to changing full B2C onboarding flows to enable fast experiments.

At some point, I decided to start doing group training to help those people that cannot afford personal coaching, while having a great practical experience.

From that need I started engineeringstrategy.academy, and I’m enjoying it a lot. It feels so rewarding to see people improving their strategic thinking within weeks, for something that people might take months to years.

I just realized this is something I’m enjoying doing but it doesn’t require a full-time dedication. I’m running the coaching sessions and trainings as an afternoon initiative.

I’m missing working with more people

I have been helping people on driving high-stake business challenges. And while doing it, I felt that I was missing that part of cross-team collaboration, cross-team influencing to drive an initiative, coaching people, and see their growth while working together.

One of the best experiences I had was at Creditas, working with talented people, building a great product, while improving our product-engineering culture. It was amazing to see the whole progress when you look back.

It implied:

• Collaborating with business, product, design, customer success.

• Collaborating on the design and execution of an engineering strategy.

• Training people on advance topics such as DDD, Team Topologies, Event-Driven Architectures, and Evolutionary Architecture.

• Critical projects hands-on when needed to:

  • Train people on specific practices, methodologies, or architectures.

  • Deliver key system components

And after feeling and thinking it for a while, I realized that being part of something bigger fulfills my personal mission while enjoying the energy that gives me being part of a higher mission.

I’m happy to share my talk at CraftConf 2025 where I shared my journey as an engineering strategist while focusing on the Engineering Strategy Foundations.

I hope you enjoy the talk! 🙌

Hi, I’m Eugene, Director of Engineering at Flo Health. Today, I want to share how we evolved our onboarding experience from a rigid, release-bound flow into a dynamic, server-driven platform that now powers rapid experimentation across mobile and web. This is a story about breaking Conway’s Law, building internal platforms with product thinking, and enabling teams to move fast—without breaking things.

Introducing the company

Before diving deep into details, I want to give you an overview of Flo’s domain, scale, and challenges. This information can help you understand why our onboarding is so complex and diverse.

Flo is a super app with various user segments: cycle tracking, getting pregnant, pregnancy tracking, sex life, socializing in secret chats, and many more. Moreover, we recently launched a Flo for Partners feature with 1+ million MAU in 2024, meaning we are no longer only a female health app.

What was the high-stakes problem?

At Flo, onboarding isn't just a product feature - it’s a critical growth lever. As a product-led growth (PLG) company, our ability to convert new users into active, engaged members within their first few minutes in the app directly influences our retention, revenue, and impact.

Initially, we approached onboarding as a set of hardcoded screens - a simple solution that sufficed for a time. But as our ambitions grew, so did the complexity of our onboarding journeys and the urgency to iterate on them quickly. To scale experimentation, we introduced a domain-specific language (DSL) that allowed onboarding flows to be described more flexibly. However, this DSL was still embedded in the app codebase, locking every onboarding change to the mobile release cycle.

This created a high-stakes bottleneck.

• Every experiment or fix was gated by a mobile release, making it impossible to react in real time to user behavior or localization issues.

• Errors took days to detect and fix, delaying learnings and negatively impacting conversion metrics.

• The complex onboarding created a cognitive and operational burden on engineers, PMs, and QA to maintain.

• Mobile engineers were disengaged, spending time updating massive DSL configs instead of solving high-impact user problems.

In short, the very process designed to accelerate onboarding innovation became the blocker. And in a PLG company, slow onboarding iteration is not just a developer inconvenience - it’s a growth risk.

Engineering Strategy

As a business it was critical for Flo to grow onboarding revenue and incite higher engagement from our users. So to address the growing complexity, slow iteration cycles, and developer pain points in our onboarding system, we defined a strategy focused on decoupling onboarding logic from mobile releases and empowering product teams to move faster. Inspired by existing server-driven UI patterns used in multiple parts of the app, we began migrating onboarding flows to a server-driven model. This shift enables real-time updates, safer experimentation, and faster hypothesis validation - without waiting for a mobile release. As a second step, we introduced a visual editor, allowing non-technical stakeholders to create, manage, and test onboarding flows autonomously, further reducing engineering overhead and accelerating iteration.

Analysis

What Works Well in the Flow

1. Established DSL & Contracts
   We already have a robust domain-specific language and clear contracts for rendering key onboarding screens, providing a solid foundation for further abstraction.

2. Backend-driven UI
   Our Backend-Driven UI system is mature enough to describe screen layouts and deliver UI configs via the server, reducing the need for mobile releases.

3. Cross-Platform Consistency
   The DSL allows us to maintain consistent onboarding logic across iOS, Android, Web, reducing platform-specific divergence.

4. Experimentation Culture is Strong
   The product team is hungry for faster iteration and has a clear sense of the right hypotheses to test - demand for rapid change is high and well-structured.

What Blocks the Current Flow

1. Slow Mobile Release Cadence
   Mobile releases are on a two-week cycle, delaying onboarding experiments, fixes, and urgent updates (e.g., localization or attribution errors).

2. Error Feedback Loop is Too Long
   It often takes more than 24 hours to detect misconfigurations in experiments due to non-real-time analytics and delayed rollout visibility.

3. Engineering Time Spent on Config Work
   Mobile engineers are blocked doing low-leverage work like editing large onboarding JSON configs, which reduces team engagement and velocity.

4. Mobile-Only Team Structure (Conway’s Law)
   A team composed entirely of mobile engineers naturally gravitates toward mobile-driven solutions, limiting exploration of server-driven or cross-platform strategies.

5. Lack of Visual Flow Management
   Product managers and QA rely on Miro boards and ad hoc tools to track flow logic. There’s no unified source of truth or editor to visualize and modify onboarding journeys safely.

Direction

Things We Want to Do

1. Apply the Conway Maneuver: Add Backend Engineers
   To break out of mobile-centric thinking and enable backend-driven solutions, we expanded the team to include backend engineers. This shift allowed us to rethink onboarding as a distributed, server-powered capability—not just a mobile UI flow—and enabled quick validation of this new architectural approach.

2. Use Download-at-Once Strategy for Config Delivery
   Following the Lean methodology, we selected the simplest and fastest approach: downloading the entire onboarding JSON (up to 300KB gzipped) at app start. In the first iteration, our backend service was a lightweight wrapper serving configs directly from Git. As a fallback, we include an embedded version of the main onboarding flow (without experiments) in the app bundle during each mobile release. This setup balances speed, reliability, and offline coverage.

3. Launch via Controlled Experiments
   We introduced server-driven onboarding behind a feature flag, starting with Android EN users and gradually expanding exposure (5% → 100%). We defined success not as improvement but as no statistically significant negative change across key business and technical metrics—signaling a safe infrastructure shift.

4. Enable Safe, Validated Server Releases
   Our backend performs structural validation of onboarding flows before serving them to clients. It checks for graph consistency, unreachable nodes, duplicate transitions, and cycles. Invalid configurations are blocked from release, ensuring high confidence in every server-side deployment.

Things We Discarded or Don’t Want to Do

1. Introduce a New Team Prematurely
   We intentionally avoided creating a new team or scaling the org structure before validating the value of server-driven onboarding. Instead, we applied a lean approach—testing the hypothesis with minimal changes and leveraging existing team members to deliver the proof of concept.

2. Build a Visual UI or Complex Backend Logic Early
   For the initial phase, we decided against building a visual editor or adding complex backend authoring tools. It was acceptable that all onboarding configurations would be written by engineers using the existing DSL. This kept the scope tight and allowed us to move quickly while focusing on validating the core approach

Coherent Actions

After the successful proof of concept, it became clear that backend-driven onboarding was technically feasible and brought tangible business benefits—faster iteration cycles, more robust experimentation, and reduced engineering overhead on repetitive tasks.

Rather than treating onboarding as a standalone system, we chose to take a deeper, more strategic step: we established the Survey Engine as a dedicated platform team. Onboarding became just one of many internal customers of this platform. This shift allowed us to generalize the infrastructure and scale its impact across multiple user-facing surfaces like in-app quizzes, polls, and dynamic content.

Key coherent actions we took:

• Established Survey Engine as a Platform Team
  The team’s mission expanded beyond onboarding. It now owns core capabilities such as configuration delivery, runtime rendering contracts, and safe rollout mechanisms- serving multiple product teams across the org.

• Provided Visual Tooling for Configuration Management
  The team built internal tools enabling product managers and content teams to visually create and manage onboarding flows, significantly reducing the need for engineering involvement in day-to-day experiments.

• Integrated Existing Capabilities into a Unified System

  • CMS Integration: Enabled safe release and publishing of onboarding content.

  • Experiment Service Integration: Allowed dynamic branching and targeted delivery of flows through experimentation.

  • Localization via translation management system (TMS): Made all experiments fully translatable from Day 1, eliminating a common delay in onboarding launches.

• Introduced a New Role: Content Operations
  To streamline the workflow, we introduced a Content Operations role. This person acts as a bridge between product, design, and analytics - taking ownership of flow configuration, copy updates, and experiment setup.

• Redefined the Role of Engineers
  Engineers are now focused solely on developing new capabilities (e.g., new component types, data logic, validation rules), not maintaining onboarding flows. This shift both reduced cognitive load and increased engineering team engagement.

Together, these actions established onboarding as a high-leverage, product-led capability- no longer a bottleneck, but a dynamic and adaptable system aligned with Flo’s experimentation culture.

Outcomes, Learnings & Next Steps

The migration to the Survey Engine platform delivered clear, measurable impact:

• Significant Uplift in ARPU and Subscription Conversion
  The shift to rapid, low-cost experimentation drove substantial business impact: average revenue per user (ARPU) increased by 13.5%, and the conversion rate to subscription during onboarding rose by 20%. These are critical metrics for PLG companies, highlighting the direct connection between experimentation velocity and monetization outcomes.

• Experiment Velocity Increased by 170%
  After moving onboarding to Survey Engine, we now launch an average of ~30 experiments per month. This made onboarding one of the most iterative and data-informed parts of the user journey.

• 87% of Experiments Launch Without Engineering Involvement
  By enabling visual tooling and empowering product teams, 87% of onboarding experiments are now launched without engineers, dramatically reducing the cost of iteration and freeing up engineering focus for core platform work.

• Cultural Shift in Product Thinking
  Product managers increasingly validate hypotheses directly with real users rather than relying solely on upfront user research. While user research remains valuable, the lower cost of experimentation has shifted the balance toward more hands-on testing in real contexts.

• Survey Engine Gained Broad Adoption Across the Org
  Thinking globally from the start—and building a platform rather than an onboarding-specific solution—allowed us to onboard ~20 internal customers. Several teams have decommissioned legacy tools or stopped using third-party vendors, consolidating efforts around a shared, robust infrastructure.

• Unified Web and Mobile Onboarding Experience
  Completing the migration of web onboarding to Survey Engine enabled the merger of mobile and web onboarding teams. Product managers now focus not on individual platforms but on delivering a cohesive, cross-platform user journey.

Next Steps

• Integrate AI as a Copilot for Content Creation
  To further accelerate time from idea to release, we are embedding AI capabilities into Survey Engine as a creative and operational copilot. This includes assisting with content generation, validation, and layout suggestions—especially important in sensitive domains where medical and legal credibility are paramount.

• Speed Up Experiment Delivery with AI-Powered Workflows
  We’ve already seen early success: in a recent use case, researchers fully created and launched a survey using just a PRD and prompt within Survey Engine—no engineer and designers' involvement required. This demonstrated the potential for AI to radically simplify and speed up the path from concept to live experiment.

• Content Safe and Credible Automation
  As AI takes on more of the content lifecycle, we’ll implement guardrails for automated validation—checking for medical accuracy, localization quality, and compliance with internal and external standards.

Further Reading & Technical Deep Dives

This post focused on the strategic and organizational aspects of our onboarding evolution at Flo Health. For readers interested in the technical implementation details, architectural decisions, and deeper engineering insights, we've published a comprehensive series that covers the full journey:

• Mobile Onboarding Evolution - Part 1: The Technical Foundation Dive deep into the technical architecture that enabled our server-driven onboarding platform.

• Mobile Onboarding Evolution - Part 2: Migration & Scaling Explore the practical challenges of migrating from client-side to server-driven flows at scale.

- X: I’m leading an infrastructure team, and we have the vision of becoming a platform engineering team, but I see multiple challenges. Our engineers do not know our developers pain, our leadership doesn’t support us, and I don’t see it happening. What do you recommend?

- Aleix: Do you use Jira for internal tickets to support teams?

- X: Yes.

- Aleix: They you already have a good starting point for your internal customers needs, AKA developers. Get the top 3 more repeated tickets, and automate that.

- X: But how we do get the buy-in from the leadership to do so?

- Aleix: That’s the neat part, you don’t. You don’t ask for permission, you just do your job taking into account the business needs, the amount of risk you can take, and be ready to ask for forgiveness.

- X: And how do I do for all the developers team to use the platform if I cannot communicate with them?

- Aleix: You also don’t do that. Before starting any platform initiative, you:

1. Identify the top 3 more repeated use cases, they are probably the ones blocking flow the most.

2. You let some people know that you want to to start automating some tickets as self-served, do not mention platform yet

3. Tell them that you’re looking for 2-3 teams to try it out. They will be the early adopters, the ones that will deal with all the bad stuff before the platform has as good user experience.

4. Involve them on the platform definition, make your infrastructure team be part of the conversation. Help them understand the user pains to build the thinest viable platform first with a good DevEx, and extend it later.

5. Release small, gain early adopters, they will be the ones sharing this with other people.

6. Before you realize, you have the first functional internal platform solving the top 3 developers pains/dependencies to you. You will achieve a faster flow of change, and you gained trust and a success case within the organization.

   1. Hopefully, by this time, you have been communicating with leadership, and they started to understand the impact of this approach.

7. At this point, you and the leadership might decide to make official the obvious, the infrastructure team became a platform team. 🎉

This is an adaptation of a real conversation I had at Platmosphere, where I spoke about Team Cognitive Load as a Metric to Measure Platform Impact. You can check the slides here.

Platform Engineering teams are hard, in several aspects.

1. They need to help internal developers to deliver faster with less cognitive load. But who takes care of their cognitive load? 🫂

2. They are hard to fund, and are being challenged constantly if that investment could be better used somewhere else.

3. They are hard to manage to offer a compelling internal platform that solves the internal developer needs, making sure that it has a great DevEx, and they own the platform adoption, and distribution. Avoiding technology for the sake of technology.

But I believe we are falling into a fundamental mistake. We don’t always need to create an Internal Development Platform (IDP) on top of Kubernetes (reinventing AWS Fargate once again) to offer a great Platform Experience that solves our developer needs.

We can start smaller, and focus first on learning our organization, its needs, and the developers’ needs. Yes, I say developers’ needs a lot of times, because we kind of forget from time to time.

When you are in an organization that has an existing infrastructure team, that handles tickets reactively, and you find that all the flow value is slow, you’re considering a platform approach because you know all the benefits. You know it’s a great approach, but going from ticket handling to self-served platform isn’t trivial. Indeed, it is quite painful experience.

Instead, I suggest you to try something else first.

Thinnest-Viable Platform (TVP)

A TVP is a careful balance between keeping the platform small and ensuring that the platform is helping to accelerate and simplify software delivery for teams building on the platform. (p.101, Team Topologies)

Team Topologies shared this concept some time ago, and created a GitHub with a set of examples. You can see it here.

A TVP can be:

• A wiki with a set of guides and templates on how to achieve something.

• A Slack bot that triggers certain scripts.

• A GitHub template with the Terraform that can be configured with a script.

• You name it.

The important aspect is that you start with the use case that will impact the most to your developers, and it is achievable in a reasonable time. You do not want to expend 6-12 months developing something, you want to have a fast feedback loop.

That use case, you can find it via:

• Talking to people.
  The preferred method, but you need to have some product skills to do a good research, and not impose your own view. Partner with your product and design peers to make this process.

• Your ticket system, like Jira/Trello/Linear/GitHub projects.
  Those tickets that repeat a lot, those are the ones that you want to automate.

Meet your customers where they are

Sometimes we want to deploy a new technology, maybe adding a Backstage, or whatever you consider it is good, but we are used to their stuff. And maybe the best area to start offering your platform isn’t a new website but in Jira or Slack.

Potentially you need to configure a Webhook on a certain Jira ticket with a tag, or with a Slack bot with those use cases preconfigured.

Reduce the friction to start using your platform as much as you can. It is better that you adapt to them, than the other way around. You can educate them, as you release new versions in the future.

Be aware of the adoption curve

The adoption curve is a model that describes how new technologies or ideas spread through a population over time.

The chasm represents a significant gap between the Early Adopters and the Early Majority. It highlights the crucial transition point where many new technologies and products fail.

You cannot start pretending that everyone will use your platform. The only way to do so it is by a top-down decision, and people will find workarounds to keep doing what they did before, not leveraging the potential of the platform, and you losing extremely valuable feedback. A lose-lose for everyone.

Instead, start small. Find 2–3 teams, and 1–2 people within those teams to help you start the platform. Do product platform interviews to them, involve them on the platform design, and help them be early adopters. They will have more tolerance to the initial bad experience of your platform, and they will help you get into an OK state before releasing to other people.

If you do it good enough, those people will become your platform champions, spreading the good of it to others, and creating adoption momentum.

So, when people that are more demanding on the platform experience, they will find a good developer experience already.

Learning about your developers’ needs first, improve your TVP, then you build the Internal Developer Platform (IDP)

Don’t get me wrong, I’m not telling you to not build something on top of Kubernetes. What I’m saying is that you can focus on the thinnest platform first, focus on learning about your developers needs first, and then, from that super important context specific knowledge, build a great IDP.

Maybe, you find yourself with a good enough TVP that doesn’t require you to invest into a complete IDP, saving you a lot of time and effort, and a lot of money to the business.

1. Recap of Engineering Strategy’s kernel and types
2. The method - Leveraging the informal communication first.
2.1. Create the network before you need it
2.2. Involve the right people before you decide
2.3. Pre-announce the announcement
2.4. Communicate the strategy that everyone knows already

No Engineering Strategy is designed and executed in the vacuum. An Engineering Strategy addresses the high-stake business challenge from the engineering lenses.

That’s why it is always in collaboration with other disciplines/departments/roles such as product, business, operations, marketing, … Each strategy depends on your context, purpose, and situation at hand.

Therefore, communicating the Engineering Strategy to technical and non-technical is essential to increase the odds of success.

1. Recap of Engineering Strategy’s kernel and types

Let’s recap the Kernel of an Engineering Strategy.

• Context and Purpose: The moral imperative, why we do what we do. Which is the current situation at hand.

• Understanding: Help us to identify the main blockers, risks, and opportunities that could prevent us to overcome the high stake business challenge. It helps us to focus on the important aspect of the challenge without feeling overwhelmed with information.

• Direction: A guideline to help people understand where to focus.

• Coherent actions: A set of coherent actions to accomplish the direction. They are coherent to one another, and they add up instead of compete.

Plus, the two types of an Engineering Strategy:

• Deliberate strategy: Intentional and more formal, it assumes the future and defines what needs to be true. It helps to create alignment.

• Emergent strategy: The organization's response to unanticipated events. It

In this post, I focus on the Deliberate strategy.

For simplicity, the Deliberate strategy has 3 high-level phases.

• Pre: All the work needed before starting the formal strategy process. Informed by the learnings of the Emergent strategy.

• Meanwhile: The actual Deliberate strategy design phase.

• Post: The execution phase. Often overlapping with the Emergent strategy.

2. The method - Leveraging the informal communication first

The first thing I do to avoid formality is to reject existing formal communication structures, such as leadership meetings with structured agendas, team of teams meetings, and similar gatherings.

Those forums may have the expectation of knowing your stuff, and sometimes we don't leave space for brainstorming. It can feel like we don't have things under control. Or the pressure to end the meeting with a plan.

Not a healthy dynamic, but a common one. Preventing people to express their concerns, and adopt a resistance to the unknown behavior. Stick to the plan!

On the other hand, informal approaches, like:

- Aleix: Hey! Do you have 30 min? Need your help to understand a thing. Let’s grab a coffee whenever you have time.

- Aleix: I’m facing some challenges here, and I might need your help to understand this area better. I think we’re missing something, and your point of view can clarify a lot of the stuff.

Those are real sentences I used to help me understand better what needed to be considered when facing a challenge. I look for more information. Learn from people, have an open mind, and learn about:

1. Their context and challenges.

2. What is important for them to consider.

3. What’s working, what’s not working.
   Are people leaving? Are people burned out or feel unchallenged?

4. What is in their roadmap.
   Are they overcommitted without capacity to absorb more work?

5. Which is the existing relationship with the department/teams/people.
   What happened in the past? Exists a healthy relationship? Or people do not talk to each other?

✍ Take notes of everything. Maybe not during the conversation, but later. Taking notes during the conversation make things way more formal than it should. Focus on connecting with people first, notes second.

🎦 Ask for recording the conversation. There are situations that you’re gathering knowledge. In these moments, I ask for recording that part of the conversation, and include it as part of the diagnosis phase. People are super open to share knowledge in a way that they don’t need to repeat themselves, and their knowledge can reach more people.

It is easier for me to start by understanding them, than the other way around. As I understand their context, I learned that some people like to learn about you, by asking back the questions for example, and others don’t. That also gives you feedback on how to approach the communication, and the expectations on who can help and who will be harder.

2.1. Create the network before you need it

Any high-stake business problem requires the collaboration of multiple people.

You need to understand the people around you, and the people that you will need to be around you to succeed.

Your team (direct influence), others are your peers/collaborators (indirect influence with a supporting collaboration structures), and other times are people that aren’t within your close cycle, but you need their support for success.

A good model to understand this is The Team Onion Model.

Start understanding who is in each layer, and who might be missing to unlock the Engineering Strategy.

In the following article, I understood that I had to create a stronger relationship with the business, and product people to unlock a new way of working to enable empowered teams. That’s why I started talking to the right people that could influence, for good and for bad, the needed change.

• Core: Mainly lead by the tribe management team, me included. We also had some principal engineers as part of the tribe management team to be sure all points of view were included.

• Collaborators: We collaborated with the business unit management team to be sure they understood the need of the change, and we needed them to be part of the change. We had direct collaboration of VP of Engineering, VP of Product, and VP of business. That made the whole processes achievable.

• Supporters: We needed HR support to start adopting a new Hiring Process to help us on the path to product developers with E2E ownership. If we kept hiring specialized people, we would repeat the same structure of teams by technology. We also needed Ops’s support to be sure that during the necessary changes, we minimized any customer facing impact. I think we didn’t require it at the end, but it was critical to have them onboarded to be sure that in case of need, they were able to address any customer concerns, and not deviate the team’s attention.

2.2. Involve the right people before you decide

While you create the network, you understand their context and situation at hand. You can start to identify who will be critical to be involved in your challenge.

The right people can be senior managers, key stakeholders, but also the teams that the strategy will affect. The buy-in and alignment is needed in all the layers. Sometimes we put too much effort in the upper management, and we forget to manage down.

Here, I start creating some kinds of artifacts, usually in a Miro board. A board that I place a lot of information, not structured, but what’s important for the people, is there.

People like to add information, and sticky notes have emotional attachments.

What it’s important for me is being considered! I want to contribute and be sure people understand my/our needs. I can help them as well, because it is a joined effort!

Most people like to help. Never found a person that doesn’t like that. What I found is people overloaded in work, about to get a burnout, that put healthy boundaries on how much they can help. Sometimes we expect people that help us more than they can. We need to adapt our expectations.

During this process, I start to share a draft of the Engineering Strategy. I explain:

• What’s being considered.

• Why it is important.

• Areas of risk.

• Why their involvement is important.

My recommendation is to make the draft public, maybe comments only enabled when it is too early. But this depends on your company’s culture and/or what’s being considered. Sadly, sometimes this isn’t possible. Regardless of that, try to default to an open approach. The first time will be hard, and mistakes will be made. Learn from those, and next iteration will be better.

During the informal conversation. I seek for feedback.

- Aleix: Does this make sense to you? Do you think this is the most important thing we should be doing? If you can support us, what we need to do to help you? What is a NO-GO for you? What can prevent us to achieve these goals?

I create a space for all those answers. I need people’s support, and we also support people on their journey. The Engineering Strategy should also help them. We are together on this challenge.

By understanding all these considerations by the key people. I can include those as part of the communication and engineering strategy design.

It doesn’t mean that we will address everything. It means that it is being considered, and I will explain why we will address it, or why not.

Up to here, you have been working informally on Context and Purpose, and Diagnosis. You made great steps in the Engineering Strategy Design diagnosis phase.

Now, you can start moving into a more formal approach, in those forums where decisions need to appear to be made.

2.3. Pre-announce the announcement

You have done a great steps forward on the Engineering Strategy. The purpose and context is understood by everyone, the diagnosis has been contributed by the key people, stakeholders and teams, and you are moving towards Direction.

Here, you start leveraging again the informal structures with the same key people.

- Aleix: Hey, thank you for your time. I have been putting everything together. We did a great job here. I want your feedback on the direction and the proposed coherent actions. Does this make sense to you? Are we missing something? What can prevent us to overcome our high-stake challenge?

At this point, I present the strategy draft. I share with them that this is what I will share in the formal meetings.

Hopefully, at this point. You already aligned all the people, and you got the necessary buy-in.

2.4. Communicate the strategy that everyone knows already

Use the formal structures to announce the strategy and its expectations. First, leverage your more inner forums, like 1:1 with your manager, and team or tribe meetings.

Like a rolling release strategy, if you will.

Be involved into the communication of to teams, directly or indirectly. I suggest tech leaders to start sharing the strategy before the announcement is official. Try to execute some coherent actions, as a quick wins. Start seeing it in action, making it more realistic.

By the time I made most of the public announcements, people shared that they already started, and going in this direction. It is awesome when you see team members championing and having high ownership on the strategy.

Sometimes, we got that buy-in, that teams wanted so badly to start in that direction that we had to ask for shorter iterations, and leverage the existing structures to understand impact to proof that our hypothsis was correct.

It was awesome when people understood what needed to be done. Yet, you want teams to dedicate time to strategic coherent actions, but do not move all the effort into those. The product delivery mustn’t stop.

So, the process of a deliberate strategy worked without finishing it, a total success. It created purpose, direction, and alignment. And the teams moved into an emerging strategy mode. They learned as they did, but with a shared direction, and supporting structure at place.

At this point, we achieved great engineering strategy velocity.

This increases the trust, and buy-in from senior leadership, as they see how teams are able to connect with the high-stake business challenges from an engineering point of view.

When I became a manager, I understood the importance of a great culture. Yet, I had a hard time describing what’s culture, what’s a great culture, and how to make actionable actions to influence it for the better.

I didn’t study Anthropology, if you did, please, point out any misconception in the comments!

When I ask people what’s company culture for them, it usually reduces to:

Long story short, how decisions are made.

Then, I read The Staff Engineer’s Path by Tanya Reilly, and it contains a great way to understand your company’s culture, and what people refer to.

When people ask about culture, they might refer to:

• How much autonomy will I have?

• Will I feel included?

• Will it be safe to make mistakes?

• Will I be part of the decisions that affect me?

• How difficult will it be to make progress on my projects?

• Are people nice?

We can say that our culture is how we behave in our day to day, how we make decisions, and based on which values.

I find this way of describing the company’s culture very on point. You can answer to those questions to people you are onboarding, and you can spot any issues in certain areas of the culture.

Tanya even goes further, and provides 7 dimensions in which you can describe the company’s, business unit, tribe, or team culture.

Here is a shorter version of the 7 dimensions based on Tanya’s book.

• Secret vs. Open.
  How much does everyone know? Information is currency? Calendars are private?

  Slack channels are invitation only? Does everyone have access to everything? Even messy first drafts?

• Oral vs. Written.
  What gets shared by word of mouth, and what gets shared written down? How much writing and review is involved in decisions? Features come with formal specifications, or you need to go to the person that made the feature?

• Top-down vs. Bottom-up.
  Where do initiatives come from? A completely bottom-up culture is one where

  employees and teams feel empowered to make their own decisions and champion the initiatives they think are important. But, when those initiatives need support, they slow down.

• Fast vs. Deliberate.
  Rapid decisions and pivot abruptly to try a new opportunity. Or you need to show that you've thought through the whole plan before start executing?

• Back channels vs. Front doors.
  How do people in different groups talk to each other? Formal path of communication, via the teams' managers for example, or people can send friendly DMs cross teams?

• Allocated vs. Available.
  How much time does everyone have? Are teams understaffed or overworked? Are you able to absorb new work as they appear, or does it end in the backlog and needs to get prioritized in the next cycle? (it can mean next quarter OKRs review)

• Liquid vs. Crystallized.
  Where do power, status, and reputation come from? How do you gain trust? Clear

  hierarchy? Are you in a specific point in the hierarchy, and as others move up into the latter, you also move? Or you are more Liquid, where it offers room for change and you need to move yourself to be promoted in the organization?

I use these 7 dimensions a lot to understand my clients company’s culture, and why they are struggling to drive the needed change.

Understand your company’s culture first

As part of my coaching and consulting engagements, I ask leaders which is their company culture based on those dimensions. Interestingly, I receive kind of two main responses:

• That’s not the type of company I want to be part of.

• That’s why we’re not able to drive the necessary change, because the culture isn’t helping us, we need to change it first so that we can do the necessary changes later

Culture is never black or white, but a grey scale in multiple levels.

Plus, I’m sure that you will describe your company’s culture differently if I ask you for the overall company culture, your tribe’s, or your team’s.

The leaders that I support in their journey understand that culture is important, and they want to improve it for better.

BUT, I distinguish two scenarios. Improving company’s culture as:

• C-level, like CTO or CIO.

• Middle management, such as VPs or Heads of Engineering, Engineering Managers, or technical leaders like Staff or Principal Engineers.

In this article, I focus on the group that driving a company cultural change is more challenging, the middle management.

When I talk to middle managers and Principal Engineers about their challenges, they often aren’t about culture as their challenge or goal that they want to accomplish, but as a blocker to achieve the desired outcome.

Principal engineer: I want to drive this initiative to accomplish A, but it would be easier if we had a more Y culture. How can I influence my leadership to change this culture so that I can accomplish the other thing?

Aleix: Well, you don’t aim to change the culture. Cultural change takes time, requires constant leadership support, and a lot of patience. By the time you achieved that, the challenge you have now will no longer matter. Instead, follow the culture. It is the path for less resistance to achieve what you aim to achieve.

If the approach, plan, strategy, you name it, isn’t possible due to the company’s cultural restrictions. Then the problem is your approach that’s not possible in that context. You need to find another way that fits into the company’s culture way of working.

Yes, it can mean that you need to play the company’s rules like being in the right meetings, with the right people. It can even mean that you need to move into the management career to influence the decisions where it happens. Not everyone wants to do it, but some has to.

Focus on achieving your goals and overcoming your challenges within the scope of action you have first. Once you are in the middle of the progress, aim to influence the culture as part of journey.

Cultural change is part of the process

The best way to influence your company culture is part of succeeding in high stake business challenges. You shouldn’t aim for a highly disruptive new way of working for the company, but “the adjacent possible1”.

If you are part of an organization with a top-down approach, secretive, and oral based communication, you can start influencing the company’s culture by driving your initiative by making the information available and written. But keeping the approach top-down. You don’t want to change too many ways of doing stuff at the same time.

This way, when you…

When you succeed

• Achieve your business objectives first, delivering company and customer value.

• You create trust between the all parties. High level leadership, and teams.

• You show that by doing X, Y, Z, you achieved your objectives. Company’s love success, and we all try to repeat success. By doing so, the next time you face a similar challenge, the default approach will be the new ways of working.

When you fail

• You learn why you failed. You don’t blame the culture, but understand why that approach didn’t succeed. Then you adapt your methods, and try new approaches.

• You don’t create high resistance to change due to disruptive new ways of working. That can prevent any new improvement initiatives in the future.

  • The worse that can happen is that the people stop believing in the change.

Make it iterative. One step at a time.

You can learn more about it with this two posts.

Hi everyone! 👋

Reserva tu plaza

I’m starting a new project to help more people on their engineering strategy journey. Well, they are kind of two projects.

Wardley Mapping en Español cohort

A dedicated cohort course in Spanish for the Spanish-speaking community for an in depth learning on Wardley Mapping applied to Software Companies facing high stake business challenge.

A brief description of Wardley Mapping benefits in Spanish.

Los mapas de Wardley nos traen diferentes beneficios:

👉 Clarificar el pensamiento: ¿Qué cosas importan? ¿Cómo funciona todo? ¿Y qué es lo que quiero?

👉 Eliminar la desalineación: ¿Dónde estoy siendo poco claro con los demás, y ellos conmigo?

👉 Evite errores embarazosos: ¿Cuáles son las cosas obvias que debo saber y hacer?

👉 Acabar con el trabajo que no aporta valor: ¿Dónde estamos malgastando nuestro tiempo, energía y esfuerzo?

👉 Derrotar a las palabras de moda: ¿Cómo puedo crear significado donde no lo hay?

👉 Crear claridad de propósito: ¿Cómo puedo crear un entorno que otros querrán aportar?

During 6 weeks, we will have 6 interactive live sessions of 2h each plus more than 13 in-depth lessons to go from 0 to your first strategy based on high situational awareness.

Because you are part of this community, you have a 20% discount using the code MAPA20. If you’re a paid subscriber, DM me for a 25% discount.

If you still have doubts if this course is for you, leave a comment to the post or DM.

Cohort based courses

I found the cohort based courses to have a lot of benefits:

• Active hands-on learning: Course built on live workshops and hands-on projects.

• Interactive and project-based: Interacting with other learners through breakout rooms and project teams.

• Learn with a cohort of peers: A community of like-minded people who want to learn and grow alongside you.

If you want me to do specific cohort courses on topics like Engineering Strategy core concepts and in practice, Domain-Driven Design, Team Topologies, Wardley Mapping, or whatever you consider. Take 1 min to answer this survey. 👇

Show your interest here!

Why starting in Spanish?

Ben Mosior did an awesome job sharing about Wardley Mapping in English, I learned a lot from him.

I found that the Spanish-speaking community didn’t have many resources available about Wardley Mapping, and I want to change that!

At the same time, cohort based courses on Wardley Mapping isn’t that common, or at least I didn’t find any.

The good thing about cohort based learning is that it is interactive, you connect with like-minded people, and we explore multiple contexts in the same cohort.

That’s why I consider running an English edition if enough people are interested!

YouTube channel

I love to write to help me understand better the concepts, it helps me organize my mind. I love to teach courses, it helps me connect with awesome people facing hard challenges, and learn together on specific real life scenarios.

Now, I want to explore how video content on hard concepts such as engineering strategy can bring to me as a creator, and to you as an engineering strategist.

That’s why I started a Wardley Mapping playlist in Spanish first. I’m adding some shorter videos based on the cohort course so you can get a feeling on how the recorded videos in the course looks like.

I will publish content in Spanish and English on similar content I write in my newsletter.

Subscribe to YouTube

Wardley Mapping is provided courtesy of Simon Wardley and licensed Creative Commons Attribution Share-Alike.

You’re an engineering manager of a tribe with three teams. Two stream-aligned teams and one platform team.

At some point, you start noticing critical areas of improvement.

The platform team is under a huge pressure to deliver features because they are blocking stream-aligned teams. Stream-aligned teams lack the proper structured processes, and are making the whole problem even worse.

We wanted to achieve a fast flow of change, but we are seeing that all teams are constantly collaborating to ship the features.

You see the product having some delays, we identify a lack of quality on the shipped product. We understand that it can mean a:

• Not well-defined architecture.

• Lack of testing and other QA practices.

• Missing ownership due to shared responsibilities between teams, making it hard to own a deliverable end to end.

Your team members share that the testing process takes a lot, and it is a bottleneck. The platform is supporting all the stream-aligned teams needs, and they are unable to handle any more work.

At the same time, you’re under pressure to deliver features. You have a budget available, and your manager gave the OK to spend the money with flexible talent, like external consultants or freelances, if you consider it necessary.

You have to take action.

Seeing a problem and do nothing isn’t good for your job security. It’s better to spend money you have available, and try to do something, and fail, than do nothing and still fail, isn’t it?

So, what do you do? How is your culture? What is the acceptable decision?

Let’s hire a set of consultants to help us on the bottleneck, because we want to optimize, the consultants we will be shared between teams.

We hire them temporally to support us on our process.

They are tasked with two goals:

• Unblock our stream of value.

• Train our people.

And all of a sudden, they have been with us for two years. The process didn’t improve, the ownership isn’t there, and the pressure to deliver faster, and better keeps increasing.

Indeed, they are asking more budget to add more people because the processes started to become slow again, and we need more business agility.

Yet, because in your organization you made the decision that is more acceptable by your culture, you’re doing a good job.

But, are you really doing it, or you made the easiest decision?

Why was it the most accepted decision?

• Because you used your budget to add people to the problem.
  But it made the problem worse

• Because you solved a problem with people, because you’re a manager.
  But you know about the processes, and architectural problem. That wasn’t addressed in your approach of hiring external consultants.

• Because you added a new step into the process, and you made them responsible for the quality of the whole product.
  But the product is complex, they are unable to attend the whole team’s needs, the same problem as the platform team had, and they are adding more lead time as more rework is needed.

  • You added more meetings. Shame on you!

Which isn’t the most accepted decision, but an alternative that addresses the problems you identified? Engineering management acting as Enabling Team

You, as part of the engineering management team, have identified the team gaps, the problematics, and adding another step into the problem only makes it worse. You weren’t addressing the root cause.

But instead, see yourself as an enabling team.

You will upskill your teams on the areas that you identified while you gain another point of view. The challenges your team faces.

Being closer to the teams, helping them unlock the necessary change, and facilitate different workshops, trainings, and helping that the new ways of working to stick will unlock a lot of the problematics that you, and your teams are facing.

Why don’t we see management as an enabling team?

Some organizations design the manage role as a people only role.

Missing all the potential of engineering leadership, which it is the combination of people management and technology. We can understand it as the combination of:

• People and processes.

• Technology, such as architecture.

If managers can only influence people, and maybe processes, they will need to act on that dimension. Making their solution space limited and suboptimal.

By understanding our engineering management teams as people, processes, and tech, we enable new possibilities.

Make yourself the next question:

Why do you need to hire a trainer for unit testing if you can do the training?

What is preventing you as a manager of managers to be involved in the teams?

Is it that you are too busy for this work? Why? Is the other work more important, or it is unnecessary bureaucracy?

Stop for a moment, and understand what’s preventing you to do the most sensible actions.

Read more at Team Topologies Newsletter

Update May 12th 2025.

I wrote an extended version of this post as an article for Team Topologies. You can read the full article using the following link, https://www.linkedin.com/pulse/leadership-enabling-team-team-topologies-5icbf/.

The Netherlands 🇳🇱 Fast Flow Conf edition had an Open Space Format.

What is Open Space?

When you bring together a group of folks, empower them to co-create their own sessions about what they want to talk, provide just enough structure to ensure progress, and hit the Start button – that’s Open Space, a style of self-organized “un-conference.”

Two people proposed a similar topic on platform engineering:

• Why do PMs run away from internal platform products?

• Who will take care of platform engineers?
  Referring to the cognitive overload platform engineers usually face.

A great outcome of these spaces is that we connect with people with similar mindset, and facing similar challenges. We feel less alone, and we gain new perspectives.

So, I want to address both questions in this post from my perspective based on my experience.

Subscribe now

Why do PMs run away from internal platform products?

Internal Platforms Products are hard. The users are our internal teams, developers. Developers are the type of users that I found harder to:

1. Understand their user needs.

2. Create an enough good experience so they adopt the platform product, instead of “we prefer to do it custom to our specific context”.

As a non-technical PM, it is hard to understand how to deliver those experiences if you didn’t experience the pain yourself. Plus, talking to developers teams gives you some insights, but those are hard to convert into something actionable without the help of your technical peers.

Platform PMs face a hard question.

How can you demonstrate the impact of the platform team?

We are investing NN.000 EUR/month in this team, are we able to return a x10 on the investment? How do you measure the impact? Shouldn’t we assign those engineers back to the product teams, where the impact is more direct? Do you have the needed support from the data team to create the dashboards to track the impact, or are you very low on their priority?

Those questions are hard to answer. You don’t have it easy. For one side, you are learning the domain, you’re making sense, while seeing as a cost rather than a value generator. Without the needed support by your peer teams that you should be building the platform for.

It’s hard.

Try this instead — Enabling work

What worked for me, for Platform Teams PMs, is to train senior or tech engineers on a set of Product Manager skills. So, we cover one part of the problem, knowing the engineering domain.

Yet, knowing the engineering domain isn’t enough. You are missing a lot of other essential skills. How to prove value, help platform adoption, user interviews, prioritization, …

Without those skills within the team, you have a hard time moving the platform forward, and having the x10 impact that a platform team should aim for.

Upskill your platform team on the product essential skills with a product enabling team.

In our case, we focused on helping them to upskill on:

• Product discovery.

• Go to market approach. How can we help other teams to start using the platform without enforcing using a bad platform experience.

• Gather product feedback.

• Prioritizing and saying no.

Build the team from product team engineers that show product thinking

Another great way to increase the odds of succeeding is to have people that are already used to product thinking.

They will be people that have been exposed to product reasoning, and they can do something similar in the platform team. You still have to upskill people in certain areas, because they won’t have the PM support, but they have already the mindset for continuing learning in this direction.

Who will take care of platform engineers?

From a Team Topologies perspective, we see Platform Teams as a way to improve flow by removing blockers and reducing cognitive load.

But the question was, who takes care of the platform engineers’ cognitive load?

We see from time to time platform engineers having a hard time delivering platform improvements.

They have a lot in their plate. They are unable to move forward but keeping the lights on. Plus, they're getting tickets from everyone with high priority, and unable to say no because product teams are busy doing important and valuable work.

We have been there, and we kind of were able to go out of that mess.

Antipatterns or bad practices

Platforms being the else clause of the backlog

if (productTeam.hasBacklogAvailability()) {
  productTeam.assignInitiative(initiative);
}
else {
  platformTeam.dealWithTheInitiativeNoOneElseCanDo(initiative);
}

This was our norm. We don’t know where this belongs, or the teams don’t have capacity, but it is “important”, therefore it goes to the platform team, asking to address that ASAP. Interrupting their current work in progress.

Too much work in progress

We need to do all of these things, let’s do them all because everything needs to be delivered together. Plus, we have this requests from product teams that’s blocking the business.

Platform Teams having a hard time prioritizing is a common problem. It is hard to say no to stuff that’s blocking the business. But we will see an alterative to this problem later.

“We know better than product teams”

This is way more common than I thought. Platform teams building a platform product without talking to internal teams. In the vacuum.

Guess what, that platform doesn’t solve the developer’s needs and either it’s dropped, or worse, it is enforced to use, making the whole DevEx a mess.

In this antipattern, we have a very late feedback loop, increasing the odds on:

1. Not solving the real need.

2. Not gathering feedback until too late.

3. Not showing the value faster enough to build trust and adoption momentum.

Understaffed platform engineering with unrealistic expectations

Can it be a team of 2 for the full 500 organization? Make it 3 so that one person at a time can go in vacation.

Having a well stuffed platform team is hard. Not staffing the team to handle a realistic workload will make the platform initiative to have a hard time to succeed.

Platform is a blocker for flow, let’s add 2 more people to these 20 people team to go faster

On the other side, I saw overstaffed platform teams. Usually, the platform team helped on key delivered, leadership saw the results, and now they are becoming bigger and bigger.

This will just slow everything down and create damaging behaviors, like:

• Senior engineers only going to the platform team, creating kind of a backend team for product/frontend team doing simpler stuff.

• Owning a lot of domains, from infrastructure, to core product facing features.

• Increase of the communications internally and externally, increasing the telephone game.

• Making the whole process slower, increasing cognitive load for all the platform people, and product teams.

• Stopping the platform team because it doesn’t work.

Not knowing how to, or even trying, measure your value

This is the hardest thing I found on Platform Teams. How can we measure its value? It is hard, but not trying to have a way to understand how you are impacting the platform teams is a problem.

Because when the question of which is your impact? Which is the ROI the team generates? It is already late to start measuring it.

Platform Teams is about impact overtime, you need the data’s history and its trends to prove your value

SysAdmin Team 👉 DevOps Team 👉 Platform Team. Same behavior, different name

Old behavior, new naming.

I saw this multiple times, that teams adopts the latest trendy name without adopting the practices and underlying values.

It is true that it’s not 1 or 0, everything has an adoption curve. Yet, try to challenge how far you’re into adopting the new practices and values that apply to your context.

Try this instead

Define the platform team purpose and the domain

The platform team purpose is about helping internal teams, not about building an abstraction on top of K8s, nor do what others do not want to do.

Having a clear purpose and a domain will help you to say no easier. You will have a leverage point to not be the :else clause.

Not only externally with the other teams, but internally too.

When someone might propose to do X with Kafka, you can challenge that and say: How does it solve our user needs? Can we do it smaller? Or is it up to us, or can we just give a Terraform configuration for others to use in AWS Kinesis for example, so that they don’t depend on us?

Limit the platform team size, make the platform open for extension

Small platform teams create thin platforms. You can read more about this idea of thin platforms at https://github.com/TeamTopologies/Thinnest-Viable-Platform-examples.

Having between 3 and 6 platform team helped me a lot by:

• Avoid being the :else clause. The team is unable to absolve all the work, we need to be mindful of the work load.

• Limited work in progress. Teams find 1 to 3 WIP stuff to be a reasonable peace, adding more WIP will just increase communication, and it is not lineal with the throughput. 1 to 3 WIP for platform team is great.

• Keep the domain small enough. If the domain needs to be bigger, we can consider adding another platform team, and then create a unique experience for the consumers.

  • We had a compute platform team, and a mobile platform team. But as well as security platform team and so on. Domain specific platform teams.

• Their cognitive load becomes more obvious and works as a sensor to understand blockers, and problems down the road.

Allow platform enhancements by other teams.

When teams require stuff from the platform that the platform team cannot absorb, but it makes sense to be done there because it will help other teams too (an identified product team need), allow them to contribute to the platform.

Inner sourcing

InnerSource is the use of open source software development best practices and the establishment of an open source-like culture within organizations for the development of its non-open-source and/or proprietary software.

We can adopt a lot of good practices from the open source community. By making it easier for product teams to contribute back to the platform following the platform team guidelines, we ensure that we aren’t a blocker for change.

An alternative is to allow people to by pass the platform for their specific use case in case the platform doesn’t resolve their issue. Always with the vision of standarizing the component when more teams have the same need. We don’t want 200 components doing the same thing in different ways.

Rotate developers between stream-aligned teams/product teams and platform teams

Based on Dynamic Reteaming by Heidi Helfand, we can leverage people moving from team to team.

We can learn from the product teams needs by moving a platform engineer developer to the product team, do daily work delivering new features, and experience the product team members pains by themselves.

Then, they can bring that back to the platform team. This is a nice way of exploring user needs, and also provide insights on how to leverage the platform, helping on the adoption side.

The same way, we can move product team engineers, to the platform engineers for some time. They can bring all this knowledge, pains that prevent fast flow, as well as product skills to the platform team.

If platform name adds friction, do not use it

Platform is an overloaded word. Sometimes, we want to make sure leadership understand the value of a platform team. Yet, for them might mean business platform.

Instead of focusing on the naming, aim to focus on the team purpose. Improve this, or that. Like, product resiliency, product throughput, whatever it is a pain for the business that’s preventing flow of value.

By focusing on what it’s the team purpose, how you aim to impact the business, and how we can see if the team is performing, you can win way more support to drive the needed platform initiative.

Talk about money.

Each company is different, but here I want to give you some guideline on how you can start understanding your cost and the value you (need to) provide.

Get the amount of team members, and multiple by the average salary per month. Now, make that x12 to understand the cost of the platform team.

A common platform team could be 5 team members, monthly average salary of 4.000EUR/month.

Now, let’s add the lost of opportunity of that team working on a product initiative.

Usually, a product initiative aims to give at least 5x the ROI of the cost.

So, the potential cost of opportunity is around 1.200.000EUR.

You are aiming for high returns because most product initiatives fail, so the one that succeed needs to pay all the failed initiatives plus provide revenue.

You don’t need to justify the 240.000EUR, you are justifying the 1.200.000EUR.

That’s why you should find leverage points that, in combination to the Developer Productivity improvements, you can help product teams to go faster, and so on and so forth.

You should aim to provide at least 5 times your value, either by allowing new initiatives to go faster or reducing cost.

So, you need to generate indirectly 1.200.000EUR anually.

How do you measure this? With proxy metrics.

Let’s see a set of proxy metrics, some are better than the others, but start with the ones that are available for you and you can influence for business impact.

• Jira Tickets per week.

• DORA metrics.

• Team Cognitive Load. You can use Teamperature for this.

• Opened customer support tickets.

• Downtime.

• AWS bill.

You name it.

You need to choose the ones that are more relevant to the business, while improving the developers productivity.

Create a platform for what’s not availabile in the market. Stop productizing compute

I'm surprised how many times we create an AWS Fargate abstraction on top of Kubernetes, while the major developer pains are somewhere else.

It’s so hard to do a better DevEx that public cloud because the DevEx goes beyond the API. It is the tooling, the documentation, the available training, and YouTube videos.

Do not underestimate the effort needed to deliver a capability.

Take into account the business priorities