Structuring multiple teams within an organisation

I'm currently working in a mid sized organisation with around 40 people working on software in total, divided over multiple teams. Recently, I've been having some issues with cross-team communication and scheduling, and I'm looking for some advice on how it can be improved, as well as some sources of information to help me convince management that something should change. Most teams are assigned to a specific product, my team works only on product A, and another team works only on product B. Some people are in multiple teams, in case a product is really small or in maintenance mode. We also have 2 other teams. An 'ops' team that handles server setup, Azure resources and roles, CI/CD and other infrastructure, but also handles all support. We also have a 'FME' team, which consists of ~5 developers for the domain specific language FME. They have a lot of their own 'products', but also implement functionality for my team and other teams. We don't need to communicate a lot with other product teams, but we do need things from these 2 teams. Recently, we needed to integrate functionality from an existing product from the FME team into our product by calling their API. During implementation we found out that we need some small changes to the API, but they have not allocated any development time, so we'll need to wait at least 3 weeks on them. Once they pick it up, they don't know all the background information we have, and the result is not really what we expected. Similar issues happen with the 'ops' team, where we request some permission changes or new Azure resources, and it takes weeks before they have time to work on it. I think the core issue is that our team does not contain all the skill sets to complete the feature, however, we also don't normally have enough FME or ops work for a full time team member working on that. I was thinking of something like a 'short term feature team'. Small cross-functional teams that work on a specific feature that is disbanded once the feature is done. I'm not sure if that's a good idea, and what it would mean for the current product based teams. How do other organisations manage these kinds of issues?

Feb 24, 2025 - 12:54

I'm currently working in a mid sized organisation with around 40 people working on software in total, divided over multiple teams.

Recently, I've been having some issues with cross-team communication and scheduling, and I'm looking for some advice on how it can be improved, as well as some sources of information to help me convince management that something should change.

Most teams are assigned to a specific product, my team works only on product A, and another team works only on product B. Some people are in multiple teams, in case a product is really small or in maintenance mode.

We also have 2 other teams. An 'ops' team that handles server setup, Azure resources and roles, CI/CD and other infrastructure, but also handles all support.
We also have a 'FME' team, which consists of ~5 developers for the domain specific language FME. They have a lot of their own 'products', but also implement functionality for my team and other teams.

We don't need to communicate a lot with other product teams, but we do need things from these 2 teams.
Recently, we needed to integrate functionality from an existing product from the FME team into our product by calling their API.
During implementation we found out that we need some small changes to the API, but they have not allocated any development time, so we'll need to wait at least 3 weeks on them.
Once they pick it up, they don't know all the background information we have, and the result is not really what we expected.
Similar issues happen with the 'ops' team, where we request some permission changes or new Azure resources, and it takes weeks before they have time to work on it.

I think the core issue is that our team does not contain all the skill sets to complete the feature, however, we also don't normally have enough FME or ops work for a full time team member working on that.

I was thinking of something like a 'short term feature team'. Small cross-functional teams that work on a specific feature that is disbanded once the feature is done. I'm not sure if that's a good idea, and what it would mean for the current product based teams.

How do other organisations manage these kinds of issues?