Manager-less RnD: How to Promote People

It’s been more than two years since we threw the gambit of having manager-less R&D. Now, we’d love to share with you a couple of lessons we learned on this journey. Figuring out promotions in the flat structure wasn’t anywhere close to the biggest obstacles of the transformation. However, it’s something we’re getting a lot of questions about. So here goes!

The Art of Promoting People

Having the proper job title not only informs others what to expect from you but also contributes to employee recognition. While it could be a great experiment to lose the titles entirely (and some companies have), there’s a bunch of research proving that promotions make sense. Studies suggest that promotions have positive effects on job satisfaction, commitment, performance, and retention.

We decided to take a minimalistic approach. No stuffed corporate job titles. We have juniors, intermediates, seniors, and principals in our Research and Development teams. Here’s a loose definition of what these titles mean to us:

Ready for your promotion? Prove it!

There is no manager to nudge our developers toward working on their skills. Accepting an active role in one's professional development is the cornerstone of our setup. If a developer feels it’s time to get promoted, they must provide a testament to support it. You may argue that not everyone who’s ready for a promotion is able to ask for it confidently. That’s true!

In many of these cases within Y Soft, we've learned that other team members will support and encourage their mates to actively seek out promotions they feel they’ve earned. 

Here’s what needs to be done to get promoted:

1. A self-evaluation. Our predesigned questionnaire helps employees figure out if they’re ready for a promotion.
2. Ask others for feedback. The more senior role a person applies to, the broader the circle of people to ask for feedback from. That includes not only engineers from different teams but also Product Owners and people from Support, Sales, and Marketing (for principals). 
3. Submit all materials. When an employee decides to move forward with the process, a committee comprised of junior and senior members from different teams, coaches, and HR evaluates if all needed inputs were collected (guarantees fairness and consistency of the process) and if the presented documentation supports receiving a promotion or not.

The whole system is designed to provide the employee with tips on what to do if they happen to change their mind or conclude they’re not ready during the promotion process. It may happen after the self-evaluation or after receiving feedback from colleagues.

If colleagues' feedback doesn’t support their promotion, they can pull the break at any time and focus on improvements. The system also has other regulative measures, such as publicly announcing all promotion requests so anyone can voice their concern if needed. We reached out to other companies and professionals for inspiration on this. 

The Corporate Rebels blog offers some further reading on the topic.

PROMOTION VS SALARY RAISE: ADDING MONEY TO THE MIX

There are no dry promotions in our current setup. A new role always comes with a new salary range and, thus, with a salary raise. On the other hand, there’s flexibility within the range. You can get a salary raise without being promoted. This allows us to reflect on the differences in individual contributions of people on the same level.

Salary raises are in the competence of the only manager remaining in the system who holds the approving power for formal matters. The reasons for keeping one manager in the system are connected mainly to finance handling (employees in the Czech Republic have the right to keep their salary a private matter). The deciding power of our RnD members is over who’s roughly on the same level when it comes to their product contribution.

FOOD FOR THOUGHT: LIMITATIONS AND RISKS

Every setup comes with limitations and hiccups. One of the funny ones (not unlike how it was quickly picked up that AI has biased tendencies) was the promotion committee, which started to act like a manager.

Committee members tended to make decisions based on their personal experience with the employee in question instead of considering only the collected feedback. It was necessary to discourage this a couple of times. Also, adding the public announcement and call for objections helped. Like other team members, committee members should submit their feedback before starting the evaluation. 

Also, our promotions work retrospectively. In other words, you need to be there to get promoted. This setup doesn’t allow for motivational promotions when you put trust in someone before seeing if they can do the job adequately. 

Another valid point is that the process can be time-consuming. Remember, it’s your developers now who must collect the feedback, make decisions, and communicate. Our experience suggests that it’s worth it. The coding time loss is compensated by steep growth in their soft skills and business understanding.

SO FAR, SO GOOD

Employee surveys prove that developers are mostly happy with the new setup. From an HR perspective, we see that the amount of promotion requests correlates well with the number of employees who are indeed ready for promotion. In detail, we’ve seen the following results:

• 23 colleagues in RnD have requested a promotion
• 20 of those were approved the first time around
• 3 requests were rejected, with feedback on what to work on
• 2 of those 3 were promoted later that year
• When facing rejection, colleagues accepted and worked on their feedback  

That makes about 20 promotions in our roughly 100-headed RnD in two years. It seems that our RnD reached a new internally induced balance. Now, we’re keen to see what happens next!