Every so often I see a Twitter thread where a new manager asks for advice, and inevitably, someone in the comments below says something to the effect of, "hire awesome people, listen to them and get out of their way"
Let me tell ya, this is not advice. It's wishful thinking
This advice has its roots in the servant leadership philosophy, which holds that a leader’s primary job is to help their people be great at what they do.
I’m not sure how it got introduced to the tech world, but I suspect it is in large part a reaction to the fact that tech leaders often have no idea what they’re doing.
And to be clear, I generally like this philosophy and find it rewarding to manage this way. But it’s not the whole story of people management, and IMO this advice so frequently given because people wish it was how things worked.
The advice that you need to simply stay out of people’s way assumes those people always have the skills, maturity and organizational context to make the right choice for themselves and the company. This is a BIG assumption.
It is your job as a manager to help them get there, but that sometimes means telling them no—that a project they’re excited about is a deadend, that their ideas need more work before they’re ready for primetime, that they actually don’t know better than some coworker they resent
There are times when you need DO need to get in your direct’s way. It may not come naturally to you, but telling people what to do is part of being a manager. It may even be in the IC's best interest, even if it means siding with the company or a stakeholder over them.
Teams and companies are more than the sum of their parts, and managers need to learn to think about how the people they manage fit together and into the company as a whole. This sometimes requires prioritizing the group over the individual, and this can be uncomfortable.
It is especially uncomfortable as a new manager, because the experience of being an IC is still fresh in your mind, visceral. You don't know how to assess your own managerial ability, so you fall back to easiest measurement proxy--how do much do my ICs like me?
Part of what makes people management such a difficult and emotionally draining experience is that you have to stop caring about this. It'd be a lot more fun if all you had to do was cheer on great people, but even great people will lose their way on occasion
When that happens, it's your job to get them back on track. The empathetic mindset of servant leadership helps you build the trust you need to tell them things they might be resistant to, but it doesn't change the fact that you still need to be honest with them.
If you manage people long enough, you WILL find yourself in this situation. You'll go through it many times, in fact, and you will get better at it the more you deal with it.
So yes, listen to your people and be their advocates. But also be prepared to act like an authority figure sometimes, because you are one.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
DS teams' work is often referred to as "consulting," an appropriate term for swooping in and lending your expertise to a group you might not be a permanent member of. I generally find the consultant framing useful, altho at first blush some concepts may not seem transferrable
Take billable hours, for example. Activities that are done in direct service of a client--doing research for their case, planning and executing the work, corresponding with them (in all forms)--the time spent on those things are what you directly invoice your client for.
Any other professional activities you do (like improving your firm's systems or processes, spending time on professional development, or marketing to find new customers) are not things you can charge the client for.
The push to execute quickly--to "move fast and break things" is easy to vilify. It thrashes the team, leads to accumulating tech debt, and tends to be motivated by poorly weighed risks-reward tradeoffs. But IMO, speed is not the enemy as much as a lack of humility is
If you're moving fast to test hypotheses and figure out what works in practice vs. theory, you're going through a helpful exercise of reducing risk. It prevents you from investing a ton of effort into scaling something that leads you straight into a dead end
If you DON'T have a hypothesis or you're not willing to accept that you may be wrong, that's when speed is the enemy
It's fun to speculate about what direction DS as a profession is going, but it's also instructive to dig into how it grew into its modern form. This paper's an example of that, a snapshot from a few years before the term itself was coined circa 2008 projecteuclid.org/download/pdf_1…
The author Leo Breiman (who you may know from such greatest hits as bagging and random forests) talks about going from stats academia to working in industry as a statistical consultant. When he eventually returned to academia, he experienced a sort of reverse culture shock
He frames academia and industry as different cultures of statistical modeling. Both share the goal understanding the relationship of some input variables X an output variable Y. The true relationship is unknown, a black box, but statisticians in both camps aim to approximate it
The surest sign that a company has no idea how to work with Data Science is requesting Insights™ as its primary output. You can tell just from the word--it's vague and sort of mystical, which is not exactly how you want to describe your quantitative teams
Yes, data analysis is about convincing someone (perhaps yourself) that something is or isn't true, but it takes a special kind of talent to do it consistently. It's easier to remember your analyses that changed someone's mind because it's easier to remember unusual events
That's definitely been the case for me, at least. I've done a lot of analysis over the course of my career, and I can only think of a handful that meaningfully changed the conversation around a subject
I remember the first time I made an important decision at work. It was defining a metric a sales team would be using, and I didn't even realize I'd done it until it had already happened.
It was bizarre. I'd always thought people should be listening to what I thought and taking my advice, but this felt very abrupt. They were just going to take my word for it? Wasn't someone going to check my work? What if I was wrong?
This was the first time that I felt like there might be real consequences to me being wrong, and it intimidated me. The fact that people WOULD just take my word for it meant I had responsibility to not say things lightly.
What is the difference between an engineering manager and a data science manager? It's a question I find myself ruminating over almost constantly. There's tons of good thinking and writing about eng management out there, but I don't find that it always translates to the DS world.
Granted, "Data Science" is still a broad cover term, so depending on your flavor of data science, the leap is shorter. One way of segmenting the DS world that relate to is the type A vs. type B DS, where A is for "analysis" and B is for "building"). medium.com/@rchang/my-two…
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.