Structuring multiple teams within an organisation

Question

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?

Answer 1

There are some frameworks to start reasoning about the problem in your context. Two that come to mind are Team Topologies and the unFIX Model.

Using the Team Topologies framework, it sounds like your product teams are stream-aligned teams, the ops team is a platform team, and the FME team is a complicated subsystem team.

In the unFIX Model, the product teams are value stream crews, the ops team is a platform crew, and the FTE team is a capability crew. However, the model also allows for describing governance crew (often the senior leadership of the business, business unit, or product portfolio), forums (for cross-team development), and other types of crews.

Depending on your model, you can apply patterns. Team Topologies defines interaction modes of collaboration, X-as-a-Service, and facilitation for how teams interact. Generally, complicated subsystem teams offer their subsystem as a service, while platform teams typically offer the platform as a service and/or collaborate with stream-aligned teams to build knowledge and skills. The unFIX model offers a number of patterns for organizational structures, cross-team collaboration, and decision-making.

Working through these models and patterns as an organization can help you find the approach that works for you. However, there are likely some other changes that could be beneficial on top of these patterns. For example, why must you wait at least 3 weeks for a team to make a change? There are probably other changes that you can make to reduce those cycle times. As you dig into modeling your organization, you'll come across other ideas for improvement.

Answer 2

I can feel your pain, since I work in an organization which had some very similar issues in the past. There is often no easy answer here, but there are at least some measures which can be taken.

It is quite normal in the described organization that other teams like the FME team or the Azure teams have other priorities than your team. They typically have other top goals, and "give help to other teams" usually has a lower prio than "lets solve the problems of our own team". Once you realize that, it becomes clear that if you really need help from the teams within a given time frame, you need strong backup by the upper management.

So if you can get management to support this and make some restricted support for your project a top goal for one of the other teams, you are half-way done. Of course, you need a person from your team who knows the requirements well working together with another person from the specialists team who knows the specific technology well. Call that a "short term feature team", if you like, but if it is really necessary to make this formally a team within you organization depends heavily on the organization and the people involved.

In reality, however, I have run into situations where management was not willing to make clear and strong decisions about the goals. Instead, they were relying on the teams working it out among themselves (which is not necessarily a management failure).

For that case, I see only two options:

• Live with the fact that implementing certain things (and implementing them correctly) take a long time.

  For this, it is important to write down your specs and test cases very precisely, so when the other team finally starts to work on your requirements, they can verify for themselves whether their implementation does what you need (or not). A "development cycle" might require a few weeks or longer, hence you should take any measure to avoid more cycles than necessary. Or in other words: when there is no chance to work agile with the other team, you have to live with a waterfall-like approach and try to make the best out of it.

• Bring your team in a position to become more independent from the other teams.

  There are different ways to achieve this, depending on the specific case. For example, "permission changes" should be something your own team should be able to do autonomously - not arbitrarily, but restricted to the systems your product interfaces with. Ask the Azure team how a solution could look like where they don't have to interfere manually for each and every small permission change - maybe the kind of permission changes can be scripted or done by some small web interface. Maybe they can build it for you, or your team can build something with them together.

  Or for the FME team: maybe you need some restricted FME know-how in your team. Or maybe you can solve your requirements completely without FME, by choosing some libraries which fit better to the technologies your own team is familiar with (that is indeed something we did in the past to become more independent from "our" FME team).

Answer 3

Those "weeks before they have time to work on it" have a name. That's called a sprint. Sprints were invented to keep people from showing up while a developer is solving a problem and changing the problem. It's easier to hit a target that isn't moving.

What you should be doing is using those weeks to iron out the details of what you're asking for. Collaboration during this time is encouraged. Specify what you need and show it to the other team and get their reaction. Find out what isn't clear. Find out what assumptions are wrong. Refine the ticket with this feedback.

This is work. It's part of creating tickets. You must make sure that what you ask for is really what you want. Lots of development time gets wasted specifically because this step is skipped. A few extra minutes spent here can save days later.

Only resort to formalizing this collaboration with temporary teams if that's the only way to make the collaboration happen. In most heathy shops this sort of thing can be solved by keeping a guest chair at your desk. Maybe a few desk toys.

Answer 4

This is vendor management. The problem is that your vendor works for the same organisation so people get a little squeamish about holding the otherside to the contract.

It looks like you failed on your end of the vendor relationship as well. You haven't established expected response times, neither have you established how to describe software with them.

There are always many solutions to these problems.

You could actually bring vendor management into your team. Establish those service levels required. Chances are you'll have to formalise this. Unfortunately the only reliable way is to establish it with cash. In an org i used to work for my team received cash flow from the client departments that used our software to service their clients, in turn that payed for engineers, and to the platform teams we used services from.

You could advocate for dissolution of the teams. 40 engineers does not require 4 teams to organise. You could function as 1 team that break into focus groups to handle streams of work. Teams/Pods are just another word for Silo. Dissolving those boundaries removes the siloing. The problem is that this means that every engineer needs to skill up across the whole domain as they may be called on for this or that work. Not that some devs can't be specialised but it takes skill to keep the work matched up, and flexible devs make it easier. This isn't a magical fix either. The team as a whole must be more disciplined to ensure adequate coverage of all work streams, including reassigning engineers between streams dynamically.

Alternately you could argue for self-service. Particularly with a lot of cloud stuff, it was designed with that in mind. If the self-service doesn't exist instead of asking fro the resource, ask for a way to create the resource on demand. Testing environments are a good engine for this. Their lifecycle of create/test/destroy demands scriptable self-service for them to be effective. By being test environments they need 90% of what would be needed in a production environment, and you can sell the fact that the script works in test and so should work equally well in production.

Frankly though. It might just make more sense to work on communication between teams. You can do this at the individual level by organising one on ones, lectures, game days, hackathons, etc... or you can do this at the team level by working on how your team communicates with their team. Perhaps you have a placement day were you work as part of that team, or perhaps you establish some standards for how to describe complex coding work. Maybe you standardise common requests, maybe you get them to sit an expert in your team during some projects. Particularly if you know you'll be closely working with them on this or that technology.

Answer 5

There's no formula for team organisation that will ultimately relieve you of the need to properly resource the activity, or to work at a pace appropriate to the scale of the activity.

Steering a ship of forty developers is bound to occasionally involve having to wait, but if it's getting to the point where small but important requests are taking several weeks for another team to execute, then it might be a sign that they're not leaving enough slack in their planning to accomodate responsiveness to colleagues. The fix might be as simple as compelling this allowance to be made.

And if you're asking for things but not getting the right result, it might be that there isn't enough time being allowed for discovery or for adjustment to feedback - in other words, you're not being realistic (and incorporating past experience) about the allocation of time required, including for the developer to wind down from the previous task and get properly involved in the next.

Loss of subtlety and fineness in the work can also be a sign of overwork or a culture of habitual rushing. Certainly, if the idea of "feature teams" implies more merry-go-rounding and diversity of tasks, then it might only increase the intellectual overhead. Or it can be a sign that insufficiently skilled and experienced people are being accumulated and retained in the business.

Finally, drawing the borders of the "product" for each team is always an art form. Much more commonly, the principle of a free-standing product collapses, and staff end up lumped together in pools of technical specialities (or generalities), such as suggested by an "ops" team who handle allsorts including "support".

Neuroticism about avoiding waste or inefficiency, is often the biggest cause of waste and inefficiency, because first on the chopping block is always the modest amount of idle or unregimented time associated with flexibility and responsiveness to events. The second symptom is frequent impulsive reorganisations and innovations - especially grand and experimental ones - that upset habit, memory, and communication patterns.

Answer 6

I think with just three teams and 40 people there are some practical "common sense" measure you could take to reduce these issues.

1. Get people from the other teams involved earlier.

Tell them you will need their help with the feature, chat with them about what you need well before you need it so they know it's coming and can make a slot.

2. Manage expectations around how long things will take when they require out of team actions.

You know it's going to take longer, so make that clear up front.

Regarding how other companies manage the problem, Thomas is right to suggest those books and methods. But. You have to remember there is a whole industry selling this kind of management advice to companies and companies rarely apply it in whole or in the same way. It's good to know what the terms mean and how the system is supposed to work, but frankly they aren't going to solve all your problems or tell you what gets implemented, or survives the first 3 months in other companies.

• Cross Functional Teams

  This used to mean you have a JavaScript guy and a DB guy on your team. Now it's more forming "tactical" or "ninja" teams that jump in and change code they don't understand. I think you are right to be skeptical.

• "Stream Aligned" Teams and CSSs

  This is just grouping up the teams differently so they have the same goals. Hopefully having the same goals mean they help each other more, but unless you have weird groupings now, or want to change the focus of the company, you still have the same code and people at the end of the day.

• Scrum of Scrums

  The idea is that a person from each team joins to form one super team so they work together to achieve goals which require more work than can be done by one team. Great, but don't you already have managers?

Essentially all these techniques come down to having shared goals everyone can understand and all working towards those goals.

To achieve this you just need to do one thing. Finish your modules!

• If you finish "products" then teams don't become product support teams. There is no more work to do on finished products.

• Finished products don't require API changes, they are feature complete.

• With no product teams then all features are cross product

• With all work being cross product, everyone works on the same thing. The companies' goals

Now at some stage you will have built such a huge pile of code that you won't be able to understand all of it. But this is a self solving problem. Instead of changing code you don't understand, you will add new modules and use them instead. Old stuff is naturally deprecated and replaced, or works forever because you never touch it.