Delegation is hard until you embrace it. It also depends on who you are as a person. If you enjoy taking a step back and being more of a 'manager' it will be easier. If you are still in the mode of always doing the things and getting your hands dirty, it will be harder.
Probably the hardest part honestly. I really like the higher level work but I also love coding. There are days when I'm done with the planning and managing parts and still have an hour left but am mentally exhausted. On those days I go to the bug list and pump out a few fixes to re-energize
Kudos on making it work and getting a head of schedule. Software groups almost never get to say that
Thanks. Unfortunately, we are still at the razor's edge on scheduling. We only have a 3 week buffer before go live which doesn't make me feel great.
I'm (unfortunately?) not at a point in my career where I have been able to delegate work. That said, I do find working in larger teams on the same project to be annoying and a bit frustrating because it means either everyone has their own style of coding and they mess up what I'm doing or we all have to follow a set of standards...which of course means I have to do that too. I get that large project neccessitate multiple people being delegated work but I know it is a hurdle for me to disconnect from feeling personally involved in "my" code.
Some things that have helped me:
1. I developed and embraced a philosophy I like to call "All code is shit". In it, I recognize that at some point in the future someone is going to look at my code and go "this is shit". That person may very well be (and has been) me. My goal is to do the best I can and push that date off as far as possible.
2. Accepting that "perfect" doesn't exist and that "good enough" just has to be it at times.
3. Agree upon a set of coding standards and then aggressively enforce it. I have automated linters for Python, TS, Pug (HTML), and SCSS. If your code fails the linters then it fails the unit test and your pull request can't be merged in. The unit tests are automatically ran and reported. No one is immune.
4. Develop a development and review process that everyone (including yourself) has to follow. Now, for practical purposes I have access to violate that process if the situation warrants it. However, I'd say that 75% of the time I regret not following the process. The key here is that the process is not sacred and can be changed.
Doing the above has really helped me. Coding standards are just a part of group programming. And having worked on a large application that didn't have any coding standards really made me appreciate having standards. Going into a file with 5 different styles really sucks.