
On Teams and Problem Spaces - tysont
http://etherealbits.com/2018/03/on-teams-problem-spaces/
======
mattchamb
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.

------
evrydayhustling
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.

------
solatic
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.

