Nineteen months ago, we decided to make a structural change in R&D and remove management positions. In May 2020 (during the COVID lockdown) we implemented it. 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 decided that incremental changes wouldn’t help with massive productivity increases and we chose a more radical approach: implement full scrum combined with a manager-less environment.
Our goal was to create a scalable R&D, which means that added resources would linearly add the throughput. This would allow us to deliver many of the great ideas we had. 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 to some extent in parallel.
The purpose of Agile, in my view of the world, is to make sure that we deliver a solution to a problem. In other words, really solving a problem for our internal or external customer. We faced situations in which we deliver 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 4 tries were expensive, and despite this is 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 (i.e., customers). This early feedback allows us to change direction as needed much quicker.
For me, the primary purpose of Scrum 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 have the ability to 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 into 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.
Scrum uses an iterative approach to encapsulate deliverables (product changes) into small increments, which add value by themselves. Because Agile also uses an iterative approach, these two things are often mixed up together, but I believe they are complementary, and they each serve a different purpose.
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 in the way it was supposed to work.
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 in fact 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 anyways). 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 stuff 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:
- 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?”
This nicely illustrates the perception, right? The person was convinced, that the manager is 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 the 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.
- Bonus. Bonuses are distributed to the entire team, and it is up to them to figure out the split.
- 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 in 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). And it 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). And finally, I am sure, that this system will linearly scale. We 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, that brings transparency (and thus it is the key enabler 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 manager-less 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 that 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 be people with field experience. They must know the market and customers just as well as they know their spouses.
- Bringing a lot of business context to the teams on a regular basis is vital. Have customers (internal or external, it doesn’t matter) 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.