Pay Down Process Debt
The concept of "tech debt" is all too familiar to most engineers. You make sub-optimal technical trade offs in order to get some other benefit. There are many situations where this makes sense; you skip addressing some edge cases to hit a tight deadline. But like financial debt, while it can be advantageous to take on, it does need to be paid back.
"Process debt" is similar. It involves working in ways that involve trade offs that benefit present needs. One of the most common artifacts of process debt is recurring meetings. Someone may have set up a frequent recurring meeting when high bandwidth communication was important for a certain stage of a project, but nobody ever thought to cancel the meeting once that need was no longer there. Don't just keep that meeting on your calendar out of momentum.
Process debt can also come from responses to past problems. Perhaps after a streak of bad deploys, your team instituted a rule that no code could go out until a manager approved the PR. Maybe this rule is still helping, maybe it isn't. The important thing is to revisit and evaluate the costs and benefits of this policy. Rules don't just exist to be followed, they need to serve the team.
Make sure you're always paying off process debt by questioning and evaluating if your processes are still serving the team.