| 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. |
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.