A) Low complexity & low urgency

Anything which hasn't to be resolved immediately and also has lower complexity should be delegated immediately. You should make yourself available, of course, if the implementor seeks some guidance. Some people like to dig into a topic by themselves, though, and especially for them such an approach generally works great.

If you're anything like me you'll feel really tempted to resolve these tasks by yourself. It could be the case that it's a 5 minute job for you, because you know all the systems and maybe even know exactly which line of code or configuration you'll have to change, and it is a quick win with instant gratification. For the person you delegate this to it might easily take a day or more, since they'll have to familirize themselves with all connected systems. But by doing this the next task, which even might take you a couple of hours, might also take them only a couple of hours.

Still: Always delegate these tasks, unless you are in desperate need for some instant gratification.

B) Low complexity, but high urgency

For high urgency tasks it can make sense that you kickstart the development, since high urgency usually means that the company will significantly benefit immediately from the context knowledge you still have. What I'd suggest is to always offer pairing while you resolve the issue. So even if you immediately start working on an issue others could watch you working on it and learn from it. Not everybody is able to focus on a topic while talking and explaining the context, though. I learned that during my consulting years and this enforces even more focus on myself, so it works great for me.

After solving the issue, maybe while beeing watched by others, you can delegate documentation and even cleanup to somebody from the team, so that they'll hopefuly learn enough about the component to tackle the issue next time.

C) High complexity & low urgency

Issues affecting many components or caused by complex pre-coditions can be tricky. Not everyone is able to understand complex issues in distributed systems and it easy to draw wrong conclusions. On the other hand such an issue can be a powerful teaching tool since it usually allows you to not only explain a single component but illustrate how larger parts of your systems work together. Another reason for high complexity could be very unspecific requirements or a very broad solution space.

In such a scenario (remember low urgency) it makes sense to document and prepare the solution discovery together with a team or a person and leave the implementation to them, while still beeing available for feedback. Depending on the issue it might also be necessary to stay in the loop until after delivery if this could affect data or system consistency. So prepare well together with the team and then leave the execution with them.

D) High complextiy and high urgency

Hopefully these topics are seldom, because they usually also require a lot of focus time, which can be rare depending on your step in the CTO evolution. While the knowledge will have to be transferred evetually the high urgency can require you to work on such a topic. You can also see this as a chance to finally write some code again.

In such a scenario I tend to still implement the required solution myself – sometimes as a deployed proof-of-concept, sometimes as production ready code. What you should do is actively transfer the knowledge to one one of your teams after deploying the solution, while I sometimes fail to do this. If time allows, it of course also make sense to have people watch you solving the challenge at hand.

An example for this could of course be on-call-incidents affecting multiple systems, and there usually will be multiple people already actively involved you can then also teach how such a problem can be tackled.

Summary

Excessive delegation can feel like you don't accomplish anything yourself any more. It can also feel like you're refusing to "work" or are making yourself replacable. While I still miss the gratification from developing and deploying code it is more important to enable your teams since this is the key to scaling your company. And you'll never run out of important things to do, ever, no matter how much you manage to delegate.