Any manager needs to consider the balance between the size and seniority of their team, but data science managers are more likely to have to consider a third dimension—how matrixed their team is.
-
Show this thread
-
For the uninformed, a matrix org is one where ICs effectively have two managers. Typically, one is responsible for their career and competency in their functional role (the data science manager) and one is responsible for day-to-day task allocation (such as a PM or TPM)
1 reply 0 retweets 6 likesShow this thread -
There’s an idea of manager archetypes that I find compelling, and I think it’s a useful tool for thinking about why matrix orgs are so hard to managehttps://www.patkua.com/blog/5-engineering-manager-archetypes/ …
1 reply 0 retweets 5 likesShow this thread -
To start: for each business area your team is matrixed into, you’re more or less managing a whole new team. That team will have different needs, strengths and weaknesses, and it may require you as the manager to be a different archetype from one of the other business areas' teams
1 reply 0 retweets 3 likesShow this thread -
And even if you are the right manager archetype to match a team or IC's situation, you might be spread across more business areas than you have time to meaningfully engage with
1 reply 0 retweets 1 likeShow this thread -
Having overlap (beyond technical skillset overlap) between the areas your ICs work in reduces some of the pressure on you as the DS manager because means they have more ability to support each other. But it doesn't stop you from getting pulled between the breadth and depth poles
1 reply 0 retweets 1 likeShow this thread -
You can only do so many things at once. Or at least, you can only do so many things WELL at once. Which is to say: I'm not inclined to believe that thinly spread matrixed orgs generate the best outcomes unless all the ICs are pretty senior
1 reply 0 retweets 5 likesShow this thread -
And even then, this is another situation where a lot of pressure is being placed on a single person or too few people. Teams are guardrails that allow folks to take vacation, get sick, or move on to something else without leaving everyone else in a lurch
1 reply 0 retweets 4 likesShow this thread -
Maybe the real takeaway here is that DS teams are usually understaffed. Matrix orgs are an attempt to make the most of a difficult situation, but IMO they require a lot of skill and humility to manage well. The fact that they're so common for DS teams is nuts
4 replies 0 retweets 12 likesShow this thread -
Replying to @imightbemary
I feel like professional settings are missing ways to provide some of these services without attaching 'lead' or 'manager' to the job title.
1 reply 0 retweets 1 like
One thing that might help would be identifying the “design patterns” of DS work. There are a lot of canonical ways to build production-grade software, but I don’t know that those have been identified for DS
-
-
Replying to @imightbemary
That's a hard one. The impostor stuff doesn't help, because people are compelled to try to put a data foot into a production shoe... and data feet seem to be way more heterogeneous than production feet.
1 reply 0 retweets 3 likes -
Replying to @RussellSPierce
While that's true, I can't help but think there have to be SOME common frameworks. The specific data will always be different, but I do find myself constantly reaching for mental models like funnel analyses. It can be extended to a lot of situations
2 replies 0 retweets 2 likes - Show replies
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.

