We’re the Business Excellence team at Zalando Technology. Our job involves enabling the effective management of business processes among all business units, including modeling, 24/7 monitoring, and continuous improvement of the organization's business processes. Thereby, we provide a safety net to Zalando's operations and drive business excellence.
In this post, we’ll share the story of how we built a self-organized team – a process that was filled with ups and downs.
Our journey to becoming truly self-organized began with a far-reaching change in the culture of Zalando Technology, called Radical Agility. Radical Agility breaks up traditional organizational structures and encourages teams to work autonomously towards a common purpose. But what happens, when a well attuned working environment is changed within a short amount of time? What happens if established teams and departments are disbanded? What if team leads who give a team direction no longer exist?
Launching a New Team
In the traditional organization, team leads are direct supervisors of a team's members and responsible for all operational matters. Radical Agility made this role obsolete and teams needed to find their own direction. In our case, though we still had a “Delivery Lead” who supported several teams, we were now missing a direct team lead. We had over 10 people with different backgrounds, that had to reach the same level of understanding and become productive, rapidly. With the introduction of Radical Agility, everyone on our team was looking forward to a new and more effective working culture, but also concerned about how this could be achieved. At that point, we had a vague understanding of what the team should deliver but not how that would be achieved in autonomy. We set out to define a purpose and a vision for our team.
Understanding the purpose of what you do, exercising autonomy in how you do it, and achieving mastery in an individual’s skills are the fundamental principles of Radical Agility. With these in mind, we set out to discuss which challenges the new team should tackle, what tasks we needed to be working on, and how we should prioritize our work. Setting up meeting after meeting to answer these questions, we hit our first brick wall. Everybody had their own opinion on each topic and everybody wanted their voice to be counted equally. In a team of over ten people, this situation led to seemingly endless discussions. Having meetings with the whole team for two hours straight without a tangible outcome was no fun, and we were constantly looking for ways to get everybody in alignment.
Our first approach to solve this on this problem was the building of workgroups. As an example - we had a group of people working on analysis topics and another group working on consulting tasks. We also had workgroups to establish ways to communicate within the team and “advertise” the team's accountabilities within Zalando Technology. With the decomposition of the whole team into smaller groups, many topics could already be addressed more efficiently in meetings. Workgroups also assumed responsibility for certain tasks, for example, the analysis group was responsible for all analytical tasks. However, responsibilities within the group were occasionally not clear, as no individual within a workgroup was claiming 100% responsibility for the group's tasks. Moreover, some tasks affected several workgroups: who exactly is working on which task and who should be responsible for the outcome? We felt that a more sophisticated model to assign responsibilities was needed.
Therefore, we refined responsibilities of workgroups to responsibilities of roles. A role embraces several responsibilities, services it provides, and domains it controls. For instance, we established a role BPM coach that owned control over all coaching material (slides, process models, tools.) Every team member assumed a number of roles and inherited the roles' responsibilities, respectively. For every role, we ensured that the person assuming it was fitted with the required skills.
So far, we had progressed quite successfully in the adoption of the principles of Radical Agility. Based on our achievements, our Delivery Lead supported us in sharpening the team's self-organization even further and organized a workshop with professional agile coaches. In this workshop, we adopted various practices of Holacracy – a model for the agile governance of an organization – into a custom leadership model. We called this model Distributed Leadership Framework, as it distributes leadership on every individual of a team. The frameworks builds on the following blocks:
- Consent over consensus The term "consensus" refers to the general agreement on a topic. Consensus can make meetings inefficient if the aim is to have everybody agree on the same decision. Often individuals see roadblocks that might occur or tend to disagree for reasons that might not even affect them directly. In contrast, "consent" means the permission for something to happen. The latter can be achieved, even if not every individual agrees, as long as nobody can present a convincing objection that affects one of their roles. This turned the democratic model around into a "why the hell not?" mindset. If a something is safe enough to try, it shall be pursued.
- Virtual teams All of our work is driven by roles. Regular tasks that are required to keep the ship running are covered by the responsibilities of a role. Moreover, projects are carried out in virtual teams, where one individual is the project manager. Before a project is started, a project agreement states required skills and resources. Mapping these on roles of our team, we come up with virtual teams that consist exactly of the experts needed to successfully complete the project, and no one else. These virtual teams are created when they are needed and they are disbanded when the project is over.
- Tension based meetings By design, we abandoned meetings on special topics, such as projects, where every team member needed to participate. Instead, such meetings are restricted to the virtual teams involved in a project. Furthermore, we have established two generic meetings: An operational sync meeting takes place weekly and we report on every project’s progress and planned achievements. Additionally, we process tensions that are brought up before or during the meeting. A tension can be everything that impedes an individual or the team, and needs to be resolved quickly- such as gaining access to an information system. All topics that address the team's constitution – the definition of roles and the establishment of work rules – is processed in a governance meeting that takes place on demand. Again, all decisions made in this meeting are based on the principle of consent.
We learnt that the transition from a team with a team lead to a self-organized team is demanding. Above all, it requires every individual to develop an open, trustful, and responsible mindset towards their peers.
One of the key success factors for distributed leadership is the absence of shared responsibilities. By design, exactly one person is responsible for a project, for a task, or for a domain of control. It is necessary to ensure that another team member can jump in, if the responsible is absent.
Dependencies and problems are solved based on tensions. Unless there is an imminent problem or danger, it might not be necessary to tackle something just because it might be an issue in the future.
As of now, we are confident that we have reached a mature level of self-organization. We are aware nevertheless, that there exists constant potential for improvement. Hence, we organize regular retrospectives – a meeting adapted from agile software development – to discuss ways to advance.
And finally - every team, not only self-organized teams, needs a purpose that gives the team's work meaning and drive. It is the call to action for every individual. You can learn more about Radical Agility at Zalando Technology here.