2nd engineering strategy random coffee
I didn’t think about the potential about meeting people when I asked my network to do a random coffee to meet and chat about topics like Engineering Strategy, Wardley Mapping, Team Topologies, leadership challenges. Or whatever we like to talk about.
A random coffee ☕ or a donut 🍩 is a common technique within big organizations to help individuals to connect with people they don’t know yet and create stronger relationships. There are several bots for Slack and Teams that help you connect people.
☕ Random coffee's outcome
Compared to the first week, the topics concentrated more into exposing experiences and challenges we both had regarding driving organizational change, nailing down the challenges on adopting Wardley Mapping, or the challenges of adopting Team Topologies in a startup.
Here is a short summary of the conversations!
Unable to express the high stake business challenge because avoiding a possible conflict
I loved that this person had an identified challenge.
He identified which was the problem that were preventing the organization to deliver a better service (siloed departments as always).
He understood his clients and their needs.
He knew the business strategy and objectives.
He had prepared a presentation of which actions they should take.
But he missed something. During all the context he provided, he didn’t make clear which was the high-stake business challenge he wanted to address. It looked like he was avoiding talking about directly.
At some point, I asked directly which was the real issue he wants to address, because I felt like he didn’t want to talk about the elephant in the room.
And this is a very common situation I see when people have to make decisions, which strategy is about that, decisions. Decisions that cannot suite everyone and it will create conflict.
Strategy is making decisions based on a context, and imperfect-biased information, to address a high-stake business challenge aligned with the purpose.
I felt that he was avoiding talking about the main problem because it was a people’s problem. And I felt that he was trying to solve a people’s problem from a technical point of view with a lot of arguments, that were good, but not enough to drive change.
So, I challenged his approach. I didn’t have to know the technical context to know that the strategy he was proposing would cause come conflicts.
And that’s fine, good strategy come with conflicts because it is hard, opinionated, and imperfect. There is no perfect strategy.
My suggestion was:
Talk about the high-stake business challenge. Be sure you all agree that’s the problem.
Present your approach to address the problem. The analysis you did, the direction you will take, and which actions are needed, plus which risks did you consider.
Be open to critics and incorporate them as learnings/risks. The strategy is the sum of all the inputs, onboard the right people and capture their concerns and needs. The more information, the better. Do not create a me vs. you strategy because then it has big odds of not succeeding. Just be careful that you are listening to learn, not to create a consensus strategy.
Is Team Topologies applicable to a startup?
Yes. But maybe not in the way you think. When you are 1 team, you are a Stream-Aligned Team.
There are a lot of topics from Team Topologies that won’t apply directly. You don’t have a platform team, nor multiple teams. So, how can we adopt Team Topologies into a small startup?
My recommendation is that you are adopting a set of principles, a humane approach, and methodologies (like DevOps) that help you grow your startup in a healthier manner.
Instead of rapid growing without any principles for later on re-org to adopt Team Topologies (an undesired approach if you can avoid it), you can grow your teams based on Team Topologies principles. So, you start growing in a healthier way informed by Team Cognitive Load and Flow. You know that’s important to avoid handovers between teams, and that end-to-end delivery is desirable.
By the time you grow from 1 team to 3-5, you are already seeing the benefits of growing with a great company foundations rather than being adopted afterward, when all the culture is already established and making the improvement is harder.
Just be careful of now forcing the growth because you want to adopt Team Topologies team types like platform teams. That’s the wrong motivation.
Cognitive Load and Wardley Mapping
If you combine Wardley Mapping and Cognitive Load, you got my full attention. After Brian posted this on LinkedIn, I reached out to understand which is his experience on overcoming the inertia to change.
The interesting aspect of the chart is that he came to a similar conclusion from another point of view.
As part of my talk Design and Execute your own engineering strategy, around min 38 I start to explain a similar idea using the Core Domain Charts.
The conversation deviated to a lot of topics and similar experiences that we had to help organizations evolve their components vs keeping the same approach of custom-building everything.
On the image, you see that the more to the right (commodity) that you consume a component, the less cognitive load causes to the people. If you have a lot of components in the custom-built, more cognitive load. Easy right?
So, why don’t we adopt more product or commoditized solutions instead of custom-building it?
My experience shared that’s a more human problem than a technical problem. We discussed that there are three main factors in play. People, process, and tech.
When I was Engineering manager/Head of Engineering, I found myself that what was causing teams to keep building instead of buying was that people were rewarded to do so.
We had an incentive system that if you custom-build stuff, you have more odds of getting a salary increase because you show mastery on developing. Regardless if that component makes sense or not.
On the other hand, the budget to build teams was way higher and easier to get approved compared to the one for tooling and external services.
In my case, I had to change the budget dynamics and job expectations. It was a long journey until we started to see a change in the architecture, but it finally happens. What it was important is that regardless if you want a certain architecture to happen, if the culture, behaviors, and incentives tell people the opposite, you have a hard time driving the right change.
Top articles mentioned
Here are the two most mentioned posts:
If you want a 30-min chat to talk about anything, or about Engineering Strategy, Team Topologies, Wardley Maps, DDD, … use the following link and let’s meet!
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: