You are not alone

Welcome to our blog where we give you practical advice on facilitating change.

Contact us

What is that “agile leadership model” you’re talking about?

In the beginning of the agile journey of a company we worked at, we introduced the Product Owner and Scrum Master roles and found that the setup did not make us better at prioritizing or better-performing. Instead, the result was slower decision processes and confusion.

We concluded that the organizational structure, based on a traditional hierarchy, was holding us back and preventing empowerment of the teams as the Line Managers became bottlenecks for decision.

We decided to do something radical, and we introduced a new agile leadership model that removed the Line Manager role and replaced it with three leadership roles that would focus on products, people and teams, respectively.

  • If you are struggling with decision speed because of unclear mandate for your Product Owners and Scrum Masters, you can experiment with reducing the formal hierarchy.
  • A flatter hierarchial structure divides leadership responsibilities and reduces bottlenecks.
  • Dividing leadership responsibility leaves for more specialization and dedication to the leadership task.
  • The responsibility for ‘people’ is not clearly placed in the Scrum guide, but a solution can be to define a fourth role: an ‘organizational lead’.

Want training, consulting or inspirational talks on this subject?

In the beginning of 2018, the organization we worked in roughly consisted of people in two roles: engineers in all shapes and sizes, who ensured maintenance and development of the infrastructure; and managers on different levels, who – well, did what managers do. They tried to be a little bit everywhere, making technology choices, ensuring allocation of people and resources to projects, talking individual development with their employees, and trying to ensure that the overall work climate was good.

We had only just started our agile transformation the year before, in 2017, and we had now read (some of the) books on Scrum and began to understand that we needed special attention to be paid to the way the teams worked together, including ensuring that they were aligned on what they worked on. To facilitate that attention, we introduced the Scrum Master and the Product Owner roles, as the literature prescribed.

We had implemented the two roles of Scrum Master and Product Owner differently in the different teams: in some teams the Line Manager filled out one of the roles while a team member took the other, in other teams both the roles were filled by team members – or members of other teams who took the role in multiple teams.

The reaction was mild surprise when we during 2018 concluded that the Scrum Masters and Product Owners struggled to introduce agile processes and prioritization in the teams. And don’t misunderstand us here – it was quickly clear to us that it was not the people in the new roles who were coming up short. It was the structure that somehow did not set them up to succeed, and we had not been prepared for that as we thought we had “followed the recipe”.

This post is about our considerations as to why we did not initially succeed in introducing the Scrum roles – and the experiment we implemented primo 2019 to turn the ship around. It is about the agile organizational model we came up with and the thoughts behind it.


As a result of our approach to the agile transformation – it was based on an invitation to find the best way we could and not an implementation of a given framework – we saw many different interpretations of Scrum in our teams in 2018, but there were patterns in what happened, especially with the Scrum roles:

  • Team member in the role – authority is questioned. When team members filled the roles as SM or PO they often struggled with getting the team to back up their direction. SMs could not get teams to lean in on agile events such as daily stand up, planning and retrospective, and the Product Owners found it if not impossible then very difficult to get an overview of the teams’ tasks – and have the team share the priorities. In other words, their authority was questioned: “who are you to tell me what to do – you are not my leader”.
  • Line Manager in the role – not enough focus. When a Line Manager took one of the roles, the issue was not authority – not openly, anyways. Instead, the issue was focus. The team members in the Scrum roles could mostly find the time to attend courses and training and thus had some level of knowledge about the theory of how to execute the new role. The Line Managers were extremely busy and could in many cases not find time – neither for upskilling or for filling out the role – as they were still expected to do all their other tasks.
  • Line Manager in one role and a team member in the other. A third set of unintended consequences arose when there was a power asymmetry between the two roles, where for instance the Line Manager acted as PO and a team member as SM. In those cases, it was very hard for the SM to act as the “protector of the team” towards the PO.

We concluded that we had not empowered the people in the roles in the right way to ensure that the team was empowered. The lack of empowerment was not due to conscious ill will but rather the result of introducing a new, flat structure in an organization that had 80+ years of experience with running a smooth machine with formal (traditional) organizational structures and according to traditional thinker-doer hierarchy.

[A side note here: the machine was not smooth due to “thinker-doer” setup. As we will elaborate on in a future blog post on how we developed our Product Catalogue, most managers had did not have a high degree of insight into the projects their team members were involved in or the technologies the very specialized engineers worked on. Managers were perhaps into details of 20 % of the ongoing work and the rest was prioritized and handled by the employees. Thus, we had a huge group of “thinkers” – and very little alignment on where to go.]

The formal hierarchy and organization of the company had for many years dictated that it was the direct manager (the Line Manager) to whom the engineers reported who was ultimately responsible for the performance of the individual, of the team, and of the major deliveries themselves. Whatever went well, could be shared as a success but whatever went wrong was on the Line Manager. This naturally placed decision authority with the Line Manager.

So ultimately, we could “play the delegation game” as much as we liked, call out new roles such as Scrum Masters and Product Owners as much as we liked, but according to the organizational structure, the responsibility was ultimately with one person. The Scrum Masters and Product Owners would – if they were team members – be straw men who would always need to ask his/her superior before making a decision.

And furthermore, we could call out the PO role for a Line Manager, but he/she was still expected to continue handling all of the many tasks that he/she had before and a miracle would have to occur should he/she be able to dedicate him/herself to the new role!


There were two significant impacts of the setup. Firstly, when the role of PO or SM was filled by a team member they did not have the mandate to make decisions alone. Thus, decisions were being slowed down as there was now an extra layer between the Line Manager and the executing members of the team. 

Secondly, when the role of PO or SM was filled by a Line Manager, the limited focus on living the role meant that it became inefficient: again decisions were slowed down.

In other words, the setup gave us the opposite of what we needed and wanted, and we asked ourselves if “agile” was simply not for organizations like ours.


We sought inspiration from many sources – agile frameworks and other companies that were further on the agile journey – but we could not find anyone who addressed our problem in a way that inspired us to what we could do about it. We decided to make an experiment on our own. And it all revolved around pushing mandate as close to the team as possible by empowering the POs and SMs by removing some of the hierarchy: we wanted to formally divide the responsibility that traditionally had been with one person, the Line Manager, on more persons.

The principles

After deliberating what to do, the CTO (head of the department) was clear on that the new agile leadership model should cater for three purposes: increase the quality of leadership, increase the quantity of leadership, and increase the motivation for leading. 

Quality. To become really good at what you do, you need to focus on practicing it. A traditional Line Manager has to be good at

  • “People”. Create a pipeline of candidates for hiring, be great at spotting and hiring the talent, ensure well-being with employees, and understand which competencies the employees need to develop – and develop them.
  • “Team”. Ensure the team works well together, understand and utilize group dynamics, facilitate collaboration, and help the team remove the impediments they are facing.
  • “Product”. Understand the need of the customers and markets, understand the development in technologies, architecture and principles, negotiate with vendors and providers, prioritize on behalf of the team and set a clear vision for the product.

Our hypothesis was that if we separated the responsibilities of the traditional Line Manager, the leaders would have more opportunities to get deep into the subject matter and become more competent, i.e. leadership would be better.

Quantity. We acknowledged that our Line Managers were on a tight schedule and that as there were only 24 hours in a day – and as only 8 of them was supposed to be spent on work – they had limited capacity. Our hypothesis was that if we assigned leaders to handle either technology (products) or teams or people, we would be able to provide the amount of leadership and attention that is actually expected by both top management and by employees.

Motivation. Our experience was that leaders have a preference for working with either technology, people or processes – or a combination of those, but never all of them equally. Our hypothesis was the if we divided the leadership responsibility and cast our POs and SMs right, we would allow leaders to be occupied with the elements of leadership that interested them the most. And following from this, we believed their job satisfaction would increase.

Example of our communication of “the problem” as we rolled out the new leadership model.

The experiment

Based on the principles, we took the radical decision of eliminating the role of the Line Manager. We got buy-in from the brave HR department who let us do an experiment that was counter to the traditional way of organizing in the company, and the Product Owners and the Scrum Masters (we called them “Squad Leads”) would now be officially responsible for products and teams.

The only issue left was that we still needed someone to take care of the “people”-side. And we did not want to put that into one of the existing roles (PO or SM) as this would jeopardize the effect of these roles.

Instead, we created a third role who would handle this as well as the overall organizational design of the organization: the Organizational Lead (OL). The final element of the model was to highlight how the team played a vital role in leading themselves, and they were called out as the fourth role; the Squad, with separate and unique responsibilities.

Example of how we visualized the new leadership model with four roles.

We ended with six chapters, one per Organizational Lead who now had on average 25 direct references. The chapters were built around shared tasks, technologies or industry areas, and the assumption was that there would be economies of scale for the OL leading the chapter as the competency development need, the market for finding new talent etc. in the chapter would be similar. The employees were then spread across the 15 teams and the intention was to keep teams as stable as possible but to enable that employees could flow without losing their “home” – their Organizational Lead.

Overview of chapters, teams and number of leaders in the new organization as it looked primo 2019.

We ended up with more than double the number of “leaders” from the setup we came from, which was initially something we questioned. On the other hand, we had pointed to the fact that we needed to be better at leading and to do this we believed we needed more and more specialized people to facilitate that outcome. 


While the overall objectives had been to increase speed of decisions, motivation for leaders, quantity and quality of leadership, we made a point to make sure that the value proposition for the teams and the employees were clear: those were professionalization, clarity and stability.

Example of the value proposition we made to the employees and why they should embrace the new model.

How did it go? It worked, is the short answer. But for a long time, the improvements were not visible to us. Issues with understanding “why are we doing this”, uncertainty and overload on the new leaders, and lack of processes for coordinating dependencies overshadowed the positive effects.

Today, however, we believe the conclusion is positive:

  • Speed. The speed of decisions is much faster than it was before the organizational change. With few dependencies Organizational Leads hire and introduce new learning paths, Product Owners decide directions and priorities in much greater alignment with the reality as felt by the teams, and Squad Leads facilitate their teams. What we haven’t been able to solve are dependencies that go beyond our department and involve, for instance, HR (how many positions can we get) and top level management (where can we spend money and what is the overall direction).
  • Motivation. The motivation in the leadership team has gone up since introducing the model, and a united leadership team are happy with the increased focus. We did have a really significant dive in motivation after introducing the model in 2019, which we spend on finding our feet, but today, the model is accepted and overall the leaders enjoy being able to specialize and focus while the teams are seeing the advantages of being able to draw on different competencies. What we haven’t solved is the question of leader career paths, the intense workload on leaders – especially those with multiple teams, clarification of expectations to the role, and how to coordinate around a team, product or person as more leaders are involved.
  • Quantity. The teams experience that leaders are present. The SLs and POs meet at least once a day with teams, and they are in many of the meetings with stakeholders and vendors, to a much higher degree than before where the leader was a distant figure. Especially the OLs, though, had issues as the amount of direct references combined with the responsibility to define the overall organizational layout was a stretch.
  • Quality. The engineers are expressing the value of having a non-technical but socially and psychologically skilled OL to spare with on non-technical issues such as collaboration difficulties or personal issues, and the OLs have established a well-oiled Hiring Squad, have raised the professional bar on how to ensure a hiring pipeline as well as screening process. The Squad Leads are educated in agile practices and actively help teams remove impediments – on a daily basis, and the Product Owners are working with value measures and are learning to say “no”. We didn’t manage to install leadership learning programs for all roles and all individuals, however, so some of the leaders have been left to their own devices to ensure that they built the necessary competencies.
  • Clarity. The team members now understand which leader to approach with which issues as well as what to expect from the different roles.
  • Stability. We have managed to keep chapters and teams relatively stable as opposed to before where there was a new major organizational change every year – now changes happen when they need to.

Curious to learn more?

Want training, inspirational talks of consulting on the topic?

3 Responses

  1. Cecily Au says:

    Kudos to all of you! Those 3 roles make a lot of sense. It must’ve taken a lot of courage and pursuasion to get the green light on this.

    Have you measured in terms of product outcome how this experiment is working? For example, incidence rate, recovery time in infrastructure problems.

    Also, I’m very curious about initiatives that go beyond the department. I assume engineers would be “allocated” to projects in a traditional manner where they would work without their SL or PO or OL on a daily basis.

    • Rasmus Lund-Jensen says:

      Hi Cecily! Congratulations on being the first to comment on our small blog here!
      We don’t have direct measures currently. We would love to have it, so that is something we are looking into. More on that in a future blog post.
      What we do have measures on are our motivation and satisfaction. It took a dive initially but has since reversed and is now higher than before we started this.
      We do have plenty of indications that we have increased our capacity without increasing the number of people. Some of those indications are increased focus on reduction of tech debt, increase in strategic investments and ability to adjust to and exploit rapid changes – e.g. covid-19 – on both product and people side.

      We don’t have individuals allocated to projects. We used to. This change in leadership approach was part of a bigger change from a project to product oriented delivery model. We can elaborate this in a future blog post, but the short version is that when there is something big we want to achieve, a new initiative, we refine and split the initiative to match our product catalogue (also a new thing). This way, we move the work to the people and not the other way around. This was important for us, because stable teams is a huge help when trying to improve over time. It also helps the organization to be more resilient to changes. Previously, if a new project was needed and thus a new project team needed to be created, those people would come from other projects which would then be impacted. By moving the work to teams instead, we reduce the blast radius of changes => we are more likely to adjust to changing circumstances => we become more agile.

      I hope the answer was useful. We will try to describe more of this in future blog posts, but feel free to ask more questions in the meantime.

  2. Zoltán Csaba says:

    Thank you for this valuable post, kudos to You. It is so brave to share such details of Your transformation. I am sure that your courage will pay off!

Leave a Reply

Your email address will not be published. Required fields are marked *