How Restructuring Can Help Your Team to Claim Ownership

Problem

I was managing a team of five people and whatever task we would be given, it would be picked by an IC who would be most available at the moment. They would work on a task and once completed, they would move to the next one. This approach didn’t allow people to build strong domain knowledge and they would often complain about lacking the purpose and motivation.

Actions taken

I decided to split the team into two sub-teams. The team consisted of four back-end engineers who were split into two subteams and one front-end engineer who would be added to a subteam that needed them the most at the moment. Two subteams would have their own area that they would be focused on and have ownership of. That helped them gradually develop their subject matter expertise and position themselves as knowledgeable individuals who can be respected because of their competencies. Claiming ownership happened as a natural consequence of that approach -- they became more connected with the domain and therefore, more responsible and concerned about all details of whatever would fall in their area of interest and expertise.

Their competencies soon became known to people outside the team. They would be reached out to as domain experts by people across the company. Also, it became widely known what was the area they owned and what they were responsible for.

The team underwent restructuring two quarters ago and the feedback from the team was tremendously positive. These changes allowed us to move faster because people were able to develop specific expertise and focus on things they felt confident about. Besides the evident improvement in velocity, we noticed the improvement in collaboration -- members of two subteams were much more eager to share information from their area of expertise and enhance cooperation when working on the common task.

Lessons learned

• It is hard to enforce accountability without establishing ownership first. People tend not to care about things they don’t own and that are outside of their area of expertise.
• Before going forward with a reorg, make sure to talk to ICs and understand their wants and preferences.
• We were concerned that the reorg would eventually lead to isolation but in the long run, it enhanced cooperation. However, you have to ensure that knowledge sharing happens early on before two subteams become siloed.