The "circular and chaotic conversations" anti-pattern is one that hits DS teams especially hard, particularly DS teams that use the embedded/matrix structure. If a DS primarily collaborates with their PM, eng and design partners, other DS don't benefit from their knowledge.
-
-
Show this thread
-
As far as I can tell, sharing knowledge and context on matrixed DS teams is still very much an unsolved problem. There are tools being developed to help with this, and in time, they will probably solve some pieces of the puzzle.
Show this thread -
I'm skeptical that tools will solve the whole problem, though. Github makes peer reviewing code substantially easier, but peer review is only helpful if people treat it as a serious part of profession of software engineering.
Show this thread -
I will say, I like that article's recommendation to develop a taxonomy of your problem space. Imagine being able to map a DS project a problem space and automatically get relevant upstream knowledge and estimates of downstream impacts. I'd love a tool like that!
Show this thread -
Although now that I'm thinking about it, that sounds a lot like having well-defined user journeys and funnels. Problems arise when two DS don't use the same funnels, or don't know where the funnels they care about overlap.
Show this thread -
Which brings us back to communication. Making sure all the DS on your team have the same baseline mental models goes a long way towards enabling effective collaboration across seemingly unrelated work streams.
Show this thread -
Anyway, developing a shared mental model of your company's problem space IS a serious part of the Data Science profession. I don't know if it's accurate to say knowledge sharing is to data science as peer review is to software engineering, but I feel like there's something there.
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.

