Working at a high growth startup. Often end up feeling burnt out.

Do you feel like the growth of the engineers is reflecting more the growth of the company and not the engineering culture? If the team skews fairly young & most folks spent most of their career at the company, their view of the world is narrowed down to what works for them at the company.

Instead of rolling with the existing system, why not try to fix a small part of if? If you're serving as a TLM (tech lead manager), there's a clear line of influence on the engineers around you. If you don't think you can get buy-in from upper management to fix things, then just fix it first and then tell them later. There's a clear opportunity with the DB updates: why not get your team to make the deploy faster?

There's always a hypergrowth and/or high-paying company out there, but you only get one life. You can't work hard to make money when you're dead. If it's starting to look like the stress is causing long-term health issues, just quit.

The incentives at this company feel wrong -- ideally, you want bad news to be shared widely and quickly, since that's where you get max learning. (Meta and other Big Tech cos are famous for having blameless post-mortems.)

Can you share this idea with your manager or other leads? Talk about the negative impacts you see, both on yourself and others on the team. If you outline the damage caused, and you propose a viable solution that you're willing to spearhead, you'll get a lot more traction for your idea.

If you feel like the culture is not fixable (or not worth fixing), can you give yourself an end date? If you tell yourself that you're going to simply grit your teeth and get to the 1 year mark, for example, that may make the situation more tolerable.

See also: How can I have less burnout and better work-life balance?

The founder mentioned financial implications on EMs whose systems see outages. Thus, people started hiding outages. Managers asked folks to move alerts from P1 to P2/P3 so that they dont get flagged to the CTO and there are no financial implications. Postmortems happen but are limited only to issues which impact user journey and see social media escalations, thus are not hidden.

I would definitely flag something like this up the management chain. Of course, don't call out anyone, but it's a failure on the system because it incentivizes hiding outages and downplaying the impact that outages have. I wouldn't blame it on the individual managers because it's just the system that they are forced to play in.

I would look into adopting and evangelizing a blameless post mortem culture. If people are scared of causing incidents, velocity will slow down and engineers will try to hide any incidents, as you've seen. Incidents should be seen as an opportunity to build up resilience in your engineering systems and processes.

Most of the DB upgrade activities / deployments happen late night. Thus, while the day starts at 10-11 AM. It continues till 3 to 4 AM in late night. This has caused my health to deteriorate severely. When mentioning that this is causing my health to deteriorate, he mentioned that this is baseline expectation from leads / staff engineers. I am still trying to come up with ways to get these deployments done in day as well like adding redundancy. I have started having occassional fever / headaches due to this.

I would definitely flag this to your manager and write up a preliminary doc about addressing this. If you are feeling this pain, there's probably a lot of other engineers that are feeling it, too. You'll be celebrated among your peers if you can solve this problem. Is there a reason that everyone has to stay up in the night? In the short term, is there an oncall schedule people can rotate monitoring the database activities go smoothly. In the long term, I agree with you about adding redundancy to ensure a database failure doesn't ever get surfaced to the user. It's good practice in general especially at the scale that the company is operating at now.