Operate on simplicity
It's easy to get seduced by complexity. The more simple the operational structure of your team, the more productive you will be.
Problem Statement
We are spoiled for choice as developers these days. There is no single solution for anything anymore. This freedom for choice brings substantial risk to team productivity and, by extension, your business prop overall.
These choices plague us every step of the way, from "dev ops" and infrastructure to what I like to call "work ops" to bonified work on your team's actual software deliverables.
These complexity quagmires keep us dev teams from not just being productive, but from feeling productive, which I argue is just as detrimental to overall team effectiveness.
Fortunately, there is a simple way out.
What to do about it
Here's what I've seen work before.
1. Identify your team's core value-add.
What are y'all here to really do, anyway? Is it to add a new, shiny multi-epic feature? Is it to squash bugs and raise product quality? Is it to improve site performance? Remembering what you're there for is a critical first step.
And yes, these objectives can change by quarter or by month or by sprint or what have you. But generally it's good if the team has one objective, and only one, to focus on for any extended (week or longer) period of time.
2. Push back on everything your team is doing that detracts from your core value-add.
Are you working on a feature with a deadline and are then solicited to bugfix an entirely different portion of the app? Push back (or at very least, get an extension on that featture deadline).
Are you finding that your team is spending 10 minutes+ to push a test deploy, and the deploy consumes your devs' workstations for said period of time? Find a way to offshoot that, pronto (I've been looking into remote docker builders lately for precisely this purpose).
Are you wading through a bureaucratic QA process represented by a complicated flow diagram in a shared Google Drawing that has become a recent new requirement to get anything done? Yep... do what you can to simplify this into as concise of a workflow as possible.
Drawbacks
Sometimes your product is so darn complex that added complexity is required. That's just a fact of life. But complexity is a liability that compounds super-linearly with time, with personnel changes, and with other complex parts of your job's day-to-day.
Conclusion
In my experience, whether it's from collective self-importance, or a way to combat imposter syndrome, or a cynical take on job security, or maybe because we're just engineers working in isolation and, hey, look, we over-engineered ourselves again, teams frequently have a tendency to over-engineer. Which plays into the over-promise, under-deliver nightmare we've all experienced.
Complexity may scratch the "coolness" itch some members of your team may have. But to the extent that you can, resist it. It is my strong conviction that the simplest solutions, the ones that enable you to nimbly make changes and get out, are the most valuable.