Celebrating mistakes: learning from our holacratic experience
Holacracy is an amazing tool that enables companies to work in a more agile, adaptive and responsive manner. Boldare started transitioning to a holacracy in 2018 and by now has grown in every possible direction. But what we enjoy here at Boldare today wouldn’t be possible without a few hard lessons learned along the way. We asked our most experienced leaders to share their (sometimes quite painful!) learning - enjoy reading!
Table of contents
Where did we fail on an organizational level? Our co-CEO recalls
Our Co-CEO, Piotr Majchrzak, named three main areas that, from an organizational point of view, didn’t go as well as planned:
- transforming Boldare as if we were a hierarchical, top-down, traditional organization,
- turning leaders into lead links, without appropriate care for the people on how to become self-organized leaders,
- not taking care of our People space right away.
Let’s discuss those topics in a more detailed way.
Treating Boldare like a traditional organization
Our first attempt to implement holacracy was based on a wrong assumption. Our advisors, who were helping us with the transition, approached us like a traditional organization, with a rigid structure and high degree of hierarchy. And it didn’t work too well for us. Why? Back then we already had a flat hierarchy and a casual work environment - just like many IT firms of that period. So the tools we had to “install the holacracy operating system” were not suited to the environment we had at that time. Not acknowledging that sooner led to another problem from the list.
Lesson learned: Always give your partner the entire context of your situation, and make sure they understand your position.
Burning out middle management
A big part of holacracy is that traditional leaders are replaced with the role of lead links, who among other things, help to set out goals, communicate the company’s strategy, and are responsible for the purpose of the team. They become leaders in the sense that they were showing people what they could achieve, without telling them how to get there. And we took it too literally giving people full freedom of decision, but there were some of them who needed some guidance on the how part. And that created a lot of confusion - regular employees were asked to make decisions that they hadn’t been making before and speak their mind on subjects that they had no expertise in. Lead links were not allowed to intervene and it left them feeling burned out - which affected everyone else as well. We faced the so-called “change fatigue” described by John Kotter.
Over time, we found a solution: to break down the implementation of holacracy into more stages. Also we would recommend starting with the Shu Ha Ri stages of learning.
Lesson learned: Divide big changes into smaller parts, and move forward step by step. This should sound quite familiar to all Scrum enthusiasts!
Not taking care of our HR space sooner, aka the People
At the time, what other companies called the HR department, we called “People”. Our mistake was that we didn’t redesign it early on to fit into the decentralized work environment that holacracy is. As we rolled out the tools and methods of holacracy and replaced traditional leaders with lead links, there were some responsibilities that were left without owners, such as conflict resolution and career development. That caused our employees to feel confused - there was no one to show them a direction in their career.
It happened because implementing holacracy was a lot like changing the operating system - there was no need to change your hardware or delete your tools for the sake of it. We didn’t change anything in our other processes, be it finance or product delivery. Looking back, we should have made an exception for People and redesigned this department early on.
Lesson learned: Don’t involve people in change without providing guidance and a clear path for resolving basic challenges.
Chapters - a platform for our experts. What would we have done differently?
Another wave of valuable lessons came from the implementation of chapters - highly specialized self-organizing groups dedicated to a single, clearly defined purpose. Currently, we have multiple chapters that create improvements to the way we measure, learn, and build our products. But back then, things didn’t go so well.
Lack of clear vision
We asked Mateusz Rosiek, a lead link of the Build chapter, about his earliest memories of problems from the times when we were implementing holacracy. The Build chapter is dedicated to ensuring that digital development teams are using tools appropriate to their current product development phase. And while it is one of many chapters that bring benefits to the organization consistently, Mateusz remembers that in the early days, chapters were more like “fishing clubs”, where a group of enthusiasts was very keen on doing something, but lacked a clear vision of why they were doing it.
For example, he recalls the time when we created the Architecture chapter to help our developers pay closer attention to the programming architecture that they were building in. People were in this chapter out of curiosity and only for part of their capacity, while in order to do something right we needed to spend some time on each project. Mateusz remembers that the Architecture chapter was doing something but nothing really came out of it. The problem was the lack of a clear vision that everyone involved would have followed. To solve this issue we had to invest in the time and capacity of people who would be dedicated to leading chapters with their vision.
Lesson learned: Goals and definition of done are the way to go if you want people to be effective.
Everyone had a different understanding of the strategy
Lack of vision wasn’t the only problem. While working on their projects, each chapter had its goals and strategy they were meant to follow. The problem was that some team members understood their goals and strategy differently than others, which didn’t occur to the lead links until the end of a quarter. In order to ensure that the entire chapter was working in unison, lead links had to start paying closer attention to how each member understood the chapter’s strategy and if they knew what the purpose of each project was.
Lesson learned: Make your strategy… simple. And make sure that everyone understands it in the same way.
Some roles were overloaded
In holacracy, responsibilities are defined by roles. Each employee can have multiple roles, but also one role can be shared by multiple people. The latter was the case in the early days, with some roles having an excessively long list of responsibilities, to the point that they included 90% of everything that the chapter was doing. It was a role held by multiple people, but none of them really owned any of the responsibilities. At the same time, people in junior positions who wanted to take on new responsibilities were not confident enough to include themselves in a big role like that.
Lesson learned: The solution was to break down the big roles into smaller ones and let people choose which responsibilities they want to take ownership of.
How did holacracy affect our developers? Our scrum master remembers
Basia Strąk is the lead link of our Problem-Solution Fit circle, but back when we were introducing holacracy she was one of our scrum masters. She remembers that we were expecting that due to introducing holacracy and all the major changes that come with it, our turnover rate would reach about 20%. In reality, it was way less than that - which means that we must have done a lot of things right. But not everything, as Basia recalls how in the early days developers felt excluded and how anything related to holacracy wasn’t popular among them. Here’s how it happened.
Developers felt excluded
When holacracy was first introduced, there was a lot to learn: from terminology, methods of self-organization to new types of meetings (tactical meetings, governance meetings, etc.) Basia remembers that in order to prepare our crew, we organized a series of workshops and training sessions for non-developers. At the time, our developers were already working in Scrum and knew how to self-organize within their product teams. For that reason, they weren’t included in those training sessions for holacracy - and that was our mistake.
As we work in interdisciplinary teams, we need everyone to understand the new way of working. Without proper training, developers weren’t able to learn all the do’s and don’ts of self-organization and worked in their own way that was different from what the rest of the company was doing. Over time, we managed to solve this problem by mixing developers and non-developers within each chapter and creating a culture where they were working together. Also, every new joiner has two days of training dedicated to self-organization and holacracy.
Lesson learned: Big changes and transformations have to include everyone in the process. Leaving people out of the loop risks potential misunderstandings.
How implementing holacracy affected our digital product delivery
Patrycja Wala has been with us since 2015 and is now a lead link in the Delivery circle, responsible for building the digital products that we are so proud of. She remembers that at the time of implementing holacracy, we were also merging XSolve and Chilid into a single organization - Boldare. And sometimes it could be hard to know whether some of the problems with product delivery were caused by implementing holacracy, by the merger, or by a combination of the two.
We temporarily stopped innovating and lost some of our good practices
Patrycja recalls that back then we were still delivering products, but had no room for innovation and improvement of our practices. There were initiatives and interesting ideas that didn’t really go anywhere as the implementation of them was too chaotic. Also, we shifted much of our focus towards learning holacracy to the point that we lost sight of a number of good practices along the way. Patrycja says it’s hard to tell if it was more due to the merger than holacracy but we had to put in extra effort to bring those practices back and start using them as standard procedures again.
There were also the little traditions we lost along the way - for example, whenever we were building a 404 Error page, we were always sneaking a little piggy into the design. Patrycja fondly remembers those times and it’s too bad that these tiny traditions were lost along the way.
Lesson learned: It’s very easy to lose part of your culture when you implement such a big transition. It’s also time consuming to restore those lost elements. It would have made sense for us to map those standards and take special care to preserve them.
Leadership disappeared among developers and scrum masters
Also, whenever there was a problem, teams were switching into “war-time mode” when scrum masters, lead links and customer success specialists were dropping everything trying to repair the damage and maintain a relationship with the client. Patrycja recalls that in those moments, a lot of people were saying what needs to be done, but no one was able to take ownership for the problem and commit to solving it.
There was a similar issue with our scrum masters, as they paid a lot of attention to what was written in their role descriptions. As a result, they started neglecting their project management responsibilities and focused solely on what was happening within their teams.
Lesson learned: The solution was to expand scrum masters’ responsibilities and ensure their duties include taking care of the product’s budget and emphasizing project management duties in everyday activities. This way, their focus went back to how each team influences Boldare as a whole.
Always keep learning
With the benefit of hindsight, it’s very easy to point out these errors. But when you’re in the middle of a transition or any other big change, some things are not so clearly seen. This is why we share these stories with a last, but not least lesson learned: mistakes are a part of progress and the learning process. Don’t hide the mistakes - celebrating them produces much more value!
Share this article:
