4 Comments

Someone said the quiet part out loud! Indeed - fix the underlying problem, don't blame the signal...

Expand full comment
Nov 23, 2023Liked by Maarten Dalmijn

I agree, given that the teams work is actually more like 'developing a product'. If it's more like 'providing a service' it's a different matter, primarily because of the different nature of uncertainty attached to that. And sadly that crucial distinction got lost in the rush away from projects towards (so-called) products.

Expand full comment
author

Yes, that's kinda covered in point 3, except I talk about component teams instead of a service team, but the idea is the same. You're serving multiple teams.

Expand full comment
Nov 23, 2023Liked by Maarten Dalmijn

That's true, to some degree. I'd say that component teams are somewhere in between. They - even though they often have more stakeholders - still have more autonomy regarding when to do what kinds of improvements to their component than teams doing primarily service-like work have. At least they can negotiate with their stakeholders, while the reality in more service-like work is, that you either can provide the service NOW or you're considered not being fit-for-purpose. And this in turn injects a kind of uncertainty that's hard to cope with; not to mention what a "goal" for a iteration or increment should be and look like then.

Expand full comment