[atmartins]

It sounds like you're a holistic or big picture type. I struggle with this too. I don't have all the answers but my advice would be to try and focus on a smaller thing and get a win with that. Don't propose several projects, propose one and give it enough attention and proof that it's hard to refuse. Are your proposals measurable? Are they valuable? Are they framed in business context?

If more is thrown at you, push back using phrases like "adding this initiative may put effort #1 at risk. I think we should concentrate on effort #1 a bit longer while #2 takes more shape"

Why are your PRs not being approved? Do you need more time pair programming so what you submit is more aligned with reviewer expectations? Have you asked for that pairing time?

Overall I hear two disconnects, one at a business/product level and one at the engineering level. Your expectations sound out of alignment with your peers. You might try and work on relationships, build trust, find the fun puzzle and try and enjoy any little bits you can.

[burnoutgal]

I'm definitely struggling with finding the one big thing I should focus on. My team has a few objectives for the coming year, but it's unclear who actually owns them or how to get involved. We have a new manager coming in to replace the one who left, but the timing is not great given how long I've already been treading water.

PR approval is mostly down to not being able to get any person to actually +1 - our deploys are pretty slow and high-risk right now, and if your project isn't important it just kind of seems to hit a wall. The code itself is fine, but nobody cares about the result (even though I've talked to them about the benefits and they agree).

[rendall]

> our deploys are pretty slow and high-risk right now

This could be a potential focus? Everyone loves continuous integration. What would it look like for every team and every project to deploy confidently? If you could be instrumental in getting that going, every single dev and manager would be thankful

[legerdemain]

Oh jeez, that sounds oddly familiar!

Right before the pandemic I joined a large company you've heard of. My boss was mostly absent - I talked to her maybe four times during my entire stay. We were actively hiring for an intermediate lead to take the load off her.

My teammates had no idea what to have me do. We operated a confusing distributed workflow that touched many teams. Changes and deploys were seen as risky, but failure was also constant, and my teammates spent a lot of time shepherding various parts of the workflow manually. The whole thing had lots of dependencies that were owned by different teams, and none of them felt the need to take on the risk of approving each other's changes.

I ended up leaving after a couple of months. Satisfyingly, the company went on to lay off 20% of its engineering staff right after, including the intermediate lead we had just brought on. I managed to fall back onto another offer I had received earlier in my job hunt (and then left that position about a year later for similar reasons).

What I took from the experience is that not only do a lot of software teams treat hiring as a mystical ritual full of supernatural risk to their very existence, but they also don't have a clue about what to do with a new hire. That's also a mystical ritual, in which they want you to somehow "get absorbed" into the team without any explicit planning or guidance on their part.

Some teams (some) have wish lists of project ideas and tasks that they wish they had the bandwidth to work on. Other teams at least have bug queues that range from bugs appropriate for new hires to much more general issues that take planning and triage.

But a surprising number of teams hire as a means of throwing spaghetti at the wall to see what sticks. Maybe the lead is frustrated with the pace of work. Maybe the team has an unfilled FTE role and they don't want to lose it. So they end up hiring someone because (a) you must always be hiring, duh, and (b) not filling that FTE vacancy means your team loses the zero-sum competition for prominence with other teams.

In my experience, I would have probably unearthed some red flags, had I dug in more. There are usually red flags in the hiring manager's description of what they want a new hire to accomplish. I now know what to look for, I think (basically, comments suggesting that your job, as an IC, is to "transform" things or even "blow them up!").

What would I have done if I had to stay? Well, sometimes dysfunction works well for all parties involved, and that would have been mind-numbing. But I would have gambled on the possibility that painful, risky deploys and unclear success criteria were a pain point for everyone. That means work on metrics, tests, and the tooling for them. It means building reliable rollback and faster deploy. It means building parallel testing pipelines. Overall, when there is chaos and lack of buy-in, one possible solution is to build stuff that demonstrates usefulness without a need for buy-in. I wasn't eager to build any of those things. I had another opportunity, so I took it and left.

My guess is that your experiences are only partially connected to who you are as an engineer. A lot of teams are just disappointingly unprepared to use a new hire. Some people do thrive in such environments, either thanks to past experience or a quirk of personality. Given the opportunity of unformed chaos, they build projects that they know can't fail and then deliver on them. You might not have that confidence or experience. If you want to get more resilient to this kind of situation, either keep rolling the dice with new teams (they can't all suck at onboarding!), or find ways to use dysfunction as an opportunity to show off your initiative and experience.

[rendall]

> ...would have gambled on the possibility that painful, risky deploys and unclear success criteria were a pain point for everyone. That means work on metrics, tests, and the tooling for them. It means building reliable rollback and faster deploy. It means building parallel testing pipelines. Overall, when there is chaos and lack of buy-in, one possible solution is to build stuff that demonstrates usefulness without a need for buy-in.

Absolutely excellent advice.

I would start by getting consensus on process. Hit up the main engineering chat channel and describe the issue you want better. "Deployment is painful and bug prone. In order to get code to production, first we have to..." Of course use neutral, non-judgmental language - this is the process that has emerged, no one's fault. This is an engineering problem to be solved. Next, ask for thoughts and opinions. You could suggest your own if you think it will help, but it's about building consensus. Just starting these conversations can be enough sometimes. But you can take it to the next step and actually build the tools that are suggested.

[burnoutgal]

I've commented elsewhere, but this is a >1000 person company where deployments are owned by a dedicated team. There's a lot of technical debt involved, but my team is pretty far removed from it, and there is also necessary complexity. Dropping in and proposing a new process isn't really feasible.

[legerdemain]

I'll just come out and ask: is this literally Palantir?

[burnoutgal]

It is not. As many people have pointed out, this seems to be a ubiquitous pattern in high growth companies that I assumed was unique to my last big startup