How an Effective Delegation Looks Like

Effective delegation enables the team and creates positive culture

If engineering leaders want to scale their impact, they naturally delegate smaller tasks to the team. However, poor delegation can lead to frustration and a toxic culture. On the other hand, effective delegation can help enable the team to build a positive culture.

Today, we are very lucky to have Artur Henriques as our guest writer. He shares his journey from an overwhelmed tech lead to an effective engineering leader through delegation. He breaks down common delegation pitfalls and provides a framework for doing it right.

I hope you like the stories and insights on today’s post, and feel free to share your views and comments below!

Artur is the author of The Long Missing SoW newsletter, which focuses on Leadership and Project Management with a special emphasis on IT. With over a decade of experience managing IT projects and teams, Artur uses his newsletter to share lessons learned and insights with those curious about the rollercoaster world of management.

Let’s Start

Hello everyone, my name is Artur Henriques and I want to thank Adler for this opportunity. I am the writer for The Long Missing SoW, which covers a lot of topics regarding IT Leadership and Management.

Let me start by sharing a story with you. The moment when I got my first promotion, I was then the Tech Lead for a Software Development team, building a web portal for our institutional clients (B2B). With the promotion, I got loads of impostor syndrome attached to the nomination. Not only was I far from being as good technically as other Tech Leads in the company, but some months before, someone far more knowledgeable than me was leading the same team.

The reason I took the role is because I wanted to shift my career into management, and at the time, this was the only step in that direction. I had completed several project management certifications and leadership workshops, and I felt ready to take on bigger responsibilities. However before that moment arrived, I needed, for example, to tackle with Infrastructure teams about how to set up new Application Servers I barely knew how it worked. Eventually, my grasp of the topics increased, and with that, my workload as well.

Eventually, the tasks I wanted were finally arriving. I was asked to plan releases and prepare critical documents and workshops with senior management and clients. It was finally happening. The problem: I didn’t have time, because I had so many other important topics to address with the application.

At the time, In a conversation with my Manager, he told me the tasks that we do today will be our role tomorrow. If today I am doing a lot of technical day-to-day work, tomorrow I will continue to be a technical leader. However, if I started to do management work today, tomorrow I would become the Manager, as I was aiming for. I was puzzled as to how to put the advice into practice because everything was so important. This is when I was introduced to delegation.

A Bad Form of Delegation

Delegation is very easy in theory. I have a series of tasks, I choose which ones I should do and which I want to pass on to someone else. The funny thing about delegation is that we don’t need to be a Manager to delegate. Let’s imagine that a new intern arrives on the team. I guarantee that in 8 hours, the team will magically sort out all the boring tasks to pass on to the intern. Was this the reason we created an internship position on the team? If the answer is yes, the team is losing opportunities. All my internships are used to develop new proof-of-concepts and test new ideas. Delegation should be more than passing tasks someone doesn’t want to perform. We have AI for that now.

Symptoms of Bad Delegation

One of the wonders of the modern corporate world is the creation of ICs (Individual Contributors). They are everywhere and sometimes, they are key to putting projects in motion that otherwise would be stuck on paperwork forever. They typically have a lot of knowledge and help the company to accomplish a set of targets. When those targets are being achieved, is normal to provide more “friends” to the IC, transforming the “poor fellow” into a team leader. For some, they are victims of their success and they have no desire to lead anyone. Since they are now a “team”, the capacity is increased and probably the scope as well. The ex-IC now is forced to delegate, due to the sheer amount of work and deadlines. So, as typically happens, the ex-IC starts to pass less desirable tasks to the new padawans.

Without proper context and knowledge transfer, the ex-IC starts to become angry with the results. Now there is an overall feeling that the team is not helping and the ex-IC is losing more time than before to correct those errors. This becomes a continuous cycle and the IC is now a difficult person to work with. This is not a sign of a good team relationship and dynamics. The root cause of all this, is that only the task was given, leaving aside the accountability or even the overall context.

How to delegate effectively?

1 - Start With Why

If we are asked to do a task blindly, we cannot adjust in case of an event that potentially can hurt the project. Simply because we were asked to do something in the form of a recipe. If the recipe says we need to use flour, we take the flour that is available to us without realizing it is self-raising instead of plain T-65. When the product of our hard work goes to the oven, we realize the cake overflows the container. Now, our ex-IC from the previous example needs to add a little detail to the recipe: the type of flour. And this will continue in a continuum because it is simply impossible to anticipate everything that could potentially go wrong.

It makes it easier for everyone if we explain why a certain task is done, and explain the context of it. The Padawans can learn by asking questions and sharing previous experiences and insights. Understanding the context of a task and why is designed like that can be key to anticipating potential problems, especially when we are working in an ever-changing context. Companies are not in a static environment where each variable can be controlled. Weird things happen every day, and we need to know if those events are impactful or not in the task’s output.

2 - Delegate the Accountability

Once a task is given, the Padawan is now the proprietor of all the merits and good decisions forward. This is key for the person to understand who is responsible for pushing a task forward and who needs to communicate with the stakeholders about outcomes and forthcoming events that might impact a given task. This builds a level of trust between team members. Good professionals take pride in their work and accountability is something taken very seriously.

It helps the team members improve their work, and feel more confident when given more challenging tasks. In some cases, they might become a superstar in the organization and you might be the one who discovered a key talent for the company. Providing accountability is a key factor for professional growth and overall project success.

3 - Providing Space For Failure

As it goes for Knowledge Management, it is important to have some space to make some mistakes and course corrections. It’s all part of the growing and learning process. Any expert in any situation was eventually a junior. To progress in the seniority ladder, one needs to try and error multiple ideas until one gets it right. This is how we all grew, and for sure if all have some incredible mistakes to share over a beer. However, the key is to have control of those mistakes. We cannot let someone go to a catastrophic event and eat our popcorn while watching the poor guy fail. Needs to be controlled situations, where the person has the maturity, skillsets, and conditions to pull it through, and if mistakes are done, are manageable.

Some years ago a new Business Analyst in one of my teams was energetically proposing how we should put in place a Confluence page in a certain way, and have it to be the main knowledge hub for the team. An interesting proposal to link JIRA tickets and documentation. If followed by everyone it would be a great help for the team. Because I knew the company, and I had implemented similar practices in the past, I shared my little hope because the company was too old-school in regards to some collaboration tools. I have experienced situations where the team had lost an entire knowledge base, because the platform was discontinued overnight, without any chance of transitioning into other forms of documentation. Nevertheless, I agreed with him and warned him not to put too much hope into this idea. It was better than a fake promise of having it all sorted out in Word documents that no one updates. He executed the initiative well and communicated with the team. The solution was onboarded by other stakeholders who were working with us directly.

Overall a success! Hold and behold, we got the news the on-premises Jira platform was to be unplugged with any of its historical data to be saved. Let’s imagine the countless teams who had sprints worth of findings, and complete analysis written on those tickets, lost forever. But not us. Because we organized ourselves in such a way, the information was saved and continuously updated. I believe this platform is still being used today, despite all the years since. I guess the joke is on me. If we let others make what we foreseen to be a mistake, we can be surprised.

4 - Communicate Expectations

We always hope that we will work with colleagues who are interested and take the initiative. However, the reality might be much different. Tasks are assigned with the context and why we are proceeding in such a way, but, the execution is below par. That’s one of the reasons I like Agile so much. Those definitions of Done and Acceptance Criteria can help provide visibility what is the quality standards we are expecting. The person who will execute the task needs to understand in which capacity the work is considered to be good.

In a project that had direct visibility to corporate clients, we needed to figure out a way to implement guidelines for a migration, which involved direct collaboration with some key clients. Communication was a big thing here. We needed to figure out delays for each step, how we would communicate with different clients, and implement feedback loops after the execution, the complete show. Because we needed to perform this multiple times for different types of clients, we decided to implement a system with template-like communications, to be reused rapidly and conveniently.

The task was given to a person responsible for setting in place this template. Not only she delivered a first draft, that was later on picked up, but she also proposed a new “governance” around the entire procedure. It was a delightful moment to see. I could go for a big holiday somewhere tropical, my job there was done.

5 - Setting for Success

If you managed to read until here, congratulations. Not only do you survive two stories, but also you get the most important topic: We need to delegate and set up for success. You might ask: Wait what? What about that Business Analyst story? The success of that story was about learning the environment we were working on, and I was the one getting the lesson. Here, the focus is to provide the resources and the context for someone to succeed in their task. There is no point in delegating a hot requirement analysis and being ready in 24 hours, about an entire new system that will generate payments. Right?

When the task is delegated, our colleague might have further questions and would need the right contacts to get those answers, as well as having the appropriate tools. There is no point in asking a developer to find bottlenecks in an application’s performance while using VSCode alone. People need to have the right tools to succeed. The same way the person who delegates would like to have.

As Managers, we should provide those conditions while delegating. Helping our team succeed should be our number one focus.

Last Words

Really appreciate Artur for sharing his insights and experience. Remember to check out his newsletter The Long Missing SoW.

---

Thank you for reading the post!

❤️ Click the like button if you like this article.

🔁 Share this post to help others find it.

Resources

Tokyo Tech Lead is a blog/newsletter for engineering leaders. Check out this overview guide for all resources it provides.

Guest Post Opportunities

If you are interested in writing for Tokyo Tech Lead, check this guideline post and let’s build something together!

Contact

You can find me on LinkedIn or Substack.

If you want more content like this, consider subscribing to my newsletter.

See you in the next post!