I'd say that startups sometimes get away with focusing on getting things done over having processes in place, but even then it's not a good choice long term, es

I'd say that startups sometimes get away with focusing on getting things done over having processes in place, but even then it's not a good choice long term, especially in more established companies. I've also seen plenty of environments where onboarding and documentation aren't given a high priority, which I'd also suggest are red flags - such environments are more likely to make you struggle with things because someone couldn't be bothered to document their architectural choices, pipelines or anything else, therefore preventing you from delivering results. This sort of technical debt compounds and will make things harder as the project and architecture complexity increase. At best, you learn a lot and implement a lot of good practices, at worst, you end up underperforming in a dysfunctional environment where an increasing portion of your time is spent fighting fires. In most cases, if you want to see any actual changes, you have two choices: either change the company, or change the company. The former could involve encouraging your colleagues to at least write simple Markdown docs and instructions, you or others leading internal seminars or workshops in which you could explore certain tools or development practices. The latter would involve you updating your CV and seeing what other companies are hiring, while attempting to figure out how good their practices are during research or interviews. Personal advice: make sure that your efforts and the amount of stuff you do are very visible to both your colleagues and management. Talk about database outages or times you had to administer environments, do post mortems, inquire about possible improvements and back up the need for them with data involving how many hours were needlessly spent on that stuff.