I recently started a new job and things were going well until I encountered a challenge with one of the higher-ups. This lead has been pushing changes into our production pipeline without consulting the team first, which has created a frustrating and exhausting situation. Despite voicing my concerns, he seems to be doubling down, encouraging my team lead and others to follow his lead without proper communication. As a result, my team of four is now working in silos, with our DevOps team turned into just a support team on call, leaving us barely any time to actually develop tools.
I've tried to introduce practices like a staging environment and proper testing before changes go live, but these suggestions have been ignored, leading to a constant barrage of emergencies each morning as we scramble to fix things that could have been avoided. Management insists that modern development is about "moving fast and breaking things," which feels demoralizing because there's no accountability on their end, and we bear the brunt of fixing issues. It seems I can't change this culture, and since leaving isn't an option for me now, I'm looking for ways to maintain my sanity while navigating this mess.
5 Answers
It might help to direct people to create tickets when problems arise instead of reacting immediately. If they want fast changes, they should be prepared for the consequences. Logging everything can help your lead realize how unsustainable this pace is.
You mentioned that they seem behind the times. The whole idea of 'move fast and break things' might have worked a decade ago, but now it’s more about 'move fast with stable infrastructure.' Maybe you're dealing with people who aren't up to date?
I feel for you! Documenting issues clearly can really advocate for better processes later. Find small wins in your workflow to keep your morale up, as it can be easy to feel overwhelmed in such a chaotic environment.
I've been documenting issues, but I feel like my efforts are just noise to the higher-ups; they want solutions fast, not details.
It sounds like you're in a tough spot! My advice would be to let some things break intentionally. Maybe hold a post-mortem discussion on what happened and make it a learning experience, even if they don't usually do that. It can be quite liberating!
They don't do postmortems? That's frustrating, even more reason to document everything when things do break.
Modern development is all about building confidence in your code. You can’t just rush through changes without testing and expect everything to work perfectly. Your lead's approach sounds reckless. Keep your own work tidy and ensure you document every issue, so you're not blamed when things go south.
That’s great advice! Keeping your work documented will help you show that you’re doing your part, even if others aren't.
I try to log everything too, but it piles up quickly because there’s always a new fire to put out.