DEV Community

Cover image for Range of autonomy practices: Six examples
Arsen
Arsen

Posted on

Range of autonomy practices: Six examples

Image description

Autonomy is one of the core intrinsic motivation factors. When we talk about performance and motivation, the freedom to choose what and how you do is indispensable.

I used to think about autonomy as "leave product decisions to the Product Owner and technical decisions to developers". But from recent reading I discovered a whole range of autonomy people have in various companies. I ordered the list by the level of trust and transparency between the employees and their leaders. Let's start from the top.

1. Microenterprises: Haier

Haier is a Chinese home appliances manufacturer that revolutionized the organizational structure with its RenDanHeYi model. Haier consists of 4000 "microenterprises" - completely independent groups of 10-15 people. Each microenterprise functions as a small company in a network of companies. It can contract with other microenterprises, seeking services and sharing a part of its income. Anyone is free to organize their own microenterprise if they see the need. You can even contract with an external service provider if an internal service is not good enough. There are microenterprises for HR, legal, compliance, and anything else you need to deliver service.

Haier says that the best employees are those who have the entrepreneurial spirit, and the RenDanHeYi model allows everyone to unleash their inner entrepreneur.

More about Haier by Corporate Rebels

2. Teams define their product backlog: Shopify

James Stanier, Director of Engineering at Shopify, wrote a post for LeadDev describing their approach to autonomy. In that case, the product items don't come from executives to the bottom. Instead, engineering teams propose things they want to add to their product. There are processes to align them with the organizational goals, to review by the executives, and to define good metrics. Then, the engineering team is responsible for the delivery and the outcomes.

Encouraging autonomy within engineering teams

3. Teams choose items from backlog: LeSS

The LeSS framework suggests a more strict approach. The roadmap and prioritizing are still done by the Product Owner. Then she brings the next upcoming items to the Engineering teams (there can be up to 8 teams per one Product Owner), and the team representatives negotiate who takes what. A team might choose an item because they have the proper expertise, so they'll do it quicker. Or they may want another one because they lack the knowledge and want to learn it better.

It's a lower level of autonomy, but it still allows the engineers to grow and contribute in the best way. It is important that the engineers decide what is best for them.

Large-Scale Scrum: More with LeSS

4. Dynamic reteaming: Valve, Pipedrive

Dynamic reteaming is when people can change teams and projects to increase their impact and learnings.

In my game development past, 10 years ago every other game developer dreamed about working at Valve. I clearly remember that their New Employee Handbook said every office desk had wheels. This is because anyone could change their project at any time. If you are bored with your project and you have found another one - more interesting, more rewarding, and where your skills are needed - you can join it, just roll your desk.

Valve: Handbook for new employees

Another example is Pipedrive and the Launchpad system, as presented in a case study of the unFIX model. All the engineers start in a Launchpad group that deals with maintenance and overall improvements. From there, people can form Mission Teams that leave the Launchpad to deliver certain items. The Mission Team is gathered for the specific needs of the challenge they resolve. After the item is delivered and accepted by the Launchpad, the Mission Team returns.

The case study presented by Jurgen Appelo

5. Individuals work on their ideas: Google

Another famous example of a smaller scale of autonomy is Google and their "20% rule" - 1 day per week each employee can spend on something they see to be valuable for the company. In case of success, these small experiments grew into services like Gmail.

There are rumors that Google dropped the 20% rule, or at least it is restricted by conditions. Allegedly, nowadays an employee needs her manager's approval, as the 20% on a side project would impact the team's performance.

Other companies also use different forms of this rule, ranging from 10% to 20%.

6. Hackathon

The least risky option is an internal hackathon. 3 days every 4 months would take just 3% of working time, and it still gives people the freedom to experiment, learn, reteam, build horizontal connections, and do something meaningful.

Autonomy is a cultural matter

Not every option suits every organization. The autonomy level is strongly tied to the organizational culture - not only values but also practices, processes, and beliefs that support those values. Changing a culture is possible, but it requires both executive support at the top and engaged people managers at the bottom.

Top comments (0)