Hi, I'm also in the industry and in the same situation. The best life changing advice I can give is to introduce a one week delay between finishing features and releasing them. Adjust your software versioning so that you only release what was done a week ago. You have to stick to that one week delay as much as humanly possible. This gives a lot of confidence and room to breathe so you can enjoy work again.
To clarify, let's say you are asked for a feature. The normal workflow is to determine when it will finish and crunch for the deadline. Once the deadline arrives, you are going to finish and release at the same time and hope that you have done enough testing during development. At this point get ready for embarrassment because you will inevitably make a few mistakes and cut some corners.
What I am suggesting is, you take a bunch of requests, but manage two roadmaps. One is the feature roadmap with reasonable dates, the other one is the release roadmap which lags one week for each feature. So once you release that awesome backtesting feature, you've been testing it internally since a week and finding bugs as you go. Do not release when done with a feature.
Ok, I think I understand better now. We typically turn on the feature for internal users first and then do a gradual rollout using feature flags so it's not as high stakes and can be rolled back easily in case of problems.
Yes, feature flags are technical debt and need to be removed after rollout is complete. But undeployed code is debt, too, and the ability to do gradual rollouts or pull features back in case of issues makes feature flags worth it, in my opinion.
Can you expand on this? What do you do during that week?
This runs really counter to my instincts. The first thing I wanted to do at my current job was move from weekly deployments that were lagged by a week of QA to nightly deployments behind feature flags, so product managers could launch quicker, allowing faster feedback loops.
