Our Journey to an Agile Structure

Compared to other companies, we invest a lot of time in finding the best talents. And yet, despite the strong growth of the team, the extremely high pace of updates of our software declined. There were more and more projects that depended on cross-team collaboration.

Our Advisory Board Member Niels Doerje and I were thinking about how to solve the problem best. We realized that the obstacles lay in the rigid organizational structure at OnPage.org. After all, with the growth, we had initially set ourselves on a traditional divisional structure. In our search, we came across a publication by Spotify, which describes in detail how an agile organizational structure works.

Convinced of the benefits, we decided to change our divisional structure radically and to transform OnPage.org into an agile organization with so-called "squads" and "chapters".

What are Squads and Chapters?

Squads are mini start-ups. They usually physically sit together as a team and have all the skills and tools they need to develop their products. Their common goal is to develop the best product on the market.

Chapters are the technical home base of the agile structure. Within a chapter, employees share their professional knowledge.

How did the introduction go?

We first discussed how the how the organizational structure could look for us. Then we took all our employees along with a paper that was specially designed for OnPage.org and an information event on the new agile structure and the resulting changes.

I am happy to share our internal document with you:

What were the reactions?

To quote Top Manager Ihno Schneevoigt: "All change creates fear. And the best way to combat fear is by improving the knowledge." We experienced it quite similarly at OnPage.org. Many employees were initially skeptical about the new organizational structure. However, with transparency and communication, we have been able to turn initial concerns into new ideas. Furthermore, everybody was quick to realize that the new organizational structure is not only incredibly supportive of cross-team collaboration, makes processes faster, and less complicated, but also eliminates the emergence of comfort zones and challenges everybody every day to take the initiative.

What were the difficulties?

The biggest issue surely was that many people could not imagine the theory in practice. Through the direct introduction, everyone quickly realized how the whole thing works and what benefits it entails.

Due to our team size, some people also had to fill two positions temporarily: overnight they became both Product Owner and Chapter Lead. Since both positions have entirely different requirements and one role alone already comprises an enormous responsibility spectrum, it was not an easy balancing act. We are currently taking this double burden off our employees’ shoulders by looking for additional "Chapter Leads" or "Product Owners" for the respective positions.

What struck us during all this: Agile structures change the mindset regarding leadership culture. Here, we have all learned a lot, both through the feedback of our employees and through the exchange with other executives in agile organizations, for example at a meeting with Florian Gschwandtner, the co-founder and CEO of Runtastic. While in a classic divisional structure as a leader, you define the majority of the tasks, in an agile organization it is more important to motivate your team to implement projects and ideas themselves by projecting a clear vision and direction.

What did we differently?

True to the motto "Everybody said: That's impossible. Then somebody came along who didn't know that and did it anyway" there is a something special to our company: We have established the structure in every team. In all of the companies we know that have established an agile organization, the structures are always limited to certain divisions of the company, while other organizational units are still organized as a traditional department. At OnPage.org, we have built Squads for Acquisition (formerly Marketing) and Operations (formerly Administration, Finance, and HR). As a result, even in teams that do not build the software themselves, there are stand-ups, roadmaps, and team members of different chapters, such as engineers who develop tools for internal processes in the Operations Squad.

Figure 1: Roadmap planning at OnPage.org

What has changed?

The biggest change, which was also the springboard of our decision to switch to this structure, is the re-established speed of all further developments. Furthermore, we are back to communicating much more and more efficiently. Also, the startup mentality, in other words being able to introduce ideas at any time and to test with an MVP quickly, is now more noticeable again.

Another nice side effect of the new structure was that we have been able to strengthen one of our most important values - the- "entrepreneurial thinking." We try to be a company especially for people who want to create a startup by themselves or those who were not successful building their startup on their own.

When does the introduction make sense and when doesn’t it?

For us, the introduction of the agile organization came at the earliest, but also the latest possible time.

In the first years after founding our company, we knew the to-dos and priorities exactly. With a small, agile team, we were moving at a breakneck pace. With a growing team, the tasks of our founders and managers change - from operational to strategic. The sooner you have a structure in place that offsets this and enables a strong team to make things even better, the easier it becomes for a founder to focus on the necessary strategic tasks. With an agile structure, everyone can concentrate better on their projects without losing the exchange. This creates a lot of trusts - both in the team as well as in us founders.

The traditional divisional structure quickly creates small principalities. Everyone wants to have the most beautiful, greatest, and biggest team. The focus, however, shifts from the product to the own department. Once this happens, it is not a trivial matter to break up these structures and habits again.

After four years, this was not a simple step, which required a lot of trust and reflection on all sides. With an even bigger team, this move would certainly have been much more challenging.

tl;dr

We have thought a lot about whether it would make sense to change the organizational structure to an agile company structure and had great respect for this radical change. In particular, since our business continued to develop beautifully and just the further developments went too slowly. This, however, made us concerned about the future, because we have great aspirations in terms of speed and innovation.

Of course, we are only at the beginning with the new organizational structure and cannot say how well it is going to work in the long run yet. But when we are looking back at the past six months and talk with our team, we are 100% convinced that it was the right move, as communication and the number of updates has picked up at an enormous rate.

This structure is now lived by OnPage.org throughout the entire team and further improved in line with the motto "1% done, 99% to go ;-)"

Our structure lives from the steady emergence of new squads and chapters, to successfully churn out new ideas in small and agile high-performance teams. We are therefore always actively looking for people who want to take on a steep learning curve in our lively agile organism.

I would love to hear your experiences and opinions on organizational structures. If you have any questions, of course, I'd be happy to answer those as well. Just use the commentary section under this article.