Vaclav Muchna, CEO
6 min read
Nineteen months ago, we decided to make a structural change in R&D and remove management positions. We implemented it in May 2020 (during the COVID lockdown). What was our expectation back then, and what is the reality now? Would I recommend this to others? What are the next steps for us in R&D? All these answers can be found in this article.
WHAT LED US TO THE POINT OF CHANGE?
At Y Soft, we have been organically growing double digits for almost 20 years. So has our R&D teams (which maxed at 130 headcounts). But some years ago, we reached the point when adding more developers resulted in lower throughput.
We had been trying many incremental things (including many “agile rituals”), but none of them led to a significant increase in productivity. We thought that managers may add value in some areas, but they intrinsically take the responsibility/accountability from the developers. This became the main motivation.
We had been trying many incremental things (including many “agile rituals”), but none of them led to a significant increase in productivity. We thought that managers may add value in some areas, but they intrinsically take the responsibility/accountability from the developers. This became the main motivation.
We decided that incremental changes wouldn’t help with massive productivity increases, so we chose a more radical approach: implement full scrum combined with a manager-less environment.
Our goal was to create scalable R&D, which means that added resources would linearly increase throughput. This would allow us to deliver many of our great ideas. Our product delivery capability became the key to our success.
First, I need to align you with some of the terminology. In fact, there are three complementary frameworks we have been implementing in parallel to some extent.
Our goal was to create scalable R&D, which means that added resources would linearly increase throughput. This would allow us to deliver many of our great ideas. Our product delivery capability became the key to our success.
First, I need to align you with some of the terminology. In fact, there are three complementary frameworks we have been implementing in parallel to some extent.
AGILE
In my view, the purpose of Agile is to ensure that we deliver a solution to a problem—in other words, that we really solve a problem for our internal or external customers. We have faced situations in which we delivered fantastic technology, but it didn’t really solve the problem.
As one of our customers said, “Y Soft can do great things. But they need four tries to deliver what we asked for.” These four tries were expensive, and despite this being quite common in our industry, it does not create the customer experience we aim for. We had to change it.
Agile uses an iterative approach to validate progress early and continually with key stakeholders (e.g., customers). This early feedback allows us to change direction much quicker.
SCRUM
For me, Scrum's primary purpose is to minimize the cost of change. The high cost of change is driven by all the context a team must absorb to produce a deliverable (product increment). If we manage to split work into value-adding increments, we can switch priorities at the right moment.
The main outcome is that the work in progress gets finished to the point where the deliverables start to add value (i.e., they start returning the investment). Minimizing work in progress is vital.
A secondary purpose, in my mind, is that it enables planning, transparency, and predictability in our delivery. What good is a plan if the organization is unable to deliver it? That’s not a plan, but wishful thinking after all.
The main outcome is that the work in progress gets finished to the point where the deliverables start to add value (i.e., they start returning the investment). Minimizing work in progress is vital.
A secondary purpose, in my mind, is that it enables planning, transparency, and predictability in our delivery. What good is a plan if the organization is unable to deliver it? That’s not a plan, but wishful thinking after all.
MANAGER-LESS STRUCTURE
We have been experimenting with Scrum at Y Soft for years (we implemented LeSS—Large Scale Scrum). However, from my management perspective (which I think is shared by many of our developers), it never worked the way it was supposed to.
There were a number of reasons for this. I believe many of these reasons were behind the engineering itself (Product Marketing, Product Owner, etc.), and solving it required a holistic view of the entire product development process.
The middle management layer of the R&D organization was partly why it did not work. Implementing Agile and Scrum requires a great deal of commitment and accountability. However, in a traditional structure, no one can really tell who is accountable for delivery. Is it the teams’ manager? Or Product Owners? Or the teams? Or all of them?
There were a number of reasons for this. I believe many of these reasons were behind the engineering itself (Product Marketing, Product Owner, etc.), and solving it required a holistic view of the entire product development process.
The middle management layer of the R&D organization was partly why it did not work. Implementing Agile and Scrum requires a great deal of commitment and accountability. However, in a traditional structure, no one can really tell who is accountable for delivery. Is it the teams’ manager? Or Product Owners? Or the teams? Or all of them?
The reality was that no one was accountable. Engineering teams were shielded by managers; they wanted to be rather safe, which did not encourage any risk-taking within the teams. Product Owners did not understand the business (well, they thought they did, but that is a different story).
Managers in Scrum environments are supposed to surrender the accountability to the teams, which leads to their feeling, that they are no longer important. Their role must change from managers to coaches. I personally didn’t believe that such a transition could be possible at scale.
The effect was as expected. Teams became accountable. The feeling of accountability led to better planning (in most cases, missed delivery was due to poor planning anyway). Things that were impossible (such as 90% accuracy of roadmap delivery) became a reality.
Managers in Scrum environments are supposed to surrender the accountability to the teams, which leads to their feeling, that they are no longer important. Their role must change from managers to coaches. I personally didn’t believe that such a transition could be possible at scale.
The effect was as expected. Teams became accountable. The feeling of accountability led to better planning (in most cases, missed delivery was due to poor planning anyway). Things that were impossible (such as 90% accuracy of roadmap delivery) became a reality.
MANAGER-LESS ENVIRONMENT CHALLENGES
Well, I must admit that the world is not ready for this type of organizational structure. There are lots of process-related issues that must be solved—for example, an ERP system that doesn’t understand that there is no single approval authority.
We had to overcome many challenges. Let me mention some of them:
We had to overcome many challenges. Let me mention some of them:
- Vacation approval. That was easy. In a knowledge-worker environment, I believe that a manager’s value-add to vacation approval is exactly zero. I’ve heard a funny argument:
Person: “The team took a vacation exactly during the time we were supposed to deliver something really important. That would never happen if a manager would be in place.”
Me: “Oops. That’s bad. And did someone tell the team that we have this important commitment during their time off?”
Person: “Yeah. We told them when we learned that they are going to be off.”
Me: “And what happened?”
Person: “They canceled their vacation.”
Me: “So where is the manager’s value?”
Me: “Oops. That’s bad. And did someone tell the team that we have this important commitment during their time off?”
Person: “Yeah. We told them when we learned that they are going to be off.”
Me: “And what happened?”
Person: “They canceled their vacation.”
Me: “So where is the manager’s value?”
This nicely illustrates the perception, right? The person was convinced that the manager was important as a vacation approval point, but all that was needed was to make sure the team had the right information.
- Promotions. How do you promote people without a manager? Well. My belief is that the manager is typically the last person in an organization to know what is going on. At least, it applies to me 😉. But here is what our people invented as a promotion process:
- There is a simple evaluation form that helps each individual assess whether they are ready for a promotion or not. If not, they at least get a clue in the areas they need to improve upon.
- Based on a positive self-evaluation, peer feedback is collected. For junior positions within the team, the more senior promotion, the further away we are reaching for feedback. Based on peer feedback, the promotion is recommended to a committee.
- The committee checks the quality and scale of the feedback, and either approves or rejects the promotion or requests additional feedback.
Read more about the promotion process in this article.
- Bonus. Bonuses are distributed to the entire team, and it is up to them to decide how to split them.
- Missing 1:1. In fact, we are trying to figure this out as we speak 😊
These were just examples of stuff we had to overcome. The purpose is to illustrate mankind’s ingenuity and ability to find a solution.
CONCLUSIONS & WHAT’S IN FRONT OF US
It was a ride, but it was the best R&D-related ride of my life. We managed to increase productivity by triple digits. If you ask me whether I would do it again, I’d answer “ABSOLUTELY.” Sure, I would learn from some missteps, but it was the right direction.
That said, it is not for every organization. I think it works well with knowledge workers, especially if you can create substitutability among the teams (but that is not a condition). It also requires executive management to really believe in their employees.
I admit that we were surprised by the productivity growth. But even more valuable is the growing predictability (which enables us to deliver as promised). Finally, I am sure that this system will scale linearly. We have already added a couple of engineering teams, and this year, we plan to add four more teams. I am confident that we will see an equivalent increase in throughput.
While there is a lot more to improve upon, we are all motivated to continue as the benefits of this transformation have tangibly materialized.
Here are a couple of points to summarize the entire experience:
- Trust engineers and delivery teams in general. Have good reporting so that you know what is going on, but first and foremost, trust them.
- Regular reviews are the most important process. They bring transparency (and thus are the key enablers for trust) and peer pressure (you don’t want to show that you haven’t delivered while everyone else did).
- It is not only about a manager-less organization structure. That by itself doesn’t solve anything. Even when integrated with Agile and Scrum, it is not enough. It requires a holistic view that starts with Product Marketing. That’s why it requires top management support. Ideally, from the CEO.
- A managerless organization requires great agile coaches. I would say great coaches rather than agile coaches because agile is just a buzzword used to drive up salary. 😉
- Agile coaches must be accountable for their teams’ capability growth. Their work must be systematic and measured. Agile coaches who are not accountable don’t add any value. (Disclaimer: this is my opinion.)
- We plan to implement maturity models to systematically work with teams, identify their gaps and blind spots and measure value add by the coaches.
- Product Owners must have field experience. They must know the market and customers as well as they know their spouses.
- It is vital to regularly bring the teams a lot of business context. Customers (internal or external, it doesn’t matter) should directly engage with the delivery teams.
Engineers from R&D shared with us what it feels like to work in a team without a manager. What are the best advantages and are there any obstacles? See their feedback below.
