Organisational Fluidity in Digital Platform Ecosystems: Strategic Alliance Teams
Platforms which enable digital ecosystems are growing in prevalence. Organisations want, and need, to expose their APIs as an enabler for not only teams within their organisation, but partners and 3rd parties to build rich, connected applications and seamless digital experiences.
And there is a critical justification: not exposing the data in your systems via an API Platform for app-builders to leverage leaves you vulnerable to competitors who will.
There are thousands of platforms out there: Twitter, Facebook, and Salesforce are obvious ones, but there are also API platforms for banking, news & sport, and almost any domain you can think of.
If you’re among the thousands of organisations building a platform-powered digital ecosystem, you face serious organisation design challenges. Without an explicit organisation design strategy, you will over-commit resources to low priority initiatives and starve your big bets — the key initiatives your success in the market hinges on.
In this article, I’m going to show you why you should be fully cognizant of two fundamental and essential organisation design considerations:
- Where do the bottlenecks occur that prevent you innovating at speed on your key initiatives?
- Balancing the need for stable-product teams with organisational fluidity
If you’re not focused on these two considerations, I am convinced your organisation is not set up to effectively exploit the opportunities you are chasing. You are another organisation whose success is dependant on the competition being in an even more dysfunctional state.
App Teams vs API Teams: Serious Bottleneck Risks
In platform ecosystems, there are two main types of agent: capabilities and experiences. Capabilities are typically APIs exposed via the platform and experiences are applications (web apps, mobile apps, and so on) which consume platform capabilities.
Here’s where problems arise. Capabilities and experiences need to co-evolve. When the business identifies profitable new product opportunities, applications will need to be enhanced to provide the new features, but the platform capabilities will need to be enhanced to provide the necessary data and capabilities.
We have now identified the golden bottleneck. Experience teams wanting to rapidly add new features will be blocked waiting for platform capability teams to implement the required APIs. Political disputes and technical integration dramas are highly probable.
Importantly for your organisation, there are likely to be many competing requests on capability teams from multiple experience teams. You need to ensure that the biggest value initiatives gain the highest priority and suffer the least.
Can App Team/API Team Bottlenecks be Avoided?
How can we avoid this handover between app teams and API teams? This question has existed in some shape or form for at-least the last decade when we started building SOA systems with loosely-coupled backend services and monolithic frontends.
Using Technology: UI Composition and Micro-frontends
One approach that emerged back in the SOA days was UI composition, which has been re-branded to micro-frontends and given a makeover in the microservices-era. With this approach, teams own a full-slice from UI all the way down to database.
UI composition had some success in web apps, but it never truly took off. Even micro-frontends hasn’t become a huge success (although it certainly does work in many situations).
More importantly, I’ve not heard of anyone doing micro-frontends for mobile apps and I think with the current technology it would be too complex. Although, maybe I’m wrong and React Native can solve this?
Perhaps even more pertinent, in app ecosystems there are tens, hundreds, or thousands of apps built consuming the platform APIs. It’s not practical for teams to own a full vertical slice of the UI through all of those applications for many reasons, including:
- Too many technologies for a single team to master
- Teams would need to grow too large
- Applications belong to different business units. Accounting and financing would become challenging
- Teams cannot own UI components for 3rd party applications
Using Scaled Agile Frameworks
Maybe we just have to accept that when we need to coordinate multiple teams working towards shared goals we need to roll out a scaled agile framework like SAFe?
Unfortunately, such frameworks do not remove the bottleneck. They add a lot of process for coordinating teams, attempting to minimising the costs of the bottleneck and keep teams aligned.
There’s a horrible truth about scaled agile frameworks that some people know and others don’t: scaled agile frameworks may be an improvement on where you are now, but they will give you mediocre performance compared to the top engineering organisations.
What I have seen in high performing organisations, is highly-autonomous teams using low-ceremony, low-process, low-bureaucracy organisational fluidity patterns to self-organise around the highest priority work and maintain continuous, high-speed software delivery across multiple teams. For organisations I choose to work with, scaled agile frameworks are never good enough.
Organisational Fluidity Pattern: Strategic Alliance Teams
A strategic alliance is an agreement between multiple parties with shared goals and complementary assets. This is a concept we can apply in organisation design. When a programme of work covers multiple teams, those teams can form a strategic alliance until the goal is satisfied.
A Strategic Alliance Team is an organisation design pattern whereby members of each team in a strategic alliance form a temporary, cross-functional team until their shared goal is achieved.
With all of the skills and knowledge of existing systems in a dedicated team, the team can make rapid strides toward shared goals with few or no dependencies on other teams.
Typically, Strategic Alliance Teams will operate similarly to regular teams, with activities such as daily standups, collective planning sessions, and retrospectives.
The team may also pair on work. With team members from API teams and app teams pairing with each other, optimising for effectiveness over efficiency.
Previously I’ve written more generally about fluidity patterns for teams self-organising around the shape of the work (while still being optimised for continuity) and I highly recommend the book Dynamic Reteaming by Heidi Helfand which is full of fluidity patterns.
Strategic Alliance Team Challenges
There are, though, numerous dangers with this pattern, including:
- Team members may lose alignment with their ‘home’ teams and lack knowledge and shared-ownership of some parts of their services
- Team members’ work may clash with their ‘home’ teams
- Responsibility for supporting production systems may become unclear
- Team members may spend all of their time in transitory teams yet rarely with their ‘home’ team
- It may take a while for the team to become comfortable and effective working together
- If this pattern becomes the default, it can generally reduce the incentive of API teams to improve their responsiveness to app teams
- As the number of teams in the strategic alliance grows, this pattern may be hard to apply effectively
The trade-offs are complex and hard to calculate. And only you can know what is best for your particular business goals and organisational constraints.
Working with External Partner Teams
Can this pattern work when the team building the app is outside of our organisation — a customer building an app on top of our platform?
Potentially, yes it can. It doesn’t make sense to form a team with every customer who wants to build apps for your platform, but for key strategic partnerships where quality of integration and speed to market are important, it should definitely be a consideration.
Pre-conditions for Organisational Fluidity
“Adjust the shape of your organisation to respond to the opportunities in your market.”
I gave the above advice recently during my Sociotechnical Architecture: Aligning Teams and Software for Continuous Delivery talk. Afterwards I received the question “How can we estimate and measure velocity and burn down if teams are fluid?”. My response got quite a laugh from the audience: “I don’t measure velocity”.
Most organisations are trapped with project-mindset behaviours. To command-and-control micro-managers, the idea of having fluid, self-organising teams is not going to work for reasons such as resource utilisation and productivity measurements.
Even within many progressive organisations, there is a mantra that teams should be stable. This concept was actually a correction of the old project mindset where teams and they software they built would have no long-term continuity.
The stable teams principle is based on solid reasoning: with stable teams, people building the software are responsible for its long-term maintenance so are incentivised to do a good job, and the teams work together and form strong relationships. But there’s a key insight that a lot of people miss: stable does not mean static.
So if you want to leverage fluid organisation design for competitive advantage, there are two pre-conditions you must satisfy:
- Unlearn the project mindset. Stop focusing on time, budget, and scope, and start focusing on outcomes instead
- Unlearn the static teams mindset. As the business context evolves, so will the shape of your teams to be best positioned to satisfy market demand better and faster than your competitors
Organisation Fluidity is the Next Frontier
Over the past decade, our industry has matured immensely with respect to how we architect loosely-coupled systems which are owned by product-focused engineering teams continuously delivering value.
To gain advantage, we now need to embrace these challenges at a higher scale — continuously delivering value and driving high-speed innovation for programmes of work that span many teams.
While most people are distracted by scaled agile frameworks — general purpose solutions which will deliver mediocre results at best — I encourage you to focus on organisational fluidity if you want to innovate faster than the competition.
To build market-leading products at industry-leading innovation speed, you’re going to have to continuously optimise and improve the design of your organisation and processes.
Mediocrity or market-leading? It’s your choice.
