How (and why) you should remove hierarchy from your dev team
This article was originally published on .cult by Dirk Ziegener. .cult is a media platform for untold developer stories, where developers can read content around the softer side of development and watch documentaries about the tech they love. You can read this original piece here.
When you are looking for a job in tech, everything is about teamwork, agile methods, flat hierarchies and beer pong – at least that’s what every company claims for itself. I had to learn that there are companies that take this really seriously. Okay, maybe not the beer pong – but certainly everything else! The company I am talking about is Studitemps, a temping agency for students based in Cologne, Germany. We help students get a job while they are studying in University, and do this with a strong presence in all major university towns in Germany and, of course, with a robust digital platform facilitating the process behind the scenes.
In February 2018 I joined Studitemps as Head of Development. Coming from years in the world of marketing agencies and high-pressure development projects, I was super excited to get the chance to work with product teams again. I took over the responsibility for three development teams which were working autonomously on different parts of our product.
Our main mission was to modernize the software platform that runs our entire business from the ground up. Naturally we faced many technical challenges when we split our software monolith into microservices, but I’d rather share about the way our department is organized and what it means to be the manager of self-organized teams with as little hierarchy as possible.
What does a dev world (nearly) without hierarchies look like?
To be honest, we still have some sort of hierarchy. It’s very flat and has only one level. There are team members and there is the Head of Development, with nobody in between.
The Head of Development is officially responsible for the professional and disciplinary management of all members of the Dev Teams, the Data Engineers and Scrum Masters of the department. So, I am in charge of the long-term technical strategy, the stability and performance as well as the operation of all our applications. I am responsible for the growth of the department, the staffing and recruiting process, our employer brand, sponsoring, event management and of course the entire software development and delivery process. I talk to more than 35 direct reports in seven teams in regular one-on-ones. And if shit hits the fan, I am the single throat to choke. The only way to handle this is to trust your people and hand over the responsibility to them. This is why our teams are self-organized and take care of many of the things listed above.
When I started at Studitemps, this wasn’t so obvious to me. The department I took over was already self-organized. So it was on me to learn how to handle this. It took me some time to understand how to approach things and I am still learning and adjusting every day. This starts with simple things like holiday planning. In my old job I was used to approving every single holiday request to make sure that not everybody leaves for holidays at the same time so that the teams stay productive. It felt uncomfortable when this wasn’t under my control anymore. All I could do was rely on the teams, but it didn’t take long to understand that I could relax and trust them. They handled this just as responsibly as I would have done it.
So, then, what exactly does self-organization mean?
What is self-organization?
In the context of an organization, self-organization means the delegation of leadership into the teams. The team members take over the tasks and responsibilities of the manager. They manage themselves, organize their working day together, take over responsibility and ownership and act with a lot of decision-making freedom.
By doing that, the role of the manager changes from being the one person who tells everyone else what to do – or even worse: how to do it – to the person who provides guidance and support, so that the teams know in which direction to head. You can compare self-organized teams with a football team. Your players need to understand the purpose of the game (shoot the ball into this goal) as well as the rules (don’t break other player’s bones) and the boundaries of the playing ground (the ball needs to stay within the touchlines). Within this system, with its given boundaries, they can move freely and make their own decisions to reach their goal.
Obviously it’s not possible to simply hand over all possible tasks and responsibilities of a manager to the teams. The transition from a classic top-down organization to self-organized teams is a continuous process and you have to start slowly and delegate more and more decisions to your teams over time.
What does self-organization look like at Studitemps?
Our teams are already quite mature regarding their level of responsibility and ownership. Each team develops, maintains and owns one or more software services and applications from our overall product platform. They decide who becomes a member of the team and organize the recruiting process, conduct the job interviews and host a get-to-know-you day with each candidate who made it that far.
Each team decides which technology to use in order to solve theirs or their user’s specific problem. We have teams writing their applications in Elixir and Phoenix while others use Ruby with Hanami or Rails, Flutter or React, Gatsby or Python. Whatever tool or platform is needed, the team can decide what to use.
If the teams realize they have to improve their skills in a certain technology or method, they decide which training or conference they need to visit. The team makes sure that they constantly deliver software as well as support and maintain their apps. Within this agreement they manage their working time, their remote working rules or holiday schedule completely on their own. No manager ever needs to agree to a leave request anymore. The team organizes its work on its own.
Speaking of rules and agreements: Like in football or any other sports, it’s crucial that everybody understands and agrees to the common rules. You want to make sure that nobody forgets them or simply doesn’t know about them. So you should write them down and make them transparent. A very nice tool to negotiate the levels of delegation for certain decisions and to give them visibility is Jurgen Appelo’s wonderful Delegation Board. When I joined the company, it was one of my first challenges to find out and understand what already was delegated to the teams and what was still my responsibility. It’s quite easy to put your foot in it when you don’t know about these rules. So always write them down and make them visible, for example, by creating a Delegation Board.
So while we have already delegated many decisions into the teams, there are still a lot of topics we haven’t tackled yet. So far, these responsibilities remain under control of the manager. The biggest example here would be salaries. As much as management would love to delegate the responsibility for the individual salaries of each team member into the team itself, this would mean a very big change for everyone involved; as much for the organization as for the team members themselves.
Suddenly you – as a team – would have to find ways to measure the performance of your teammates and negotiate a fair salary based on skills, competence or experience. We have to ask ourselves: does every team member want to have that much power and responsibility? And could this even cause harm to the health and culture of the team?
What should teams control?
Allowing teams to make these decisions would solve so many current problems. The model of having a single manager who talks with eve
ry single team member about performance, personal development and salary does not scale very well. At a certain size you either have to add more managers and thus increase the levels of hierarchy – or delegate it down into the teams.
To find out if and under which circumstances this could work, we are running an experiment with self-organized salaries in our internal IT-department. The results so far are very promising! An interesting effect of teams taking over more responsibility is that they get more independent and confident over time. If you have multiple teams that need to cooperate a lot, this could result in a lack of communication and finally, lesser cooperation between these teams. This can worsen if the teams decide for completely different working times, remote work agreements or Scrum sprint rhythms that are not synchronized. Events that improve collaboration like Community of Practices, regular Scrum of Scrum meetings or department-wide retrospectives with all teams participating can help to counter this effect.
The future of management
Does this mean that managers become obsolete in the near future? Maybe! But not too soon. For the manager this world without hierarchies obviously means a big change, but there is still the need for leadership in this world – not so much as a position of power inside a hierarchical system as it used to be, but as a service to the employees to support them in their work. Managers can provide goals and guidance to the teams, communicate the values and visions of the company to them, remove impediments and moderate processes. Maybe, one day, the manager will delegate these leadership tasks to a team itself. And then the world will really be without hierarchies.
Let’s block ads! (Why?)
, The Next Web reports