One habit I built during my early days was to read design docs, even if they did not belong to my team. The first thing I did after joining Amazon, back in 2016, was to go through their internal Wiki portal. The portal hosted all the public design docs and documentation written by various teams. The portal was a goldmine of information.
One thing that I absolutely love about design docs is how practical they are. The designs are not just some random set of boxes drawn on a piece of paper, but rather they contain highly practical approach to solving a problem and the solution will be shipped to production.
With multiple engineers writing them and several tech leads reviewing them, these docs hold all the required context, trade-offs made, alternate designs, implementation nuances, and potential pitfalls. Reading them gives a deeper understanding of the domain, the problem, and the system.
To be honest, I was initially quite overwhelmed reading them. But over time I got used to it and started connecting the dots. So, if you try to do this, do not be discouraged by the initial complexity, because things will get easier over time.
So, if your company also practices writing design docs, do spend time reading them, even if they are from different teams. If not, then be the one who initiates and drives this process.
Forming a habit of reading design docs consistently, rewired my thought process and made me a better engineer; hence I would highly recommend you pick this habit up.