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

1. The users
2. Their needs
3. Value chain
4. Evolution
5. Factorial’s gameplay
5.1. Becoming an ecosystem
5.2. Jobs to be done
5.3. Efficiency for innovation

⚠️Disclaimer. All the content, assumptions, claims, and so on I do on Factorial Product are my own interpretation, and it doesn’t represent the company’s reality. This post is an open practice on Wardley Mapping to understand how more products are relevant to map.

Factorial is a product/company quite known in Barcelona, Spain, as they have their headquarters here, and they run a quite famous podcast in Spanish, Podcast de Itnig.

They are an all-in-one HR SaaS for SME that intend to automate everything HR, from time management, to talent from hiring to performance review, via finance such as payroll, and employee expenses.

I used it during 2020-2022 when I was Engineering Manager.

What I want to say with this is that their business domain is quite huge and complex. Which makes it a perfect product to explore using Wardley Mapping.

The other reason why I chose Factorial is that we have been experiencing several changes in the tech industry compared with the Zero interest-rate policy, ZIRP for short, period.

We are seeing less rotation, harder to find competing job offers for software engineers, and other roles within the tech industry, a push for efficiency, and that translates pressure for HR software to adapt to the new context where focus moves from attracting and keeping talent, to employee efficiency, followed by policies like Return To Office, RTO for short.

You can see more in the following post about the ZIRP, and the change in the industry.

The Pragmatic Engineer

What is Old is New Again

👋 Hi, this is Gergely. I give one conference talk per year: this was the one for 2024. It’s my best attempt to summarize the sudden changes across the tech industry and what they will mean for the next few years of software engineering…

Read more

2 years ago · 361 likes · 2 comments · Gergely Orosz

1. The users

By looking at the top menu items, we can already tell that Factorial is a huge product serving a variety of users and industries. I’m not able to map everything, therefore I’m focusing on the Technology industry needs because that’s the ones I’m more familiar with, plus it’s the purposes of this post.

Based on the menu item by Role, we can assume there are three users to map.

2. Their needs

When I started to understand the user needs, I noticed that I might mapped it wrong. The landing page lists three roles, but I think this is a marketing acquisition decision to attract the main buyer personas that convert the most.

I think their users looks more like this:

I merged CEO and HR managers because their expectations right now much aligned. The landing page says that HR Manager to streamline administrative tasks and focus on team development, and CEO to optimize, reduce structural costs, and boost the business.

Which long story short, it is about efficiency.

I believe that the role of people management and growth (at number of employees, and employees career) isn’t the primary business focus anymore. I’m basing the article with this assumption.

The ultimate value proposition is about to spend less time on manual tasks related to HR and dedicate that time to productive tasks, those that aim to generate revenue. From this perspective, I will map the user needs.

Furthermore, I made explicit the needs of Managers, and Employees. You cannot streamline administrative tasks, nor optimize structural costs without reducing the gross time spend where you have more people, in non-HR roles.

So, I consider factorial is achieving their mission by providing an all-in-one solution targeting HR managers/CEO as buyer personas, and then rolling it out to the product users such as HR managers, Managers like Tech Leads, and Employees.

In order for this to work, they have to delight those three users.

3. Value chain

Factorial’s pricing page is the full representation of the components needed to fulfill those user needs. You can see this within the application after registering, I didn’t find it public.

By looking at the value chain, we can see how much features are related to Talent Management, involving the different users. In order to understand more of that area, we should do another map only zooming into that area, but I leave that for the reader to do. I don't to spoiler all Wardley Maps we could do on Factorial’s business landscape.

4. Evolution

As I was adding the evolution axis, I noticed that almost all the Factorial’s capabilities are in the product or commodity space.

Well known client needs to be integrated in one place.

We can even see some of the commodity products being included in the pricing space and not being optional, while other’s that are more in the product area being an add-on to the monthly basis subscription.

After trying the Factorial’s product thanks to the free trial, I had the impression that several capabilities are self-contained, not depending on other capabilities other than shared concepts such as employee, company, and alike. Everything you need to do on a capability, it is under the same tab/URL.

I’m not sure if they are reusing code, copy-pasting, creating shared libraries, or having subset shared capabilities as a Factorial’s platform focused on common user facing needs. I’m having this guess due to the common UX, that requires a lot of shared building components to be sure that the app behaves the same, combined with the shared language on what some key concepts mean, like employee, company, etc.

5. Factorial’s gameplay

The beginning of the post I assumed I could describe how post-ZIRP affects SaaS HR solutions for SME market such as Factorial.

Even though I cannot share a 1:1 relationship, I think I can describe three main factors that could represent a response to a market that needs to be do the same with less/do more with the same. For both, clients and providers.

1. Becoming an ecosystem.
   Factorial cannot serve an hetergeneous market by itself. So, it invests on becoming an ecosystem where others can build on top of.

2. Rethinking the UX of HR needs with Jobs to be done.
   If clients needs to have an even more efficient HR department, and all the related management tasks, they have to stop investing on local feature optimizations, and think the E2E HR user journey, and optimize those jobs to be done.

3. Efficiency for innovation.
   For internal development, decrease the cost of solving new critical user needs by creating an Internal Product Platform. Instead of requiring more product-tech teams to keep delivering/removing features, reduce the cost of creating new capabilities by having a compelling and thin product platform for the main use cases.

5.1. Becoming an ecosystem

There’s a moment when you cannot solve a huge variety of user needs, and you need to opt for another approach. Allow external developers to solve those user needs for you in exchange for an ecosystem they can sell their products/integrations to.

I saw it quite clearly in the Integrations page.

The ecosystem gameplay can be expressed quite clearly as a Wardley Map. We have 3 users:

• Factorial. Wants to create an ecosystem for others to innovate on top of.

• Factorial customers. Want to adapt/customize more Factorial to adapt to their needs.

• Factorial partners/developers. Want to publish integrations, to either serve better their customers within the Factorial’s ecosystem, or obtain new users thanks to Factorial’s ecosystem.

This approach, which means releasing an API where others can build on, will support Factorial in the next way. Factorial will be able to add metadata on how the different set of integrations behave, and detect future user needs that they want to invest on.

5.2. Jobs to be done

I recall a Podcast where they were sharing some of these insights, but I’m guessing the reasons, and the approach. Remember, I’m exploring as an external viewer.

As up to today, Factorial’s user needs are quite self-contained. Which means that they solve one thing, like Time tracking. During a podcast, I recall that they want to create a new user experience that go beyond of self-contained features, to Jobs To Be done. Or how I understand it, instead of focusing on needs == capabilities, moving into needs ==> a set of capabilities well interconnected.

My bet here is that Factorial is investing in a better UX, moving from commodity capabilities for well-known user needs, to reinvent how HR is doing their job to make their job even more efficient.

The guess here is that they cannot make the HR processes more efficient within the same capability, and they need to move to make the Job To Be Done more efficient to have huge impact. Moving from local optimizations, to big picture optimizations for their clients.

The approach might be AI Agents.

Factorial partnered with Microsoft Azure OpenAI during early 2024. There is a high chance that this Jobs to be done will be driven by AI agents touching a broad set of capabilities.

5.3. Efficiency for innovation. Platform?

I recall a Podcast where they were sharing some of these insights, but I’m guessing the reasons, and the approach. Remember, I’m exploring as an external viewer.

LinkedIn says there are 1.666 associated members, which I can assume between 300 and 400 works in product-technology.

Sales, ops, business development, and customer-success are around 800.

Factorial focuses on SMEs, but the amount of people in sales, ops, and customer-success suggests that:

• They are approaching an upper market, maybe more mid-market.

• The platform isn’t as self-served as I expected, and it might require a high touch engagement model. That’s due to the emphasis on customer success service.

Combining the point 5.1. becoming an ecosystem, adding new capabilities, and addressing new and existing user-needs shouldn’t require duplicating the engineering team. The size is already significant, and the benefit of creating new teams isn’t lineal to ROI.

The amount of customers, and the product size should allow Factorial to have enough data to invest in safe bets, and have great Go-To-Markets to deploy new products to existing customers that those needs have been already detected.

So, instead of creating new full features by new teams, it can be interesting to create a kind of Internal Product Platform, using the Team Topologies Term of Thin Platform As a Service.

The Internal Product Platform (IPP) should act as a set of common capabilities to help product teams to deliver products to address known user needs, or explore new ones.

IPPs enables you to:

• Make the product more stable, as you make high-used, high-dependency, use cases stable.

• Create a shared language among all teams on key concepts, and the cost of integrating those concepts instead of build-it becomes worth in the mid, long term.

I recall last time I did an IPP to make some sensible decisions such as:

• IPP team members were part of product teams, and understood the user problems.

• IPP team members had the right product skills such as explore user needs, talk to customers, pragmatic, soft skills, and familiar with Team Topologies to be sure they were creating the thinnest viable platform, and not a big one.

• Facilitating the adoption of the platform by use case as soon as they were available, reducing the risk of platform adoption, and be sure we were building the right thing that solves business, user, and product-engineering needs.

A good way to understand the teams context, and where to start investing is to understand the socio-technical system from a team cogntive load perspective following the Team Topologies guidance.

We are building Teamperature to help organizations to make conscious decisions taking into account teams cognitive load, and track the impact overtime. Check it out!

That’s it! I hope you enjoyed the post as I did writting it. Love to hear your feedback, and know which product you want me to Wardley Map next, leave a comment.

Leave a comment

If you are from Factorial, and you want to help me to fix some things that are wrong, and collaborate on making a more accurate article, feel free to reach me via DM, at LinkedIn, or at hello at aleixmorgadas.dev. Love to chat! 🙌

I’m helping organizations to design and execute their engineering strategy. If do you think I can help you, let’s chat!

Schedule a 30min chat

1. Top-down and Bottom-up culture
2. Do not try to change the culture
2.1. What to do instead
3. Execution eats strategy for breakfast
3.1. What to do instead
4. The meetings you’re not part of
4.1. What to do instead
4.2. You have other channels
5. The network
6. Iterate fast, keep stakeholders updated, and accept it will take a while
7. Embrace conflict
8. Stakeholder management
9. Take risks when you’re about to resign

We are starting 2025, and it is the best moment to take the right time to design a coherent engineering strategy. Yet, having the right high-stake conversations, talk about the elephan in the room, and make though decisions isn’t easy.

That’s why I’m writing this posts, to help you though your strategist journey. At the same time, I provide services to facilitate those conversations, and co-design your company’s engineering strategy within a week with a dedicated workshop.

Know more at https://aleixmorgadas.dev/services/engineering-strategy. Feel free to reach me via DM, LinkedIn, or at hello at aleixmorgadas.dev

A constant challenge the people I coach face is the not having the authority to design and drive the engineering strategy. They are part of a top-down organization, and unable to set the right resources for the strategy to succeed.

During the coaching sessions, we work which kind of activities, artifacts, and including skills are needed to drive an engineering strategy without authority.

In this article, I share some of those practices, and techniques for middle engineer leaders, like engineering managers or staff engineers, to overcome the key obstacles to influence the organization for good.

Schedule a coaching session

1. Top-down and Bottom-up culture

A completely bottom-up culture is one where people and teams feel empowered to make their own decisions, and champion the initiatives they think are important. But, when those initiatives need support, approval, and like they slow down.

On the other hand, in a top-down organization, initiatives happen on the top, and they are communicated, and any change on the direction needs higher-ups approval.

A top-down organization can be transparent, share all the decision in front-doors in Slack channels, or all-hands sessions for example. Yet, those decisions are made by a closed group of people in the top of the hierarchy, the top-management team, or the C-suite.

If you are reading this article, there is a high chance you are facing challenges to lead your own initiatives without higher ups approval, or even worse, your efforts being constantly overruled.

You’re experiencing:

👉 Decisions happen in meetings that you are not part of.
👉 You follow the top-down decisions, propose an action plan, but then overruled without being part of the conversation.

So, let’s see how can you influence the strategy in this adverse context.

2. Do not try to change the culture

Aiming to enhance a company culture without authority is a recipe for burnout. Instead, adapt to it.

Define a company’s culture is hard, but I found the next dimensions based on The Staff Engineering’s Path by Tanya Reilly to be a good starting point.

• 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.

• 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?

• Back-doors 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?

• 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?

• 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?

• 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)

Let’s assume this describes your company culture. We can interpret it as a top-down, transparent, and bias towards action guided by product/business needs.

Aiming to change the culture to be part of the conversation could mean that you aim to influence your company culture to become:

If you aren’t part of the C-suite, with a huge effort by all the departments, which a set of coherent actions that sets a new company values, and all the support for all the effort needed to make this happen, including incentive systems like performance reviews, and expectations on the role definition… I don’t have many success cases of cultural change without leadership support.

I’m building a product to measure company’s culture to help conscious leaders to make informed decisions to drive impact. You can join the beta at culturesensing.com

2.1. What to do instead

The good thing here is,

So, instead of opposing it, you need to embrace it, even though you consider it isn’t the best culture.

Why? Because you cannot fight too many battles at the same time, if you’re changing the company culture, that deviates your attention from engineering strategy. If you consider it is the only way, OK, invest your time there, but then you have another (bigger) challenge.

3. Execution eats strategy for breakfast

Another way to express it is about bias towards action.

Bias towards action in an organization context means the ability to overcome the “analysis paralysis” that prevents people from making an informed decision, based on imperfect information, especially in the face of uncertainty.

It has a lot of benefits, such as:

• Allow organizations to move fast.

• Overcomes overanalysis and procrastination.

Bias towards action isn’t incompatible with strategy. Yet, I found this principle to be used to prevent bottom-up strategy, conflict, and crucial conversations that need to happen. Or at least used to stop being questioned too much by teams.

Strategy shouldn’t lead into overanalysis or procrastination. Indeed, it helps you to move faster, when uncertainty is high. Because it’s not about moving fast on one task, but that all the actions we do are coherent to each other, instead of competing.

3.1 What to do instead

• Do not mention strategy.

• Make strategy work as part of your day-to-day job.

• Gather more context for your current task.

• Collect that information, and make it available as part of your journey.

• Record some decisions in a lean format, such as Architectural Decision Records, or notes in the OKRs definition in Notion/Confluence.

• Redirect people to those notes/principles when high stake actions are taking place to help people make decisions that are coherent with each other.

• Identify the key metrics that can (in)validate your assumptions, and make them visible during your 1:1s with your manager.

• Ask for which metrics are relevant business/product wise, and aim to make your actions backed up with the intentionality of impacting those from an engineering point of view.

Here is good read to completement this point.

4. The meetings you’re not part of

Not being part of the meeting it doesn’t mean that your ideas, needs, and so forth aren’t present. Your manager will need to communicate them in your behave. But so will others.

A meeting doesn’t happen in the vacuum, it has a context, and it is part of a bigger vision. Each person within a meeting has into account:

• Their own needs.

• Their reports needs.

• The people they report to needs.

• The bigger picture, or goal, or whatever the context of the meeting is.

As an orange sticky figure, you have your own needs, and you take into account your team needs as well.

But here is the problematic, does your manager understand your needs? Does she have the right material to defend your needs, and the teams you lead needs?

You can create some documentation, some slides, or even some dashboards, but you’re missing one thing. In that meeting isn’t about you, nor your needs.

It is about the company needs beyond engineering. The conversation won’t be around we need of implementing Kafka, but how can we keep delivering value in these times of high uncertainty.

Therefore, it is so hard to put the team needs into the table, because it isn’t speaking the language of business that takes place into that meeting.

4.1. What to do instead

• Focus on understanding the key meetings needs.

• Who will be attending? Who has more voice/influence?

• Which are their needs and concerns?

• Which is their leadership style?

  • Are they gut based? Or do they need data evidence?

  • How do they make decisions? Consensus? HiPPO makes the call?

• Are they having problems meeting the C-level expectations too?

• Which are the metrics that they value the most?

• Can you connect all those priorities, concerns, uncertainty, with specific team needs?

When you understand all those drivers of decision-making, you show how you understand your manager’s needs, and co-prepare materials that addresses both, top-management needs AND the team needs.

By co-creating this materials, your manager will be able to use them to influence in those meetings to do some steps forward in the engineering strategy.

Be patient, because this takes time, and you’re heavy dependent on your manager’s influecing skills to make this happen.

4.2. You have other channels

Not being part of the meeting it doen’t mean that you cannot contribute in other channels.

Those meetings have resources, communication channels, and so forth. Aim to contribue to them by:

• Communicate proactivly in Slack channels.

• Add comments to Slides, Notion pages, Confluence pages, that are being used on those high-stake meetings.

• Add your input/point of view to Architecture-Decision Records.

Find where the communication happens async, and contribute to those situations.

5. The network

Create a network within your company to understand their needs, their career expectations, and build a healthy relationship with people before you need it.

Some people see this as politics. IMHO, as long you don’t influnce in bad faith, you set a clear expectations, and you take into account people to build together, I see as part of the manager’s job.

TL;DR: It’s a good thing, and you should aim to create a healthy and robust network within your company.

Why?

Because it will help you understand other people needs, their manager needs, and create a compelling vision to address their needs, and their boss needs, and also including your needs for a collaborative strategy.

It will help you a create a we strategy and not an us vs you strategy.’

So, you can move from “We need to invest on DevEx because 🥔” to “Improving our cycle time is critical for deliver sooner and safer, we see product not meeting their goals, and continue with the current approach won’t help but make it worse. We consider investing on this specific area to be a safe bet, and we will measure the impact based on X metric for this amount of time”.

Hopefully, by the time you are making this statement, all the parties understands why you are proposing that, how that will affect them, and you should have bigger support to drive those initiatives without impling overanalysing, or big intiatives.

Achive that by iterative and incremental improvements, and having a fluid and contant communication with the right stakeholders.

5.1. Leverage skip-level meetings

A skip-level meeting is a meeting with people you don’t directly report to or people that don’t report directly to you. This works in multiple directions.

Start meeting with people that has influence to your area beyond your closer cycle. People like Heads of Product, and so on that aren’t close to you in your day to day, but their input matters.

6. Iterate fast, keep stakeholders updated, and accept it will take a while

As I wrote in the Engineering Strategy Guide - Introduction, a strategy is composed of 4 points.

• 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.

• Business and context: Those three components live within a context of the business purpose and organization context. They need to directly address those business needs.

You don’t need an strategy to be big nor inspirational. You can keep it local, boring, and that addresses a high-stake challenge taking into account the business needs, and the team pains.

So, don’t make big sessions but small ones often.

1. Create a place where you will keep all the information available, like in a Notion or Miro.

2. Add the context and your initial diagnosis.

3. Adopt the current strategy, even if it’s an unspoken one, and define how people are measuring its success.

4. Record the small actions being done to make this strategy happen.

5. Redirect people to the document (no need to call it strategy, engineering principles looks like a good name), and help people to share:

   1. If they are able to apply those principles/direction.

   2. Note down what works and what doesn’t work.

6. Iterate the document, by showing those insights with your manager, and ask for support for those things you cannot do.

7. Show regurarlly the progress you’re doing, and ask for clarifications on what makes sense, what they want more of, and what they want less of. Adapt your communidation, and stratetgy accordantly.

   1. Hopefully, some of those insights will be part of the meetings that decisions take place.

Involve your manager when it is necessary, not for everything.

When you have insights that either the strategy isn’t working, and you need higher-up commitment. In that moment, you have enough documentation, you know what’s important and your top-management need.

Now, you are in a good position to influence the strategy, directly or indirectly.

7. Embrace conflict

Are you avoiding conflict? Are you using techniques like “yes, and” that aims to create a sense of agreement but you’re not really agreeing?

Strategy is conflict.

Therefore, you need to learn to be OK with it, I don’t ask you to be comfortable, but at least not avoid it.

Why is it conflict? Because strategy cannot suit everyone, and you need to make compromises.

Conflict needs to be practiced, and you learn by doing. Yet, having some resources can help you navigate them better.

Here some books that helped me to navigate better conflict:

• Radical Candor by Kim Scott.

  • Radical Respect by Kim Scott.
    To understand the nuances of psychological safety. A perspective missing in the first book.

• Non Violent Communication A Language of Life by Marshall B. Rosenberg.
  Understand how can you communicate your needs better, by ackowledging others needs without attacking, nor being unable to put your needs first.

• Crucial Conversations: Tools for Talking When Stakes are High by Kerry Patterson

• The Trusted Advisor by David H. Maister

• The Five Dysfunctions of a Team by Patrick Lencioni

On the other hand, avoid non productive conflict. That will drain your energy for no real purpose.

8. Stakeholder management

You need to master stakeholder management.

Be sure that you:

• Understand their needs, and they acknowledge that you understood them.

  • A good way is to keep a record of why certain decisions were made in the past. Knowing the past will help you set for success in to the future. And it is quite probable that that information isn’t documented.

• Keep the information available.

• Proactively communicate changes, and risks.

• Consult regurarly.

• Involve stakeholders in decision making.

• Address concerns first and quickly.

• Constantly adapt as needed and you learn.

• Check regurarly if you are communicating enough.

• Keep communicating!

9. Take risks when you’re about to resign

At some point, and after trying multiple times to make an impact without success, you have considered, or you are considering it right now, resigning, and looking for a new opportunity out there.

That’s legit. Before you do that, let me suggest you a last initiative.

Aim to design, and execute an engineering strategy that you consider that makes sense, that’s executable, and measurable in a reasonable time frame (no more than 3 months).

No need to ask for permission, better ask for forgiveness. Because:

1. If it works, you learned. And you can resign later if you want to.

2. If it doesn’t work, and they fire you.

But the key takeaway is that you will learn. And it is the moment that you can take more personal risks, because you are putting your job security at risk by taking bolder decisions.

Do not confuse this by making riskier decisions for the company and your colleagues. That’s not responsible.

How that will influence you?

You will stop doing expected work, you will prioritize some stuff over others, and you will miss deadlines.

But let me tell you something 👇

So, start practicing in a place that you have few things to lose. If you’re lucky, you can practice it in your organization without putting your job at risk, but that’s not the context for everyone, unfortunately.

Navingating a top-down organization is hard, and you don’t need to do the journey alone. I help leaders like you though tailored coaching sessions based on your needs and goals.

By only explaining and understanding your challenge, you are already half though the solution.

Schedule a 30min call using the following link.

Schedule a coaching session

1. The users
2. Their needs
3. Value chain
4. Evolution
5. Sociotechnical system
6. Buffer’s gameplay
6.1. Expanding into revenue
6.2. Channels expansion gameplay
6.3. Ecosystem (new thanks to Amanda from Buffer clarifications)

⚠️Disclaimer. All the content, assumptions, claims, and so on I do on Buffer are my own interpretation, and it doesn’t represent the company’s reality. This post is an open practice on Wardley Mapping for PLG products to understand how more open products are easier to map compared to more closed ones.

🎉Update 16th December 2024: Amanda Marochko, Staff Product Manager at Buffer, reached me after reading the post, and share clarified in some areas that I was mistaken/had the wrong information. Amanda, thank you very much for your time!

I will mark the previous info and the new info so you know the difference before and after the conversation. Plus the Amanda’s clarifications. The words are mine, and might not be 100% accurate due to making a summary of the conversation.

I use Buffer to schedule some of my content for Bluesky and LinkedIn, and I wanted to learn more about this product because it has several interesting traits.

• Open Company. I can find all relevant information at https://buffer.com/open.

• Podcast Interviews. I can learn more about their decisions at interviews.

  • R072 - Cultura de producto en Buffer, con Mike San Román

  • Defaulting to Transparency with Joel Gascoigne

• Product-led Growth approach. Which helps me identify the customer, and their needs easier as I don’t need to speak to sales.

1. The users

Learning which is their customer is quite straight forward using key sections of any landing page.

• The testimonials.

• The pricing page.

• Use cases.

Buffer has the first two.

Based on these two sections, we can determine that the users are:

• Individual content creators due to the Essentials plans.

• Marketing/content teams.

Amanda’s clarification: You are right. We have these two user personas, we have aimed to attract SME businesses, but we found out that individual content creators, such as thought leaders as you, are the main user persona that we are attracting. More focus on them will be put into 2025.

2. Their needs

Understanding the user needs is quite straight forward for individual content creators out of the Tools navbar menu.

On the other hand, content team owner can be inferred from the pricing page, but I tried the organization features to be sure those are the main ones for teams. Thanks to the free trial, I was able to verify those needs.

3. Value chain

Buffer has a quite interesting approach on the subdomains, almost a subdomain per navbar item.

Create and Publish sharing the same subdomain can determine a legacy constrain due to the company probably started with a monolith providing creation and publishing posts, and later-on has evolved into their own products, but the code probably being coupled kept them together.

At components level, we can identify few, but they vary a lot depending on the channel and post type. I consider them to be like a pipeline, where we have several components evolved differently

Let’s explore it directly into the Wardley Map with the evolution.

Amanda’s clarification: Yes, the subdomain approach is a legacy decision when we had a subproduct approach. Right now, we are considering Buffer as a one product to have a unique experience. We are working on this for 2025.

4. Evolution

I identified some key components like Ideas, Posts, and Reports. Those looks like they have been a pillar for Buffer. When navigating the product, I could see how the channels influenced the post types, as well as the feature maturity beyond create and publish.

I could identify text and image posts to be well establish, and be part of cost of doing business, while video is part of the new offering. On the other hand, polls posts aren’t supported (AFAIK).

That’s why I create a pipeline for the Channels, where the channels that support more features are more evolved than the ones that aren’t that evolve like Bluesky. It has been interesting to find that Meta products, Facebook and Instagram, are quite evolved, but Threads don’t. The evolution Thread’s API could benefit Buffer to extend the use cases for Threads as well.

Other channels are keeping most of the API restricted to publish, and few are opening for analytics.

5. Sociotechnical system

By looking at LinkedIn, we can infer the amount of teams, and how that affects their domain structure.

I did this exercise after the Wardley Map, so, let’s see how by knowing the team size can help us identify which domain boundaries they could define, and how that can evolve in the future.

• Total: 226

• Operations: 58

• Engineering: 40

• Customer success: 27

• …

• Product management: 7

LinkedIn isn’t accurate on the numbers, but based on them, we can assume Buffer has around 5-7 product-engineering teams.

Amanda’s clarification: This is the part of the post more wrong. We aren’t +200 people, we are 80 people company.

• Total: Around 80 people

• Operations: 5 people

• Engineering: 25-30 people

• Customer success: 27 people

• People department: 4 people

• Marketing: 15 people.

With 4 product-engineering teams:

• Apps, channels, and platform.

• Consumer experience.

• Audience engagement.

• (another I don’t remember the name) 😅

They leverage multiple providers, such us:

• A lot of customer success tooling like HelpScout, Klaus, Pendo, Retool for internal dashboards probably

• All connected with tools like Fivetran.

Even though it looks like they have the approach of buying off the shelf as much as possible, they also do custom build solutions. Those are made with:

• Web and API: ReactJS, NodeJS, Typescript PHP, GraphQL and MongoDB

• iOS: Swift, SwiftUI & Objective C

• Android: Kotlin, Java and Jetpack Compose for Android

• Infrastructure : AWS, Kubernetes, Datadog, Terraform, Docker, Github Actions

I didn’t identify the need of providing an iOS or Android app.

Regardless of that, it seems like they have a full-stack mindset, and everyone is expected to help everywhere when possible.

Because of the usage of K8s, and the stack, and the URL composition, it is quite possible that they are using a microservice architecture.

It doesn’t look like they have a platform team, even though a candidate can be the channels component.

The channels component needs to provide connect to all the social networks, and that would require a unified API, but at the end, and because of the post topology, encapsulating that can be complex. So, I’m quite sure some common stuff like Authentication, OAuth2, and alike are shared components of that microservice, but then each channel has its own implementation, and that’s exposed to the different components in some degree.

I believe the teams aren’t per user need/domain.

I believe that the teams might have some degree of influence based on the product structure per subdomain, but I think the teams work on domains that overlap, and they share some components, to deliver product increments.

Those shared user journeys, or shared components, are beyond the channels. They also have the components of:

• Organization, user management, and permissions.

• Payments processing.

• Landing page.

• Internal tools for customer success.

• Internal data tools for high visibility and decision-making due to the product-led growth approach, and the need of optimizing the right user funnels to make it as low touch as possible.

6. Buffer’s gameplay

Buffer biggest constrain is the social-network API’s dependency. As long as social networks don’t support posts formats or key APIs for engagement/analytics, they are unable to offer a value add on the new features such as analyze and engage.

The bet on Buffer’s AI is key for the creation/idea phase, and also as engagement.

If they are able to augment the personal brand by, instead of generating out of the blue content, creating tailored content based on previous posts, understanding the tone, the audience, and so on, it can be very beneficial.

Combining Buffer’s AI with:

• Current posts to understand the brand tone.

• Understand which posts brought more engagement.

• Provide insights on industry trends…

can be awesome.

6.1. Expanding into revenue gameplay

Engaging and growing the social networks might not be enough, and the customers need to understand if that converts to revenue.

Right now, Buffer is solving the content creation pain. If they are able to extend that into understanding revenue via Shopify APIs for example, it could provide in-app insights on which pots provided bigger ROI.

That bet would require bigger understanding of their user base, and start by a concert segment of their user base.

This can position Buffer’s as a NoCode application from building an audience, to creating a sustainable business guided by data.

Amanda’s clarification: We won’t do that specifically due to the risks you are mentioning. Expanding into this area is a huge bet, instead, we will do (See point 6.3. Ecosystem).

6.2. Channels expansion gameplay

Keep integrating with other places where content creators audiences could be, such as Quora, Redit, WhatsApp channels, Telegram Channels, …

It is a well understood gameplay by Buffer’s team, and probably following the same strategy in terms of go-to-market, engineering, product, etc.

Amanda’s notes: Yes, being the first ones to adopt new APIs for channels to expand the channels feature is a strategy we keep. That’s why we are close to those channels to be the first ones to implement.

6.3. Ecosystem

This point is thanks to Amanda’s clarification. Thank you for allowing me to share this insightful strategy with my readers 🙌

Betting on new lines of business, and user needs, have a high risk.

Instead of betting on certain new user needs, and limiting the innovation. Buffer’s 2025 strategy is focused on creating an ecosystem to help other’s build on top of Buffer.

In order to do so, they are working on three main “new” components:

• Buffer’s external/public API to access all the components like channels, and so on that I mapped previously.

• Buffer’s marketplace to help Developers publish their products, let’s call them power-ups following the Trello’s terms, and Buffer content creators customers to find new ways to engage, and reach a bigger audience.

• Buffer’s new pricing model to support the marketplace approach.

If you are from Buffer, drop me an email, a comment, or a DM, to know much right and wrong I was!

Thank you a lot for reading this post 😄.

I love to read your feedback and opinions to help me improve. You can DM at my LinkedIn or just leave a comment using the following links:

• 😍 Awesome

• 😐 Okey

• 😨 Bad

Leave in the comments another product that you want me to Wardley Map.

Leave a comment