I've been recently asked by a fellow engineering manager what was my framework for delegation, and it got me thinking about how to boil down what I believe to be good delegation into a few principles. There's plenty of literature out there on what good delegation looks like. Still, I never spent time synthesising what I believe to be good delegation into something as simple as a set of principles.
In essence, the best examples of delegation I've experienced shared a few characteristics. As the delegator, I could focus my energy elsewhere; I had the right level of involvement when asked for guidance and got to the expected outcome through the delegatee. Similarly, as a delegatee, I got opportunities to work on challenging problems and figure them out myself; I had the right level of support whenever I felt stuck and was held accountable for the expected outcomes.
The pattern is pretty clear: the best delegation examples I can think of combine moving autonomy and accountability simultaneously from the delegator to the delegatee. I boiled it down to three principles to help myself reproduce the pattern I believe to be good delegation:
§Delegate problems rather than chunks of a solution
Most of the time it is a bad idea to delegate with a lot of structure. If you have to break down all steps to get to the solution, it probably means you're still solving most of the problem yourself. Work is like a hill and a lot of it is in figuring out what to do. Incentives are not aligned if you delegate with too much structure: two of the primary outcomes you get from delegating to others is exposing people to a learning experience and freeing up yourself to focus your attention elsewhere.
When delegating with too much structure, you're likely not fulfilling neither. Firstly, learning is limited as most of it comes from figuring out how to break the problem into a solution. By coming up with a set of instructions to get to the solution yourself, context transfer to the delegatee can end up being even more expensive than letting them figure out what to do themselves.
Conversely, framing the problem well and clarifying why it matters usually leads to much healthier dynamics and better outcomes. By delegating a well-framed problem, you're much closer to exposing the delegatee to learning and getting to an outcome where you have less involvement.
§Define clear boundaries for the problem you're delegating
Besides framing the problem clearly by defining why it matters, defining the constraints for the problem to be solved, and aligning on the expected outcome are equally important.
For instance, not being aligned on inputs such as priority and timelines are a recipe for loose accountability and disproportional effort/outcome ratio. By defining the inputs beforehand, both parties can align expectations on importance and effort.
Not being aligned on the outcome is a recipe for reduced autonomy. The delegator is pushed to delve into details. All the complexity of the problem at hand becomes the main subject in conversations rather than how to maximise the outcome. The delegatee gets squeezed into mostly execution and loses autonomy.
By defining precise inputs and outcomes, you set boundaries of the problem, which defines a cleaner contract between parties. As you shift accountability and autonomy to the delegatee, the challenge becomes setting them up for success.
§Manage risk with the delegatee, not for them
Risk management is a fundamental aspect of delegation. As risks emerge, it's essential to not jump straight to intervention as it comes at a very high cost in multiple ways.
One common failure mode for delegation is offering advice you're not asked for. As much as it may come from a place of care and protection, it will take away from both autonomy and accountability, especially given a situation under pressure. The delegatee is very likely to take the delegator's advice much more seriously in such scenarios.
The alternative I've found is to manage risk with the delegatee instead. Assuming you haven't set up the delegatee for failure by delegating something much beyond their task-relevant maturity, and that you delegated the entire problem rather than a black-box chunk of the solution to the problem, they are in a better position to make decisions. In such cases, you can manage risk with them rather than for them by being curious, asking questions, and supporting them to reach their conclusions.
This set of principles is notably biased towards successful scenarios. Things don't always go as planned. When that happens, good leaders make people feel like they have a safety net and may intervene if the situation requires; but most importantly, they provide the right combination of learning and support people need to grow and succeed next time.