Comment by czep | Hacker News Reader

Comment by czep | Hacker News Reader

This is so eerily familiar I swear I've had many of these exact conversations word for word. The only way this doesn't turn into a complete nightmare of a cluster is if the exec team "gets it". If so, you just might stand a chance at building a data team that gels with the rest of the org.

But if the exec team simply hired you for window-dressing, expect to be treated like a scapegoat and a punching bag. Any mistakes will be your fault. Any wins will be to the credit of the business. The Director of Product will ask to "embed" dedicated DS headcount and you won't have any real power to shape the roadmap. If the exec team doesn't give you equal footingf with Product (or Marketing, Finance, and Eng for that matter) then this will rapidly become a soul-sucking job. However, if E-team does give you the authority to call Product's bullshit, and tell Finance to stuff it, and not take direction from Eng leads, then you actually might be able to accomplish something really cool.

This applies to most specialties. Companies tend to have a few teams that lead the charge and expect everyone else to follow. Knowing which teams get the authority and which teams are along for the ride at a company is important for knowing what your job experience will look like.

> However, if E-team does give you the authority to call Product's bullshit, and tell Finance to stuff it, and not take direction from Eng leads

I know this was meant partially in jest, but if you reach the point where you're at odds with all of the teams and departments in the company you may get a lot done in the short term, but long term it's going to be difficult if you don't have some allies in each of those departments. Obviously no one should roll over and take orders from other departments, but some times it's necessary to do some give and take to build rapport. It's a balance, not a war.

Thanks for the tips! One mantra I've tried when starting at a new job is "for the first 3 months say yes to everything, for the next 3 months say no to everything." The idea is you first immerse yourself in everything, to find out what works and what doesn't. Then you dedicate time to fix the broken processes so that hopefully when you hit 6 months your team is better positioned to be more efficient. Obviously you can't be too rigid, but it seemed to work for me when I had buy in. Curious if you think that approach sounds good.

Good advice as long as you don't take it too literally.

The most important thing is to work closely with your manager on expectations. If someone from another department comes to you with a proposal, an ask, or a directive, you don't want to say yes without first consulting with your manager. Depending on company politics, some managers might try to rope new employees into doing work that isn't actually part of their job description.

Discovering expectations and then proactively managing those expectations is key in any role.

Very good advice. I've also seen this from new ICs (incidentally from one of our new data guys). I bet he said yes but he shouldn't have.

New guy, knows nothing about the company and product yet but was asked to "get KPI X by end of day". He obviously has no idea how to get this done so goes to various people and throws around the "VP XYZ wants this by end of day, help me now or else!".

Needless to say I, as politely as I could, told him to shut it, look at his data and what he could get from it and stop interrupting dev with mid day, two days after start of a sprint, requests to do his work for him (dude I don't even have access to your data storage, don't know what data you have or don't etc). And do it by end of day. Sure.

The guy is burned for me now. He will have to do a LOT of sucking up to dev now for his try at "do my job for me or else"

This was my only complaint about this great article. The CEO was innately "data-driven" which opened a lot of doors.

OTOH, if the execs don't have this priority, no one gets hired to lead and scale a data team and the story never starts.

In my experience much of this is a question of trust, political capital and soft power. Find out the problems that the key players in the business are actually having that you can solve and then solve them. Find out what the key KPIs are for the business and make a plan to improve them and then have a plan to publicize that improvement. And make sure to hire a team that covers your weaknesses rather than exposes them. Don't fight people if you can help it, either they're as competent as you on average or you shouldn't have taken the job. Figure out how to help them and what they need to work more efficiently and then give it to them. Sure there's a ton of politics involved in all of that but that's management in general.

> However, if E-team does give you the authority to call Product's bullshit, and tell Finance to stuff it, and not take direction from Eng leads, then you actually might be able to accomplish something really cool.

So what's the business case for having a data team independent of product, business and engineering?

Because as I see it the data team is a support function not q core part of the business. I'm sure it can be cool for you but if you are at odd with all the people actually creating value, what exactly do you bring to the table?

Engineering is building some schema, creates and uses multiple data stores , message queues, etc, eventually the queries do not longer work properly as the company scales and gets more and larger customers and hundreds of other issues. Doesn’t engineering need a proper data engineering team/dba/you name it to handle those?

Reply on news.ycombinator.com