The art of proper delegation
I am writing this entry to share my learnings during the Manager Development Experience in adidas. I will not synthetize in this post all the learning obtained during these months, instead, I will focus on the workout that was more impactful for me. In this case, delegation; or, let me refine it, proper delegation. I will list some of the themes captured during the reflection, when I was getting documentation about the topic. I hope this can be interesting for you as it was for me.
First of all, I have to admit that I’ve always been quite sceptical with this kind of programs. I’ve been a developer for the most part of my career; when you are on the technical part of this industry, it is very easy to underestimate the value of the management; or, in some circles, consider it as the enemy, same as issue trackers. While I am getting older, I consolidate the idea that, the richer your perspective, more impactful you will be in your role. In other words, if you have been working in management for some years, you would be a better individual contributor and viceversa. I am learning that enabling teams has a science behind, same as the hands-on work, perhaps the main difference is how deferred is the visibility of the results, hence, the gratification.
The other preconception that you need to fight against in order to extract some benefits of these programs is considering everything obvious or “already known”. At the end, if something is obvious for you today it is because someone told you the same in the past; be humble and openminded.
Why
Let’s review the basic motivations that makes so important to delegate.
- The obvious, scalability for your company; if you, as an individual, centralise the job, eventually you will become a bottleneck in the process. I will quote my former manager, Fernando Cornago: “make yourself redundant to do the next thing”. This sentence illustrates perfectly the mindset of the enabler.
- The ‘ not that obvious ‘, but definitely more important in the long-run for the company, gratification, happiness and engagement of the team.
Autonomy — Mastery — Purpose
To extend the second point I will use the concept elaborated by Daniel H. Pink in his book ‘Drive’ where the key drivers for motivation are:
Autonomy — Our desire to be self directed. It increases engagement over compliance.
Mastery — The urge to get better skills.
Purpose — The desire to do something that has meaning and is important.
I truly believe that these are the ingredients to have good performance, engagement and happiness as employee.
Autonomy is strictly linked to delegation; if you delegate properly, the team will feel autonomous and engaged. I would go one step further by putting this in form of the Maslow’s pyramid. I am not structuring this way to make it proportional to the importance, the intention is to illustrate the sequentiality in the process: first of all you need to understand your purpose, that’s the initial pre-condition. The next step will be having autonomy to execute your purpose. Once you have the basic foundations, you will invest in your proficiency to do it.
Focus more on ‘the why’ and ‘the what’, less on ‘the how
Very often, technical people like me who move into management, have one characteristic in common that is really valued in technical implementation but could be a limiting factor in leadership and management: perfectionism. When you are developing one application, this corner case that is not covered by one unit test… just one little error, can imply the complete failure of the system; whereas, when your duty is enabling, defining processes, those edge scenarios rarely make the difference. Nevertheless, it is important not to confuse perfectionism with professionalism. Pareto’s principle illustrates perfectly this idea — “roughly 80% of the effects come from 20% of the causes”; in our case, 80% of the results as manager, comes from 20% of the effort.
At this point you can think, ok, cool, what has perfectionism to do with delegation? Well, if you’re a perfectionist, most likely you will tend to over-control every aspect, and this could tend to micromanagement, we have just found the first obstacle on the road. As a leader, you should start by setting up clarity with ‘Why‘, which connects with your purpose, as explained before. Then, you should put your effort in the ‘What’ you want to be delivered, not in the ‘How’, giving this autonomy to your team on the implementation. We can use again Pareto’s numbers: spend 80% of your time defining the purpose and the expectations and leave 20% to track the execution.
Impostor syndrome
It is very typical to encounter one enemy in the way to proper delegation: impostor syndrome. Sentences like: “what am I doing as manager? What are my merits? Am I a fraud? I am finishing the day and I have not done anything yet! “. It is normal, that is human… You have to be very cautious with these internal dialogues that are toxic and can lead to micromanagement, which is exactly what we are trying to avoid.
People in management positions can have some “attack of utility” where they jump to implement some work that was delegated — or, what can be more noxious, invest their time mainly in follow-up meetings to have the feeling of being useful. I am not saying that tracking is not needed, moreover it is one of the basic ideas of agile methodologies, but over-tracking is one bad symptom, same as over-reporting.
Be confident, understand your position and link your value to your purpose.
Build a delegable environment
So far, if you are part of the sceptical group, you may think that I am covering here the happy path — and that’s a fair statement. In order to be able to delegate we need to build a delegable environment and that’s not easy, nor fast. You need the proper individuals and time.
For the first condition, there is not magic formula, just the usual suspects when working with humans: emotional intelligence, empathy and knowing them well. There will be team members more or less engaged, this is the first item to focus as manager, to create interest.
We are doing software, that is a creative and intellectual process; therefore, one team needs stability and time to be delegable — understand the purpose, the idiosyncrasies of the group of people that form the team and the relationship among them. It comes with time where the team is mature enough to consider it completely delegable.
Psychological safety
It seems obvious, but everyone in the team should be safe enough to express their ideas, to make mistakes; otherwise, this lack of security will break any notion of being autonomous. Lead by example to gain respect, never intimidation.
Select the timing
For some members of the group, it could be a problem if you delegate something that they are not prepared to tackle — perhaps in those cases, you need to balance, and invest more time in short iterations with them not to impact their self-confidence. Adjust the exposure, otherwise the result will be the opposite to the desired. There is one secret that works surprisingly well: speaking ;) Open communication is the best way to handle these situations. The foundation for this point is precisely the previous point, psychological safety.
Invest on the vision
Setting the vision scales better than dictating what to do; if the vision is not clear, autonomy becomes dangerous.
Wrapping up
I name this post the art of proper delegation because it is not easy to find the balance that I’ve been describing during this post, it is quite complex. There are multiple nuances to consider when applying these ideas. When working with people, and their unpredictable nature, intuition and common sense are definitely more important than any set of rules; however, it is important to be clear on the style, vision, and to know what other people have studied related to this matter.
And, of course, be humble and never stop learning and evolving, perhaps my team is thinking when reading it, that I am not doing what I write ;) I am trying guys! :) I hope you like it and if you have any feedback about it, just reach out to me in any social media ;)
Originally published at https://pelayuko.github.io on June 28, 2020.