"Everyone knows, don't deploy on Friday."
This isn't rocket science, but I still hear way too many teams say that you shouldn't deploy at 4:30pm on a Friday.
Or before a long weekend. Or any number of other occasions.
If this is a statement that your team is regularly making you need to start deploying exclusively at 4:30 PM every day, but especially on Friday, until it no longer scares you, and no longer hurts. Change your process until literally everyone on the team is comfortable deploying anytime.
As an individual member of the team you may look at this and say:
I'm paid to ship new features, not fix the deployment pipeline.
You'll be able to ship features faster today, and in the future, if you feel confidence in your pipe.
If you're not confident in the deploy process, automate the process.
If your deploy process takes too long, make the necessary changes to ensure it can be deployed and validated inside 10 minutes.
If you're not confident in your changes not breaking things, beef up the test suite, make the change smaller, and use feature flags.
If you're not sure if things are going wrong and you just don't know it, improve error monitoring, observability, and logging, etc.
If it's your PR and it's got an approval, but you're not sure, don't merge it. Better yet, ask why you put it up in a state where it could potentially be approved and merged without you feeling comfortable with it.
If you've done all of the above and still aren't feeling confident, but you can't figure out how to further de-risk it, don't approve it during code review, and don't merge it if approved. Ask your team for ideas.
Just keep doing it. Eventually you will be in a place where you do things differently enough that you can do this confidently. So you don't have to stay late, and you don't have to stress about if this set of changes is going to break things.
The fear of deploying late on Friday isn't about Friday. It's about all of the other things your software development process is lacking. Make the changes so that your team feels confident about deploying the changes they've made.