Thanks for this. I wasn’t aware there are names to those tasks, I was doing this instinctively as I was thriving to enable the team to be more agile and less into the how. However, when we see teams that are having a “no collaboration “ policy, rotating people might not be a bad ideea. I found it a tool to ensure people need to collaborate and also ensure we don’t have one point of failure for each area.
One points of failures are dangerous. Its a good idea to rotate people across teams, and also to encourage paired-learning / paried-coding so that no one individual is solving the problem by themselves.
Thanks for this. I wasn’t aware there are names to those tasks, I was doing this instinctively as I was thriving to enable the team to be more agile and less into the how. However, when we see teams that are having a “no collaboration “ policy, rotating people might not be a bad ideea. I found it a tool to ensure people need to collaborate and also ensure we don’t have one point of failure for each area.
One points of failures are dangerous. Its a good idea to rotate people across teams, and also to encourage paired-learning / paried-coding so that no one individual is solving the problem by themselves.
Loved the post.. Gives a good mental model to think about forming product teams in a very MECE manner..
Thanks Ankur! This is almost first principles thinking to organize product teams.