[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