The recipe didn't work
At the time, the department 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.
As a part of the agile transformation, we introduced the Scrum Master and the Product Owner roles, as the literature prescribed. We implemented the roles 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.
We were surprise when we saw that the Scrum Masters and Product Owners struggled to introduce agile processes and prioritization in the teams – we had done just as the literature prescribed, and we thought we had “followed the recipe”.
Authority was questioned. When a team member filled the role 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”.
The role did not get enough focus. Line Manager in the SM/PO 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.
Power asymmetry. 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.
Traditional management thinking got in our way
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.
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 and culture, 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. Thus,
decisions were being slowed down as there was now an extra layer between the
Line Manager and the executing members of the team.
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! 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 did not give up, though. 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 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 three things: People, Team and Product.
Leading people, that is, creating a pipeline of candidates for hiring, being great at spotting and hiring the talent, ensuring well-being with employees, and understanding which competencies the employees need to develop – and develop them; leading the team, that is, ensuring that the team worked well together, understanding and utilizing group dynamics, facilitating collaboration, and helping the team remove the impediments they are facing, and leading the product, that is, understanding the need of the customers and markets, understanding the development in technologies, architecture and principles, negotiating with vendors and providers, prioritizing on behalf of the team and setting 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.
The agile leadership model
To achieve the three purposes, 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.
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 15 product 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.
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.
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.