New subscriber, long time reader - love your work. One thing I could suggest to make your content go above and beyond, is to have a git code version of your concepts outlined. Even just a really simple overview of how some of the key concepts are brought together (e.g. an automated retraining pipeline). Obviously an entire project with the end to end integration of components etc. all built out is a pipe dream, but just some code examples of key aspects of your articles would be awesome!
Hey Matt! Super glad to see you join the family :) when it comes to hands on, I will be doing all of it as part of premium content. And yes, it will eventually be an end-to-end project built step by step.
Awesome! Exciting times ahead. Looking forward to digging into the details. Also another side note, I really love how you overlay governance/operating model views over your solution architectures, it’s a very nice touch!
I tend to agree with what you’ve outlined here Aurimas.
The benefits you’ve listed are in my mind some of the strongest indicators of successful organisations, particularly those in environments that reward rapid innovation. Collocation ultimately reduces a lot of wasted effort, which should positively impact quality and velocity.
The challenges are also big headwinds, and something that any team looking to try this approach must be fully aware of. I think they are also ultimately solvable challenges, with perhaps the toughest being that of finding a single threaded technical lead for the team. Maybe that’s not important? Having an ML lead and a technical lead that can collaborate may solve for this without the hunt for an elusive jack of all trades (this has its down sides too).
The reason I made this comment is that I have just finished a 3 week project where we collocated and the results were really quite amazing. We were able to move quickly, and the empathy you speak of missing... well by working together we learn to understand one another. Happy to keep diving into this with you as I think it’s a fascinating pattern that may yield great results.
What benefits/costs do you see to further integrating the ML capability into the one product delivery team and removing yet another team boundary? The coordination of multiple teams almost inevitably creates waste in the value cycle, but is it worth the cost of increasing the scope of a single team for? I’d love to hear your thoughts.
Hi Bradley, thank you for bringing up the question!
Benefits:
- Even less handovers happening in the organisation.
- Improvement of Product/Project owners communication.
- Knowledge sharing.
- Interface contracts managed in the boundaries of the same team.
- Release cycles, A/B testing configuration managed in the same team.
Costs:
- A single ML model could be used by several projects, if we embed the creation of the project into the product delivery team it might not be efficiently exposed to a wider organisation.
- It has been shown that the size of a team that delivers software should usually not exceed 8 people, unless the organisation has extremely strong trust culture. More members create unnecessary communication channels that build up excessive cognitive load. Unfortunately, in most cases it is unrealistic (for a larger project) to fit into the constraint of 8 people if you want to have ML and non ML capabilities inside the team.
- ML Practitioners and Software developers are very likely have little empathy for each other as they are coming from different backgrounds. Managing such a team might be complicated.
- Finding a Tech Lead that could oversee architecture of the entire end-to-end flow on a deep enough level might be difficult.
This is what comes to my mind now, there are more of course.
New subscriber, long time reader - love your work. One thing I could suggest to make your content go above and beyond, is to have a git code version of your concepts outlined. Even just a really simple overview of how some of the key concepts are brought together (e.g. an automated retraining pipeline). Obviously an entire project with the end to end integration of components etc. all built out is a pipe dream, but just some code examples of key aspects of your articles would be awesome!
Hey Matt! Super glad to see you join the family :) when it comes to hands on, I will be doing all of it as part of premium content. And yes, it will eventually be an end-to-end project built step by step.
Awesome! Exciting times ahead. Looking forward to digging into the details. Also another side note, I really love how you overlay governance/operating model views over your solution architectures, it’s a very nice touch!
I tend to agree with what you’ve outlined here Aurimas.
The benefits you’ve listed are in my mind some of the strongest indicators of successful organisations, particularly those in environments that reward rapid innovation. Collocation ultimately reduces a lot of wasted effort, which should positively impact quality and velocity.
The challenges are also big headwinds, and something that any team looking to try this approach must be fully aware of. I think they are also ultimately solvable challenges, with perhaps the toughest being that of finding a single threaded technical lead for the team. Maybe that’s not important? Having an ML lead and a technical lead that can collaborate may solve for this without the hunt for an elusive jack of all trades (this has its down sides too).
The reason I made this comment is that I have just finished a 3 week project where we collocated and the results were really quite amazing. We were able to move quickly, and the empathy you speak of missing... well by working together we learn to understand one another. Happy to keep diving into this with you as I think it’s a fascinating pattern that may yield great results.
Did you have Software Engineers collocated with Data Scientists?
What benefits/costs do you see to further integrating the ML capability into the one product delivery team and removing yet another team boundary? The coordination of multiple teams almost inevitably creates waste in the value cycle, but is it worth the cost of increasing the scope of a single team for? I’d love to hear your thoughts.
Hi Bradley, thank you for bringing up the question!
Benefits:
- Even less handovers happening in the organisation.
- Improvement of Product/Project owners communication.
- Knowledge sharing.
- Interface contracts managed in the boundaries of the same team.
- Release cycles, A/B testing configuration managed in the same team.
Costs:
- A single ML model could be used by several projects, if we embed the creation of the project into the product delivery team it might not be efficiently exposed to a wider organisation.
- It has been shown that the size of a team that delivers software should usually not exceed 8 people, unless the organisation has extremely strong trust culture. More members create unnecessary communication channels that build up excessive cognitive load. Unfortunately, in most cases it is unrealistic (for a larger project) to fit into the constraint of 8 people if you want to have ML and non ML capabilities inside the team.
- ML Practitioners and Software developers are very likely have little empathy for each other as they are coming from different backgrounds. Managing such a team might be complicated.
- Finding a Tech Lead that could oversee architecture of the entire end-to-end flow on a deep enough level might be difficult.
This is what comes to my mind now, there are more of course.
What is your take on this topic?