My suspicion is that most eng management advice can apply to Type B DS management pretty readily. Their work is more purely engineering. But what does that mean for Type A DS management? What makes it different and thus hard to apply the same advice to? I have some thoughts.
-
-
Now, this all might sound like a lament, but I'm not necessarily saying that it's a bad thing. Type A DS teams are viewed as important (maybe even essential) partners much of the time, and an embedded, verticalized team structure usually generates good outcomes for a company.
Show this thread -
It's not bad, but it is different. There are some days where I what the hell my job as a DS manager is even supposed to be, but thinking through the differences helps bring me some clarity.
Show this thread
End of conversation
New conversation -
-
-
Great thread. Another angle I've experienced is that the relationship between effort and output can be non-linear for eng, but in Type A DS it can be wildly so. Can in fact be a step function when that last cut of the data yields THE critical insight.
-
This is very very true. That's why it's so important to share work with stakeholders early and often. You can get the feedback you need to know what they care about and will find useful, and focus on doing that
End of conversation
New conversation -
-
-
So part of what I think a DS manager often brings is the perspective and judgment of when to stop and move to the next question. When to pull the analyst out of the rabbit hole (because frankly, analysts kind of like it in there and rarely climb out on their own)
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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.

