It's easy to find ways to a feature launch a success, especially if basic metrics are neutral to positive. Who cares if the differences are statistically significant? We shipped fast! We paved the way for future innovation! And it is fun to use and looks great!
-
Show this thread
-
A DS can do tons of analysis to support a product area or launch, but that work could be largely ignored. As a DS manager, you are stuck wondering--was that because the DS failed to understand their customer's needs, or did their customer not use that work for some other reason?
1 reply 2 retweets 21 likesShow this thread -
This happens to engineers too, but it's not as common. Not everyone sees a DS's time as precious. It's not that they don't appreciate it it, but rather that it's a value-add. If DS work doesn't pan out, oh well! We didn't REALLY need it.
1 reply 2 retweets 18 likesShow this thread -
And for Type A DS managers, this makes measuring the contributions and progress of your team extremely difficult. The value your team adds is often realized by influencing someone else to act. It's latent, a second order effect. It takes time to see.
1 reply 5 retweets 31 likesShow this thread -
A consequence of this is that Type A DS work (and management) tends to be more relationship-based. This is a good path forward, since folks are more likely to trust someone they have a good relationship with, but it also means that Type A DS work is less modular.
2 replies 2 retweets 24 likesShow this thread -
Because DS is not essential on its own, the title of DS doesn't automatically convey authority. Customers often trust the individual to advise them, not the office, and this makes rotating people between projects on Type A DS teams difficult to do productively.
2 replies 4 retweets 24 likesShow this thread -
Siloing is a big problem for Type A DS, where one person has gone deep on an area and no one else can fill in. As a DS manager, who's supposed to keep the plates spinning regardless of staffing, this makes it stressful when your team is sick, on vacation, etc.
1 reply 3 retweets 30 likesShow this thread -
It also makes it harder for DSes to collaborate. A team of two horses can pull more weight together than two horses working alone. Engineering teams, which are inherently more modular, function like teams of horses, and Type A DS teams function like individual horses.
2 replies 2 retweets 22 likesShow this thread -
Replying to @imightbemary
This thread is awesome! A Q on this tweet – do you mean that type A DS can't collaborate, or shouldn't collaborate? I'm biased, but seems to me that part of the reason for siloing (assuming everyone is working in adjacent areas) is a lack of proper tooling...
1 reply 0 retweets 0 likes -
Replying to @DeanPlbn @imightbemary
Even if you want to manage people collaboratively you hit a lot of bumpers (in the best case, or walls in the worst) making it harder to share data, artifacts, approaches and results
1 reply 0 retweets 0 likes
I definitely DON'T mean that folks shouldn't collaborate or even that they can't, just that it can be hard. IMO this is mostly because of the domain expertise and relationship-related parts of DS work, although the tooling for DS collaboration is also a factor to be sure.
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.

