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 -
As a type A DS manager, it makes you wonder if you're really managing a team in the same way that an engineering manager is managing a team. There's less of a shared identity. It's hard to say what you're doing as a TEAM, rather than as individuals.
3 replies 3 retweets 24 likesShow this thread -
Replying to @imightbemary
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.
1 reply 0 retweets 1 like
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
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.

