Table of contents
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:
Their context and challenges.
What is important for them to consider.
What’s working, what’s not working.
Are people leaving? Are people burned out or feel unchallenged?What is in their roadmap.
Are they overcommitted without capacity to absorb more work?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.
Strategy is about decisions. What’s considered and what is not.
You cannot make everyone happy. But you can explain why you aren’t addressing it (yet).
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.
