On Teams and Problem Spaces (opens in new tab)

This is relevant to my current situation.

I was previoiusly working with a group of teams that had whole ownership of a certain product. The teams had certain areas of the product that they focused on, but all could contribute to different areas and we had a high degree of autonomy and ownership. As such, the problem scope was defined by the name of the division, and within that the team name didn't matter so much because we were all in the same office.

Now, one team has been created in our office (40 person remote office as part of a 1500 person org) to work on our parent company's enterprise offering, and we are the remote team far away from the rest of the company. Now, we are working on a project with lots of other teams we have little direct contact with; all who have highly focused ownership if different areas.

What I have found is that since these teams also have names don't relate to what they are working on, it is very difficult to know who has ownership of what since it is now very hard to cross those organisational lines.

Interestingly though, having been moved onto this work where we have very little ownership, our team name is one thing we could control.

I guess what I'm saying is that team names don't matter much, until suddenly they do.

It can be really tempting to build teams around capabilities, not problems. For example, a data science team can hire data scientists, invest in data tools, talk and hold standards about data science practices, etc. BUT, if you do this, solving any problem requires gathering people from many teams with the various skills required.

I'm a big fan of product teams that include people from several functions, organized to solve the same problem. Many internal functions can be characterized a products with internal customers. The need to promote functional expertise can be met by guilds or functional reporting lines outside the product teams.

If you have problem-solving teams instead of solution-providing teams, ultimately your problem-solving teams will reimplement the same solution multiple times, each time for their individual problem, for the overlapping parts of the solution to their problems.

Whether your organization can tolerate that kind of duplication largely depends on your organization and what kind of problems it needs to solve. Sometimes that kind of duplication presents governance problems which are unacceptable within a given regulatory environment. Other times, both implementations reach customers, and your customers are wondering why they need separate accounts for each of the company's products and why there isn't a unified UI across the company's products being driven by the company's brand.

It's important for organizations not to dismiss duplication out of hand as a form of waste, but it's also important to have a handle on what kind of duplication is going on to make sure that it doesn't conflict with the company's responsibilities or mission.