Delegation is hard, but this might help you
First published at Tuesday, 7 February 2023
Delegation is hard, but this might help you
This is a blog article out of a series where I reflect on what I learned during funding, growing (, and selling) SaaS product companies. While I write those things down for myself, since I believe self-reflection is a crucial learning tool, I also want to share my thoughts with anybody who might be interested. I'm looking forward to your comments on any of these topics. An overview of all related topics can be found below. I have a bunch of these blog posts lined up, so you also might want to follow me if you like this one.
Founding and growing a company naturally is an interesting development in many regards but one stands out, maybe in particular for technical founders: In the beginning you create the stack, write code, automate your infrastructure but at some point you scale teams and (almost) don't write any code any more. While you, at least for some time, might still be the person who knows most about the stack and might even be most efficient in implementing features or understanding and fixing issues (most likely because you caused them in the first place).
So how do you learn to delegate and learn what to delegate when? And when are you still allowed to do something by yourself and, for a moment, delay transfering knowledge to your teams? How to make sure all relevant knowledge about the stack is transferred to right people, so that your teams are able to take responsibility for those components in the future.
You'll find quadrants for basically anything, but this time there was one which helped me to think about this in a constructive way:
There are four sections in this image (suprise, it is a quadrant), so let's look at them one by one:
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.
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.