I would like to start presenting a simple organizational chart with two management layers. C-Level and middle management.
If we add the reporting lines per department, it might look like:
A structure like this one would have different communication and collaboration expectations, which each pull the other into a different flow of change. Let’s see them in action.
Within team
Collaboration and decision-making might happen at each layer with some degree of autonomy. This is the most common expectation. We want teams to make fast decisions within their team.
Each management layer also expects to have a high degree of autonomy for decision-making, BUT, it might not be the case when the next communication pattern is more intense for communication with a top-down approach.
Fast communication across layers within the department
Communication happens fast within departments. It is expected that people within the same department can communicate fast. In specific, vertical communication, either top-down or bottom-up.
When cross-layer collaboration is mainly done within the same department, we start sensing more of the top-down. Who decided this? Why? Can we speak with the decision-makers? Why are we receiving a backlog and we don’t take part in the product-ideation process?
A layer makes a decision and then uses its reporting lines to introduce change within the organization.
We can see the flow of change as:
I’m sure teams will have a certain level of autonomy, but the business initiatives are hand-off to teams, creating a slower flow of change as who thinks and who does aren’t the same people.
The responsibility to put different views together and align on the expectations belongs to the team. They receive the needs/priorities differently depending on the department that pushes them down, and it’s the team's responsibility to manage the different incoming items. Well, it’s not their responsibility, but the team that is the affected the most and they need to address it as they suffer the consequences.
This approach usually creates a lot of friction to introduce change and teams naturally evolve into the next collaboration mode.
This structure works well for reporting and a relationship between managers and team members to help people grow and provide meaningful feedback for their careers. Of course, also to communicate things that are exclusively for the department, like now we use X technology and we need to align stuff.
Cross-team collaboration
This might look like a better collaboration to introduce change within the organization, but it also contains traps.
The handover here is more blurry. Because it is hidden in a continuous collaboration mode between teams.
The main difference is that the responsibility to put things together belongs to each layer instead of the team that delivers the software at the end.
Here the friction is reduced, which will improve the flow of change. However, it is far for the organization to reach its full potential.
The more teams you have, the more collaboration is needed. Given a point, you cannot collaborate with as many people as the organization requires, moving back to handovers as the only way to give autonomy without the constant need for collaboration.
Then how?
Based on Team Topologies, the way to achieve a fast flow of change is by having a Stream-Aligned Team that owns the process from idea to production.
The ideal scenario is nice, but how do we reach this point starting from the previous scenarios I shared? What are the problems that prevent reaching our full potential?
Problem 1. Domain experts outside the Teams
It’s common that domain experts are in leadership positions. You want to boost their impact within the organization from subject-matter expert. And it is normal that they have a higher weight on what needs to be built.
Problem 2. Collaboration is expensive
The domain experts starts being pulled into many meetings and their input is needed everywhere. They start moving from explaining the why into asking for the what to be delivered as they are unable to attend all the teams demands.
Collaboration starts to become worse and the meetings aren’t productive anymore. Teams start sensing that they don’t understand the why and the organization is missing the product culture. Domain experts find themselves not understood and explaining the same thing over and over is just creating a burden on them. They opted for a more tell approach to sustain the high pressure environment.
Problem 3. Everyone has their own approach
Teams start creating their own identity that allows them to be resilient to the chaos that’s beyond their team. They understand their area of decision making and they want to master their area of expertise.
Because they are having less decision making on what needs to be build, teams start to focus on the how. They want to feel fulfilled on the craft of their work and create as much as quality as possible to feel proud of their work.
Impacting the user is each day more challenging and influencing the roadmap based on their learnings requires huge discussions and proof their points with data, otherwise the back to the default. Follow the leadership roadmap.
Problem 4. Visibility
We wanted autonomous teams and now, we don’t know what they are building nor if they are aligned between the different business initiatives. We start seeing the product divert in the user experience and which we thought was our user persona.
We start introducing more formal reporting to understand what’s happening within the organization and we consider creating a Program to align all the teams into one common objective.
Teams start to complain about the new bureaucracy introduced to the company, and the sense of we are not an startup anymore. It feels like a corporate!
An alternative to restore hope!
Empower the teams and delegate!
It is not that easy.
As managers and leaders, we have a role and a job to do within the organization. We cannot delegate completely our responsibilities and we need to be involved in multiple things that happen each day.
How can we empower the teams to make their decisions faster when the domain experts/subject-matter experts aren’t part of the team? How can we make sure that teams are aligned without adding multiple layers or reporting that slows the organization down? How do we delegate to teams that misses the skills to be autonomous? How do we make sure that all the information is available when the collaboration is that expensive?
Two team types that intentionally addresses those questions:
Platform Team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams.
Enabling Team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities.
I want you to see a management or leadership team as a kind of Platform and Enabling Team. I consider this one of the best ways to enable fast flow of change as managers and leaders.
Platform team behavior
That’s right. Just envision what is your role as leader, provide a good way for teams to make decisions aligned with the company vision. What are you providing for them to make those decisions? Let’s see some examples of company platform:
Objectives and Key Results.
Company Vision and Mission.
Product Principles.
Architecture principles.
Product Workshops.
You are just saying… we are already doing that! And that’s right! We have been doing this all along without intentionality.
Now, I want you to think how to create this product about company vision for stream-aligned teams so they can achieve fast flow of change by consuming those resources to be sure they are creating products aligned with the leadership by consuming that internal business platform.
Enabling Team behavior
On the other hand, not all teams can consume an internal business platform and make informed decisions if they are missing key skills or domain knowledge.
If the domain experts or subject-matter experts are part of the management or leadership team, you need to provide the stream-aligned teams with a compelling business platform, but also understand which are those skills gaps and training them to become more effective on the long term on the domain expertise.
That’s when you need to behave as an enabling team. Joining the teams when they find obstacles and helping them overcome those without solving it for them. By helping them become autonomous on those obstacles, you will be able to scale yourself and reduce the need of continuous collaboration.
It won’t be that easy
Leadership/management teams influence hard the company culture. Asking from leadership to migrate from old ways of working (handovers for example) into behaving as platforms and enabling teams won’t happen during the night nor it will be the outcome of a reorg.
Indeed, even though they start migrating into that direction, not all teams would adopt the new way of working. The adoption curve also applies here!
I expect two key adoption curves with the proposal of this post:
Some leadership and management teams adopting this mindset, and slowly being adopted by the rest of the organization.
Some teams will start seeing leadership as a platform and enabling team, but some would like to keep the old way of working. Forcing those leadership teams to behave as platforms, enablers, but also as handovers as they were previously doing until the late majority of teams start adopting the new way of working.
All the best on your new journey as leadership as a platform! 🙌
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:
