Hacker News new | ask | show | jobs
by PragmaticPulp 1807 days ago
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.

1 comments

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"