How Lean and Structured Teams Amplify Productivity
Whenever we talk about adopting a framework or a change management process, it is important to talk about the symptoms within an organisation.
In her talk, How a Lean and Structured Team Topology Amplifies Productivity, Rutuja Joshi focused on the change management process, and how it impacts productivity in organisations.
Symptoms of a non-lean, chaotic organisation – what are we trying to solve?
Rutuja Joshi, a principal transformation lead and coach, has been working in the HR, OKRs and team topologies space for more than a decade. Her approach is to look at the symptoms first.
“Whenever we are talking about adopting a framework, or the change management process, we should always start with symptoms of the organisation.”
A non-lean, chaotic organisation will always exhibit some signs of where things are going wrong.
A list of symptoms could include:
Teams have no autonomy
Team have no mastery
Teams have no purpose and no vision – no focus for teams and individuals
Team boundary
Hands-off and waiting time
Functional silos
Dependencies and entanglement of goals – impede the value of delivery
Huge cognitive load on Team
Redundant system/slow system
Painful re-org every few years
Unhappy people
Burn out
Looking at these symptoms, it is clear that teams don’t have autonomy, or ownership of topics. This can lead to a lot of dependencies and interactions between multiple teams; this can prove particularly problematic when a product or system is being built and there are multiple teams working together to build that product. If these teams do not have autonomy or ownership, context switching will take over whichever responsibilities come their way.
This can lead to no purpose and resolution or vision. The teams won’t understand the purpose of their team, what their goals are and what they stand for.
In situations like this where no team boundaries exist and there are team dependencies, there is a huge risk of the system slowing down and a lot of work in progress.
In order to manage this, team leads will have to carry out a lot of dependency mapping between the teams, to get a true picture of how the system will work.
Another thing to look out for is functional silos. If you have an organisation where you do not have end-to-end feature teams, these kinds of organisations will tend to have several ops departments, operating in functional silos. With these in place, it can slow down the entire system and impact multiple operations within the organisation.
Team Topologies: how can you resolve this?
Once it is evident that the organisation is showing chaos and lack of agility, the next step is to consider how to solve these symptoms and become a cleaner and leaner organisation.
Team topologies could be the answer.
Following the Team Topologies approach can help solve some of the problems, but not give a 100% of the solution. Alongside team topologies, it is also useful to look at frameworks – process framework and people frameworks which can give a holistic solution.
The impact of the symptoms can be huge on the organisation’s KPIs. This could present as cycle times fluctuating, deployment frequency declining, burn down percentages lowering and impacting predicted ship dates. These symptoms can cause a lot of turbulence when it comes to the metrics that an organisation is tracking.
If you have symptoms of a non-lean organisation, this is the cause and effect your organisation will see.
This can sometimes lead to a mish mash of strategies and frameworks – from OKRs to dependency mapping to setting some goals or adopting Scrum, but the key here is not to cause a big splash. Try and explore different frameworks that can effectively help in minimising the impact.
The symptoms of a non-lean organisation aren’t just process oriented, they are much more team centric. Which is where Team Topologies as a concept comes in.
Team Topologies
Team topology is based on the concepts outlined in the book “Team Topologies” by Manuel Pais and Matthew Skelton.
It is a combination of:
4 Fundamental Team Types
3 Core Interactions
Team Cognitive Load
Sensing Organisation
Evolution
Conway’s Law
Conway’s Law
“Any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure” – Melvin E. Conway
This can feel a bit complicated at first reading to try and understand what it is that the concept is trying to imply.
This can be broken down into layers:
In the first layer, in an organisation where there are small distributed teams, there will be more autonomous teams as they will have clearer boundaries. These teams work independently and are likely to create software architecture
In the second layer, if there are large, collated teams and are dependent on each other, they are more likely to create a monolithic architecture.
Based on this, Conway’s Law shows that the structure of an organisation’s design, or the architecture of a system, will reflect the number of communications a team has whilst they are producing the systems. The more the communication needed, the more complex the architecture. The more complex the architecture, the less chances of being able to scale. It can become chaotic and complex.
In order for an organisation to be lean, the communication needs to be lean as well.
Cognitive Load
Cognitive load is a scientific theory, based on the specific brain capacity an individual or team will have towards work.
There are three types of cognitive load:
Intrinsic Cognitive Load: What one knows about their domain to excel and recognising information
Extraneous Cognitive Load: This covers learning of an ecosystem or mechanics
Germane Cognitive Load: The way one will use memory capacity and personal intelligence to solve various problems
Cognitive load needs to be sustainable. It shouldn’t grow at a scale where it causes burnout in individuals and teams, and in order to support it, there needs to be coaching, upskilling and mentoring.
For example, if you're looking at the cognitive load within a team, and realise that there is 10% Intrinsic Cognitive Load, 0% Germane Cognitive Load and 80% Extraneous Cognitive Load, the team has more chances of burning out. There needs to be stability between the different cognitive loads.
Team Types
The Team Topologies concept highlights that any team which is a part of an organisation, should either be labelled as:
Stream-aligned Teams – These teams are feature teams that focus on the value stream map of the customers’ journey and deliver features and value towards this customer journey. These teams are fast-paced, with clear ownership and constantly delivering value.
Enabling Teams – These teams work in research and proof of concept; these teams have to stay ahead of the learning curve and their aim is to upskill the Stream-aligned teams with information and concepts.
Complicated Subsystem Teams – These teams are specialist teams that focus on particular topics and own the specialist components; they own pure components.
Platform Teams – These teams provide platforms and tools to stream-aligned teams to help them deliver on their features and values focus.
Team Interaction Modes
‘X as a service’ – There are strong delivery dependencies in this mode. The different category of teams will offer a tool or a platform as a service, which supports the other team.
Facilitating – This particularly applies to Enabling teams that facilitate and support other teams in upskilling their knowledge, from their own research and proof of concepts.
Collaborating – A two-way communication mode, teams interact and collaborate with each other to produce and consume a service.
Whenever teams interact with each other, it is important to ensure that there isn’t too much interaction to avoid dependencies. Organisations need to define teams and define the interactions that these teams will have and contribute positively towards the symptoms that the organisation would have been presenting in a chaotic and non-lean manner.
Inverse Conway Manoeuvre
The Inverse Conway Manoeuvre recommends evolving your team and organisational structure to promote your desired architecture. This is the opposite to amending the architecture and then anticipating results; your team needs to evolve around the architecture to have a leaner culture.
It is important to note that as easy as it may look, this is a change management process. The organisation cannot come to a standstill or pause, business has to run as usual.
Rutuja recommends baby steps and looking at what areas are least impacted and what areas are most affected and picking areas one by one to tackle the bigger picture.
Team Topologies in real life
Customer Value, Customer Centricity, Product Success are some of the ultimate goals of an organisation.
And to achieve them one of the focus areas for an organisation is to ensure that the teams are set up and interacting efficiently to deliver customer value with speed.
When you start the Team Topologies process, it is important to map the team topology for each team.
The process works in three stages:
Map the current state of your organisation – where do you stand right now?
Analyse the results and define action points – where are you heading?
Implement the actions – what will you change?
In order for the process, all teams need to be onboarded on the concepts of team topologies, including all the definitions and concept applications. These concepts need to be consistent and with the same definitions so that everyone is speaking the same language.
Once this has been outlined, start drawing out each team’s topology. Whether the team is stream-aligned, enabling or collaborative – note down the interactions and the services produced and consumed, so that there is clarity on where ownerships lie and where they sit against the Value Stream.
It is important to note that at this stage, organisations will have teamsf wearing multiple hats and without clear boundaries. In order to move to a lean structure, there need to be clear boundaries as well as assignment of resources, coaching and mentoring to support the teams in taking ownership of their individual categories.
Rutuja compares these chaotic team types to a bowl of spaghetti or like a spider web.
This can feel overwhelming and for managers can feel like a huge task to untangle the web of dependencies and interactions. Here, it is important to define individual team topologies and understand how individual teams interact amongst themselves, as well as their interaction with another team.
Organisations need to reflect and understand what their dream setup looks like. This is dependent on the individual organisation’s goals and aims and then look at where the organisation wants to evolve its team towards.
Team Topologies alone is not enough. It doesn’t work as a silver bullet.
Team Topologies is one of those concepts that where the more structured, the more well-coordinated and more clear teams get on their ownership, the organisation becomes more productive.
A healthy organisational culture and mindset is a must in making the change management process easier.
The leadership team needs to set clear vision and goals to support teams with autonomy, mastery and purpose and drive excellence.