Every week, a group of teams in our company gets together for a sync to share what each team is working on. During a recent sync, the dev manager announced their decision to dissolve one of the teams and assign its members to different teams. This was devastating news. Demoralizing. It could only mean one thing: the team was a total failure, right? Actually, it’s quite the opposite! Reorganizing teams regularly in order to keep a flexible team structure is a strategy some companies use to stay laser-focused on their goals.

In this post I’ll explain why at Soluto, team reorganization doesn’t equal failure, and why you might also consider adopting a flexible team structure and reorganize your teams on a regular basis.

The challenge of resource allocation

There’s an axiom in the tech world: “There’s always much more work to do than people who are doing the work”. Because of this, as a development manager or influencer in your R&D group, you have to optimize your development power, or in other words, find your Product/Dev fit. Ideally, developers will only work on the most important, valuable and profitable business goals.

So, let’s talk about business goals. They change – a lot. Deals get canceled, new opportunities emerge, new growth engines become necessary, and management shifts. Similarly, tech goals are constantly in flux. They might be affected by accumulated technological debts, greater scale requirements, or the need to adopt a new technology, just to name a few. In a world of ever-changing needs, continuous optimization is essential for your R&D group to thrive.

Don’t fall in love with your organizational structure

Now, you might have already guessed what helps us at Soluto adapt to this reality: we have a flexible team structure. The same way we establish teams – usually based on a business or tech goal that arises – we dismantle them when the team no longer serves the goal, or the goal drops in priority. Team reorganization doesn’t happen out of the blue; managers and teams think and talk about it over time, and must be confident that the change will bring about a positive outcome. Here are three examples of team reorganization that occurred at our company:

1. Business partner shifted priorities

This case is probably the most straightforward because the decision was prompted by an outside entity. This team had worked hard to find and develop customized solutions for a large partner. We delivered a pilot product and then started learning from real user experience. However, after six months, the partner notified us that they shifted their priorities and efforts to other areas that were out of our scope.

2. Team goals were limited in their potential

This team was responsible for providing our users with better content (like articles and how-to’s) based on data-driven insights in order to improve user engagement. However, when we tried translating this general goal into specific tasks, we had a hard time finding enough tasks that were both valuable and interesting to users. After giving it some thought and consulting with our Head of Product, management decided to dissolve our team and assign our members to other teams dedicated to improving user engagement.

3. Team achieved major goals

Our Data Services team was the team responsible for our data pipelines and services. After they met their primary goals, we could have chosen to go deeper and broader, to endlessly optimize our services, but we decided to shift our effort to other higher priority projects. Members still take care of ongoing maintenance and improvements as needed, but having them together as a team was no longer necessary.

So, what’s the formula for a flexible team structure?

Every company is different, but I’ve found that the following process will help engineering and business unit leaders keep their team structure flexible and agile in order to optimize development power:

1. Once every few months, thoroughly review the purpose of each team and its goals.

2. Ask yourself the following questions:

• Do these goals align with the company’s business goals?
• Do we struggle to achieve any of these goals because we don’t put enough effort towards them?
• When the next five tasks, features or user stories in the team’s backlog are complete, will we be able to say, “Now we’re close to meeting the next goal”?

3. If the answer to one of these questions is no, the first step is to see if it’s possible to change something within the team. A couple of options are defining the goals to be more focused or ensuring the team’s tasks are tightly correlated with the team’s goals. There are plenty of other options out there too.

4. If after making the appropriate changes, you still don’t see an improvement, this is the time to consider reshaping the team to the ideal structure you think it needs. This may mean aligning roles within the team more, or it could mean dissolving the team and reassigning members to other efforts. Once you decide, apply that change in order to help the group and the company succeed!

5. Lastly, don’t forget to communicate the change – first to team members, then to the company. Remember, dissolving a team doesn’t equal failure! More often than not, it’s the exact opposite.

To summarize, we at Soluto are serious about maintaining our flexible team structure. This way, we achieve our business and tech goals, while enhancing each employee’s range of experience.

What about you? Do you think this approach might fit your company? Are you doing other things to keep your dev power aligned with your business goals? Share your thoughts in the comments below, and thanks for reading!