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.

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. Understand the business model
1.1 Canvas, Excels, PowerPoints, or the CEO’s head
1.2 The game you are playing
1.3 Bootstrapped or Venture Capital
1.4 Follow the money
1.5 Consumers, Enterprise, or all in between?
1.6 The user needs, why do they buy you?
1.7 Flow of change
1.8 Business model types and margins
1.9 Relevant metrics
1.10 Funnels and loops

2. Connecting the business knowledge with the engineering strategy
2.1 Before starting understading the business
2.2 During understanding the business
2.3 After understanding the business

Can you design a good engineering strategy without understanding the business? No.

In the first designing an engineering strategy post series, I remark that:

An engineering strategy addresses a high stake business challenge from an engineering perspective.

You can check the full post here 👇

Does it mean that you need to become a business expert to design a good engineering strategy? Not at all.

Instead, what I do is partner with the business people.

I ask them a lot of questions:

• Why the business runs this way?

• Which is the business model?

• Which is the money flow?

• In which game are we playing and why this bets over that ones?

The business people aren’t necessary sales, they are domain experts (using the DDD vocabulary) or subject-mater experts (SME), from whom we can learn a lot.

In this post, I want to provide you some guideline on how to understand your business better by knowing what to ask the domain experts to gain meaningful insights that will help you:

1. Design good engineering strategies that address the high-stake business challenge.

2. Communicate better how this strategy is aligned with the business using a shared vocabulary.

3. Create stronger relationship with other people within your organization

4. Empathize why the business does what it does, and how you can contribute.

The key aspect during researching to understand the business is to keep an open-mind and be understandable that no one can have the best and perfect answers.

If you find yourself with not enough responses, partner with the person to improve that area for a better future.

Working together on this is super beneficial for the whole organization. Just remember to do it with small steps, rather than stopping everything to have a response that suits your needs. Embrace uncertainty.

Subscribe now

1. Understand the business model

1.1 Canvas, Excels, PowerPoints or the CEO’s head

If you are in a startup, the founders probably did a business model canvas, a lean model canvas, or something that will be outdated, but the important aspect is the expectations and implicit reasoning behind it.

In case you don’t have a canvas to kick off the conversation, you can have the same result with some Excels, or PowerPoint that have been used to communicate in some leadership meetings, or during the onboarding.

In case you don’t have anything of that to kick off, then you will need to do a coffee with the CEO for example, and start creating those materials yourself for future need.

Questions to ask

• Which is the core value proposition?

• How do we distribute our products?

• Why those channels over others?

• Which are our clients/users?

• Which is our main cost?

• Which is our main revenue stream?

1.2 The game you are playing

I love the North Star Framework because it helps you understand a lot of the business.

Even though the most famous aspect is the North Star Metric, I consider that how they explain how you have to understand the game you play to be relevant for the engineering strategy.

They describe that any business can be categorized into the next three games:

• The Attention Game
How much time are your customers willing to spend in your product?

• The Transaction Game
How many transactions does your customers make in your product?

• The Productivity Game
How efficiently and effectively can someone get their work done?

Questions to ask

• Which is our game?

• Which is our north star metric?

• How does that affect how to create value and capture it?

• How the current initiatives contribute to the goal?

1.3 Bootstrapped or Venture Capital

A bootstrapped business is self-founded, while a VC business requires external founding. Each have different benefits and drawbacks, and they will influence which decisions you can make.

1.4 Follow the money

How money is invested will determine a lot the engineering strategy. Are the teams founded by VC money? Are they sustained by the revenue generated by clients?

Questions to ask

• When a customer pays €1, what happens to it?

• How does it get invested?

• Which are the expectations of that investment?

• Where are you more willing to invest, and where are you more cautious?

• How much goes to marketing? To people? To tech?

• If we are not profitable, how do we cover the structural costs?

1.5 Consumers, Enterprise, or all in between?

• Product-led Growth
  The most cost-efficient distribution model in B2C and lower B2B markets.

• Product-led Sales
  It leverages customer signals and data to enrich deal qualification to identify long-term revenue before the customer even pays. This drives down our CAC, Cost to Serve, deal cycle times, and most importantly payback period.

• Sales-led Growth
  Great for products that cannot be self-served due to their complexity. Better used for up-market like enterprise.

You can learn more here 👇

Leah’s ProducTea

The PLG for Sales-Led Guide

If we talk about why anyone entertains exploring product-led growth then it’s usually for one of two reasons: You want to understand it better because the superficial implementation advice you usually deal with seems not to apply to your sales-led organization…

Read more

3 years ago · 70 likes · 3 comments · Leah Tharin

Questions to ask

• Are we or do we plan to move up-market or downmarket? Why?

• If we are PLG (or another), how does that affect our structure and expectations?

• Why are we targeting lower market instead of enterprise?

• If we had to target the enterprise, how the organization will be affected? Why not doing that?

1.6 The user needs. Why do they buy you?

You cannot create a good engineering strategy if you may understand the business but not the user needs. You need to understand both to fulfill their needs on the long term.

Questions to ask

• Which are our users/clients?

• Why they and not others?

• Which are their needs?

• Are we providing a solution for those needs?

• Is that solution fulfilled by the product, or is it human based?

• Is it our core value proposition? Is it a bet? Or is it the cost of doing business?

1.7 Flow of change

An initiative doesn’t appear from the vacuum. Someone started it. You need to understand how those initiatives happen in the first place and how it affects the flow of change on the long term.

This includes:

• Idea to founded initiative.

• Prototyping, creating the product, distributing, capturing value, legal, …

• How the work is distributed.

• If new teams are needed, how they are created, by whom, which hiring process.

Questions to ask

• When an idea happens, how does it reach production?

• Who decides which ideas become initiatives and get funded?

• When an initiative starts, how all the departments contribute to the initiative?

• Which are the needs of each department to make an initiative happen?

• Where do you find the most friction to make it happen?

• What would you make different next time?

• If an initiative requires more people, how a new team is created?

1.8 Business model types and margins

Type of business:

• Model A. The value and the cost scale linearly together.

• Model B. The value and the cost don’t scale together.

An example of model A can be a marketplace, serving more customers requires a higher cost. The margins are lower.

On the other hand, a model B can be a SaaS in which the cost of building it keeps “enough static” but the value scales a lot. The margins are huge.

While a Model A doesn’t require a huge upfront investment, the Model B requires it. That’s why business on Model B are always talking about reaching the Break-even.

Questions to ask

• Are we more like model A or B?

• For model A:

  • Which is our margin?

  • Where they come from?

  • When do we lose our margin?

• For model B:

  • Which is the estimate time to reach break-even?

  • Which is the current cost? Is it the labor? Is it the platform?

  • How do we sustain the current structure?

  • What do we need to reach break-even?

1.9 Relevant metrics

Become familiar with common metrics that usually apply to all businesses.

• CLTV - Customer Lifetime Value
  Total value generated by the client during the whole live as a client.

• ARPU - Average Revenue per User (per month or per year).

• CAC - Customer Acquisition Cost
  Mean cost of acquiring a customer.

• CAC payback
  The time it takes you to recover the investment to acquire a customer.

• Churn rate
  Percentage of clients that they cancel during a period of time.

• CLTV / CAC ratio

  Sales efficiency.

• COGS - Cost of Goods Sold
  The direct costs of producing the goods sold by a company. This amount includes the cost of the materials and labor directly used to create the good. It excludes indirect expenses, such as distribution costs and sales force costs. This is sometimes adapted for some business models like SaaS. I found companies excluding the labor cost as it keeps quite static as you can see in the previous figure model B.

Questions to ask

• Which are the relevant metrics for the business?

• How do they relate to our business goals?

• Which initiatives are we doing to influence them?

• Any expectations on how they should look like in the mid-long term?

• Do we know the value of this metrics (the previous ones I listed)?

1.10 Funnels and loops

Several organizations use some kind of funnels or loop frameworks to measure and impact from how they acquire a customer and how that converts into revenue.

The most common one I found is the AARRR Pirate Metrics, but I have seen an adopting of growth loops frameworks.

Questions to ask:

• Which is the current ratio?

• Is it OK for now, or are we actively working to improve some area? Why?

• Which teams/departments are involved in each step of the funnel?

• How does an initiative to improve a step of the funnel affects the team’s work?

2. Connecting the business knowledge with the engineering strategy

Understanding the business is a forever job. You cannot stop learning about it. The more you learn, the better the engineering strategy will become.

A great activity you can do to measure how much did you learn is the next. I hope you are able to see that you improved your situational awareness.

2.1 Before starting understading the business

Focus on putting everything you think you know about the business and the engineering strategy.

1. Save a duplicate of your engineering strategy.

2. If you don’t have one, create a document with the implicit strategy that you have. Even though it can seem like poor, it is totally worth.

3. Create a document in which you will try to answer some of the questions by yourself that I listed in this post.

4. Save that document and not share it yet.

2.2 During understanding the business

1. Create a new document in which you can share with the domain experts to capture the conversation.

2. Ask domain experts to link to the relevant information. Better to start asyncronously.

3. Collect the information and interpreation into this document.

4. Ask domain experts if your interpretation is correct.

5. Have a 1h session to go into details and collect those conversations the best you can.

2.3 After understanding the business

1. Write a new document with a fresh engineering strategy that you consider that addresses the new learnings you had about the business.

2. Compare before talking to the business and after. Did you learn? 😄

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

1. What’s not strategy

2. Core components

3. Where and when to invest in designing an engineering strategy

4. Strategy types

5. Strategy principles

6. Design and execution

7. Fractal strategy

“Strategy is how you overcome the obstacles that stand between where you are and what you want to achieve.” - Richard Rumelt

Another way to describe it is:

“Strategy is a set of coherent decisions, based on imperfect information, to overcome a high stake complex challenge”.

Therefore, engineering strategy is how we address the high-stake complex business challenge from a sociotechnical perspective.

1. What’s not strategy?

A bad strategy isn’t just the lack of a good strategy. It grows out of specific misconceptions and leadership dysfunctions. Like:

• Fluff. Use hyped words to create the illusion of high-level thinking.

• Failure to face the challenge.

• Mistaking goals for strategy. Just statements of desire than plans for overcoming obstacles.

• Bad strategic objectives. When they fail to address critical issues or when they are impracticable.”

- Richard Rumbelt

In addition to Rumbelt’s points, a strategy isn’t a plan or static. And more specifically, an engineering strategy isn’t isolated from the business strategy, it is embedded and it takes into account the whole business context and purpose.

2. Core components

Based on Rumbet’s framework

The core components of an engineering strategy are:

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

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

Engineering strategy is a business strategy from an engineering point of view.

It takes into account the entire context, culture, the business model and needs, other departments such as marketing, customer success, and more, to design an engineering strategy that’s coherent to the business as a whole.

3. Where and when to invest in designing an engineering strategy

Designing and executing an engineering strategy requires time, effort, and resources to make it happen. It is critical to know where and when to invest in an engineering strategy, as well as in which situations aren't the best approach.

The Cynefin Framework describes five decision-making contexts: clear, complicated, complex, chaotic, and, at the center, confusion.

• Clear. The relationship between cause and effect is known to all, is predictable in advance, and is self-evident. Best practices are applied here.

• Complicated. The relationship between cause and effect requires domain expertise. An expert in the field can ensure that the problem is solved properly because they did it in the past. Good practices are applied here.

• Complex. The relationship between cause and effect cannot be analyzed in advance. The connection between cause and effect is unpredictable. You can draft a desired state to reach and apply a set of experiments and initiatives to reach the desired end state.

• Chaotic. There is no relationship between cause and effect. The approach you need to apply to go out of this domain ASAP is acting instead of analyzing or categorizing. By acting, you will be able to navigate into a complex domain.

• Confusion. You don’t know in which domain you are. Your job is to decompose the situation and aim to place it in one or more of the other four domains.

The domains it makes sense to invest in an engineering strategy are complex and complicated. The other domains aren’t suitable for it.

The Complex domain is the perfect fit for how I see the purpose of an engineering strategy. On the other hand, I see complicated to be also suitable for engineering strategy, but it produces a different type of strategy.

The key difference on how they influence the design of the engineering strategy is:

Complex domain

There is no right way to address your high stake business challenge. You need to bet on a direction and perform multiple coherent actions in parallel to see which approach works better, and then pursue that approach.

While the nature of the engineering is complex, the coherent actions should be either complicated or clear. Helping the teams to be able to deliver results. Those results can be things like spikes, A/B tests, production releases, training and workshops, … anything that helps you learn fast if your strategy is going in the right direction.

There is no point to over-analyze the situation because there is no root cause due to the nature of complex systems.

Complicated domain

Exist a right way to address your business challenge but it requires domain expertise. You might find the right people in your organization or you might hire/contract a person/group of people to help you address your high stake business challenge.

You will find your strategy direction is more straightforward and help the team to understand what to address first, which are the priorities, and what needs to be delivered.

The coherent actions are as well in the complicated and clear domain. They might include actions like up-skilling the team as part of the collaboration with external people to help you execute the strategy.

See more here.

4. Strategy types

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

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

It isn’t about one or the other, but how each one complements the other. 

A deliberate strategy helps the organization to align, remove bias, gain focus, and help teams become more autonomous. On the other hand, the emergent strategy helps people to adapt as they learn while executing the coherent actions, instead of requiring the investment that a deliberate strategy requires.

Good leaders understand when it is the right moment to use one or the other, and their tradeoffs. They are able to follow the strategy principles and core strategy components in formal strategy (deliberate) or informal strategy (emergent).

You can see an emergent strategy in tech huddles, leadership weekly calls, or mob programming sessions to overcome a hard architectural decision. The output of them can be architectural-decision records, a request for comments, a new framework adopted, or a new infrastructure component.

5. Strategy principles

• Anticipate-Explore instead of Plan-Do.

• Adaptative instead of prescriptive.

• Strategy driven by value for the client and business.

• Tech at core.

• Communicate and collaborate first and later document, but document!

6. Design and execution

Be careful of one group of people designing the strategy (normally leadership) and another group of people executing it (normally teams). Minimizing the handovers is key.

The best way to increase the odds for a successful strategy is by making sure the key people that designs and executes the strategy are involved during the whole process.

7. Fractal strategy

A strategy can be implemented differently depending on each context. I expect a strategy to be interpreted and adapted for a local context and still be aligned on the C-level strategic choices.

Be sure you have the right structure to help teams inform when they need to adapt to their context and why, and how you communicate new learnings/decisions to the right people.

It is worth mentioning that those more local strategies usually have a shorter horizon. While a C-level engineering strategy can look at months to years ahead, more local strategies might be at a shorter time frame, like 3 to 6 months. 

See more here.