Using delegation board as a glue for new department structure
How we adapted a Management 3.0 practice to define a starting point after a complete Tech department reorganization.
The context
Back in 2016, the company had 3 independent Business Units with their own processes and tech teams , with their own rules and also the department of Sys and IT as independent teams. We were around 50 devs, 4 managers and 8 teams.
We detected a lot of problems related to the lack of alignment and visibility, and also some Business Units started to growth but we cannot easily share devs amongst the different BU. To solve those issues we propose to move all tech teams inside a Tech Area department collaborating with the different BU.
But unification brings the challenge to create a new team with a new culture without losing what it works on the old teams.
We’ve created a workgroup with all managers and volunteers from each of the old teams with this objective:
- Understand old boundaries from the different teams.
- Unify Tech Area and define clear boundaries.
- Be open and transparent about the type of delegation between the management and the team.
- Empower the organization by having self-organized teams with clear boundaries.
- Identify needs and define a starting point to find actions to improve.
The process
We had a clear objective and a mixed workgroup where all voices’ vote had the same value, a good start to create a department that everyone feels theirs.
Define methodology
The group decided to use a management 3.0 practice from Jurgen Appelo , Delegation Poker & Delegation Board ( a method where you can encourage employee engagement through controlled self-organization and clarified value and decision-making ) but with some modifications.
- From delegation to empowerment.
The delegation board is created from a manager perspective, and we thought that for the devs it was going to be easier reading from their perspective to understand the meaning of each delegation level.
We changed from “ Tell: I (Manager) will tell them” to “Get informed: You (Dev) get informed on the decision but you can’t participate”
We change from “Delegation board” to “Empowerment board”
- Reduce levels of delegation
Another decision to make everything easier to understand was to reduce the number of delegation levels, removing subtle changes from one level to another.
- The topics
Finally, the workgroup chose the topics and asked the tech team to review and add as needed.
Those were the topics agreed:
Salary/ Promotions / Team Methodology/ Team Activities / Team People Setup / Assigned Desks / Hiring / Firing / Technical Architecture / Technical Standards / Holidays /Working Schedule / Remote Working / Training Budget / Training Inhouse / Personal Equipment / Personal Tools & Software / Okrs Use / Personal Okrs / Product Delivery Dates
We marked the elements that imply money with ($) and also the topics where the delegation level depended on the organization decision. Finally the workgroup gave some context to each topics.
2 examples:
- REMOTE WORKING What decision level do you think you have choosing when to work from home?
- PERSONAL EQUIPMENT ($) What decision level do you think you have choosing the personal equipment you work with? (computer, screens, mouse, keyboard, …)
Empowerment poker Workshops
With everything defined, we prepared 4 workshops for the different teams to understand the feeling about delegation level for each old team.
The workshop always started explaining the purpose of the activity and that they were not defining what level of empowerment they want but the level that they feel they had.
The participants will repeatedly perform the following steps:
- Read the key value story and make sure everyone understands what it means
- Every player privately chooses one of the cards, which reflect what they think is the current state of the key value in the development team
- When all players have decided, they reveal their selected cards simultaneously
- The choices people made will probably be different. Let the people with the highest and lowest cards explain their choices. You can suggest that groups play the game again for the same story when the difference between the highest and lowest cards is high.
- Ask the group to achieve consensus about one empowerment level and place it in the empowerment board.
We had a meeting with the managers of each team without seeing the results of each team, to be able to compare the feeling of the managers vs the feeling of empowerment of the teams.
This was the output of one team
Management agreement
With the different empowerment boards and taking into account the differences detected between old teams, the managers agreed on the Empowerment board for this new unified tech department.
The non managers from the delegation workgroup facilitate the meeting with one main objective, force management to be conservative with the empowerment level for each topic. Better work to improve empowerment level than reduce the empowerment level after is communicated, because it can destroy trust easily.
Communication
We presented the final picture to the team, explaining the conservative mentality to choose the empowerment levels for each topic. Then the whole department voted for the topics they want to improve first.
So we have a clear picture for everyone about what to expect around delegation and that this were a starting point to start improving.
Learnings
After the process finished and after 3 months living with the empowerment board defined, the main learnings were:
- Topics are difficult to define, they need to be specific.
- Context is the key! Delegation level is easier to define if you give context.
- Less steps make everything easier to understand but improving is more difficult.
- Public expose is a good way for management to commit to the plan.
- Empowerment board is not a one time job. Reality changes, that’s not bad as long as you maintain the empowerment board up to date and explain the changes.
- We started with the Tech area but we strongly recommend it to the entire company.
