4 ms·

> The Team Topologies book suggests to favor teams that are end-to-end, that fully own a problem to be solved, supported by platform teams and teams that manage

> The Team Topologies book suggests to favor teams that are end-to-end, that fully own a problem to be solved, supported by platform teams and teams that manage a very complex piece of technology. Does anyone have first hand experience with this working really well? It seems sensible but in my experience it does not work. The platform teams, I think, should be collaborations between a small number of members from each end-to-end team. The platform would be allowed to grow only as needed by the use cases. As soon as you put a platform team in charge with a mandate, what they build and what is needed starts diverging in the name of "Long term planning". Instead of fixing the struggles of today, they think they have the capacity and formula for fixing the problems of a year from now. In my experience, they do not. Would love to hear from others

qznc 6y ago
I worked in an automotive project where we switched from "subsystem teams" to "feature teams" organization structure in the middle. On the requirements and system test level, it was a clear advantage. For the implementation it was a mess because where we had clear owners previously, it was now a lot of discussion who should be responsible for maintenance. From Jan Bosch, I heared the proposal to have "component owners" in addition to "feature teams". They are senior developers, normal members of feature teams, and explicitly responsible for specific components. This means they should review all code changes from any team but not do any functional changes themselves (as long as they wear the "component owner" hat), just maintenance. This might work. (Unfortunately, he hasn't published this idea anywhere yet. It was an internal talk which I cannot share.)
hinkley 6y ago
Figure out the problems today have happened before, and will probably happen again. Not just the ones people get upset about, any idiot can see those. Fix the ones people blame themselves or each other for. That’s more future proofing than most people do.

qznc 6y ago

I worked in an automotive project where we switched from "subsystem teams" to "feature teams" organization structure in the middle. On the requirements and system test level, it was a clear advantage. For the implementation it was a mess because where we had clear owners previously, it was now a lot of discussion who should be responsible for maintenance. From Jan Bosch, I heared the proposal to have "component owners" in addition to "feature teams". They are senior developers, normal members of feature teams, and explicitly responsible for specific components. This means they should review all code changes from any team but not do any functional changes themselves (as long as they wear the "component owner" hat), just maintenance. This might work. (Unfortunately, he hasn't published this idea anywhere yet. It was an internal talk which I cannot share.)

hinkley 6y ago

Figure out the problems today have happened before, and will probably happen again. Not just the ones people get upset about, any idiot can see those. Fix the ones people blame themselves or each other for. That’s more future proofing than most people do.