A reorganization that went well
I recently completed a reorg of an IT department for a client. This reorg went surprisingly well.
Let’s checkout some potential reasons for that.
The status quo
The client was in growth mode. The whole department was still thinking of itself as one team, but had 40 engineers. The client then created four teams. One bug-fixing team. And three development teams. The three development teams did not have their own domain, but worked one week on feature A, next week on feature B and so on.
Everyone in the org was really motivated. But tiny cracks began to appear:
- The bug-fixing team complained that they could not work on cool stuff. It was boring.
- Product Managers complained that it was impossible to establish a long-term product strategy: That was because they had no focus on a particular part of the software (or the customer or the value stream).
- Developers had a hard time establishing a long-term tech strategy: The teams did not own anything. Just get the feature done and move on. In case of bugs they were not even responsible for fixing them - there was the bug-fixing team after all. But that created technical debt that nobody really owned. This in turn began to slow down the development speed.
Our goals
Many reorgs do not really have goals in mind. But in order to succeed with a reorganization you need measurable goals.
We defined three goals for our reorg:
- Support the future growth of the company (onboarding and splitting into new domains should be simple)
- Give teams focus and ownership (decreased bug count)
- Establish structure that allows multiple releases per day per team (faster cycle time)
We also measured the employee NPS throughout the change process to make sure we did not kill the motivation of the teams.
How to determine the domain of the teams
It’s often easy to identify natural teams when checking out the user interface of the software in question. You’ll have some bigger parts as menu items. Think of it as Google Workplace. You got 5 big menu items: Google Sheets, Google Documents and so on. Each menu gets one team with a clear domain. That’s of course simplified, but you get the idea.
Your initial domain model may not be ideal, and you should always question your organizational structure regarding whether a team can really deliver business and customer value directly. Still, one team per menu item might be a good starting point.
We developed the plan jointly with the Product Managers and key developers. The big surprise was that - once the plan was agreed upon - the reorg was executed by the teams without any management involvement. I just had to give the initial push, but then the teams took over and implemented everything. This was extremely satisfying to see, and highlighted the quality and motivation of the workforce.
At the end everyone was happy - which is not always the case with reorgs…
The result
Five teams with clear ownership of one part of the software. Each team had customer contact and was responsible for everything (aka fullstack): frontend, backend, database.
We also gave Product Managers more powers. Before the reorganization they were mere executors of plans. After the reorganization we expected them to experiment and gave them the freedom to decide on the direction of their domain (almost) on their own. We renamed the role from Product Manager to Product Owners.
What could we have done better?
Some employees complained that we did not communicate enough. The plan was discussed - but only with the Product Managers and key developers - not everyone. This is something that we could improve in the future. Over-communication does feel strange - but it is a necessity. Next time I would give regular updates in department all-hand meetings on a bi-weekly basis.
Conclusion
Apart from the communication it worked out nicely and we completed our goals in a measurable way. The company hired many people in the months after the reorg - and the new structure was easily able to integrate new employees in a good way.
When doing a reorg in your department keep the following three points in mind:
- Define the goals of your reorg and measure whether you reach them.
- Communicate and get feedback during the process.
- Delegate and have good people that support you!
That’s it. Have fun in your next reorg!
More:
- Casey Winters about reorgs at Eventbrite: https://caseyaccidental.com/alternative-approach-re-orgs/
- Photo on top by the awesome Laura Rivera
